comp.lang.ada
 help / color / mirror / Atom feed
From: netnews!schonberg!dewar@nyu.edu  (Robert Dewar)
Subject: Re: ADA Performance
Date: 29 Apr 93 16:12:30 GMT	[thread overview]
Message-ID: <dewar.736099950@schonberg> (raw)

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.

             reply	other threads:[~1993-04-29 16:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-04-29 16:12 Robert Dewar [this message]
  -- strict thread matches above, loose matches on Subject: below --
1993-04-29 17:08 ADA Performance Jeffrey M. Creem x5700
1993-04-30 17:18 ADA performance Wes Groleau X7574
1993-05-03 11:54 ADA Performance cis.ohio-state.edu!news.sei.cmu.edu!firth
1993-05-03 21:21 Robert I. Eachus
1993-05-04 15:03 cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.
1993-05-04 15:18 Boris Pelakh
1993-05-04 19:31 Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox