Xref: utzoo comp.arch:16984 comp.lang.misc:5109
Path: utzoo!attcan!utgpu!watserv1!maytag!watdragon!watsol.waterloo.edu!tbray
From: tbray@watsol.waterloo.edu (Tim Bray)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Compiler Costs
Message-ID: <1990Jul7.183325.8135@watdragon.waterloo.edu>
Date: 7 Jul 90 18:33:25 GMT
References: <1797@apctrc.UUCP>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
Lines: 30

zrra07@backus (Randall R. Appleton) writes:
>In other words, if I take my average well written program, compiled
>with a good optimizing compiler, and re-write it in assembler, what sort
>of speedup should I expect to see?

Isn't "average well written program" an oxymoron?

The speedup, as several people have pointed out, is difficult to predict.  In
general, however, the *cost-effectiveness* is liable to be negative.  If the
program is used heavily enough that hard-won speedups look attractive, it
will require regular maintenance as people's needs change.  Performing this
maintenance on assembler code is apt to be dramatically more difficult and
burn tons of expensive programmer time.

Second, a *really* cost-effective way to make a program faster is to run
it on this year's hot chip, probably twice as fast as your current computer
if it's > 18 months old.  But if you've committed to one architecture by
going to assembler, you've closed that door.

Third, as some have already said, but it can't be said too often, the
expected performance improvement per unit effort from repeatedly profiling
your code and whittling away at the algorithms in the critical areas is
typically dramatically greater than that for assembly hacking.  And the
results are portable.

Yup, assembler hacking is a dying art, thank goodness.  But I'm glad I'm
old enough to have done it.  Doing serious work with VAX assembler was
out and out *fun* - I suppose hunting dinner with a stone knife was too.

Cheers, Tim Bray, Open Text Systems