const, volatile, etc [was Re: #

[mcdonald at uxe.cso.uiuc.edu]

>To put it bluntly, that's rubbish.  There are plenty of people out there
>who can, I suspect, testify that yes, indeed, optimizing C compilers
>*can* produce better code than non-optimizing ones, *even when the C
>source is, in some sense, "good" code.*

I can and I will so testify. (I sent the exact timings to the persons
involved by mail, but maybe it really is generally interesting.)
I tried compiling the original anti-optimizer flamer's matrix
code with optimizations turned off. It took about 24 seconds to run.
Putting in his pointer optimizations reduced the time time to 16 seconds, 
as did running the optimizer on the original. BUT, running the
optimizer on the pointerized code, the executable took 8 seconds.
Looking at the assembler output showed that the optimizer was working
on the floating point part of the code, while the gruesome pointer
stuff did the addressing faster.

(IBM PS/2-80 under Micro-way NDP-C. [NDP stands for Numerical Data
Processor - maybe that's why they worked so hard on the floating optimizer.])

Doug McDonald

P.S. The posted pointer code looks, and is, sickening. But I have started
using similar stuff in my own code. ( Yes, I stuck in the lines

#ifdef CRAY
   puts("The matrix multiply may not vectorize");
#endif
)