Re: optimizing compiler against iaverage assembly programmer.

lehotsky@tiac.net (Alan Lehotsky) says:
>>>>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 Cutler was the Chief Architect of Digital's VMS. He's also the
>guy responsible for the design of Windows/NT.
>
>Dave was one of the must incredible assembly-language coders I have
>ever seen; he was incredibly prolific and generated very clever code.
>
>Large portions of VMS were written in Bliss (a language designed
>around the goal of writing optimizing compilers). The VMS library
>routine fao (formatted ascii output, essentially printf()) was written
>in Bliss.
>
>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.


      And how much faster was it? Any idea? Are you telling me the
Bliss version didn't have any bugs in it when it was first released?
Like most anecdotes, this is a nice story but has little meaning in a
discussion of fact.


>My contention is that a good programmer with an optimizing compiler
>will usually beat a very good assembly language programmer in all but
>the most restrictive environments (e.g. real time, limited memory and
>or REALLY bizarre architectures like DSPs).


      Doubtful. I have yet to see a non-trivial routine that couldn't be
improved by a good machine level programmer.


>Remember that programmer time is USUALLY the quantity that is most
>expensive, and in least supply. Besides there just aren't that many
>assembly language programmers who really do know what they're doing!


      I think the millions of users that must sit and wait for bloated
compiler generated code to execute time after time, day after day,
week after week, month after month, year after year, is MUCH more
valuable than a few extra months of effort spent by a few well trained
programmers. The *reason* there arn't that many good machine level
programmers around is part of this self-fulfilling prophecy that is
perpetuated by all the HLL pushers. The other reason that people find
machine-level coding objectionable is because of the archaic tools
they are using. There *are* tools today that can make machine level
code as simple to read/maintain as HLL. Using HLL benifits ONLY the
software producer, NOT the end user. It ONLY benifit it could have
for the user is quicker time to market. OK, so release a HLL version
to get it out there and then at a later date (if the volume is there)
re-write it at the machine level for the benefit of ALL users.


                  Jim Neil
            Creator of The
TERSE Programming Language
      http://www.terse.com
      jim-neil@digital.net
      ISBN: 0-9652660-0-1
[I've heard this theory before, but I've never known of a product that
was later rewritten in assembler. Indeed, it's much more common to go
the other way, e.g., early versions of 1-2-3 were in assembler, later
versions in C. -John]
--

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