|Ada vs. C performance, was Possible to write compiler to Java VM? firstname.lastname@example.org (Arch Robison) (1997-01-07)|
|Re: Ada vs. C performance, was Possible to write compiler to Dave_Koogler_at_CCISDAPPS1@ppc-191.putnaminv.com (1997-01-09)|
|Re: Ada vs. C performance, was Possible to write compiler to email@example.com (Craig Burley) (1997-01-12)|
|Re: Ada vs. C performance, was Possible to write compiler to firstname.lastname@example.org (Toon Moene) (1997-01-14)|
|Re: Ada vs. C performance, was Possible to write compiler to email@example.com (Christopher Glaeser) (1997-01-17)|
|From:||Craig Burley <firstname.lastname@example.org>|
|Date:||12 Jan 1997 11:29:01 -0500|
|Organization:||Free Software Foundation, 545 Tech Square, Cambridge, MA 02139|
|Keywords:||C, Ada, performance, Fortran|
>[Do Ada compilers really generate better code than C compilers for
> similar source code? -John]
This is very easy to prove: the Gnat Ada compiler is built upon the
same code generator as the Gnu C compiler. When an algorithm is
expressed in a similar fashion in the two languages, the resulting
code is almost identical.
However, as I've learned working on g77, C has a definite advantage in
that it is the main (sometimes only) language favored by the design,
implementation, and maintenance of the gcc back end.
Though I don't know any Ada examples, having not looked at that
language in ages, I know the gcc back end doesn't provide direct ways
to express some Fortran constructs (like the lack of aliasing in
writes through pointers with writes through other pointers or
externals). I suspect Ada would suffer some from this as well.
The good news is that we're beginning to teach the gcc back end about
these new constructs -- at least, for g77, we're in the
experimental/development phase for some of them.
A minor example, that I believe rarely amounts to much in practice, is
that the gcc back end has no "and" and "or" operations at the tree
level. It has C's && and &, but no way to express Fortran's "L1
.AND. L2" such that the back end could decide, based on analysis, to
implement this as, in C's language, "L1 & L2", "L1 && L2", "L2 && L1",
"L1", "L2", "1", or "0".
Basically, for the most part, C is more of a low-level imperative
language than either Fortran or Ada, so while it tends to allow a
programmer who knows the fastest way to code something on a given
architecture to explicitly code that way, getting better results than
more straightforward code written in Fortran, Ada, or even C, C also
tends to produce slower code than Fortran or Ada when the code is
written in a straightforward fashion. (There are classes of problems
where C does much better than Fortran, and probably others with other
heightened advantages/disadvantages, but I'm referring to the large
class of problems each language has basically decent facilities to
And, the gcc back end still caters primarily to the code-generation
needs of C and its offspring (mainly C++), so inherent advantages of
other languages aren't being highlighted by the gcc technology at this
point as much as some of think they will be in the future.
James Craig Burley, Software Craftsperson email@example.com
Return to the
Search the comp.compilers archives again.