Some optimization results

[Dan Bernstein]

In article <3501 at charon.cwi.nl> dik at cwi.nl (Dik T. Winter) writes:
> It is silly to call something an optimization when it is nothing more than
> a work-around for a compiler bug.

Hold on. The ``bug'' here is simply that the compiler missed an
optimization. Do you mean to imply that any compiler which misses any
optimization is buggy?

I don't think so. In fact, I don't believe that compilers in the
foreseeable future will come even close to humans in optimization skill.
(That's why I want to see the optimizer work with the programmer, rather
than against him.)

In this case, you're right: someone who knew the Cray compiler could
introduce appropriate directives to vectorize O'Keefe's code. But what
about next time? And what about all the people who don't have a Cray?

On any given bottleneck, someone could either do the obvious big
optimizations and stop, or do every optimization that he can see that
will gain a few percent. Which strategy is better? The second has two
disadvantages: the programmer takes some time looking for simple, small
reorganizations, and that section of code will end up somewhat longer.
But it will make the code run faster on a whole bunch of machines---not
just once, but forever.

There will always be some compilers that don't see optimization X.
Someone who does X by hand will get the speedup---without even seeing
the compiler. In fact, when he writes the code, the compiler may not
even exist, but his code will still run fast when it's ported later.

I can keep pointing out how hand optimization gives huge speedups. Are
you going to say each time that the compiler is buggy? Okay, fine. Then
there are a shitload of ``buggy'' compilers in the world, and it makes
more sense to realize this fact than to pretend that hand optimization
doesn't work.

---Dan