Re: optimizing compiler against average assembly programmer.

tgl@netcom.com (Tom Lane)
20 Jun 1997 21:42:10 -0400

          From comp.compilers

Related articles
optimizing compiler against iaverage assembly programmer. gclind01@starbase.spd.louisville.edu (1997-06-15)
Re: optimizing compiler against average assembly programmer. cef@geodseic.com (Charles Fiterman) (1997-06-19)
Re: optimizing compiler against average assembly programmer. tgl@netcom.com (1997-06-20)
Re: optimizing compiler against average assembly programmer. rboland@csi.uottawa.ca (Ralph Boland) (1997-06-24)
Re: optimizing compiler against average assembly programmer. dglaston@asc.corp.mot.com (Daniel Glastonbury) (1997-06-24)
Re: optimizing compiler against average assembly programmer. walter@bytecraft.com (Walter Banks) (1997-06-30)
Re: optimizing compiler against average assembly programmer. gclind01@starbase.spd.louisville.edu (1997-06-30)
Re: optimizing compiler against average assembly programmer. norman@kbss.bt.co.uk (Norman Hilton) (1997-06-30)
Re: optimizing compiler against average assembly programmer. debray@cs.arizona.edu (1997-06-30)
[14 later articles]
| List of all articles for this month |

From: tgl@netcom.com (Tom Lane)
Newsgroups: comp.compilers,comp.lang.asm.x86
Date: 20 Jun 1997 21:42:10 -0400
Organization: Netcom Online Communications Services
References: 97-06-071
Keywords: assembler, optimize, practice

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
--


Post a followup to this message

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