Re: BLAS

[Robert Dewar <dewar@gnat.com>]

In article <E12qHFV-00005Z-00@Baldrick>,
  comp.lang.ada@ada.eu.org wrote:
> While gcc (C version) does a good job on all platforms, it can
certainly
> be beaten by C compilers tailored for the platform.  Since
GNAT can't do
> better than gcc, your remarks about DEC Ada aren't surprising;
there must
> be many other examples.  It is true that a systematic compiler
comparison
> would be interesting.

I don't think that the issues of gcc vs native compilers are
as simple as this. There are many cases where gcc does better
than tailored native compilers. For example, one comparison
between GNAT and another Ada compiler with a tailored code
generator for the Alpha showed GNAT faster by a factor of 2 in
Whetstones, and slower by a factor of 2 in a case involving an
unconstrained string return from a function.

Similarly, if you compare gcc with the compiler vendor on a
machine, you will typically find some things go faster and some
slower. There is also a huge variation in quality between
vendors compilers, and on some machines the vendors compiler
does significantly better than gcc, but there are cases where
it is the other way round.

There is nothing in the technology of GCC that results in any
particular disadvantage from the GCC approach of configuration
files tailored to the architecture. In cases where some compiler
is faster than gcc, it almost always has to do with perfectly
general optimizations that could perfectly well be done in gcc
(and indeed one should note that the new GCC 2.95 contains many
optimizations and improvements not in GCC 2.8.1, so for some
targets at least, there will be a gain from the switch in the
next version of GNAT.

Another interesting reason for variation in performance, is a
basic different philosophy in gcc up to now. Typically gcc
does MUCH better than native vendor compilers when it comes
to code sequence selection, i.e. local optimization, but not
as well with regard to global optimization. That's a matter
of historical philosophy and where effort has gone, rather
than any fundamental differences in what *could* be done
in either case. But it results in unexpected variations in
performance, since some apps are more sensitive to one style
than the other. Another issue is that many vendor compilers
have been very aggressively optimized to do well on the
Spec suite, and no one has bothered with this kind of very
specific benchmark targetting on GNAT. That does not have
a big effect on general apps, but it can have a BIG difference
on the Spec mark :-)

Coming back to global optimization, far more could be done in
GCC than is done now, and a lot of work along these lines is
in progress. For example, in GCC 2.8, the back end has no
aliasing information at all. In GCC 2.9x, aliasing information
can be represented in the back end, and part of our porting
effort of GNAT to GCC 2.9x will make use of this aliasing
information. This is particularly interesting, because this
is an area in which Ada outshines C because the stronger
typing makes it possible to derive much more precise aliasing
information for Ada than for a corresponding C program.

In the case of GNAT, we usually find that performance issues
are more related to Ada specific issues (tasking, return of
unconstrained values, etc) than to anything that is specifically
gcc related.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.