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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!trwacs!erwin From: erwin@trwacs.UUCP (Harry Erwin) Newsgroups: comp.lang.ada Subject: Re: vs Ada - Don't forget the prime directive! Message-ID: <313@trwacs.UUCP> Date: 19 Jun 91 11:57:53 GMT References: <9106151802.AA16989@zach.fit.edu> <311@trwacs.UUCP> <1991Jun18.040142.2616@netcom.COM> Organization: TRW Systems Division, Fairfax VA List-Id: jls@netcom.COM (Jim Showalter) writes: >>As a performance engineer, I find Ada unattractive. If the >>conversion ratio for C is 5 MLI per source statement, then >>Fortran generally comes in at 6-7 MLI and Ada at 10-12. >>And these source statements are no more powerful than >>C statements; there's just a lot more bounds checking, >>and other overhead, going on. >Uh, bounds checking is not generally regarded as "overhead": >many people prefer to think of it as the sort of thing that >helps prevent your expensive satellite from spiraling slowly >into the sun. Claiming that C is faster than Ada because C >doesn't deign to check whether or not it is attempting to >execute data (having walked a pointer off into hyperspace >silently) is not a very compelling argument for its use. Besides, >I can quite easily eliminate such "overhead" from Ada if I >am determined to make it execute as dangerously as C--it's >just that in Ada I'm at least given the CHOICE. Actually, the 10-12 MLI/statement is with error checking turned off. With it turned on, we're in the 15-20 range. The data are recent and for an efficient compiler. >As for the claim that the rest of the source statements are "no >more powerful than C statements", I beg to differ. Can you show >me the C statement equivalent of a task rendezvous, for example? The Ada task rendezvous is notorious in the performance engineering community as a feature to be avoided in real-time and near-real-time applications. I have written a set of C++ classes that give me a multi-tasking environment when I need it, and they're a lot more efficient than Ada. I don't usually use them, preferring instead to use the operating system tasking mechanism, but I will use them before I use Ada tasking. >>The machine architecture is deliberately hidden from the >>coder, >Thereby aiding portability, reuse, and maintenance--among the >stated goals of Ada. My experience is that hiding the machine architecture from the coder usually decreases the performance of the code by a factor of at least 5. >>These factors come together in code that >>will never be as efficient as the corresponding C code >>and that requires 10-20 times as many CPU cycles until >>tuned during integration and test. It's hard to overcome >>those handicaps. >Other than by, as you said one sentence earlier, tuning during >integration and test? Incidentally, I question your 10-20 X >figures. See other postings in this thread concerning the >relative speed of, for example, DEC Ada vs DEC C. The Ada >compilers keep speeding up, and in many cases I'm aware of >equal or exceed the speed of comparable C compilers. If your >data is more than a few years old, it is obsolete. If it >is current, I'd like more detail. The data are weeks to months old and generally proprietary. My experience over the last 12 years is that Ada, Pascal, and similar languages (CMS2, Modula-2, etc.) generate code that always has to be tuned in integration and test to overcome implementation inefficiencies. The performance improvement during tuning is almost always at least 10-to-1, and frequently reflects subtle characteristics of the hardware architecture, which those languages are intended to hide from the programmer. Tuning is less frequently needed for C code, and the inefficiencies to be overcome are significantly less. Hence, by using Ada, you're reducing your programming and maintenance costs (which are also programming costs) but decreasing your performance and increasing your integration and test costs (which is expensive anyway). You pays your money and takes your choice... -- Harry Erwin Internet: erwin@trwacs.fp.trw.com