Re: optimizing compiler against iaverage assembly programmer.

Alan Lehotsky wrote:


> >>>I was thinking about the assertion 'a good optimizing compiler will
> >>>nearly always outcode a moderately proficient assembly programmer'.
>
> Let me add an anecdote on this topic.
> [.....]
> Dave decided that it was TOO big, and slow, so he rewrote it in
> assembly language. The version he checked in was something like 12
> bytes LARGER than the compiler-generated code AND it had two bugs that
> were later uncovered.


Maybe one "real world" example deserves another.


A number of years ago, I implemented a (fairly complete) clone of the
UNIX utility "grep" in 8086 assembly language for MS-DOS.


As a standalone executable, in MS-DOS binary image format, "xgrep.com"
comes out at exactly 3380 bytes.


Stripping only English language text (a copyright statement, all error
messages, and a full screen of usage information) reduces this to just
2284 bytes.


Apart from obvious functionality, that 2.2K includes logic for full
UNIX getopt-style option parsing, the expansion of MS-DOS '?' and '*'
wildcards, recursive subdirectory searches, and some moderately
sophisticated error-handling.


"xgrep.com" is still fairly widely-used, is one of the faster MS-DOS
implementations around, and (particularly important on MS-DOS) needs
just 64K of memory. Of all my projects, implemented in a number of
(mostly high-level) languages, "xgrep" also has the distinction of
having gone out the door with the fewest number of (subsequently
discovered) bugs.


I'm certainly not detailing all this as if it were some marvel of
software engineering. (From my current perspective, the whole effort
was a staggering waste of time). But the example does relate to the
kind of implementation issues that will be familiar to those on this
list.


And if we're talking about optimizing for size (which, on the target
8088 processor of the time, pretty much amounted to optimizing for
speed), I think any optimizing compiler would have great difficulty
coming close.


However, in my view (and this is largely my point), statements of the
"optimizing compiler versus assembly language programmer" kind are so
general as to be, essentially, meaningless. (It all depends on the
processor; it all depends on the task; it all depends on the criteria
used for comparison....)


These vague and portentous pronouncements become contentious when
people apply them to the aspects of the "real world" that interest
*them*. But what inevitably follows is an argument about definitions,
not about any ultimate "truth content".


--
Robert Nordier
--

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