Re: vs Ada - Don't forget the prime directive!

[erwin@trwacs.UUCP (Harry Erwin)]

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