🚀 go-pugleaf

In article <7766@thorin.cs.unc.edu> davis@cs.unc.edu (Mark Davis) writes:
>You can always improve bandwidth with silicon (and wires).  To double
>bandwidth, double the data bus size.  You can also use interleave or
>special chip modes (static column or page mode access) to improve
>bandwidth.
>

Within a chip, yes, one can widen the bus. Even there, routing problems
will restrict it. The 128 bit bus on the recent Intel chips seems to be
a pratical limit for now. 512 bit buses probably need triple metal levels
even in sub-micro processes.

Outside of a chip, I would have seriouse doubts about a very wide bus
unless you have lot's of money. A 128 bit bus with 32 bit address comes
to 160 pins before control line, add in power and ground, double it for
I & D, and we are looking at a packaging problem. Come to think of it,
ground bounce will probably make the packaging look easy.

My view is that even with interleave and page-mode, etc, we can make
execution cores and on-chip caches that are much faster than any bus.
Even in terms of raw bandwidth, but especially in latency time required.

>Can you rephrase your
>questions to discriminate between bandwidth and latency?
>

Actually, this question on bandwidth is my followup on the recent 
discussion. I am fustrated by bandwidth and latency at very turn; yet
all the people on the net seem to think bandwidth and/or latency is not
a problem. Is this because everyone know something I don't? Do I have
a particularly difficult problem?

Basically, I like get a feel for what other poeple think are the
bottle-necks. So comments on bandwidth *and* latency are appreciated.

The real hidden agenda is the old RISC-CISC war. If bandwidth is a real
problem, then RISC is not a good solution. [Oh no, did I just restart
a religous war?]


Stanley Chow   ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-pulic

What opinion? Did I say something? Come on, you wouldn't fire me just
because I didn't put in a disclaimer?