Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!ucbvax!pasteur!sprite.berkeley.edu!tve
From: tve@sprite.berkeley.edu (Thorsten von Eicken)
Newsgroups: comp.arch
Subject: Re: Memory Bandwidth vs. Processor Speed
Message-ID: <21010@pasteur.Berkeley.EDU>
Date: 5 Jan 90 21:07:16 GMT
References: <34030@mips.mips.COM> <4322@nttmhs.ntt.JP> <39807@ames.arc.nasa.gov> <1990Jan5.193511.3879@mintaka.lcs.mit.edu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: tve@sprite.berkeley.edu (Thorsten von Eicken)
Organization: University of California, Berkeley
Lines: 15

In article <1990Jan5.193511.3879@mintaka.lcs.mit.edu> shaw@au-bon-pain.lcs.mit.edu.UUCP (Andy Shaw) writes:
>Am I wrong to say "latency" in the same sentence with "bandwidth"?
Yes, you can very often trade off latency versus 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?
Multithreading RISC processors is about to come around, i.e. having multiple
process/thread contexts loaded in you processor and switching context whenever
a long memory operation get initiated.
>
>-Andy Shaw

-Thorsten von Eicken, tve@sprite.berkeley.edu