From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: C/C++ knocks the crap out of Ada Date: 1996/03/23 Message-ID: #1/1 X-Deja-AN: 143884776 references: <9603041841.AA18366@eight-ball> <4hg318$nup@ra.nrl.navy.mil> <4j173h$lvo@oravannahka.Helsinki.FI> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-03-23T00:00:00+00:00 List-Id: Carl says "So, is C really so much more efficient than other languages (I do not question the efficiency of assembly, just C/C++) and is it not just a myth? Does anyone have figures on this? I don't think a difference of a few microseconds has any practical implications if that is what is referred to." There is no such language as C/C++ There are two completely different languages C and C++, the fact that there is a significant intersection (it's only an intersection, C is not a subset of C++) should not lead to confusing them into one language. If you are looking at C, then the answer is no, C is not much more efficient than other languages. This depends on implementations, not languages. For example, Phillippe Kahn of Borland once suprised a big meeting by noting that the fastest compiler for ANY langueg on the prime number sieve benchmark was Realia COBOL (I am talking not about compiler speed here, though Realia COBOL was and is the fastest compiler on the PC, but about performance of executable code). What are we to conclude from this? That COBOL is a more efficient language than C? Of course not! Just that the Realia COBOL compiler had a better code generator. In the case of Ada, and C, the performance varies. If you use the same code generator with similar code, then you get the same performance. Last year at the UK Ada meeting, someone came to me and reported (with an amazed tone) that Whetstone running on GNAT was comparable with Whetstone running with GCC C (and was incidentally better than any other Ada compiler he had tried). Fine, I was not surprised! What would have suprised me is if they had been different -- that could only be caused by a bug. There are still some bugs of this type around, where the GNAT/Ada performance is not what one would expect, but they are getting steadily fixed. Comparing C++ and Ada 95 wrt high level features like exceptions, dispatching, and finalization is MUCH harder here. In fact for such features, the restuts are even MORE likely to depend on implementatoin strategy and quality. You *can* make some theoretical observations on efficiency. For example, other things being equal, the obviously far superior aliasing information available in Ada, due to its strong typing, and lack of pointer punning, will give an advantage over C. However, things are almost never equal enough to actually measure these theoretical advantages. Another point that may make Ada seem slow is that it is a higher level language than C, and if you take advantage of high level features, you pay a price. For example, if you use Unbounded_Strings and compare it with do it yourself strings in C, with manual storage allocation, then you will find that the Ada is slower. THat's because there is an overhead to be paid for using high level features like the automatic finalization that is part of the Unbounded_Strings implementation. On th other hand, you have gained convenience and safety, which may well be worthwhile trade offs. I often find that Ada programmers are blissfully unaware of the consequences of the code they write. It is instructive to use the -gnatdg switch in GNAT which displays the low level generated code in a syntax close to normal Ada to understand the consequneces of the use of high level features.