From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,35ed85a9d92a025
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Ada-95 for numerics?
Date: 1996/04/01
Message-ID: <dewar.828416445@schonberg>#1/1
X-Deja-AN: 145355239
references: <4jocek$h5h@rigel.rz.uni-ulm.de>
 <316005FE.204F@escmail.orl.mmc.com>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-04-01T00:00:00+00:00
List-Id: <comp.lang.ada>

"BTW: The other compilers you mentioned are all more "mature" than
GNAT. This means they have had way more time to work on optimizations."

Actulally GNAT is rather strange in this respect. The gcc backend is
*quite* "mature", and often generates code that compares with the
best code generated by any compiler for any language on a given
machine.

If you write Ada that corresponds to the stuff gcc knows how to do well,
then you can encounter performance levels that look VERY good, often
much better than other Ada (or C) compilers.

On the other hand, it is quite true that the GNAT front end is quite young,
and some of the code for Ada specific constructs (e.g. exceptions,
aggregates, finalization, slices, runtime checks) is far from optimal,
and can be expected to improve significantly as time goes by!

We certainly are interested in detailed reports (with code) for examples
where GNAT seems slow. It is important to give the exact code. Often
it is the case that the performance is VERY dependent on small details
of how the code is written.

Let me give a specific example, to see what I mean:

procedure a is
   x : integer;
   subtype r is integer range x .. x + x;
   type a is array (r) of integer;
   va : a;
begin
   for j in r loop
      va(j) := 0;
   end loop;

   for j in a'range loop
      va(j) := 0;
   end loop;
end a;

Now these two loops should obviously be treated exactly the same. But
in fact the first loop is treated optimally, with no junk checks, and
generates essentially perfect machine code. But the second loop generates
a silly check inside the loop. The fix is actually quite simple (it might
get into 3.04, we only noticed this anomoly recently). Certainly it is
on the list. 

Note: I had to use a dynamic range here, if I had written range 1 .. 10
for r, then the code for both loops would have been fine.