Re: Gnat on OpenVMS

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <3744EFE6.79F99405@wanadoo.fr>, Daniel Thonon <Daniel.Thonon@wanadoo.fr> writes:

> I also looked at the code generated by gnat on Digital UNIX (with
> different -O levels and chip dependant optimizations) and found the same
> kind of problem. For example, just by counting the number of statements
> in a loop, I found a ratio of more than 2 between gnat and DECAda. The
> GEM code was quite simple to understand, but the gnat code was very
> complicated, with several unnecessary jumps, for example.

Be very careful with Alpha (and other RISC machines, I would presume)
to avoid seat-of-the-pants judgements about what is complicated.  It
may be that you have studied this in detail, or maybe not, but what
seems like an obvious cost comparison can often be subtle.  Looking
at GEM (DEC) code from various compilers one can find things like
NOP instructions inserted, not for "wait state" purposes but to make
branch targets have quadword alignment.

I would certainly not claim that the machine code you describe is good,
because I have not seen it.  For Alpha code I have seen, however, what
seemed questionable to me at the start actually had a reason for being
that way.  It is of course possible that you are much more expert than
I in the timing of the Alpha chip, but I make this post anyway on the
theory that someone else out there may be less expert :-).

> We did not find the same conclusion, either on simple benchmarks or with
> our complete application. In some case, gnat is faster, but overall it
> is really slower.

Yes, your application is the real test, since it was your organization
that wants the computing done, not the SPEC committee.

Larry Kilgallen