comp.lang.ada
 help / color / mirror / Atom feed
From: netcomsv!butch!rapnet!jcreem@decwrl.dec.com  (Jeffrey M. Creem x5700)
Subject: Re: ADA Performance
Date: 29 Apr 93 17:08:39 GMT	[thread overview]
Message-ID: <1993Apr29.170839.5585@Rapnet.Sanders.Lockheed.Com> (raw)

>         So the other day he asks how things are going and I
>         squirm as I try to explain why my Ada Compiler generates
>         code 3 to 8 times slower than FORTRAN!!!
>              ================================

>be more maintainable. In a just world ADA should generate code as
>optimized as FORTRAN when all exceptions are suppressed. However if 
>if the code is more than 50% slower I start having problems and I
>go balistic at 2 times.


  While I should reserve judgement until I have run these test myself
there are a few things that need to be said:

1) I can only assume that you chose the correct compiler switches to
   optimize and suppress all range checks since you did not mention
   the compiler or switches or even include pragma (suppress_all) in
   the source code.  On our compiler VADS (by verdix) on both a Sun
   and motorola 68040 range check suppression and full optimization   
   along with a few pragma inlines usually cuts execution time in half.

2) Size of the floats. Since you didn't explicitly rep spec the size of
   your Ada floats but used "long_float", I can make no assumption about
   the size that you got. On Some compilers float is 64 bits (and short
   float is 32 bits) so long float might be some awful software emulated
   ugly float or may be what you expect.

3) Agregate assignment.  Not all Ada compilers do this well.  VADS Ada for 
   instance creates the aggregate on the stack and then copies it into
   the destination. On a short structure like a complex this might not
   be too bad but put that in a loop and bad you can kiss performance
   good-bye. Although it is obviously preferable to use the aggregate  
   assignment, with some compilers it is not a good thing.

4) Timing: In some compilers calendar.clock is not the best way to
   time things. It can often be slow. I think it is ok here since the  
   amount of work done in the complex loop is large compared to
   any amount of overhead I could think of in Calendar.Clock.

5) Object Code: A good thing to do might be to look at the object
   code that is generated by both compilers for a small subset of the
   program. It is not fun and not something that one normally likes to
   do but it may give you some hint as to why this is happening. It
   is possible that the Ada compiler you have is not the most recent
   for the processor you are on and is not using the best instructions
   for the given processor (Ie not using a co-processor).

  All this said in the end the Ada could very well be much slower but
it shouldn't have to be that way. If you are going to ask for timings
on things you should be sure that the code you put out will generate
what you expect on a wide variety of platforms.  (ie the comment about
the short_float/long_float ...)

Jeff Creem

             reply	other threads:[~1993-04-29 17:08 UTC|newest]

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

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