Related articles |
---|
Ada vs. C performance, was Possible to write compiler to Java VM? robison@kai.com (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 burley@gnu.ai.mit.edu (Craig Burley) (1997-01-12) |
Re: Ada vs. C performance, was Possible to write compiler to toon@moene.indiv.nluug.nl (Toon Moene) (1997-01-14) |
Re: Ada vs. C performance, was Possible to write compiler to cdg@nullstone.com (Christopher Glaeser) (1997-01-17) |
From: | Craig Burley <burley@gnu.ai.mit.edu> |
Newsgroups: | comp.compilers |
Date: | 12 Jan 1997 11:29:01 -0500 |
Organization: | Free Software Foundation, 545 Tech Square, Cambridge, MA 02139 |
References: | 97-01-045 97-01-065 |
Keywords: | C, Ada, performance, Fortran |
Dave_Koogler_at_CCISDAPPS1@ppc-191.putnaminv.com writes:
>[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
handle.)
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 burley@gnu.ai.mit.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.