optimization (was Re: C vs. FORTRAN (efficiency))

[Tom Neff]

In article <1613 at mcgill-vision.UUCP> mouse at mcgill-vision.UUCP (der Mouse) writes:
>In article <14523 at bfmny0.UUCP>, tneff at bfmny0.UUCP (Tom Neff) writes:
>> <Burp> The fact is that every extra hour the applications wonk spends
>> trying to get the #*$&@# compiler or linker or OS loader to work, or
>> on the phone to some consultant, is worth billions of instructions on
>> any processor of his choice.
>
>Yeah, so what?  If I can shave 10% off of my compiles, that's a lot of
>time.  Suppose it takes me a week to save that 10%: then after I spend
>a total of nine weeks waiting for compiles, I've broken even: that
>would have been ten weeks.  After that it's clear gain. ...
>
>Now, if the compiler is sold to eight thousand customers...I'll let you
>work out the arithmetic for yourself. :-)

There is a fallacy in here somewhere.  Presumably we are now talking
about the application in question (to be optimized) being a compiler
itself, right?  So, if you speed the compiler up 10% and sell it to
8,000 customers, you can extrapolate truly impressive time savings on
paper, BUT none of that translates directly back to you, AND it's
running on 1,000 < N < 8,000 separate machines (in parallel as it were)
so much of the resource savings is spurious.  On an ideal, single
central, heavily loaded machine, you can reach the theoretical point
where X% of optimization yields X% more work done.  But that
configuration is a rarity in computing today.

Having said that, it's nice to have a faster compiler.  But there is no
such thing as a free lunch.  Was the release of the compiler delayed
three or four months while customers needing new features fretted, so
that this 10% optimization could go in?  Were two or three followup
patch levels required, with attendant customer confusion and frustration
and damage to the image of reliability, as latent bugs introduced by
this 10% optimization revealed themselves?  Did the competition see its
latest and greatest compiler version tested against some embarrassing
old swaybacked rev of your product in a leading computer magazine
review, because your own turbocharged 10%-optimized wonder beast was
still held up in the shop being cleaned up instead of loaded on the
reviewer's system?

This is what I mean when I talk about the distinction between
optimization for a purpose, versus optimization for its own sake.
Optimization is not some mystical state of grace, it is an intricate act
of human labor which carries real costs and real risks.  And it is
frequently resorted to for irrational reasons; computer wonks are proud
of being able to do it, so when they are not physically prevented from
optimizing, they tend to optimize.
-- 
"We walked on the moon --	((	Tom Neff
	you be polite"		 )) 	tneff at bfmny0.UU.NET