🚀 go-pugleaf

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <66071@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> _ALL_ production quality compilers I've ever used on mainframes can do
>> much better than all but the most adept programmer at this optimization.
>> Further, the adept programmer can usually do no better than the compiler.

>What?! This is absolutely unbelievable. In one of my last few articles I
>had a paragraph listing some of what a competent hand optimizer does
>regularly. A simple example
> [convoluted example]
>A less trivial example: In a heavily hand-optimized implementation of
>Nussbaumer's convolution method

Give us a break, Dan!  Both of the examples you've given represent changes
of *algorithm* based on foreknowledge of possible input values, a type of
optimization of which nobody expects compilers to be capable, at least not
in this century.  I guess in some distant future there will exist compilers
that can recognize and replace inferior algorithms with more efficient ones,
but that's irrelvant to your disagreement with Jim Giles.  What he was
talking about was an optimization that, in essence, merely rearranges the
order of evaluation of intermediate results.

I think most people admit that your obviously high opinion of your own
programming skills may not be entirely unjustified, but not everyone is
so talented.  There are many programmers out there who simply don't do
even the simplest types of hand optimizations, who write really crappy
code, and because they are so numerous I would say that it's perfectly
reasonable for compilers to optimize as aggressively as their creators
can make them.  Obviously, this should be done without sacrificing any
correctness, and may not do much for "adept" programmers, but for the
code produced by run-of-the-mill types optimization has always been a
very big winner.
--

Jeff d'Arcy, Generic Software Engineer - jdarcy@encore.com
      Nothing was ever achieved by accepting reality