Re: GNAT & GCC performace (bad news)

[Tucker Taft <stt@averstar.com>]

Robert Dewar wrote:
>...
> However, it is fundamentally flawed in terms of achieving the
> best possible efficiency, and surely this approach would never
> be chosen except for the pragmatic considerations of the
> previous paragraph.

Actually, we have been pretty pleased with using optimized ANSI C as an
intermediate.  However, we put in a lot of effort to generate "good"
C, and to preserve as much information as possible in the generated C, to 
allow the C compiler to do further code optimization.

> 
> Why?
> ...
> One very significant area is nested procedures. There are
> compilation approaches which generate extremely efficient code
> for nested procedures, but since C has not nested procedures,
> the Ada front end must "fake" the access to nested procedures.
> This means typically that you end up having to address local
> variables in an inefficient manner that may well disrupt the
> register allocation phase of the target C compiler. There are
> basically two ways of faking nested procedures, either by
> using address vectors (which tend to force locals into memory)
> or my representing the locals as fields of a record (and many
> compilers will not treat such fields nearly as efficiently as
> stand alone local variables).

For nested procedures, we pass a record, but only the variables
that are actually "up-level" referenced end up as fields in the
record, so this minimizes the effect.

> ...
> Nevertheless, I think in practice you will find that the hybrid
> approach is often disappointing. Indeed Tuck mentioned to me
> that Intermetrics had been disappointed in at least one C
> compiler that they were using as a back end.

We haven't had any real code quality concerns recently, for what it is
worth.  With our current translation approach, our belief is that
we would not do any better by connecting into the C back end
directly, bypassing the C front end.  In fact, the C front end
includes some high-level loop-oriented optimizations, so the code
has the potential of being better than if we joined up directly to the 
back end.  Of course, if the back end were Ada specific, then there is the
potential for more Ada-specific optimizations, but we trade that
off against the advantage of sharing technology with the C compiler
suite, thereby reducing the amount of Ada-specific technology that
needs to be developed, maintained, enhanced, etc.

There are certainly tradeoffs, but we are pretty happy with
the C-based compilers we have, as well as with the ones that
connect directly into backends.  

> ...
> Robert Dewar
> Ada Core Technologies

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA