Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!udel!burdvax!gvlv2!kleonard
From: kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard)
Newsgroups: comp.arch
Subject: Re: ATTACK OF KILLER MICROS
Message-ID: <359@gvlv2.GVL.Unisys.COM>
Date: 17 Oct 89 13:27:48 GMT
References: <35825@lll-winken.LLNL.GOV> <12070@cgl.ucsf.EDU>
Distribution: usa
Organization: Unisys Defense Systems, NISD, Great Valley Laboratory
Lines: 45

In article <12070@cgl.ucsf.EDU> seibel@cgl.ucsf.edu (George Seibel) writes:
* In <35825@lll-winken.LLNL.GOV> brooks@maddog.llnl.gov wrote:
* > On scalar codes, commodity microprocessors ARE the fastest machines at
* > any price and custom cpu architectures are doomed in this market.
* 
*    Speaking of "commodities",...
* ...
* *commodity Mflops*.  The issue is no longer performance at any cost, because
* if it was you would order another machine at that point.   The important
* thing is Mflops/dollar for most people, and that's where the micros are
* going to win in a lot of cases.
---- well, first...
Maybe, even, the _commodity_ is _not_ _M_flops per dollar, but just
_flop_flops per dollar?   That is, if the cycle time to "set up the problem",
"crunch the numbers", "get the plot/list/display" is under _whatever_ upper
limit fits with _my_ mode of "useful work", then I very likely _do_not_care_
if it gets any shorter (i.e. if the _flop_flops per second per dollar goes
higher).  This becomes, IMHO, even more significant if my "useful" cycle time
is available to me _truly_ whenever _I_ darn well feel the need.
All of which works, again, to the advantage of microcrunchers.
---- and, second...
A non-trivial part of the demand for megacrunchers, IMHO, stems from
solution methods which have evolved from the days when _only_ "big"
machines were available for "big" jobs (any jobs?) and _just_had_to_be_
shared.  For what _I_ do, anyhow, (and probably a _lot_ of other folk
somewhere out there), the "all-in-one-swell-foop" analyses/programs/techniques
are not the _only_ way to get to the _results_ needed to do the job--and
they may well _not_ be the "best" way.  I often find that somewhat more of
somewhat smaller steps get me to my target faster than otherwise.  That is,
if I can only get 1 or 2 or 10 passes per day through the megacruncher, the
job takes more work from me and more time on the calendar and more bucks from
whoever is paying the tab, than if I can just as many as I need of smaller
passes.
---- also third...
And those smaller passes may well be easier (and thus faster) to program,
and more amenable to validation/assurance/etc.
And they may admit algorithms which work plenty fast on a dedicated machine
even if it is pretty small but would not work very fast at all on a shared
machine even if it is quite big (maybe especially because it is "big
architecture").
---- so, finally...
I believe in micros.
-------------
regardz,
Ken Leonard