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
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!mips!apple!netcomsv!jls
From: jls@netcom.COM (Jim Showalter)
Newsgroups: comp.lang.ada
Subject: Re: vs Ada - Don't forget the prime directive!
Message-ID: <1991Jun18.040142.2616@netcom.COM>
Date: 18 Jun 91 04:01:42 GMT
References: <9106151802.AA16989@zach.fit.edu> <311@trwacs.UUCP>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
List-Id: <comp.lang.ada>

>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.

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 machine architecture is deliberately hidden from the
>coder,

Thereby aiding portability, reuse, and maintenance--among the
stated goals of Ada.

>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.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *