🚀 go-pugleaf

In article <130800001@peg> robert@peg.UUCP writes:
>Why should we welcome a continual increase in MIPS (VUPS or whatever)?
>We have enough trouble designing programs which work without error at the
>moment.  These will just get to the error state faster with more power.

You have a point; correctness is a first requirement for solving problems.
But there is a large class of problems which have an essentially unlimited
appetite for computational power.  Simulations, for example, seem to be like
fractals - no matter how precise you can make them, if you had about 10x
computing power you could make them more precise and do X or Y interesting
things with them.  For years now the engineering community has consistently
demanded MORE computational power to solve increasingly complex problems.

There is also the ever-increasing set of "basic" software without which users
of any sophistication will not do without.  Ten years ago, a lot of users
would have balked at the thought of spending "all those cycles and comm time
for all those checksums" in a scheme like TCP/IP.  Nobody (well, almost
nobody) thinks about the efficiencies of those checksums anymore - we'd rather
have the data "just get there, baby."  Graphical user interfaces are a good
example.  Five years ago, the MAC was slow because it spent all of its time
running the UI.  Now we all demand the graphics UI.  Networked windowing
systems are another example.  I'll wager that five years from now, network
window systems will become a sine qua non in software development.  And yet
it is only the most recent generation of inexpensive workstations (DEC3100,
DG Aviion, SPARCstation 1, HP 835) that have really had the gas to drive these
at acceptable speeds.

The horizon keeps moving out.  The expert systems that require the biggest
iron we can afford will become common -- even uninteresting -- subsystems of
software products, and the 10, 20, 100 mips that they consume (along with the
5 mips the window system consumes, and the .4 mips the network consumes) will
merely represent the overhead of "doing useful work" in the future.


And finally, for the collegue of mine who once snapped at the poor programmer
trying to debug a PL/I program using the optimizing compiler "I suppose it's
better to get the wrong answer faster?"  He was only half right - use the
checkout compiler on a faster box, so that you CAN get the wrong answer
faster - and then to fix it.

-- 
Brian Wong					Sun Microsystems
bwong@sun.com					Vienna, Va.  703-883-1243