Re: GNAT & GCC performace (bad news)

Re: GNAT & GCC performace (bad news)

[Tucker Taft]

Harald Schmidt wrote:
> 
> Hi everybody,
> 
> I am playing around with Ada95 since nearly two weeks
> for an upcoming project, trying to select the best
> language for a headless server application. I am using
> CodeBuilder from Feldman's Ada book which comes with
> gnat and gnu c. My experience while compiling and running
> the dhrystone benchmark was that the C version of the
> Dhrystone was nearly twice as fast as the Ada version, and
> this sounds really bad. Has anyone any idea why this
> is so and how to solve this problem.

Try suppressing all run-time checks.  Note also that Dhrystone
for Ada and Dhrystone for C are necessarily not identical programs.
Dhrystone is designed for comparing compilers for the same language,
not for comparing compilers for different languages.  It may be
that the Ada version of Dhrystone is different in some performance-relevant
way from the C version, or it is just the additional run-time checking
that Ada is providing, that makes the difference.

> ...  What I was expecting,
> because gnat isn't a compiler env. but a to-C(++) translator,
> the performance decrease about ten to twenty percent but
> not 50 percent.

You will quickly be inundated with answers to this, but GNAT
is *not* a translator to C++, it is a translator to machine code,
just like gcc.  It shares the same backend as gcc, but it does not
use the GNU C or C++ front end.

> 
> Harald

-- 
-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

Re: GNAT & GCC performace (bad news)

[Dmitriy Anisimkov]

Harald Schmidt wrote:

> gnat and gnu c. My experience while compiling and running
> the dhrystone benchmark was that the C version of the
> Dhrystone was nearly twice as fast as the Ada version, and
> this sounds really bad. Has anyone any idea why this
> is so and how to solve this problem. What I was expecting,
> because gnat isn't a compiler env. but a to-C(++) translator,
> the performance decrease about ten to twenty percent but
> not 50 percent.
>

You have to Suppress all runtime checks in GNAT by the
-gnatp switch to gcc or gnatmake for correct comparision.

Re: GNAT & GCC performace (bad news)

[David Starner]

On Thu, 02 Dec 1999 22:43:46 +0100, Harald Schmidt <Harald.Schmidt@tomcat.de> wrote:
>this sounds really bad. Has anyone any idea why this
>is so and how to solve this problem. What I was expecting,
>because gnat isn't a compiler env. but a to-C(++) translator,
It's not a to-C translator. The GCC compiler suite looks like
              ----- GNU C
GCC Backend -|----- GNU Ada
             |----- GNU Fortran
              ----- GNU C++
                    etc
not
                      -- GNU C++
GCC Backend -- GNU C |-- GNU Ada
                      -- GNU Fortran
                         etc

-- 
David Starner - dstarner98@aasaa.ofe.org
I see no trend at all, except toward women playing mean and ugly 
sociopaths who are good at killing and who enjoy dark powers. Maybe 
it's just my friends?
	-- Dr. Kromm, on who plays what type of character in RPGs

Re: GNAT & GCC performace (bad news)

[nabbasi]

In article <B46CA6A1.2991%Harald.Schmidt@tomcat.de>, Harald says...
 
>What I was expecting,
>because gnat isn't a compiler env. but a to-C(++) translator,
>the performance decrease about ten to twenty percent but
>not 50 percent.
>
 
Gnat is not a "to-c" translator. Gnat is a front end, it does the
lexical and semantic analysis of the ada source code, and generates
the same input to the backend that other gnu languages generate, which
the backend uses to emit assembler code. (I assume some sort on internal
tree data representation in some common format that all front end gnu
compiler generate).


               +----+
  gnat ------> |    |      common
  gcc  ------> |    | ---> backend -----> assembler
  g++  ------> |    |
  f77  ------> |    |
               +----+
        front   intermidate
        end     data rep.

   
Nasser

Re: GNAT & GCC performace (bad news)

[James E. Hopper]

Another thing that costs is exceptions.  in all but the latest gnats
(and only on certain platforms) ust having an exception handler carries
a fair runtime penalty.  I maintain the machten gnat and codebuilder
comes with gnat 3.10 which is two generations back.  (go to
cs.nyu.edu/pub/gnat/powermac for latest version)  also i did not
implement zero cost exceptions (a feature of newer gnats on solaris and
irix, and i belive other os's).  peraps i will get around to it one of
these days.  also older versions of gnat paid sever penalty for some
types of arrays.  newer compilers have fixed most of that.  so 

1. turn off runtime checking
2. get newest version for nyu site
3. perhaps retry your benchparms on a platform with zero cost
exceptions [either that or comment out the exception handlers]

jim


In article <B46CA6A1.2991%Harald.Schmidt@tomcat.de>, Harald Schmidt 
<Harald.Schmidt@tomcat.de> wrote:

> I am playing around with Ada95 since nearly two weeks
> for an upcoming project, trying to select the best
> language for a headless server application. I am using
> CodeBuilder from Feldman's Ada book which comes with
> gnat and gnu c. My experience while compiling and running
> the dhrystone benchmark was that the C version of the
> Dhrystone was nearly twice as fast as the Ada version, and
> this sounds really bad. Has anyone any idea why this
> is so and how to solve this problem. What I was expecting,
> because gnat isn't a compiler env. but a to-C(++) translator,
> the performance decrease about ten to twenty percent but
> not 50 percent.

GNAT & GCC performace (bad news)

[Harald Schmidt]

Hi everybody,

I am playing around with Ada95 since nearly two weeks
for an upcoming project, trying to select the best
language for a headless server application. I am using
CodeBuilder from Feldman's Ada book which comes with
gnat and gnu c. My experience while compiling and running
the dhrystone benchmark was that the C version of the
Dhrystone was nearly twice as fast as the Ada version, and
this sounds really bad. Has anyone any idea why this
is so and how to solve this problem. What I was expecting,
because gnat isn't a compiler env. but a to-C(++) translator,
the performance decrease about ten to twenty percent but
not 50 percent.

Harald

Re: GNAT & GCC performace (bad news)

[Geoff Bull]

Harald Schmidt wrote:
 What I was expecting,
> because gnat isn't a compiler env. but a to-C(++) translator,
> the performance decrease about ten to twenty percent but
> not 50 percent.

Gnat is a true compiler. It does not translate to-C(++).

My experience is that, for equivalent code, Gnat produces code
that is as fast or slightly faster than C. This is not
surprising when one considers that Gnat and the Gnu C compiler
share the *same* backend code generator.
OTOH, my first Gnat program was about 100 times slower than the C
I had translated. Once I understood why (the C was buffering its IO,
the Ada was not) and made a few changes, the Ada version was a few
percentage points faster.

I suggest you look at your benchmarks to make sure they
are really equivalent.
Also, did you compile both with the same levels of optimisation
and turn off Ada's run time checks (in my experience, the latter
doesn't usually make an enormous difference, but it is worth a try)?

__
Geoff

Re: GNAT & GCC performace (bad news)

[Geoff Bull]

Upon further reflection, I think what you are trying to do
is of doubtful validity.
The becnchmark in question is designed to compare the performance of
two machines, not two languages.


Can you tell us what compilation options you used?
Where can I get the source on the net?


Geoff Bull wrote:
> 
> Harald Schmidt wrote:
>  What I was expecting,
> > because gnat isn't a compiler env. but a to-C(++) translator,
> > the performance decrease about ten to twenty percent but
> > not 50 percent.
> 
> Gnat is a true compiler. It does not translate to-C(++).
> 
> My experience is that, for equivalent code, Gnat produces code
> that is as fast or slightly faster than C. This is not
> surprising when one considers that Gnat and the Gnu C compiler
> share the *same* backend code generator.
> OTOH, my first Gnat program was about 100 times slower than the C
> I had translated. Once I understood why (the C was buffering its IO,
> the Ada was not) and made a few changes, the Ada version was a few
> percentage points faster.
> 
> I suggest you look at your benchmarks to make sure they
> are really equivalent.
> Also, did you compile both with the same levels of optimisation
> and turn off Ada's run time checks (in my experience, the latter
> doesn't usually make an enormous difference, but it is worth a try)?
> 
> __
> Geoff

Re: GNAT & GCC performace (bad news)

[Robert A Duff]

"James E. Hopper" <hopperj@macconnect.com> writes:

> Another thing that costs is exceptions.

Well, if the Ada code has exceptions handlers, then it's not comparable
to the C code unless the C code has setjmp/jongjmp's in all the same
spots!

- Bob

Re: GNAT & GCC performace (bad news)

[Larry Kilgallen]

In article <38473D90.68D8F47@acenet.com.au>, Geoff Bull <gbull@acenet.com.au> writes:

> Gnat is a true compiler. It does not translate to-C(++).

The second statement does not prove the first.

From what I have read in this newsgroup, it emits assembly language
which then must be fed through an assembler on the machine.

To me this does not make Gnat any more (or any less) of a "true"
compiler than the Averstar product(?) that _does_ emit C (and
like Gnat got validated).

Larry Kilgallen

Re: GNAT & GCC performace (bad news)

[Robert Dewar]

In article <B46CA6A1.2991%Harald.Schmidt@tomcat.de>,
  Harald Schmidt <Harald.Schmidt@tomcat.de> wrote:

> What I was expecting,
> because gnat isn't a compiler env. but a to-C(++) translator

No, that's completely wrong, GNAT has nothing to do with C or
C++, it is a compiler structured in the traditional manner.

  Front end converts to intermediate code
  Code generator generates code from intermediate code

What may confuse you is that gcc is a multi-language compiler
and also provides C and C++ front ends which compile into the
same intermediate code.

> the performance decrease about ten to twenty percent but
> not 50 percent.


You always have to remember that you are NOT compiling the
same code. One set of code is in C and the other in Ada. As
always performance is a strong factor not only of the machine
and compiler, but also how the code is written. Basically what
your results show is that the Ada code is written in a manner
that runs twice as slow as the C code.

That does not necessarily mean that the Ada code is bad, since
often we take advantage of Ada's high level features to make
the code clearer, but there can be an efficiency cost associated
with this.

The test you refer to is only valid, to the extent that it is
valid at all, for comparing one Ada compiler to another, or one
C compiler to another, but the Ada vs C is apples vs oranges
since you are comparing two different programs. It is certainly
possible to write an Ada program that will perform comparably
with the C program (in fact if you are comparing GNAT and GNU C,
it is usually possible to get the Ada program to output
identical binary text for the program.

Robert Dewar
Ada Core Technologies


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

Re: GNAT & GCC performace (bad news)

[Mats Weber]

The level of optimization is very important if you are using gcc, and
could very well account for your 50%. With -O0 (the default) gcc
generates easy to debug but quite inefficent code (look at the gcc
docs). You really have to use at least -O1 if you want your comparison
to be meaningful.

And you have to suppress checks in Ada to compare with C.

Re: GNAT & GCC performace (bad news)

[Robert Dewar]

In article <021219992309319566%hopperj@macconnect.com>,
  "James E. Hopper" <hopperj@macconnect.com> wrote:

> (and only on certain platforms) just having an exception
> handler ...

But that's the point, how could an Ada program that is supposed
to be comparable to a C program even *have* an exception handler
in the first place? Most certainly the C program did NOT have
exception handlers!

Once again, these benchmarks are intended for comparing
compilers and machines, using the *same* program. Use the
C version to compare C compilers, use the Ada versions to
compare Ada compilers, but do not expect to use these two
quite different programs to compare Ada and C.


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

Re: GNAT & GCC performace (bad news)

[Harald Schmidt]

in Beitrag [BEITRAG] schrieb Robert Dewar unter robert_dewar@my-deja.com am
04.12.1999 5:02 Uhr:

> In article <021219992309319566%hopperj@macconnect.com>,
> "James E. Hopper" <hopperj@macconnect.com> wrote:
> 
>> (and only on certain platforms) just having an exception
>> handler ...
> 
> But that's the point, how could an Ada program that is supposed
> to be comparable to a C program even *have* an exception handler
> in the first place? Most certainly the C program did NOT have
> exception handlers!
> 
> Once again, these benchmarks are intended for comparing
> compilers and machines, using the *same* program. Use the
> C version to compare C compilers, use the Ada versions to
> compare Ada compilers, but do not expect to use these two
> quite different programs to compare Ada and C.
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

...thanks to all for all these answers. Sounds I had better
carefully select the right benchmark for my investigation.
Special thanks to J�rgen Pfeifer who does a private benchmark
based on a pde (partial differencial equation).
His experience said: g77 > gnat > gcc > gpc, which means that
g77 is much faster than gpc.

Harald

Re: GNAT & GCC performace (bad news)

[Larry Kilgallen]

In article <82fgh2$mt3$1@nnrp1.deja.com>, Robert Dewar <dewar@gnat.com> writes:

> But there is a huge difference between emitting assembly
> language, which is just a 1-1 shorthand for machine language,
> and is therefore obviously equivalent from a performance
> point of view to emitting machine language (*)
> 
> and emitting C, where there are two significant problems:
> 
> 1. It may be impossible to emit efficient code for a given
> construct in the intermediate high level language (e.g.
> exceptions, compiler checks, various other things ...)
> 
> 2. The C compiler will introduce inefficiencies of its own
> for the generated code.

The C compiler may also introduce optimizations specific to
the machine that were not provided by the earlier compiler.
If you read the propaganda for the Averstar Ada-to-C project,
an aim seems to be to leverage effort machine manufacturers
are already putting into optimizing their C compilers.  Of
course there are other optimizations that can only be done
well with the full Ada semantics.

On a theoretical basis, it is possible to do anything in
machine language one can do in a higher level language.
However I believe that optimizing for various versions of
a particular chip is higher priority for the folks pushing
that chip than they are for the folks trying to provide a
multi-platform compiler (regardless of whether it emits
assembly language or C code).

Larry Kilgallen

Re: GNAT & GCC performace (bad news)

[Robert A Duff]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> The C compiler may also introduce optimizations specific to
> the machine that were not provided by the earlier compiler.
> If you read the propaganda for the Averstar Ada-to-C project,
> an aim seems to be to leverage effort machine manufacturers
> are already putting into optimizing their C compilers.  Of
> course there are other optimizations that can only be done
> well with the full Ada semantics.

Averstar's Ada-to-C compiler does Ada-specific optimizations, such as
removing constraint checks based on flow analysis, in the front end.  It
relies on the C compiler for the kinds of optimizations that C compilers
typically do.

- Bob

Re: GNAT & GCC performace (bad news)

[Robert Dewar]

In article <1999Dec3.103807.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> In article <38473D90.68D8F47@acenet.com.au>, Geoff Bull
<gbull@acenet.com.au> writes:
>
> > Gnat is a true compiler. It does not translate to-C(++).
>
> The second statement does not prove the first.
>
> From what I have read in this newsgroup, it emits assembly
language
> which then must be fed through an assembler on the machine.



Well quibble away :-)

But there is a huge difference between emitting assembly
language, which is just a 1-1 shorthand for machine language,
and is therefore obviously equivalent from a performance
point of view to emitting machine language (*)

and emitting C, where there are two significant problems:

1. It may be impossible to emit efficient code for a given
construct in the intermediate high level language (e.g.
exceptions, compiler checks, various other things ...)

2. The C compiler will introduce inefficiencies of its own
for the generated code.

In the compiler field it is traditional (and critical) to
distinguishe between compilers that emit assembly or
machine language (the two are equivalent from this point
of view), and translators that translate from one high
level language to another.

(*) the reason that gcc (and many other compilers) generate
assembly language instead of machine language is to isolate the
compiler from oddities of diverse object code formats (indeed
it is hard to imagine a highly portable backend technology which
would make any other choice).

Robert Dewar
Ada Core Technologies


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

Re: GNAT & GCC performace (bad news)

[Tucker Taft]

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

Re: GNAT & GCC performace (bad news)

[Robert Dewar]

In article <1999Dec6.073729.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> On a theoretical basis, it is possible to do anything in
> machine language one can do in a higher level language.
> However I believe that optimizing for various versions of
> a particular chip is higher priority for the folks pushing
> that chip than they are for the folks trying to provide a
> multi-platform compiler (regardless of whether it emits
> assembly language or C code).


Nevertheless there are fundamental problems in going through C.
For example, one cannot expect a wonderful optimizing C compiler
to do much in Ada critical areas like overflow detection and
exception handling etc.

The point though is that compilers, which generate assembler
or machine language, are very different beasts from translators
which translate from one high level language to another. In
practice there is almost always a loss from the translator
approach, often significant.

You quote theory, but I am talking from 30 years of experience
in compilers, I have NEVER seen a case where language to
language translation did not lose efficiency compared to direct
compilation.

Feel free to quote a counter example, but theorizing is not
convincing!


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

Re: GNAT & GCC performace (bad news)

[Robert Dewar]

In article <wcchfhwm64u.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Averstar's Ada-to-C compiler does Ada-specific optimizations,
> such as removing constraint checks based on flow analysis, in
> the front end.  It relies on the C compiler for the kinds of
> optimizations that C compilers typically do.

This approach is of course pragmatically valuable for providing
Ada for a wide range of machines for which Ada would not
otherwise be available.

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.

Why?

The trouble is that a lot of information is lost in going from
Ada to C. In particular, the typing information, which is
extremely valuable for many kinds of optimization (e.g. alias
analysis) is simply lost in the translation to C.

There are many other similar instances where the information
available to a true Ada compiler allows optimizations that
are simply not possible once the information is lost by
translation to C.

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).

Is this significant in practice? Hard to say, optimizations are
generally disappointing :-) in that they do not achieve amazing
improvements hoped for.

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.

Most certainly in the case of GNAT we would lose by translating
to C and then going through the C compiler. A number of
important optimizations would be lost for high level Ada code
if we followed this approach.

Of course compilers can vary hugely in quality, and in
particular it is the case that a given compiler may be uneven,
and generate great code for some things, and not nearly so good
code for other things. This is certainly true for GNAT, we are
constantly improving the code quality (which would not be
possible if GNAT generated perfect code in all cases :-)

Robert Dewar
Ada Core Technologies


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

Re: GNAT & GCC performace (bad news)

[Robert Dewar]

In article <384D4A80.DBAA4E67@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> 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.

I definitely agree with this. The problems I mentioned are all
ones that are fundamental to a C back end, and it seems
perfectly appropriate to attach to the front end by generating
C. Either the front end does no optimization, in which case
it's a wash, or it optimizes, in which case you are ahead.

People often assume that gcc is a C back end, but actually at
this stage it is a multi-language back end. When we first
wrote GNAT, gcc did not know any Ada at all, and we could have
linked to the existing gcc backend by doing the same kind of
Ada-to-C mapping as is done by the Intermetrics front end
(although at least we had efficient nested procedures, because
GNU C has nested functions).

But we decided this would lose too much efficiency for some
constructions, and we modified the back end of GCC to accomodate
Ada more closely. See the paper "Teaching GCC Ada" [or somesuch
title] in a recent Tri-Ada conference (sorry, do not have exact
reference).


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

Re: GNAT & GCC performace (bad news)

[Ada2001]

In article <82kumr$jrd$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
>
> I definitely agree with this. The problems I mentioned are all
> ones that are fundamental to a C back end, and it seems
> perfectly appropriate to attach to the front end by generating
> C. Either the front end does no optimization, in which case
> it's a wash, or it optimizes, in which case you are ahead.
>
> People often assume that gcc is a C back end, but actually at
> this stage it is a multi-language back end. When we first
> wrote GNAT, gcc did not know any Ada at all, and we could have
> linked to the existing gcc backend by doing the same kind of
> Ada-to-C mapping as is done by the Intermetrics front end
> (although at least we had efficient nested procedures, because
> GNU C has nested functions).
>
> But we decided this would lose too much efficiency for some
> constructions, and we modified the back end of GCC to accomodate
> Ada more closely. See the paper "Teaching GCC Ada" [or somesuch
> title] in a recent Tri-Ada conference (sorry, do not have exact
> reference).
>

Can you give us an overview of how JGNAT differs from regular GNAT with
respect to dependence on gcc? I have the impression, quite possibly
wrong, that all of JGNAT including the bytecode generator is written in
Ada and that it doesn't depend on gcc.  Is that correct?

F. Britt Snodgrass


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

Re: GNAT & GCC performace (bad news)

[Wes Groleau]

> The trouble is that a lot of information is lost in going from
> Ada to C. In particular, the typing information, which is
> extremely valuable for many kinds of optimization (e.g. alias
> analysis) is simply lost in the translation to C.

But how much (if any) of this information is also lost by going from Ada
to the common intermediate format used by the GCC suite?

Re: GNAT & GCC performace (bad news)

[Robert Dewar]

In article <384FEBF9.5F4F6BD2@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> But how much (if any) of this information is also lost by
> going from Ada to the common intermediate format used by the
> GCC suite?

The answer to this is, less and less as time goes on. We teach
the gcc backend more details about Ada, and also the backend
improves its capabilities. For example, when we move GNAT to
the new merged GCC, the backend has much more capabilties
for dealing with aliasing, and we will be able to pass aliasing
information along from the GNAT front end to take advantage
of the more precise aliasing information possible in a strongly
typed language.

With C, you are stuck with the definition of the language
permanently, you can't go teaching C more Ada, or adding
features to C to help the Ada-to-C translation process.

Still, I do want to emphasize that I think it is very valuable
to have this capability (Ada to C translation) because it allows
Ada 95 to be used on a wider variety of targets. Note that of
course the preferred implementation of the Intermetrics front
end is to wed it to an Ada specific code generator as is done in
the Aonix and Green Hills products, but it is certainly
attractive to have an alternative path on processors for which
no such specialized Ada code generator is available! Yes, there
are some losses from this approach, but the Intermetrics
implementation shows that these can be minimized in practice to
the point where the resulting compiler is quite practical for
production use.

Robert Dewar


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

Re: GNAT & GCC performace (bad news)

[Arthur Evans Jr]

In article <82pro2$3i0$1@nnrp1.deja.com>, Robert Dewar
<robert_dewar@my-deja.com> wrote:

> Still, I do want to emphasize that I think it is very valuable
> to have this capability (Ada to C translation) because it allows
> Ada 95 to be used on a wider variety of targets. Note that of
> course the preferred implementation of the Intermetrics front
> end is to wed it to an Ada specific code generator as is done in
> the Aonix and Green Hills products, but it is certainly
> attractive to have an alternative path on processors for which
> no such specialized Ada code generator is available! Yes, there
> are some losses from this approach, but the Intermetrics
> implementation shows that these can be minimized in practice to
> the point where the resulting compiler is quite practical for
> production use.

Absolutely right!

Moreover, this approach provides developers on a new target (which
already has a C compiler) immediate ability to write and test code.
If as the project develops it appears that better code efficiency
is required, they can then go the (more expensive) route of
commissioning a new target for GCC.  But, in the mean time, they do
have a useful compiler for testing.

Art Evans

Re: GNAT & GCC performace (bad news)

[Robert Dewar]

In article <ev_remove_this_ans-1012990948080001@192.168.1.254>,
  ev_remove_this_ans@evans.pgh.pa.us (Arthur Evans Jr) wrote:

> Absolutely right!
>
> Moreover, this approach provides developers on a new target
(which
> already has a C compiler) immediate ability to write and test
code.
> If as the project develops it appears that better code
efficiency
> is required, they can then go the (more expensive) route of
> commissioning a new target for GCC.  But, in the mean time,
they do
> have a useful compiler for testing.
>
> Art Evans


Of course from that point of view, it would be even nicer to
have an open source solution. It would not be that hard to
target GNAT to ANSI C, since many of the required transformation
are already done in gigi. A nice project for someone to do!


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

Re: GNAT & GCC performace (bad news)

[Richard Kenner]

In article <384FEBF9.5F4F6BD2@ftw.rsc.raytheon.com> Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:
>> The trouble is that a lot of information is lost in going from
>> Ada to C. In particular, the typing information, which is
>> extremely valuable for many kinds of optimization (e.g. alias
>> analysis) is simply lost in the translation to C.
>
>But how much (if any) of this information is also lost by going from Ada
>to the common intermediate format used by the GCC suite?

That's hard to answer in detail since the information that's "lost" is
what the backend currently can't use.  But the major point is that this
is not a fixed thing: the intermediate format keeps growing as the backend
can make use of more data, so there is room for continual improvement in this
area, while in converting to C, there's very limited room for passing on
more such information to the C compiler.