comp.lang.ada
 help / color / mirror / Atom feed
From: James E. Hopper <jhopper@erinet.com>
Subject: Re: performance tuning with gnat
Date: 1996/05/10
Date: 1996-05-10T00:00:00+00:00	[thread overview]
Message-ID: <4n069g$rrf@eri1.erinet.com> (raw)
In-Reply-To: 4mvkq1$nr4@cville-srv.wam.umd.edu


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!




  reply	other threads:[~1996-05-10  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-05-10  0:00 performance tuning with gnat Eric Anthony Spear
1996-05-10  0:00 ` James E. Hopper [this message]
1996-05-10  0:00   ` Robert A Duff
1996-05-13  0:00   ` Dale Pontius
1996-05-13  0:00     ` James E. Hopper
1996-05-14  0:00   ` Geert Bosch
replies disabled

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