Re: Ada-95 for numerics?

[michael@ifr.luftfahrt.uni-stuttgart.de]

dewar@cs.nyu.edu (Robert Dewar) wrote:

> Second, are you using unconstrained arrays? This again is a big
> difference between C and the Ada code. 
> 
> You will find that if you turn off checks and use constrained arrays,
> that you come much closer in speed. 

This is certainly true, but in many cases it is just impractical to use
constrained arrays.

> (GNAT does not handle unconstrained arrays very well on some
> architectures, for a very simple reason that we understand well,
> and intend to fix at some point).

Can you already give an estimate when that will be?

> Our priorities in GNAT development are first to get te functionality
> complete and realiable, and second to optimize and improve the
> quality of the code. There are a LOT of optimization opportunities,
> which we wlil visit as GNAT development continues.
> 
> Actually I must say that numerical codes of this kind are not our
> first priority. That's because relatively few GNAT users have
> critical performance requirements in this area. 

Please add me to the list of these few GNAT users because "numerical
codes of this kind" is what our current project is all about. I did
some tests with a simple matrix multiplication routine using unconstrained
arrays and found that on all architectures the GNAT code is about a
factor 3 - 4 slower than an equivalent hand optimized C function but
I also found that when I write a C function that is as similar as possible
to the original Ada procedure, I get almost exactly the same timing
results as for the Ada version. To me this indicates that the problem
with unconstrained arrays is actually in the gcc backend and not so
much in the Ada frontend. As far as I know the Fortran comunity
has the same problems with the performance of g77.

From all architectures which I have tested the SUN/SPARC architecture
appeared to be the worst of all. The original performance difference
was a factor of 12. Just recently I found a switch in the gcc manual
"-msupersparc" which seems to improve the situation quite a bit. By
using this switch the factor came down to the usual 4.0. So, for
SPARC users with a reasonably modern machine I can only recommend to
use this switch if portability of the binaries with older machines is
no issue. If anybody knows about other switches of this kind, please
let me know. Two more of them and we will be able to execute an
infinite loop in less than a second :-)

For all the tests I did of course suppress all Ada checks and used full
optimization!

Michael

-- 
------------------------------------------------------------------------
--Dipl.-Ing. Michael Paus   (Member: Team Ada)
--University of Stuttgart, Inst. of Flight Mechanics and Flight Control
--Forststrasse 86, 70176 Stuttgart, Germany
--Phone: (+49) 711-121-1434  FAX: (+49) 711-634856
--Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)