🚀 go-pugleaf

In article <407@bnr-fos.UUCP> schow@leibniz.uucp (Stanley Chow) writes:
>In a recent series of articles about address modes and other topics,
>some posters claim that memory bandwidth is not a problem - to quote
>Brian Case, "bandwidth can be had in abundance". I happen to think that
>we do not enough bandwidth now. What to other people think?
> 
>[ ... parallel/multi-processing.]


Seems to me that backplanes (or, in general terms, processor-to-
main-storage data trunks) are nearly pooped out.  At least for the
kinds of air cooled, medium-priced computers that tend to have
microprocessors for CPUs.

For example, the 20-VUP {1 VUP == 1 VAX-780 unit of performance}
"M/2000" machine transfers 32 data bits (+ checkbits, etc) per
40 nsec, over a backplane that's about 1/3 meter long.  This is
traffic between the 128 kbytes of cache and the dRAM.

Wow.  100 Mbytes/sec for a 20-VUP uniprocessor.  Imagine what will
be needed to keep a multiprocessor fed, where each of the processors
is 60-VUPS or more.  Bigger caches alone won't solve the problem;
hit rates are pretty good already with `only' 128 kbytes of cache.
Plus there may be extra backplane traffic, over and above the
necessary CPU<->memory transfers, to implement coherency.  Yuck.

Wider datapaths _might_ get a 4X improvement, if you don't mind
paying for 128 wires.  And slick electrical wizardry like Bandgap
Transciever Logic (TM nat'l semi) might allow a backplane bus
containing 12 card slots to perform one transfer per 20 ns, giving
another 2X improvement.  But we still need another 3X to keep
an 8way x 60VUP multiprocessor from starving!

And that's just for the very next generation of air cooled, medium
priced CPU --- 60 VUP performance is eminently forseeable in the next
6 to 24 months (schedule varies depending upon who you talk to :-).
Soon thereafter it will be 1994, when you can buy 125-250 VUP micros
for cheap, and when the few remaining software issues concerning
32-way multiprocessors will be solved :-).  *Those* kinds of machines
will, um, provide a challenge for the processor-to-memory
data transfer engineers.
-- 
 -- Mark Johnson	
 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
	...!decwrl!mips!mark	(408) 991-0208