performance tuning with gnat

performance tuning with gnat

[Eric Anthony Spear]

Hi!  I'm running gnat 3.01.  I have a program that runs slower than I'd
like.  The trouble is, I don't know which parts are causing the
slowdown.  Are there any tools that can help me profile my program,
breaking down by procedure/function cpu usage and/or disk usage/wait
times?

Thanks in advance.

Re: performance tuning with gnat

[James E. Hopper]

In article <4mvkq1$nr4@cville-srv.wam.umd.edu> Eric Anthony Spear,
spear@wam.umd.edu writes:
>Hi!  I'm running gnat 3.01.  I have a program that runs slower than I'd
>like.  The trouble is, I don't know which parts are causing the
>slowdown.  Are there any tools that can help me profile my program,
>breaking down by procedure/function cpu usage and/or disk usage/wait
>times?
>
I can offer a few guesses and places to look for slowdowns.  We developed
our Digital
Radar Landmass Simulation (DRLMS) using gnat on an SGI but i think most
of this applys
to all gnats

1.  Exceptions are really slow.  By that i mean even having an exception
handler slows 
    things way down.  we ended up at the end stripping out most of our
exception handlers
    
2.  Unconstrained Arrays are REAL slow compared to constrained arrays and
compared to
    the Vads compiler we were using on our first generation product.  in
some cases they
    were as much as 5 times slower than the same code compiled with VADS.
 Most of our
    arrays were bitmaps and we ended up using constrained arrays and
using a bounds rect
    to specify which part of the array held valid data.  with this we ran
slightly faster
    than the VADS implementation.
    
in addition since we were doing convolutions of large bitmaps in realtime
(30 hz) we had
to suppress checks in critical sections. 

these were the critical time elements we discovered.  there is lots of
machine specific
stuff that SGI's toolset made easier to find using their profiler and
pixie utilities
but you didnt specify platform and i didnt do most of this work so i am
the wrong person
to talk about it (the correct person is doing final integration of the
radar into an
F-111 flight trainer in austrailia now). 

Final word is we ended up processing 4 times the number of pixels at a
faster frame rate
30 vs 25 hz in about 2.5 times the processors on an Onyx (no pipe
required) from our
first generation product using vads.  yes a LOT of this comes from
improved algorithms
but we were VERY pleased overall with compiler performance.

[which reminds me of a kind of funny story.  we wrote the original
marketing demos of our
SAR radar sim to run on a mac.  we were showing it at ITSEC on a mac
powerbook
and a man from a spanish firm was looking at it. when i asked him if he
wanted 
to hear about it he told me no he needed it to run real time.  Since the
powerbook demo
was already running at 2-3 times FASTER than realtime i replied "no
problem i will be happy
to slow it down for you!" ] ;-)

In any case gnat on the sgi impressed our team as well as the customers
engineers.  they
were a VADS house but they are switching as fast as they can to gnat
after seeing how responsive
ACT and SGI were. As well as how easy it was to go from version to
version during the sgi beta
period.

best jim

Jim Hopper
Chief Technical Advisor
Systems and Software Technology Division
Science Applications International Corp.

I speak only for myself by the way!

Re: performance tuning with gnat

[Robert A Duff]

In article <4n069g$rrf@eri1.erinet.com>,
James E. Hopper  <jhopper@erinet.com> wrote:
>In article <4mvkq1$nr4@cville-srv.wam.umd.edu> Eric Anthony Spear,
>spear@wam.umd.edu writes:
>>Hi!  I'm running gnat 3.01.  I have a program that runs slower than I'd
>>like.  The trouble is, I don't know which parts are causing the
>>slowdown.  Are there any tools that can help me profile my program,
>>breaking down by procedure/function cpu usage and/or disk usage/wait
>>times?

I had some luck with GNAT on Linux using gprof.  Use the -pg option to
the linker (that is, put "-largs -pg" on the gnatmake command line).
Then run gprof.  If you use -pg on the compiler, in addition to the
linker, it's supposed to give even more useful information.
Unfortunately, I got core dumps when I tried that, and I didn't
investigate further.

- Bob

Re: performance tuning with gnat

[Dale Pontius]

In article <4n069g$rrf@eri1.erinet.com>,
        James E. Hopper <jhopper@erinet.com> writes:
>
>1.  Exceptions are really slow.  By that i mean even having an exception
>handler slows
>    things way down.  we ended up at the end stripping out most of our
>exception handlers

I seem to remember seeing something about exceptions a month or two
back, that takes effect in GNAT 3.03 or 3.04. I think I heard that
the exception handling has been sped up significantly, just about to
the point of no penalty for a non-taken exception. I'd wait for more
authoritative word on this one, though. It still might be worth
checking out.

Dale Pontius
(NOT speaking for IBM)

Re: performance tuning with gnat

[James E. Hopper]

In article <4n79if$qhc@mdnews.btv.ibm.com> Dale Pontius,
pontius@twonky.btv.ibm.com writes:
>I seem to remember seeing something about exceptions a month or two
>back, that takes effect in GNAT 3.03 or 3.04. I think I heard that
>the exception handling has been sped up significantly, just about to
>the point of no penalty for a non-taken exception. I'd wait for more
>authoritative word on this one, though. It still might be worth
>checking out.

Since Robert is on the road, and off email for a couple days i will
respond to this
based upon what he and Wes Embry at SGI have told me on this issue.  

3.04 has a change which is inteneded to speed exception handling up quite
a bit. 
while this has been verified to work well on the sun, Wes tells me it has
also been
verified (well this was a month or more ago) to NOT change things much on
the sgi.
thus i guess your milage may vary.

best jim

Re: performance tuning with gnat

[Geert Bosch]

James E. Hopper (jhopper@erinet.com) wrote:
   [About what causes most slowdown]
`` 2.  Unconstrained Arrays are REAL slow [...] ''

I've found this too, but for most places where this mattered it's
possible to gain a large speed-up by tuning a small piece of code using
pointer operations.  While rewriting a regular expression matching
library for Ada I found that at first the performance was really bad
(2-3 times as slow as the original C version), but after changing a few
lines the speed came close (20% slower) to that of the C-version..

Since most time was spend in a simple routine that searches the first
occurrence of a character in a string, I've rewritten that routine
using a character pointer, which is incremented after each comparison.
The function still works on arguments of the standard type String, but
is several times faster. 

Hopefully GNAT will be able to make this conversion itself in a future
version, as it's possible to calculate the bounds only once before
entering the loop. BTW: is there some program that makes it possible
to have a readable assembly output where addresses are symbolic and
assembly lines are mixed with Ada source lines. (Like those Turbo
Pascal days.) It would make debugging GNAT code generation problems
(both performance and correctness) much easier.

Of course these 12 lines are "ugly" and need unchecked conversion
and/or Address_To_Access_Conversions, but the original "clean" Ada
version is left in the code as an alternative for programs where safety
is more important than speed.

The main point in writing an Ada version of the regexp library was to
see what the performance difference would be when going from an
implementation using dynamically allocated memory (at least for the
regexp finite state machine), only uncheckable pointer operations and
"printf" on detecting errors to an implementation requiring no dynamic
memory allocation (the FSM is an unconstrained type), just one place
with pointer operations and raising exceptions on (expression) errors.

The results really surprised me. The "literally converted" regexp
library generated code that was nearly exactly the same speed (as
expected), and the code without any unchecked conversions or pointer
operations was only 2-3 times as slow. The compromise that I prefer has
just 1% "ugly" code and performs just slightly slower thant the C
version on my test cases.  (The differences will be bigger when the FSM
will make many transitions without doing much more character matches
and some other uncommon cases.)

It's worth noting that declaring new types and packages, instantiating
and using Unchecked_Conversions are all essentially free in terms of
execution speed.  So, it often pays off to declare new types and do
unchecked conversions to/from them when those types are more efficient
in some function and speed is really critical.

Especially when it's possible to convert loops that process small (8-
or 16-bit) data values to loops that process 32-64 bit data values
(depending on the architecture) at once can make large speedups
possible, since each loop iteration 2 - 8 data items can be processed
instead of 1 and on some RISC machines processing 32- or 64-bit data is
faster than processing 8-bit data.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl     *** The moon may be smaller than ***
 Phone: +31-53-4303054        ** Earth,  but it's further away. **