|Re: Possible to write compiler to Java VM? firstname.lastname@example.org (W. Wesley Groleau (Wes)) (1997-01-02)|
|Re: C vs. Ada performance WStreett@shell.monmouth.com (1997-01-03)|
|Re: C vs. Ada performance email@example.com (Walter Banks) (1997-01-04)|
|Re: C vs. Ada performance firstname.lastname@example.org (Dean Sutherland) (1997-01-07)|
|Re: C vs. Ada performance email@example.com (1997-01-12)|
|From:||Dean Sutherland <firstname.lastname@example.org>|
|Date:||7 Jan 1997 12:32:16 -0500|
|Keywords:||C, Ada, performance|
W. Wesley Groleau (Wes) <email@example.com> wrote:
> Comparing C with Ada: the amount of semantic consistency required
> by Ada and shunned by C is the reason why code optimizers for Ada
> can do so much more. (I don't care whether you post this or not.
> comp.lang.ada has had several very lucid discussions of this point
> in recent months.)
> [Do Ada compilers really generate better code than C compilers for
> similar source code? -John]
It depends what you mean by "similar source code". For example, C
programmers typically use pointer arguments (eg. struct *) where an
Ada programmer would use an "in out" or "out" parameter. The
under-the-floor view involves a pointer in either case, but the Ada
version has more optimizer-friendly semantics (because the pointer was
introduced by the compiler and must follow language mandated
semantics). Well written Ada programs generally have far fewer
explicit pointers than C, which makes optimization much easier. A
straight transliteration from C to Ada would present an Ada optimizer
with the same problems as the original C
Wilbur Streett wrote:
> Ada compilers do more because they are farther away from abstraction
> of the hardware. That doesn't mean that the resulting code generated
> is faster, it means that the Ada code is typically written farther
> away from the hardware level in the first place. I would imagine that
> a good C coder would consistently generate faster code than an Ada
> programmer would. There's much less chance that a C programmer would
> get very far away from the most optimized algorithms, since the
> abstraction is so close to the hardware level.
This is not necessarily the case. Optimizing true array access is a
lot easier than optimizing *p++. Ada makes a lot of guarantees about
array indexes being withing bounds in correct programs, etc.
Optimizers can also extract a lot of useful information from subrange
declarations. (I've only scratched the surface, 'cause I'd like to
finish this message this week...)
> Claims that Ada generates faster code seem like a straw horse to me,
> as Ada as a language reminds me so much of PL/I. Optimization by the
> compiler may be a good thing, but nothing beats code that is written
> cleanly in the first place.
Here at Tartan* we write Ada, C, and C++ compilers for embedded
systems ranging from MilStd 1750a, to DSPs (and just about everything
in between). Our Ada compilers outperform our C/C++ compilers for
every target where we support both -- with the exact same optimizer
and code generator -- assuming well-written idiomatic C and Ada. This
is because there's an awful lot of semantic information available in
an Ada program that is either not present or hard to compute in C.
Ada is MUCH more friendly to an optimizer than C or C++.
For a little more info, check out
Dean F. Sutherland
*Tartan was acquired by Texas Instruments in May, so I probably should
have written TI.
Return to the
Search the comp.compilers archives again.