Re: C is 'better' than Ada because...

[Tim Behrendsen <tim@airshields.com>]

On Thu, 1 Aug 1996, Keith Thompson wrote:

> In comp.lang.ada you write:
> 
> I don't believe C's expression syntax or close-to-the-metal pointers are
> particularly good for optimization.  They're good for making it easy to
> do straightforward compilation, and allowing source-level optimization.
> This made a lot of sense back when C was first developed.
> 
> An optimizing compiler typically has to build up some fairly high-level
> information about the structure of the program.  It then analyzes this
> structure, rearranges it for greater speed and/or smaller code size,
> and generates executable code (or assembly language, or whatever).
> If the language uses a lot of very low-level constructs, the compiler
> has to synthesize the higher-level information.
> 
> [interesting optimization examples snipped for brevity]

Unfortunately, it's very difficult to find good examples of things
that are difficult to optimize, because a case can always be made
for a specific optimization.  In my experience, optimizers are usually
strong in some areas, and weak in others.  Unfortunately, every one
is weak/strong in different areas.

Let me try this from a different direction.  Let's say I have the
theoretically perfect optimizer.  The perfect optimizer is capable of
taking HLL code and producing the absolute most efficient translation to
assembly.  It is not capable of improving the algorithms, of course;
a O(n^2) algoirthm is not going to improve to O(n).

Now, if I have a perfect optimizer I should be able to arrange my
code in *any* algorithmically valid sequence, and it will still produce
the same code by definition.  In fact, I should be able to toss in
red-herring code and it will drop out because it adds nothing to
the algorithm.

OK ... back to the real world.  We know that this isn't the case, and
we have to use *some* responsibility when coding our programs to not
doing something so boneheaded that the optimizer can't save us.

So, here's the question, then.  Where is the middle ground?  Given that
optimizers do not approach the ideal, how does a programmer know what's
going to be optimized efficiently, and what isn't?  I submit that it's
valuable to for a language to be capable of structuring the syntax such
that the optimizer can do straightforward job on it.

The thing about C is that the syntax is so loose and fast, naively coded
subroutines can defeat the optimizer just from the side effects.  How
about this; I'm just thinking off the top of my head, but perhaps there
is a "range of optimization" for a language.  Given a language, the
syntax has a certain range of flexibility.  For the C language, it is
extremely flexible in the number of ways something can be coded.  This
produces a wide range of optimization efficiency.

Would it be fair to say that Ada has less structural flexibility, but
you gain more consistency in optimization?  If this were true, then
it could be said that a carefully programmed C program could potentially
be faster, but the skill level required for the average optimization
efficiency for C is much higher than Ada (or another more rigid language).

The above is off the top of my head; does any of that make any sense?