Re: optimizing compiler against iaverage assembly programmer.

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


I have. I am quite good at writing excellent assembly code (at one
time or another in several architectures). Once I was optimizing a
radiation transport code for use on small/slow 360s. The Fortran H
compiled code, profiled to be spending 45% of its time in a single
routine (it did a dot product, followed by a vector/matrix multiply,
followed by some other operation -- this was 20 years ago -- and
returned an array of values for sorting). The code was about 700-800
instructions long. I never beat the compiler without failing on one
of the functional tests. The register scheduling and global
optimization was beyond what a normal human could handle without
obscene numbers of hours and obscene quantities of notes. And I am
not now, nor was I then, "a good machine level programmer." If I
could not improve that code, perhaps two or three programmers in the
world, no more, might have been able to do so (I am also somewhat
conceited about this issue).


On the other hand, I have seen no such code in the past 12 years I've
worked with PC compilers.


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


I disagree. If a significant number of people were of this opinion,
there would be a market for such programs. And there is not. I used
to know many shareware authors that felt this was so, none of them
ever broke into the market dominated by bloatware. Why? Because the
price of the software, and the rate of change of features are the keys
to success. Wait time (user wait time, that is, not programmer wait
time) is just not important to most users.


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


You miss the point of <rate of change of feature set>. There is no
market 6 months later.
--

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