Re: optimizing compiler against average assembly programmer.

gclind01@starbase.spd.louisville.edu (George C. Lindauer) writes:
> I was thinking about the assertion 'a good optimizing compiler will
> nearly always outcode a moderately proficient assembly programmer'.
>
> Clearly, this is true if I do what proponents of this always suggest,
> that is compare single procedures as written by an average programmer
> and as generated by a compiler.


Huh? The version of this assertion that I subscribe to goes the exact
opposite way: on a small (procedure-sized) chunk of code, a reasonably
proficient *and motivated* assembly programmer can beat any compiler.


The programmer's problem is that he can't maintain that level of
tenseness over all of a multi-megabyte application. At least not if
he'd like to ship a finished app while it's still relevant. But the
compiler never gets bored, nor tired, so *on the average* over a large
pile of code it can beat the assembler programmer.


I believe the above argument holds good even if one just considers the
machine-language-level optimizations that one would normally expect a
compiler or good assembly programmer to perform. But in reality
there's more to consider. Freed from machine-level details, the human
programmer using a compiler can spend his time defining better
algorithms or optimizing system-level considerations. The assembly
programmer is unlikely to have the time to consider any optimizations
at higher design levels. So the programmer using a compiler is likely
to be able to leave the assembly programmer in the dust.


There's a famous paper by (IIRC) Raj Reddy et al, circa early 70s,
that describes six separate levels of design in a speech-understanding
system, and gives reasons to think that a factor-of-ten speedup at
*each* design level might be achievable compared to what was then
state of the art. Multiply it out, and you get a speedup factor of
one million. *That* is the real reason why humans should not be
spending their time doing assembly programming, except perhaps on
critical hotspot routines identified by profiling. Don't try to
replace a compiler; use it to multiply your own abilities.


(Anyone have the exact citation for Reddy's paper? It was in an
AI-flavored journal, I think, but it should be required reading for
every computer scientist.)


regards, tom lane
--

Return to the comp.compilers page.
Search the comp.compilers archives again.