[comp.lang.ada] Ada Code Efficiency

sampson@cod.nosc.mil (Charles H. Sampson) (02/23/91)

     A few weeks ago I used Cray Ada as an example to show that Ada is not an
inherently slow language; I said that the code produced by Cray Ada is outper-
forming that produced by Cray FORTRAN.

     This assessment was objected to by Phillipe Collard, the project manager
for Cray Ada at Telesoft.  He pointed out that in his presentation at Tri-Ada
'90 he only claimed that Cray Ada's code was outperforming Cray FORTRAN's on
two sets of benchmarks and that Cray Ada was still behind on scalar operations,
but catching up.  He furthermore stated that the primary thrust of the Cray Ada
effort to date has been to vectorize loops, which it is now doing as well as
Cray FORTRAN.  Only now are they beginning to concentrate on improving the
scalar code.

     It's certainly refreshing to meet someone so against vaporware that he
won't even let a disinterested third party do it for him, but I think Phil-
lipe's modesty is a bit excessive.  The two benchmarks in question are Whet-
stone and Dhrystone!

     I still think that Cray Ada is a good counterexample to the idea that Ada
code is inherently slow.  I'll wait for Telesoft to issue an official announce-
ment about the scalar code efficiency, rather than give out the current figure
that Phillipe gave me.  I see no reason why the final figure should be much
less than 100%.  If constraint checks are suppressed, to let Ada and FORTRAN
compete on equal terms, I would expect it to be so close to 100% that any dif-
ference is insignificant.

                               Charlie

mfeldman@seas.gwu.edu (Michael Feldman) (02/24/91)

In article <2860@cod.NOSC.MIL> sampson@cod.nosc.mil (Charles H. Sampson) writes:
>
>     I still think that Cray Ada is a good counterexample to the idea that Ada
>code is inherently slow.  I'll wait for Telesoft to issue an official announce-
>ment about the scalar code efficiency, rather than give out the current figure
>that Phillipe gave me.  I see no reason why the final figure should be much
>less than 100%.  If constraint checks are suppressed, to let Ada and FORTRAN
>compete on equal terms, I would expect it to be so close to 100% that any dif-
>ference is insignificant.
>
Well put. On similar benchmarks I have seen straightforward scalar Ada 
come very close to what C can do on the same code. (Indeed I have seen
claims that for this kind of code, Ada has done _better_ than C).

I am very surprised that anyone who halfway understood compilers would
claim that unadorned, numerical, scalar code from a language A program
would _necessarily_ be slower than the same from from language F. I'd be 
really delighted to see these claims debunked forever. On a level playing
field, there are only X many ways to evaluate a scalar expression. This means
turning off constraint checks to level the field.

I believe that as compilers get smarter about avoiding unnecessary checks
(and the LRM never required unnecessary checks!), and programmers get smarter
about just how, when, and where to help the compiler by _selective_ use of
pragma SUPPRESS, we're going to see just the right tradeoff between speed
and safety. The growing maturity of compilers, users, and managers is really
gratifying! How long do you think it'll take for the bulk of the industry to  
throw away their outdated stereotypes about slow, clunky Ada?
 
It's good to see intelligent debate about what really makes programs slow.
It ain't the source language, folks.

Mike Feldman

jls@yoda.Rational.COM (Jim Showalter) (02/24/91)

We sell several compilers that stomp the shit out of the best
C compilers available. No big deal--just computer science. People
have been acting like there is something magical about all this,
which is just dumb. Graph coloring algorithms for allocating
registers work basically the same regardless of the language
for which said registers are to be allocated. Etc etc etc. Put
enough effort into writing a quality compiler, and you get quality
results.

And, best of all, you then get to write in Ada instead of some
godawful abortion like C.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
                   -- "When I want your opinion, I'll beat it out of you."

simonian@x102c.ess.harris.com (simonian richard 66449) (02/25/91)

Our division is currently in the midst of a heated debate with our
customer on this very issue.  Their counterexample is C.  One of their
objections (which they can't really substantiate; they've just heard
of problems) is the performance of Ada on Unix.  My claim is that the
only thing that Unix has to do with Ada performance is in the realm
of tasking, and even then the only problem is when one tries to use
tasks incorrectly.  In-house benchmarks, and data we've gathered from
other sources, indicate that a good Ada compiler with checks on can
approach 90% the performance of the best C compiler, and with checks
off can meet or beat C.  Note that I said _good_ Ada compiler.  There
are dogs out there...  Our basic statement to our customer will be
that this is a compiler issue, not a language issue.



Richard Simonian
Harris Space Systems Corp.  407-633-3800
simonian@x102c.ess.harris.com
rsimonian@nasamail.nasa.gov