Re: Ada vs. C performance

Here's my omnibus reply about Ada vs. C. Note that I am arguing
(perhaps incorrectly) reality of the marketplace, not theory of compilation.


Laurent Guerby <guerby@gnat.com> writes:


> Of course the argument doesn't hold with GNAT since the backend is
> the same for Ada and C. I'm pretty sure that for every C program, you
> can write an Ada program (C-style) that will generate the same code.


A couple of people have cited the shared backend of GNAT as an
example. But GNAT proves my point, because the GCC backend is
inferior (as of 1996) to the best C backends, at least for the
workstations and codes of my interest that I have tried. (Not that
the GCC backend is bad. Given its GNU goals of wide copy-lefted
distribution, it is singularly impressive.)


My main point is that economics, not theory, has the biggest effect on
whether C or Ada compilers generate faster code. GCC, driven by goals
other than money, cannot compete with commercial platforms when
optimization is economically important. My claim is that the best
optimizing C compiler for a given platform will often better code than
the best optimizing Ada compiler, at least when the C market for that
platform is much bigger than the Ada market.


Of course, for some platforms (notably DSP chips), the market is
driven by assembly code. On those platforms, the more level economic
playing field may let Ada exploit its semantic advantage.


> A minor point, it's easy, given a factor k, to write an Ada program
> that will outperform the "same" C program, just put a large local
> array in a procedure and call it a lot, in C it must be initialized to
> zero, and this is not the case in Ada so it will be faster (how
> semantic can affect performance ;-). (I don't think there's a way to
> have non zero'ed data on the stack in C.)


This is not true. C does not require that stack variables (even
arrays) be zeroed.


Dave Koogler writes:


> The Gnat implementation allows you to readily compare the
> effectiveness of the two languages without the 'noise' introduced by
> differences in the maturity and capability of the code generator.


My argument is that the differing code generates is *not* noise, but
in fact dominates the issue. Fortran and C will often get the most
mature code generators first.


Brian Wichmann <baw@cise.npl.co.uk> writes:


> There are several cases in which Ada compilers can produce
> fundamentally superior code to C. Examples are as follows:


My issue is not *can*, but *does in practice*.


> 1. Using the ability in Ada to in-line a function.


There are C compilers that inline functions too.


> 2. Using ability in Ada control the representation of a type
> so that the compiler performs bit manipulation for data
> access.


A specific example would help here.


>3. All cases in which C optimization is unsafe due to the
> inability of the compiler to detect if aliasing is present.
> (The C standard is very careful here, but your compiler
> might not be!)


Aliasing affects primarily state-of-the-art optimizations, which are
usually targeted towards C and Fortran because it takes a lot of work
to implement those state-of-the-art optimizations, and the
implementors need to make a return on their investment. Once again,
economic forces pay writers of (some) C optimizers to do some fairly
trickly alias analysis.


For example, a fairly recent (past decade) optimization that's hit
mainstream processors is software pipelining. How many Ada compilers
do good software pipelining? How many C compilers? (I really do not
know the answer. Maybe they all do?)


For another example, I'll cite our own stuff. Our C++ optimizer has
novel optimizations for structures and pointers that no other compiler
(even Fortran!) has (at least for our target platforms). Eventually
this technology will reach Ada, but when? Can any of you Ada compiler
writers out there claim significant optimizations that are only in Ada
compilers so far?


Richard Hash <rgh@shellus.co> writes:


> Indeed. I worked in that Ada group at his former employer (and still
> do), and can offer another data point that says "(modern) Ada
> compilers nearly *always* generate as-good or better code for
> *similar* source code"


Hi! Thanks for the update. There's hope in the world yet for saner
languages.


> What is tricky, of course, is what constitutes "similar" code.


Amen.


Arch D. Robison Kuck & Associates Inc.
robison@kai.com 1906 Fox Drive
217-356-2288 Champaign IL 61820
Lead Developer for KAI C++ http://www.kai.com/C_plus_plus/index.html
[Several other people pointed out that C doesn't initialize auto variables.
Sorry, I should have caught that. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.