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

["Tim Behrendsen" <tim@airshields.com>]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<4tkeuk$cu2@goanna.cs.rmit.edu.au>...
> In article <01bb7bfc$3c5ca460$96ee6fcf@timhome2> "Tim Behrendsen"
> <tim@airshields.com> writes: 
> >   Behrendsen's Law: "All optimizers are crap."
> 
> [paraphrase: Modern compilers *awesome*, global optimizations, run time
> [profiles for next compilation cycle. Humans too busy to/can't do this]

I'm not going to claim to have used every compiler, obviously, but
I base this opinion on often viewing the assembly language output when
I get a core dump or during debugging sessions.  Now, I've used a lot
of assembly language, so I usually write my C code to be easy on the
optimizer (use pointers when needed rather indexes, for example), and
I admit that sometimes optimizers are very good.  The problem is, the
compiler often doesn't have enough contextual information to know what
to do compared to the human writing the program, which bring us to ...

Global optimization: The compiler can often make decisions better
than the human can because of the large scope of global optimizations,
but again, the information needed to know when certain areas are
going to be used a lot versus other areas is not known at compile
time, which moves us to ...

Run time profiling/compiler feedback: This can certainly provide
good information back to the compiler, but it seems a little
dangerous.  I have not used this type of optimization, so my
opinion means little in this case, except for just my general
impression.  Anything other than a trivial program is going
to be very difficult to simulate real-world conditions in order
to get an optimal result.  The downside is if your test conditions
are wrong, you may end up with a "most pessimum" optimization.

It just seems to me that there is no substitute for a well
thought-out design.  Depending on the compiler to save bad design
is just a bad idea.

> >   We will never have an optimizer that can do as good a job
> >   as human optimization until we get "strong AI", but that would
> >   take an actual science of AI to exist (let's not get started on
> >   *that*!).  C is one of few languages that recognizes this.
> 
> You just haven't a clue about the things modern compilers can do, and do
do.
> Loop unrolling, strip-mining, vectorising, analysing the class hierarchy
so
> as to replace dynamic dispatch by inlined code, branch prediction based
on
> profiles, AND IT ALL HAPPENS EVERY TIME I RUN THE COMPILER.  What we get
> right now is better than almost every programmer there is, and we get it
> far cheaper.

The above are all worthwhile opimizations; I'm not claiming that
optimizers do nothing.  All I'm saying is that too often programmers
fall back on the lazy line, "Oh well, the compiler should take care
of that."  For example, if I have ...

for (i = 0; i < 10000000; ++i) 
    array[i] *= abs(values[i]);

Should I be *sure* this is going to be done efficiently, and use
pointers, or should I just let the compiler handle it? I say that
a competent programmer should use pointers out of habit, because
its just good design and practice.  And when the problem becomes
less trivial than the one above, the programmer will already be
using the proper techniques *the first time*, rather than having
to go back and fix the inevitable performance bottlenecks.

I think you are being too optimistic that optimizers produce
better code than "almost every programmer there is".  If that were
true, then projects would *never* be written in assembly language.

As it stands, we know that often times things are written in
assembly for performance reasons, such as device drivers.
The perfect example of this are computer games.  If your theory
were true, then they would all be written in high-level languages
to gain the best performance.  We know that this isn't the case,
however.  A bright human can always outdo the optimizer.

> And you know what?  C is one of the *harder* languages to optimise!

You are probably right, if you let the optimizer handle everything.
But C also gives the capability to do things such as ...

if ((array[++n] = GetValue(arg)) != 0) {
    ....

v.s. a typical non-C language ...

n = n + 1;
array[n] = GetValue(arg);
if (array[n] != 0) {
    ...
}

Now, which is easier to optimize?  For this trivial case, a
modern compiler would probably do exactly the same thing, but
what about when it starts getting non-trivial?  If I code my
expressions to take advantage of the "data flow" nature of C's
syntax, I can make it very easy for the optimizer to do a
great job.  And it's not any more work, it's just a matter of
experience and living in reality, and not pretending that the
compiler is smarter than it really is.

-- Tim Behrendsen (tim@airshields.com)