Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!mintaka!shaw
From: shaw@abp.lcs.mit.edu (Andy Shaw)
Newsgroups: comp.arch
Subject: Memory Bandwidth vs. Processor Speed
Message-ID: <1990Jan5.193511.3879@mintaka.lcs.mit.edu>
Date: 5 Jan 90 19:35:11 GMT
References: <34030@mips.mips.COM> <4322@nttmhs.ntt.JP> <39807@ames.arc.nasa.gov>
Sender: news@mintaka.lcs.mit.edu
Reply-To: shaw@au-bon-pain.lcs.mit.edu.UUCP (Andy Shaw)
Organization: Laboratory for Computer Science, MIT
Lines: 23

In article <39807@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>It is interesting to contemplate $100-300K systems, like the SGI Power Series,
>with each CPU based on an 80MHz R6000.  The possibility is there for a
>system which looks like a Cray scaled down by a factor of about 5 for scalar
>work, a factor of 15 for vector work.  At a cost of 1/30 - 1/100.  What would
>prevent this from happening?  Memory bandwidth could.  Nobody 
>really wants to talk about this in public, but I bet a lot of people are
>staying up nights trying to figure out how to scale up memory bandwidth
>with processor speed.  Cheaply (If you build it like Cray does, it will
>cost like a Cray).

Actually, I was under the impression that this was no big secret --
memory bandwidth and latency are going to be the limiting factors in
the speed of computer systems (both parallel and serial) of the very
near future.

Am I wrong to say "latency" in the same sentence with "bandwidth"?  I
don't really think that they are separate issues.  I don't think
anything spectacularly interesting has been done about memory
bandwidth or latency recently -- registers, caches, and interleaving
are all old, old ideas ... what else has come around?

-Andy Shaw