Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!littlei!omepd!mipos3!blabla!kds
From: kds@blabla.intel.com (Ken Shoemaker)
Newsgroups: comp.arch
Subject: Re: One aspect of bandwidth (backplane bus)
Message-ID: <3915@mipos3.intel.com>
Date: 17 Apr 89 19:07:51 GMT
References: <407@bnr-fos.UUCP> <17500@obiwan.mips.COM> <17527@winchester.mips.COM>
Sender: news@mipos3.intel.com
Reply-To: kds@blabla.UUCP (Ken Shoemaker)
Organization: Santa Clara Microprocessor Division, Intel Corp., Santa Clara, CA
Lines: 47

In article <17527@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>In article <17500@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes:
>.....
>>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 :-).
>
>3) it is pretty easy to look ahead just a few years, to see how to build
>systems in the 500-1000-VUPS range, which could fit in a deskside (large
>deskside) package, if you wanted, assuming you could build a main
>memory bus in the 750-1500MB/sec region......
>
>4) Does anybody know of anything like that being proposed as a standard?
>No? well, it looks like we're in for a lot more multiple-bus architectures...:-)

Well, large memory arrays tend to be long latency/fast transfer time
devices, so supporting multiple outstanding requests seems like a good
start.  As for speed on the bus, I believe that the Futurebus supports
asynchronous transfers running just as fast as the handshaking lines can
wiggle.  And it also supports a distributed multiprocessor cache consistency
protocol.  How nice.  Also, large, multi-level caches tend to favor long
line sizes (well, the multi-level is kinda superfluous to the point, but is
probably necessary for the system implementation) which fits well in all
this.

On chip caches can also take care of lots of the processor to memory
bandwidth, but you don't want to make them too large(!) because as you make
them larger, they get slower (even if they are on chip).  The good news is
they don't have to be tremendously huge to have an effect.  Our measurements
of the 8K i486 cache shows a better than 90% hit ratio for a large number of
program traces run on the Sun 386i.  And this is for both user and system
code.  Of course, your mileage will vary.  And in a large multi-processor
system, you would still want to have a second level (external) cache, but it
would have to be at least 256K to make a difference (reference to an Alliant
(?) paper from a while ago about using multi-level caches in a large,
multiprocessor system).

And as for I/O, maybe the next generation of systems will use their mips 
to do something besides generating I/O requests.  The kind of thing that 
the MIPS guy at Comdex said absolutely requires "risc performance" 
(whatever that means, maybe VUPS will become RUPS or RIPS) to do.  
Nah, too radical a thought.
----------
I've decided to take George Bush's advice and watch his press conferences
	with the sound turned down...			-- Ian Shoales
Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California
uucp: ...{hplabs|decwrl|pur-ee|hacgate|oliveb}!intelca!mipos3!kds