From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 29 Apr 93 16:12:30 GMT
From: netnews!schonberg!dewar@nyu.edu  (Robert Dewar)
Subject: Re: ADA Performance
Message-ID: <dewar.736099950@schonberg>
List-Id: <comp.lang.ada>

The subject line of this thread is seriously misleading. The post had nothing
to do with Ada performance per se, but rather with the performance of a
particular Ada compiler compared to a particular Fortran compiler. Well no
one would claim that Ada (or Fortran for that matter) has a secret guarantee
that it is impossible to write slow compilers! Indeed we all know counter
examples.


But that should not lead one to believe that somehow there is something
inherently wrong with Ada performance. Certainly for example in GCC, if
you write a program in C, and then you write the same program in Ada, using
GNAT, you will get exactly the same optimized code because it's going through
the same back end. At least that's true if you use roughly the same level of
abstraction. Clearly introducing extra levels of non-inlined calls will slow
things down, but many Ada semantic features like packages, overloading,
generic instantiations, won't affect the code in any way, sinc they are 
essentially front end abstractions that are lost long before the code 
generator is reached. Similarly if you have checks on, you can expect a
(not terribly big) degradation -- FORTRAN looping type code is actually a
best case for minimal impact of checks in a decent Ada compiler.

That being said, comparing performance on type Complex between Fortran and
Ada 83 is definitely a worst case comparison from Ada's point of view. That's
because Fortran has the Complex abstraction built in, and it is always easier
to get a built-in abstraction working at high efficiency. Ada 9X recognizes
this particular problem by proividing Complex as a predefined abstraction in
the numerics annex. This doesn't guarantee efficient implementation, but in
practice it will help.

What would be useful from the original poster, is not so much the names of
the products involved, but rather an analysis of where the inefficiency is
coming from. Random mucking with the sources won't give this information.
What is really needed is to look at and analyze the resulting object code.