|optimizing compiler against iaverage assembly programmer. email@example.com (1997-06-15)|
|Re: optimizing compiler against average assembly programmer. firstname.lastname@example.org (Charles Fiterman) (1997-06-19)|
|Re: optimizing compiler against average assembly programmer. email@example.com (1997-06-20)|
|Re: optimizing compiler against average assembly programmer. firstname.lastname@example.org (Ralph Boland) (1997-06-24)|
|Re: optimizing compiler against average assembly programmer. email@example.com (Daniel Glastonbury) (1997-06-24)|
|Re: optimizing compiler against average assembly programmer. firstname.lastname@example.org (Walter Banks) (1997-06-30)|
|Re: optimizing compiler against average assembly programmer. email@example.com (1997-06-30)|
|Re: optimizing compiler against average assembly programmer. firstname.lastname@example.org (Norman Hilton) (1997-06-30)|
|Re: optimizing compiler against average assembly programmer. email@example.com (1997-06-30)|
|[14 later articles]|
|From:||firstname.lastname@example.org (Tom Lane)|
|Date:||20 Jun 1997 21:42:10 -0400|
|Organization:||Netcom Online Communications Services|
|Keywords:||assembler, optimize, practice|
email@example.com (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
Search the comp.compilers archives again.