In article <5mbe7m$s3...@goanna.cs.rmit.edu.au>, Richard A. O'Keefe wrote: >>It says almost nothign about C++. Instead, you're just showing how >>inefficient STL is.
>I can't win. Some people bash me for not understanding that Stepanov >is one of the world's greatest programmers, so that any efficiency >problems _must_ be because I'm using a bad compiler. Now you are bashing >me for not understanding that Stepanov is not a good programmer.
Um, a valid C program is a valid C++ program. Your results showed better results for C than for C++. On many systems, the exact same executable is used to compile C and C++. The fault then probably does not fall with the C++ language, but in how it is used. My point is that if a custom library were used instead of STL, that much better performance could have resulted.
>I've said it several times. I don't *CARE* where the fault lies. >Whether it is C++ in general, the STL, the compiler, or invisible >blue monkeys stealing cycles, the question I was interested in was
>"Stepanov wants to provide the world with an *efficient* generic > library. He claims that C++ is the only language available which > comes close to letting him express his ideas (although he does NOT > claim it is perfect). Very well, *DID* C++ let him provide *ME* > with an efficient library?"
>The evidence is that it _didn't_.
Again, my point is that the evidence isn't valid. STL is arguably not a part of C++; and even if it is, it's not mandatory that users use it. The evidence you have is that *one* library does not provide efficiency, it says nothing about what other libraries might do, or that the library could not be used in more efficient ways.
You didn't highlight the word "him". Is your whole contention just that he personally didn't do it? I can agree with that. But the way things are worded, at least on first read, it sounded more like you were saying that the evidence shows C++ was at fault.
>>The big drawback is that, when used in the >>fashionably correct manner, STL spends lots of time copying values.
>Not this test program, no. Remember, it was sorting LISTS. The bulk >of the time went on sorting a list. There is no reason for it to do >ANY copying in that phase, and as far as I can tell from reading the >g++ headers, it doesn't.
Hmm, you could be right. But there are a lot of places that do copying or constructing behind the scenes that aren't readily apparent. Ie, moving an element from one list to another involves copying! It would be interesting to put some instrumentation into the copy constructor and assignment operator to see how often they're called, or to have a list of pointers and see if there's any difference.
>Now, if you had said that vector sorting in C++ is inefficient compared >with list sorting because of the need to call swap() operations, I'd >have gone along with that.
I haven't spent the time to fully grok algo.h, but iter_swap appears to do full copying when used with list iterators (ie, the nodes themselves aren't swapped, the .data field is what's swapped); and iter_swap appears essential to sort().
Iter_swap has T tmp = *a; *a = *b; *b = tmp;
Now, "*a" will be the iterator's operator*(), which returns a reference to the node's data (of type T). Expanding the inline functions, the compiler is left with something like: T tmp = *a.data; *a.data = *b.data; *b.data = tmp; And that has to do a copy three times. This is reasonably efficient if "T" is a pointer, but can be very slow if "T" is a class. If "T" is a string, it'll do allocation/deallocation as well.
I could be wrong, but this is what I get from reading the code quickly.
Richard A. O'Keefe wrote: > Come now. How many times do I have to say that my aim was to test > doing something a certain _way_? sort/sort/merge is a paradigm of > great importance.
I agree that sort/sort/merge is a very important sequence and it must be done efficiently in C++/STL. But you did NOT test this sequence. You tested "sort & remove duplicates" in C/Scheme versus "sort with duplicates" followed by "remove duplicates" in C++. Surely, you would agree that the latter is much slower. You said you did it because STL did not provide the means to do it in one step. This is *very wrong*. STL not only provides such algorithm, but actually *encourages* users to use this more efficient algorithms instead of the slower algorithm you used. This feature is provided by the (sorted) set container. Set is strictly better approach than list in this case because it has all list's functionality plus efficiency for sorting with removal of duplicates. STL design assumes that you always choose the best container for your needs. Hence, it does not provide algorithms tailored containers inappropriate for the task, but rather forces the user to work with the correct container. If you *did need* a list in your problem, use it. But before you do "sort removing duplicates", convert list to set. And then, *if needed* convert it back.
As an example of how this approach works, see my posting about hash_sets in this thread. When trying to rewrite your algorithm to use hash sets, I made *exactly* the same error as you did running "sort-unique" on list. I rewrote an algorithm set_difference to work on hash_sets, only to see that STL's idea "convert to set, do set_difference, convert back if you need" is more efficient. I have been using STL for 2 months only, hence such errors.
> 1) I have repeatedly stated that the documention I was working from when > I wrote my test code was the April 1995 draft of the C++ standard.
Well, why do you work from a Draft Standard? You can refer to it in cases of ambiguity about what is considered portable, and what is not. In you normal work, however, you should use the documentation provided by the vendor who supplied your library/compiler/etc (unless the vendor guarantees full compliance with the standard, which no current compiler does). GNU, being a free compiler, has limited documentation. If you use it, you are supposed to either learn its features by trial and error, or by reading newsgroups, etc. But even in the free domain, there is an implementation of STL with very good quality documentation (SGI STL adapted for various compilers- you have been already referred to it).
> 2) Anyone who has some experience with STL will be aware that the set > class template, whatever its other merits, had at least in that draft > very few operations on whole sets.
That is wrong. You have few *member functions* on sets. But several generic algorithms work on sets. Particularly, set_difference works very efficiently on sets (see 25.3.5.4, if you really want to use the Standard).
> sets?) From the documentation available to me, I didn't really know > if I _could_ convert a set to a list the right way: is it guaranteed > that a forward iterator over a set will deliver elements in strictly > increasing order? If so, is it guaranteed to take O(N) time, or might > it be O(NlgN) or what?
Yes, it's said in any documentation on sets I've ever seen. Including in Draft Standard, 23.3.3 (reversible container implies O(N) for traversal, sorted container implies delivering elements in ascending order).
> I don't know whether this _must_ work or just works by accident.
You should use inserter initialised to end():
..., inserter(setResult, setResult.end()))
instead of back_inserter. It's guaranteed to work because of what I said above and because of the definition of inserter. It's also the first example of usage of sets in at least one documentation and two tutorials on STL. "RTFM" applies to libraries no less than to games.
> I don't know whether there is some way for the last argument to > say "insert into a set, not a sequence". I would _much_ rather > say > DF = set_difference(set1, set2);
Assignment is inefficient; you first build an object, and then copy it to another. STL puts output directly to DF by asking you to supply to it iterator to DF.
> or even, > set1.difference(set2);
The algorithms set_difference is generic, and it is not intuitive to define a generic algorithms as member fn.
> 3) My original aim as stated was to try out the generic _sequence_ > operations in <algorithm>. A program working on sets would not be > testing those operations.
As I said above, STL does not have *sequence* operations for the purpose of showing off how efficient it is with sequences. It has only those sequence operations that make sense for real programming. If it knows that an operation will be more efficient if you convert the sequence to, say, a sorted container, do the operation, and convert back, it tries to force the user to apply this approach.
This convert->run algorithm->convert is not *always* more efficient in case of simple sort, so a version of sort *is* provided for lists. But it is *always* more efficient for "sort&remove duplicates", where there are many identical items. I ran my version of C++ code on 40 MB and 10 MB files, and got even stronger results in support of what I say than with 1 MB files you use.
> Ok, now I've managed to get it working. Here are my results for > building a set as you go, flattening that to a list, and taking the > set difference of two lists.
You should not flatten to a list before taking set_difference. It would only be a small improvement, though, since the results are already rather small in size.
> My code reported above still uses <string.h>. But I repeat, that is > part of the draft standard for the language, and has been for more than > two years. I don't _care_ whether the compilers aren't up to it, or the > libraries aren't any good yet, or whether the interface specified in the > draft standard necessitates high overheads, the C++ *systems* available > to me either don't conform to the standard or don't have efficient strings.
You should not use string.h strings. You should const char*. There is no reason in the world to use complex strings in this case. string.h is there for you when you need it. const char* has NOT been deprecated by C++ standard, and it is even DIRECTLY supported by STL. Your usage of string.h here is similar to using -g switch when compiling a program, and then comparing it with ones compiled with -O5.
> THIS MAKES THE TEST AGAINST THE STL UNFAIR, in that it isn't the STL's > fault if strings are slow. But it _is_ a property of the STL that I have > to use C++ in order to use it, so to that extent it _is_ the STL's fault > if I have to use a language processor with slow strings.
This is wrong. STL fully supports const char*, as just any other type. Moreover, in SGI STL there are even predefined (for your convenience) hash functions specifically for const char*.
Rainer Joswig wrote: > Well, AT&T was doing a switching system in Lisp and another one > in C++. The C++ system did take a lot more resources (it was > done as a production system). The Lisp version was more > like a research project (let's see what we can do). As it > turned out the Lisp version did have more functionality > at comparable speed and was *much* cheaper to built.
> This was a large project (if I remember correct, up to 100 people were > working on the switch based on Lisp). It did touch areas like real-time GC, > OODBMs, fault tolerance, the system should be down in the > range of a minute per year, etc.
> The group has reported about that publicly and they seemed a bit > frustrated that despite the clear superiority of their switch, > the company still wanted to market the system based on C++.
This is *very* interesting. Do you know where I can find more detailed information about this?
cosc1...@Bayou.UH.EDU (cosc1...@bayou.uh.edu) writes: >Jay Martin (jmar...@cs.ucla.edu) wrote: >: jos...@lavielle.com (Rainer Joswig) writes: >: >In article <BITMEADC.97May20111...@Alcatel.com.au>, >: >Chris.Bitm...@Alcatel.com.au wrote: >[Snip] >: >> Well, the research papers give the evidence. What more do you want? >: There are no such research papers. >There have been comparative studies of C++ vs. (among other things) >Ada, Haskell and Common Lisp.
If you mean "Haskell vs Ada vs C++ vs Awk vs... An Experiment in Software Prototyping Productivity" by Hudak and Jones, then I am not impressed since this "definitive study" is about prototyping 85 line Haskell programs. Its sickening that after 30 years this is all Computer Science has accomplished.
> In article <5mbkt8$1...@uni.library.ucla.edu>, Jay Martin wrote: > >So such comparison should be based on a > >reasonably large and long projects where long term maintanance is of > >central concern and with programmers that not at some the extreme part > >of the bell curve.
> I will first admit that I have only worked at (and am working) one > site that sold commercial software. Long term maintenance is > important - but it is not practiced! There more of a feeling of > "rush it out the door" here than when I was in academia or at a > commercial research environment. Some programmers want to have more > discipline, but can't.
The reasons are pretty obvious, just to start another long, drawn out, and meaningless argument ... :-0
The reason is that you cannot sell quality to most customers of software. Quality is not quantifiable in such a way as to be externally verifiable. And customers are generally incapable of verifying it themselves, since (if they had that skill) they could right it themselves probably and make the money for themselves.
Without this ability to sell the quality of one's architecture, what is the likely outcome? Basically its exactly what we see, where the internal architecture and the quality of the software is forced to take a distant second or third or fourth to features, political strategic decisions from on high, and so forth.
I think it sucks too, but I'm not sure what to do about it. There are obviously some customers who you can sell quality to, but the shrink wrapped market certainly ain't among them as far as I can tell. To the end user, it can be band-aided and glued together internally as long as it looks pretty and does not crash too often. So ad hoc fixes are generally done instead of fundamental improvement, every one of which degrades the overall quality and stability of the product.
Jay> [ ... ] Of course, I am talking about serious software engineering Jay> efforts not prototyping.
Of course, that allows you to claim that pretty much any serious software engineering effort done with functional languages or Lisp is merely prototyping.
Jay> So such comparison should be based on a reasonably large and long Jay> projects where long term maintanance is of central concern and Jay> with programmers that not at some the extreme part of the bell Jay> curve.
There, Ericsson's experience is bound to me more significant than the above reference. Someone just posted on this. The above reference reports on experience (albeit in Haskell) with both expert and novice programmers. Interestingly, there was almost no difference in productivity.
There *is* evidence however on what takes up the most time in software maintenance in C/C++ projects. Around 35% of all bugs in C/C++ development come from memory problems that can't arise in safe languages. The follow-up costs seems to be even higher in proportion. We haven't even started talking about other factors, such as decent, expressive type systems, proper polymorpism, higher-order abstraction or modularization. The above data is from a '95 PLDI tutorial by John Ellis. I could probably dig up a reference if necessary.
-- Cheers =3D8-} Mike Friede, V=F6lkerverst=E4ndigung und =FCberhaupt blabla
>>There are research papers that show Lisp giving much higher >>productivity than C++.
>Then kindly someone point me to a web site with this glorious >evidence. I have never seen serious language productivity research >and it was my opinion that CS academia was not going to do it anytime >soon.
Here is one example of such research. Of course no one research paper is going to satisfy everyone's questions or concerns. I think there is enough information in this paper though to draw *some* fairly significant conclusions, or at least provides the beginning of some hard empirical evidence. Certainly much more than anything put forward in this debate so far.
* Max Moroz -> Richard A. O'Keefe | Well, why do you work from a Draft Standard? You can refer to it in | cases of ambiguity about what is considered portable, and what is not. | In you normal work, however, you should use the documentation provided by | the vendor who supplied your library/compiler/etc (unless the vendor | guarantees full compliance with the standard, which no current compiler | does).
I can't speak for Richard, but I prefer to write my software in a language, not a particular product. I strongly prefer knowing how things should work, what constructs should mean, etc, and then augment this by a list of implementation restrictions, bugs, and other deviations. plus a full specification of the (inevitable) implementation-defined features. if this is impossible for some given language and one is expected to keep up with an increasingly erratic set of random features, I consider it a waste of my time to learn to use just a (buggy) product, except in some very special cases (like Emacs and experimental languages).
#\Erik -- if we work harder, will obsolescence be farther ahead or closer?
> >Well, AT&T was doing a switching system in Lisp and another one > >in C++. The C++ system did take a lot more resources (it was > >done as a production system). The Lisp version was more > >like a research project (let's see what we can do). As it > >turned out the Lisp version did have more functionality > >at comparable speed and was *much* cheaper to built.
> This is total heresay and of course is pointless as it says nothing > about the the long term maintanance which usually consists of like 80% > of the project costs. If it was a research project, then it was > highly likely that it was a poorly designed piece of crap. Most > researchers just don't have the discipline to be good software > engineers.
Funny. You know, contrary to the apparent beliefs of some people in this thread, there are imaginative programmers in other parts of the world than the USA, and even companies other than Lucent in the telcom switch business.
Eriksson has started programming their exchanges in Erlang, a dynamically typed functional programming language (i.e., like scheme) with facilities for parallelism. They do everything except hard realtime stuff in it.
The reason is that after long study, they found that correct code written in a functional style was easier to write, and easier to maintain.
In fact I have a paper currently sitting on my desk `The concurrent programming language Erlang - An overview', from http://www.ericsson.se/cslab/~dan/
Opening paragraph:
Erlang is the result of a consistent search for a better programming tool for telecom applications. At the beginning of the 1980's a large number of programming languages was tested for controlling a small telephone exchange. From the experiments, it became quite clear the symbolic programming lanuages, such as Lisp nad Prolog produced the shortest code'
That `quite clear' is very emphatic.
I think this, and the other Erlang papers might make educational reading for some people in this thread.
Perhaps, if you'll forgive the speculation aloud, Eriksson, which is not *quite* as big, rich and dominant as Lucent, thinks it needs a competitive edge, and can't affort to indulge the conservativeness of some of its programmers to the same extent.
Of course the only way to decide these things really is in practice, so...
> In article <5mbkt8$1...@uni.library.ucla.edu>, Jay Martin wrote: > >So such comparison should be based on a > >reasonably large and long projects where long term maintanance is of > >central concern and with programmers that not at some the extreme part > >of the bell curve.
Long-term maintenance is primarily a matter of careful planning and structuring - it can be supported in many different languages.
At Ericsson, we have plenty of evidence to support the claim that The Erlang language supports and encourages the writing of maintainable code. If you want specific data, contact <sa...@erlang.ericsson.se>. For obvious reasons, not all information on our product development is available to the public.
If you believe our 300+ Erlang programmers are all at the extreme end of the bell curve, you should buy lots of Ericsson stock! (well... you _should_ buy lots of Ericsson stock.)
> I will first admit that I have only worked at (and am working) one > site that sold commercial software. Long term maintenance is > important - but it is not practiced! There more of a feeling of > "rush it out the door" here than when I was in academia or at a > commercial research environment. [rest deleted]
The importance of maintainable software varies in different fields. In a product with an expected shelf life of a few months to a few years, maintenance is not a vital factor - code reuse probably still is.
When building a telephone switch, which might be supported for decades (e.g. the Ericsson AXE switch), maintenance is essential. It would surprise me to learn that the researchers at AT&T didn't factor in maintenance as a vital design parameter when prototyping a switch in LISP.
-- Ulf Wiger, Chief Designer ETX/DN/XBS <etxu...@etxb.ericsson.se> Ericsson Telecom AB tfn: +46 8 719 81 95 Varuvägen 9, Älvsjö mob: +46 70 519 81 95 S-126 25 Stockholm, Sweden fax: +46 8 719 43 44
In article <337d90f9.7857...@news.demon.co.uk>, Alaric B. Williams <ala...@abwillms.demon.co.uk> wrote:
> They weren't. They just had a good hardware architecture.
Not really. On the first 68000 based amigas the graphics hardware was a win, but not a huge win, and for the 68020 based ones the CPU was better than the blitter.
> The OS had no form of memory protection,
This is true, but as proven by such real-time microkernel operating systems such as QNX you can get the same sort of performance without sacrificing memory protection. The original Amiga operating system had protected memory support (that's what MEMF_PUBLIC was for) but the initial hardware didn't have any and backward compatibility issues kept them from implementing them with the limited resources Commodore had as it slid into bankruptcy.
And the resolution of the original Amiga video was much better than that of the other PCs of the same era. Again, a lack of resources kept them from progressing much beyond the original specs (though my Amiga 3000 supports 1280 by 512, which was pretty damn good for the time, and third party products went well beyond that).
In this discussion I'd put the Amiga users in the Lisp camp. The Wintels are MUCH more like C++, with layers of patches to cover up the original design decisions. -- The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II. Har du kramat din varg, idag? `-_-' Kulanu Kibo. Hail Eris! All Hail Discordia! Vi er alle Kibo. HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
> >Well, AT&T was doing a switching system in Lisp and another one > >in C++. The C++ system did take a lot more resources (it was > >done as a production system). The Lisp version was more > >like a research project (let's see what we can do). As it > >turned out the Lisp version did have more functionality > >at comparable speed and was *much* cheaper to built.
> This is total heresay and of course is pointless ....
Did you mean to write "hearsay" or "heresy?" I can't tell.
> If it was a research project, then it was > highly likely that it was a poorly designed piece of crap. Most > researchers just don't have the discipline to be good software > engineers.
Some researchers at least have enough discipline to communicate in a civil manner, and some of them in my experience write damn good software. Better than many commercial products in some cases, partly because the researchers might not be faced with unrealistic deadlines, scope creep, and all the other extraneous issues that often (usually?) attend commercial development projects.
> >This was a large project (if I remember correct, up to 100 people were > >working on the switch based on Lisp). It did touch areas like real-time GC, > >OODBMs, fault tolerance, the system should be down in the > >range of a minute per year, etc.
> Well it actually "touched" them, wow!
Brilliant retort. Do you have anything substantive to offer?
> >The group has reported about that publicly and they seemed a bit > >frustrated that despite the clear superiority of their switch, > >the company still wanted to market the system based on C++.
> Do to that software is a incredibly incompetent and religious field, we > have to wonder wether the group was the usual bunch zealot crackpots.
[...] >Well, AT&T was doing a switching system in Lisp and another one >in C++. The C++ system did take a lot more resources (it was >done as a production system). The Lisp version was more >like a research project (let's see what we can do). As it >turned out the Lisp version did have more functionality >at comparable speed and was *much* cheaper to built.
This is total heresay
Negative. It existed, and probably still does. I worked for one of the contractors involved at the time it was going on, and worked on the OS portion.
and of course is pointless as it says nothing about the the long term maintanance which usually consists of like 80% of the project costs.
Maintenance cost was one of the reasons they decided to try something else (lisp!?! why would you want to use that??) in the first place. The existing C/C++ system was so difficult to maintain that it took a team of over a thousand people doing ongoing maintenance to stay on top of it. And any complex change was so risky that it was ages before it actually materialized in the released software.
If it was a research project, then it was highly likely that it was a poorly designed piece of crap. Most researchers just don't have the discipline to be good software engineers.
It's certainly true that some of the folks we worked with were more along the lines of researchers than engineers. (That seemed to be true of all their groups, for what it's worth) A bunch of the engineers were refugees from other switch groups.
>This was a large project (if I remember correct, up to 100 people were >working on the switch based on Lisp). It did touch areas like real-time GC, >OODBMs, fault tolerance, the system should be down in the >range of a minute per year, etc.
Well it actually "touched" them, wow!
Enough to make it work as a real-time system.
Sarcasm, while, amusing, doesn't do much to advance the debate, or get to the truth. Perhaps those aren't among your goals?
>The group has reported about that publicly and they seemed a bit >frustrated that despite the clear superiority of their switch, >the company still wanted to market the system based on C++.
Do to that software is a incredibly incompetent and religious field, we have to wonder wether the group was the usual bunch zealot crackpots.
They were serious, and they had technology that worked, for far less effort than the alternative.
My understanding was that upper management was basically completely unwilling to deploy anything not written in C (remember, big company, big company politics), so no matter what results were acheived, there was no chance that the stuff would be used for real. The fact is that it's a huge corporation, and it costs them essentially nothing to have lots of technology groups kicking around, whether they plan to use the results or not.
cosc1...@bayou.uh.edu <cosc1...@Bayou.UH.EDU> wrote: > I think the question goes further to "do we even need to obtain and > dereference them?". I'm using Scheme, and before that Haskell -- 2 > languages without pointers, and I've yet to run into a situation > where I even remotely missed them much less thought about them.
Last I checked, Scheme was a very close Lisp variant. Now, Lisp has pointers and pointer operations (CAR, CDR, RPLACA, RPLACD, ...). Doesn't Scheme? -- The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II. Har du kramat din varg, idag? `-_-' Kulanu Kibo. Hail Eris! All Hail Discordia! Vi er alle Kibo. HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
cosc1...@bayou.uh.edu <cosc1...@Bayou.UH.EDU> wrote: > First off, just so I know from where to discuss this, do you agree > at least that the number of assembly language programmers has > declined?
Has it?
Given the increase in the number of programmers, as computers are applied to new feilds of endeavour, a moderate increase in the number of programmers involved in the sort of project that assembly is suited for (which is about the same thing it was suited for 10 years ago) would look like a decrease by comparison.
-- The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II. Har du kramat din varg, idag? `-_-' Kulanu Kibo. Hail Eris! All Hail Discordia! Vi er alle Kibo. HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
In article <BITMEADC.97May26125...@Alcatel.com.au> Chris.Bitm...@Alcatel.com.au writes: > I think what the benchmark was designed to show, and what it had some > degree of success showing, was that many of the people who choose C++ > because they think that they need it for efficiency, are at best not > getting their priorities right, and at worst are just wrong.
But it doesn't show that. No single benchmark could.
Nor does it do what I thought it was intended to do, which was to refute the claim that C++ allows generic programs to run as fast as their hand-coded counterparts.
What it does do is compare programs written in Scheme and C++ that solve one specific problem. It is not clear that either of those programs is the most efficient that could be written in their respective languages, nor is it clear whether or not either of the compilers used have performance bugs.
I've seen examples of similar comparisons before. Typically, small tweaks in the programs in question can make large differences in the execution time, both in C++ and in other languages. So genuinely useful comparisons are hard to come by.
Moreover, truly fair benchmarks have to be run by someone who does not have a vested interest in any particular result. That is one reason I do not post benchmarks. -- --Andrew Koenig a...@research.att.com http://www.research.att.com/info/ark
In article <5mbhae$u...@goanna.cs.rmit.edu.au> o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
[a 346-line message, to which I do not have time to respond in detail, but of which I believe the main point is]
> Yeah, well, all I can say is that the test was actually written in the > expectation that it would show something very different. I found the > results *shockingly* different from what I had expected. It certainly > wasn't written with the intention of stressing whatever it is that it > does stress.
...
> - an experienced programmer wrote a program in three languages. > - the program is small, but follows an historically extremely important > outline: sort two sequences and merge them.
...
> - the results were shockingly different: 1:3:9 C:Scheme:C++ times.
...
> question is yes" is a triumph of faith over reason. I *tried* it. > It just plain DID NOT HAPPEN THAT WAY. C++ generic/C++ specific = 6/1.
If this is true -- that is, if what you think you are measuring is what you are actually measuring, then there is surely a performance bug somewhere.
It might be in the compiler, or in the particular implementation of STL, or elsewhere in the library, but something is definitely not working as it should.
If you had said `I don't want to use C++ because the compiler available to me has a serious performance bug,' I would have nothing to say. If you had proof that what looks like a bug is actually an intrinsic flaw in the language, then I would also have nothing to say.
But to dismiss the entire language because one implementation appears to have a performance bug that shows up in one test case is just silly. -- --Andrew Koenig a...@research.att.com http://www.research.att.com/info/ark
* Hans-Juergen Boehm | Thus it seems to me the Scheme to C++ comparisons using this benchmark | don't show much, as it stands. You either need to compare the fastest | possible programs to solve a given problem, or solutions based on exactly | the same algorithms and data structures.
other axes of comparison are certainly possible. for instance, you can give the same problem to top-notch (or even "average") programmers in each language and compare their results when they are "satisfied" with a solution, or give top-notch (or "average") programmers a specific time to solve the problem, and compare their results according to completeness, correctness, and execution speed.
choosing exactly the same algorithm and implementing it in different languages (ignoring the cost of implementing it) would obviously ignore _algorithmic_ advantages in one language over the other, or remove the meaning from the benchmark altogether.
#\Erik -- if we work harder, will obsolescence be farther ahead or closer?
a...@research.att.com (Andrew Koenig) writes: > If you had said `I don't want to use C++ because the compiler available > to me has a serious performance bug,' I would have nothing to say. > If you had proof that what looks like a bug is actually an > intrinsic flaw in the language, then I would also have nothing to say.
> But to dismiss the entire language because one implementation appears > to have a performance bug that shows up in one test case is just silly. > --
I don't think that Richard is dismissing the C++ language. This whole measurement thing has been blown up to silly proportions. This looks to me like a very simple empirical study (emphasis on _very simple_). People (not you of course) waltz over to comp.lang.lisp/scheme and make stupid/absurd claims about how much better C++ is than lisp/scheme from the one-dimensional point of view of efficiency. This is very silly in my opinion since we all know that for a large percentage of the complex applications out there, out of all possible paths through the code, only through profiling can you determine where to concentrate your efforts and that effort is usually concentrated in a small percentage of the code.
Anyway these people (I am trying to be polite) waltz in here and crosspost to most of the known universe that C++ is superior along the efficiency dimension. In addition Mr. Stepanov says that C++ is the only language in which he could effectively implement his ideas. So Mr. O'Keefe said to himself "OK self. Since all of these people make this claim about C++, I should be able to write a simple generic program in C++, scheme and maybe a couple of other languages and the C++ version should be clearly faster". He says this because people keep making this "Lisp is sooooo slow" claim and it doesn't matter that we point them to several Lisp and scheme implementations that are obviously _not_ slow. No matter that we point to this feature or that feature. It doesn't matter what we say, we are dammed if we do and dammed if we don't. So if C++ is that straightforward, one should be able to find a compiler that implements the language efficiently. In fact I ran his first example in DEC C++ v5.6 deleting one #include line. Seemed pretty quick. I know that it inlines pretty well. If you don't believe me, give me a snippet of code and Ill send you back the assembly file.
What he finds instead is that his program is slower in C++ with the compilers he has available and that one won't compile it at all! Now this is no less than what these whiners in the C++ camp do. Now of course this does not include you or Mr. Boehm, or Mr. Stepanov or Austen. What you guys would like to see is a complete study done. But that is not the point. With the sort of money that has been put into C++, I argue that if it was straightforward to compile generic C++ into very efficient code, it would be in every compiler, free, pay, whatever. What we see instead is that the language is tough to compile cleanly. Thats OK, lots of power, lots of trouble. But there is this perception that I can walk up to some drunk on the street and he will hand me a bottle and a blazingly fast C++ compiler. Whereas Mr. Siskind, not even working in his specialty, with no direct funding for this work, was able to write a Scheme compiler that competes with C on some programs and beat the pants off of the given C++ program. And that the language was so straightforward, that there was a little extra functionality in the Scheme code and it was still faster.
Mr. Stepanov claimed that C++ was the most effective language for writing his generic algorithm package. At first glance I dismissed that statement, but then I thought about it a bit. The conclusion that I have come to is that that may be true in a very restricted sense. Lisp+CLOS could do the exact same thing. The difference lies in the history of the languages. Since Mr. Stroustrup did not package a library with his implementation of C++, the field was wide open. Because you had nothing, one could do anything. With Lisp, CLOS did not get accepted until quite a few vendors, some of them pretty major like DEC for example had DEC Lisp for VAX/VMS, already had implementations out based on CLTL1. If the Lisp standards committee could have somehow forced all of the vendors to redo those implementations with CLOS throughout, it would have been pretty straightforward to add in generic functions to do what he wanted. If he felt that it was to slow, he could have used the MOP to make the metaclass more efficient. Instead Lisp has some 20 years of baggage that it still carries around (how many old-timers still use car/cdr instead of first/rest).
So All Mr. O'Keefe did was write some simple generic functions and compared. This is what thousands of small and big time C++ programmers do when they are telling their boss which C++ implementation is the best to buy. They don't have time to do extensive studies, they just believe the hype machines of the rags that run these stupid benchmarks which probably run nothing like the program they are designing, or run micro-benchmarks which either tell you everything or nothing at all, and then recomend which implementation to spend the next $30,000 on. He just extended the test to other languages. C++ happened to lose. Now the experts show up, with the whiners in the background yelling sic'em, and you would like a formal study done.
Ill tell you what, lets all take a year or so out of our product delivery schedules and design a fair test to compare the quality of languages across the board. OO, functional, both, neither, logical, all three, and assembly language too. Oops, my boss won't let me do that, he just wants me to pick out the best C++ implementation so that we can try to get this product out of the door. "Those other languages are too darn slow Reggie. Get your butt back to your desk and find me the best buzzword compliant, popular language implementation"(this is sarcasm ladies and gents). Back to small-time hacks and semi-meaningless micro-benchmarks. Let me know what the results are. Remember, it has to be a significant problem.
Turnabout _is_ fair play in this case. Jam Now _not_ Jam Later
P.S. This is not directed at you personally. I have lots of respect for you and the work you and BS and AS have done. It was because of you and C++ that I got a promotion! So I can't be that upset with what brung me to the dance. :-)
> In article <BITMEADC.97May26125...@Alcatel.com.au> Chris.Bitm...@Alcatel.com.au writes:
> > I think what the benchmark was designed to show, and what it had some > > degree of success showing, was that many of the people who choose C++ > > because they think that they need it for efficiency, are at best not > > getting their priorities right, and at worst are just wrong.
> What it does do is compare programs written in Scheme and C++ > that solve one specific problem. It is not clear that either of > those programs is the most efficient that could be written in > their respective languages, nor is it clear whether or not either of > the compilers used have performance bugs.
I think it has been established that the C++ program is NOT the most efficient way to solve the problem in C++. Two of us have posted much faster C++ solutions to the same problem, using either sets or vectors instead of lists. It also presumably does not use the same data structure as the Scheme program (the C++ code uses doubly linked lists, I would be amazed if the Scheme program did), nor does it use the same algorithm (duplicates eliminated early vs. late).
Thus it seems to me the Scheme to C++ comparisons using this benchmark don't show much, as it stands. You either need to compare the fastest possible programs to solve a given problem, or solutions based on exactly the same algorithms and data structures. (The latter is still tricky because Scheme implementations emphasize list handling, where C++ usually does better with arrays.) The current benchmark does neither, though it was an honest attempt to do the latter. Benchmarking is hard.
I haven't seen the C version, so I can't judge whether that's comparable to the others.
: > I think the question goes further to "do we even need to obtain and : > dereference them?". I'm using Scheme, and before that Haskell -- 2 : > languages without pointers, and I've yet to run into a situation : > where I even remotely missed them much less thought about them.
: Last I checked, Scheme was a very close Lisp variant. Now, Lisp has pointers : and pointer operations (CAR, CDR, RPLACA, RPLACD, ...). Doesn't Scheme?
However car, cdr, etc... implement their operations is a non-issue, what matters is what we are made to see -- and in this case, we never need to know that pointers are being dereferenced behind the scenes. This entire genre of operations is abstracted away from us, we are given a view of lists. This is what I meant by "dereferencing". I explained this in a previous post, but only after I managed to cloud the issue (I have a gift for being vague at the worst possible moments).
In any case I hope I made things clearer.
: -- : The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II. : Har du kramat din varg, idag? `-_-' Kulanu Kibo. : Hail Eris! All Hail Discordia! Vi er alle Kibo. : HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
> > question is yes" is a triumph of faith over reason. I *tried* it. > > It just plain DID NOT HAPPEN THAT WAY. C++ generic/C++ specific = 6/1.
> If this is true -- that is, if what you think you are measuring is what > you are actually measuring, then there is surely a performance bug somewhere.
> It might be in the compiler, or in the particular implementation of STL, > or elsewhere in the library, but something is definitely not working > as it should.
No, the "performance bug" is mostly in the source code. Several people have pointed to very clear misuse of STL features in the original code. Richard was objective and kind enough to partially correct C++ code as I suggested, and rerun it on his machine. He posted the results with the total time reduced 2.4 times. Obviously, improvements can also be made to Scheme and C code. But just as obviously, the results measure Richard's relative skills in the three languages much more than they measure anything about the languages themselves.
Also, if Richard went one step further and rerun the C++ coded with all obvious corrections I suggested, including the use of const char* instead of String to read in the input data, he would have obtained another improvement; my experience shows it to be about 1.4 times. Richard for some reason believes he must use String to test C++, while in this context the advantage of const char* is obvious, and nothing prohibits a C++ programmer from using it.
And if he went one *more* step further, and posted the C code he used, I am sure we would identify the source of the remaining performance difference. My guess is that after C and C++ codes are reasonably optimized, C++ code would be slower than C by a factor of not more than 2. More likely, C++ code would run *just as fast* as C.
> In article <5maer6$...@uni.library.ucla.edu>, jmar...@cs.ucla.edu (Jay > Martin) wrote: > The Lisp system worked. One person > told me that he phoned home to France using the switch.
Working means it works under full load, not for a call. Is there any experience under these conditions?
> - a number of special purpose processors doing the switching
Ok, so hardware did all the fast stuff and Lisp was the glue. There's no reason this could not work i'd imagine. I take it all the drivers, which a switch would have a lot of were not in lisp.
> One of the architecture problems they solved was the maintainability > of a system that should have no down time at all. So you could > reprogram the switch on the fly.
There would have to be some unavailabilty because of actively running code referencing changing code. In C++ you can download new programs and do a reboot, other parts of the system have to handle the load while this happens. Or you can download scripts which puts you back at lisp i'd guess.
Question 1: was the lisp used commerically available or was it home spun? If so it would be very difficult for your average shop to reproduce the results.
Question 2: how would it work in small memory footprint and anemic processor environments? A switch is going to have all the memory and processor it needs, an embedded toaster won't.
thanx
------------------------------------------------------------------ t...@possibility.com | I have no interest in any ship that http://www.possibility.com | does not sail fast, for I plan to go http://www.sendmecoffee.com | in harm's way. -- J.P. Jones
>There have been comparative studies of C++ vs. (among other things) >Ada, Haskell and Common Lisp.
If you mean "Haskell vs Ada vs C++ vs Awk vs... An Experiment in Software Prototyping Productivity" by Hudak and Jones, then I am not impressed since this "definitive study" is about prototyping 85 line Haskell programs. Its sickening that after 30 years this is all Computer Science has accomplished.
<Ranting looney personal attacks deleted>
I was about to delete those ranting looney wholesale attacks against academia and computer science, but then -- I wanted to put my reply in context.
It is true that the Haskell program was very short. The same was not true for the programs written in some of the other languages, including C++. Admittedly, though, the problem was not large to begin with (nobody has the resources to develop a complete telephone switch in 10 different languages only for the purpose of a comparison).
Anyway, nobody claimed that the study was "definitive". In fact, the authors were very careful to explain the scope and the limitations of the experiment. One can draw conclusions as one likes, but insulting statements like the above are clearly out of place.
By the way, if academia and computer science are so sickening, then why do you post from a UCLA Computer Science account?
