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=-0.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 29 Apr 93 17:08:39 GMT
From: netcomsv!butch!rapnet!jcreem@decwrl.dec.com  (Jeffrey M. Creem x5700)
Subject: Re: ADA Performance
Message-ID: <1993Apr29.170839.5585@Rapnet.Sanders.Lockheed.Com>
List-Id: <comp.lang.ada>

>         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