🚀 go-pugleaf

In article <14235@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
> Good example.  It demonstrates the point I've been making all along!
> Ther are optimizations that the compiler can't yet do well.  There _may_
> be optimizations that compilers will _never_ be able to do.  It is these
> types of things that programmers should spend their effort on.

Finally, we agree! The argument is one of degree: how much time to invest
in optimizing various ``levels'' of a program. You trust your compilers
to do a good job of strength reduction, array indexing, common expression
elimination, and so on, so you don't worry about them. I'm more cynical,
so I write things like #ifdef HANDOPT ... #else ...  #endif in critical
sections of a program. (As long as I remain consistently better at this
than my machine's optimizer, I'll keep doing it.)

In any case, neither of us bothers with trivial optimizations, and both
of us worry about major changes.

  [ hand optimizations ]
> They are also things which
> decrease the clarity of the code.

How? 

In one program using FFT-related methods I use a reverse(n,bits) function.
n can be very large, up to 2^30. First I wrote out the obvious code. Now
it's in comments, replaced by very fast code and a precomputed 128K table.
You might just leave the slow version, as it only took 10% of the program's
time before optimization.

How is my version any less clear than the original? If you want to
understand the ``real'' workings of the code, the original is still
there for you to see. It's in comments, but it's there.

You shouldn't criticize hand optimization. You should criticize the
poor coding practice of throwing away the unoptimized version.

---Dan