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

[wheeler@aphrodite.csed.ida.org (David Wheeler)]

In article <01bb7e2f$aeef4660$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:

:   > 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.

Actually, the assumption that C pointers always (or even usually)
generate better machine code is an urban legend.  On many
computer/compiler combinations, using arrays generally yields BETTER
performance.  This isn't just a recent occurance -- I changed C code
running on 8086's from using pointers to using arrays and produced
noticeable improvements.  This was a stupid C compiler, too.  AND I've
found that arrays are less likely to have bugs in them.

When you're _really_ concerned about performance, try different
approaches and MEASURE.  If you aren't measuring, then you aren't
very concerned about performance.  Code that gives the optimizer more
information (e.g. arrays not pointers) will often give better results
because it gives the optimizer more information to work with.  Sometimes
that isn't true, which is one reason why you need to measure.

If you're interested in performance, take a gander at the example
where a novice Ada coder beat experienced assembly language programmers (!)
because the optimizer could try out more approaches than the experts:
 [Elam 1992] Elam and Lawlis.  March 1992.  ``Ada Whips Assembly''.
   "http://www.seas.gwu.edu/seas/eecs/Research/ada/lawlis.html"

--- David