* Re: performance tuning with gnat
1996-05-10 0:00 ` James E. Hopper
@ 1996-05-10 0:00 ` Robert A Duff
1996-05-13 0:00 ` Dale Pontius
1996-05-14 0:00 ` Geert Bosch
2 siblings, 0 replies; 6+ messages in thread
From: Robert A Duff @ 1996-05-10 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: performance tuning with gnat
1996-05-10 0:00 ` James E. Hopper
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
2 siblings, 1 reply; 6+ messages in thread
From: Dale Pontius @ 1996-05-13 0:00 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: performance tuning with gnat
1996-05-13 0:00 ` Dale Pontius
@ 1996-05-13 0:00 ` James E. Hopper
0 siblings, 0 replies; 6+ messages in thread
From: James E. Hopper @ 1996-05-13 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: performance tuning with gnat
1996-05-10 0:00 ` James E. Hopper
1996-05-10 0:00 ` Robert A Duff
1996-05-13 0:00 ` Dale Pontius
@ 1996-05-14 0:00 ` Geert Bosch
2 siblings, 0 replies; 6+ messages in thread
From: Geert Bosch @ 1996-05-14 0:00 UTC (permalink / raw)
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. **
^ permalink raw reply [flat|nested] 6+ messages in thread