Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mcnc!ecsvax.uncecs.edu!dukeac!wolves!ggw
From: ggw@wolves.uucp (Gregory G. Woodbury)
Newsgroups: comp.arch
Subject: Re: ATTACK OF KILLER MICROS
Message-ID: <1989Oct18.021003.501@wolves.uucp>
Date: 18 Oct 89 02:10:03 GMT
References: <35825@lll-winken.LLNL.GOV> <1081@m3.mfci.UUCP> <35896@lll-winken.LLNL.GOV> <MCCALPIN.89Oct16141656@masig3.ocean.fsu.edu>
Reply-To: ggw@wolves.UUCP (Gregory G. Woodbury)
Organization: Wolves Den UNIX BBS
Lines: 54

In article <MCCALPIN.89Oct16141656@masig3.ocean.fsu.edu> mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) writes:
>In article <35896@lll-winken.LLNL.GOV> brooks@maddog.llnl.gov (Eugene
>Brooks) writes:
>
>>Microprocessor development is not ignoring vectorizable workloads.  The
>>latest have fully pipeline floating point and are capable of pipelining
>>several memory accesses.  
>>[ ... more stuff deleted ... ]
>
>It is not at all clear to me that the memory bandwidth required for
>running vector codes is going to be developed in commodity parts.  To
>be specific, a single 64-bit vector pipe requires a sustained
>bandwidth of 24 bytes per clock cycle.  Is an ordinary, garden-variety
>commodity microprocessor going to be able to use 6 32-bit
>words-per-cycle of memory bandwidth on non-vectorized code?  If not,
>then there is a strong financial incentive not to include that excess
>bandwidth in commodity products....
>
	This is quite a statement.  Don't forget - even if the micro
can not make FULL use of a vector pipeline, including one will enhance
performance significantly.  The theoretical folks in this forum are quite
useful in the development of theoretical maxima, but even some partial
vector capabilities in a floating point unit will be greeted with joy.

	Lots and lots of "commodity" programs out there do things that would
benefit from some primitive vector computations.  Just in the past couple of
weeks we have had some discussions here about the price/performance
aspects of these "Killer Micros".  ( I do want to acknowledge that my
price figures were a little skewed - another round of configuration work
with various vendors has shown that I can find a decent bus speed and
SCSI disks in the required price range - thanks for some of the pointers!)

>
>In addition, the engineering/cost trade-off between memory bandwidth
>and memory latency will continue to exist for the "KILLER MICROS" as
>it does for the current generation of supercomputers.  Some users will
>be willing to sacrifice latency for bandwidth, and others will be
>willing to do the opposite.  Economies of scale will not eliminate
>this trade-off, except perhaps by eliminating the companies that take
>the less profitable position (e.g. ETA).

	This is an good restatment of the recent "SCSI on steroids"
discussion.  The vendor who can first put a "real" supercomputer or
"real" mainframe on (or beside) the desktop for <$50,000 will make a
killing.  Calling something a "Personal Mainframe" makes marketing happy,
but not being able to keep that promise makes for unhappy customers ;-)

-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>