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
next 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