Speeding up Ada procedure?

Speeding up Ada procedure?

[Papandopulo]

I have certain procedures dealing with
large arrays which are potential performance
bottlenecks. While they didn't cause
performance problems yet I intuitively
feel they will.

Is it a way to remove runtime array
bounds and other checks for particular
procedure ?

While Ada checks are excellent on
control-type part of program where is
a lot of logic and not much time spent
it can become deadly if massive arrays
of data are being processed.

If the procedure just takes an array and
produces an array I can be sure it's not
faulty by testing it with different size
arrays and than turning off runtime checks.

That's my rationale.

Thank you,
George

Re: Speeding up Ada procedure?

[Hyman Rosen]

Papandopulo wrote:
> it can become deadly if massive arrays of data are being processed

That depends a lot on your pattern of usage.

In many cases, the compiler can eliminate checks by "proving" to itself
that they can never fail. Or it may hoist checks outside loops.

I would suggest that you ignore your intuition, and only try to fix
things once you have measured and know for a fact that the index checks
are a problem.

Re: Speeding up Ada procedure?

[tmoran]

>Is it a way to remove runtime array
>bounds and other checks for particular
>procedure ?
  Pragma Suppress

>bottlenecks. While they didn't cause
>performance problems yet I intuitively
>feel they will.
  Intuition is highly unreliable.  It's only good for suggesting where to
look, not what to do.  Try running timing tests with and with suppressing
various checks.

Re: Speeding up Ada procedure?

[Steve]

If your indexes are of a type that is restricted to the range of the array
bounds, the compiler need not do a check on those bounds when indexing the
array.  Some compilers take advantage of this.

Steve
(The Duck)

"Papandopulo" <papand0pul0@yahoo.com> wrote in message
news:1d13e1b4.0302261526.40058154@posting.google.com...
> I have certain procedures dealing with
> large arrays which are potential performance
> bottlenecks. While they didn't cause
> performance problems yet I intuitively
> feel they will.
>
> Is it a way to remove runtime array
> bounds and other checks for particular
> procedure ?
>
> While Ada checks are excellent on
> control-type part of program where is
> a lot of logic and not much time spent
> it can become deadly if massive arrays
> of data are being processed.
>
> If the procedure just takes an array and
> produces an array I can be sure it's not
> faulty by testing it with different size
> arrays and than turning off runtime checks.
>
> That's my rationale.
>
> Thank you,
> George

Re: Speeding up Ada procedure?

[Gautier]

Papandopulo:

> I have certain procedures dealing with
> large arrays which are potential performance
> bottlenecks. While they didn't cause
> performance problems yet I intuitively
> feel they will.
> 
> Is it a way to remove runtime array
> bounds and other checks for particular
> procedure ?

There are pragmata suppress (standard) and it
is meaningful to apply them. What I do for
number-crunching with big matrices is
to compile the whole with two different option sets

1/ a "debug" without suppressing anything, no optimization
   and eventual compiler-dependent extra checks

2/ a "compute" one with suppress_all, plus all optimization
   goodies provided by the compiler, including loop-unrolling

You can always add a few before-calculation explicit
checks to verify data consistency, e.g.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Speeding up Ada procedure?

[Duncan Sands]

On Thursday 27 February 2003 09:38, Gautier wrote:
> Papandopulo:
> > I have certain procedures dealing with
> > large arrays which are potential performance
> > bottlenecks. While they didn't cause
> > performance problems yet I intuitively
> > feel they will.
> >
> > Is it a way to remove runtime array
> > bounds and other checks for particular
> > procedure ?

Also, try to avoid cache misses.

Duncan.

Re: Speeding up Ada procedure?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]


"Papandopulo" <papand0pul0@yahoo.com> a �crit dans le message de news: 1d13e1b4.0302261526.40058154@posting.google.com...
> I have certain procedures dealing with
> large arrays which are potential performance
> bottlenecks. While they didn't cause
> performance problems yet I intuitively
> feel they will.
>
*NEVER* trust your intuition for performance problems - measure.
I usually refuse to discuss efficiency issue with people who didn't make measurements.

There is only one constant I found about efficiency: when you do the measurements, what
you discover is very far from what you expected in the first place.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Speeding up Ada procedure?

[Mark Johnson]

Papandopulo wrote:
> 
> I have certain procedures dealing with
> large arrays which are potential performance
> bottlenecks. While they didn't cause
> performance problems yet I intuitively
> feel they will.
> 
Hmm. Have you tried measuring the performance of the routines in
question? I have found that my "intuition" (and others) fails to find
the real problem area more often than not. An example of some code I had
to fix was a Jovial to Ada translator. The developer knew that symbol
lookup needed to be fast so did a pragma (Inline) to speed it up. When I
fed a large file (say 3000 lines) with a lot of symbols, the program ran
really slow (over two CPU days - never finished). A profile did not find
the problem until I removed that pragma (Inline) and then 99.999...% of
the CPU time was in that symbol lookup routine.
 The lookup method was a linear search of an unsorted list!
We changed it to a hash table & the CPU time for that one file went to
less than 5 minutes.

Remember - measure before optimizing. Then fix the "right thing".

> Is it a way to remove runtime array
> bounds and other checks for particular
> procedure ?
> 
As several others have mentioned pragma (Suppress). However I don't
recommend it; like inline it may hide the real problem.

> While Ada checks are excellent on
> control-type part of program where is
> a lot of logic and not much time spent
> it can become deadly if massive arrays
> of data are being processed.
> 
I would not be so sure of that. Again you need to do the measurements.
If the arrays are as massive as you say they are - the compiler can do
the check of an index against the limit once or twice (say to the min /
max values of a loop) which is negligible overhead for a 1000 element
array. See what your compiler does or measure it before taking that
optimization step.

> If the procedure just takes an array and
> produces an array I can be sure it's not
> faulty by testing it with different size
> arrays and than turning off runtime checks.
> 
You would be better served by using Spark or some other proving system
before you make that decision.
  --Mark

Re: Speeding up Ada procedure?

[Alfred Hilscher]

Papandopulo schrieb:
> 
> I have certain procedures dealing with
> large arrays which are potential performance
> bottlenecks. While they didn't cause
> performance problems yet I intuitively
> feel they will.

I did performance measurement and improvements as my job for many years.
Experience showed that the problems often (nearly always) occured where
they were _not_ expected. 
So I would suggest to do some measurements first.
You can do this with GNAT very easy by running gprof.

> Is it a way to remove runtime array
> bounds and other checks for particular
> procedure ?

If it is assured that really the arrays are the problem then this could
be a way, but there raises the danger of (C-like) "buffer overflows".

Re: Speeding up Ada procedure?

[John R. Strohm]

"Papandopulo" <papand0pul0@yahoo.com> wrote in message
news:1d13e1b4.0302261526.40058154@posting.google.com...
> I have certain procedures dealing with
> large arrays which are potential performance
> bottlenecks. While they didn't cause
> performance problems yet I intuitively
> feel they will.

George, there is a very fundamental rule-of-thumb in this racket.  You NEVER
speculate about things that MIGHT become performance problems.  You profile
the code and FIND OUT if they are IN FACT performance problems.

Some years ago, on a 50 MHz 486, I had a bunch of floating-point
calculations.  I was PLANNING on rewriting them in fixed-point (integer),
for speed, because I was worried that they might be a problem.  Before I did
that, however, I ran them and measured the time they took.  When I
discovered that they were nowhere near as bad as I'd expected them to be, I
left them in floating-point.  End of problem.

> Is it a way to remove runtime array
> bounds and other checks for particular
> procedure ?

pragma suppress

> While Ada checks are excellent on
> control-type part of program where is
> a lot of logic and not much time spent
> it can become deadly if massive arrays
> of data are being processed.
>
> If the procedure just takes an array and
> produces an array I can be sure it's not
> faulty by testing it with different size
> arrays and than turning off runtime checks.

No, you can't, not necessarily.  You have to understand the algorithm, and
be able to say that the subscript expressions will never blow.

Some Ada compilers are smart enough to figure out that subscript expressions
will always be in bounds, and optimize out the checks.

The other thing is this:  Depending on what you are doing, do you MIND if
the code runs slowly?  If you're not doing real-time stuff, it may not be an
issue.  Are the consequences of an UNDETECTED subscript fault worse than
having the code run slowly?  What about the consequences of a program crash?
(Twenty years ago, I watched a one-byte error in some 8080 code scrag the
hard disk on an Intel MDS.  I was writing a threaded-code interpreter,
playing games with the stack pointer.  It wasn't pretty.  After the hardware
guy rebuilt the disk, I formed a habit of hitting the write-protect switches
before I started my code.)

Re: Speeding up Ada procedure?

[John R. Strohm]

"Mark Johnson" <mark_h_johnson@raytheon.com> wrote in message
news:3E5E32A2.DA8DDA1C@raytheon.com...
> Hmm. Have you tried measuring the performance of the routines in
> question? I have found that my "intuition" (and others) fails to find
> the real problem area more often than not. An example of some code I had
> to fix was a Jovial to Ada translator. The developer knew that symbol
> lookup needed to be fast so did a pragma (Inline) to speed it up. When I
> fed a large file (say 3000 lines) with a lot of symbols, the program ran
> really slow (over two CPU days - never finished). A profile did not find
> the problem until I removed that pragma (Inline) and then 99.999...% of
> the CPU time was in that symbol lookup routine.
>  The lookup method was a linear search of an unsorted list!
> We changed it to a hash table & the CPU time for that one file went to
> less than 5 minutes.

Just out of curiosity, where was this?  GD/Fort Worth, by any chance?

Re: Speeding up Ada procedure?

[Mark Johnson]

"John R. Strohm" wrote:
> 
> "Mark Johnson" <mark_h_johnson@raytheon.com> wrote in message
> news:3E5E32A2.DA8DDA1C@raytheon.com...
> > Hmm. [snip - speed up of horrible algorithm in J2A translator]
> 
> Just out of curiosity, where was this?  GD/Fort Worth, by any chance?

Nope. The location where I did it is now part of L3. The original code
was from a group working on the F-15 Radar OFP's and none of their
modules were over about 300 lines of code. The OFP's on the F-16 were
coded quite differently so we had to enhance the translator to work for
us.

  --Mark