Path: gmdzi!unido!mcsun!uunet!convex!texsun!newstop!sun-barr!
cs.utexas.edu!mailrus!purdue!mentor.cc.purdue.edu!pur-ee!csh
From: c...@pur-ee.UUCP (Craig S Hughes)
Newsgroups: comp.arch
Subject: RISC multiprocessors
Keywords: RISC,multiprocessors,parallel
Message-ID: <13319@pur-ee.UUCP>
Date: 2 Nov 89 18:27:55 GMT
Organization: Purdue University Engineering Computer Network
Lines: 12
Posted: Thu Nov 2 19:27:55 1989
Does anyone know of commericial implementations of bus-based
multiprocessor RISC machines? I know about the DG AVion file server, and
an 8-processor 88K based multiprocessor from Tadpole Technologies that
uses the Motorola Hypermodule.
If there's interest, I'll post my summary to the net. I think machines
based on these processors could give their CISC counterparts (eg
multimax, sequent etc.) a real run for the money.
--craig hughes
c...@ec.ecn.purdue.edu
Path: gmdzi!unido!mcsun!sunic!maxim!prc
From: p...@erbe.se (Robert Claeson)
Newsgroups: comp.arch
Subject: Re: RISC multiprocessors
Keywords: RISC,multiprocessors,parallel
Message-ID: <1012@maxim.erbe.se>
Date: 4 Nov 89 14:57:54 GMT
References: <13319@pur-ee.UUCP>
Organization: ERBE DATA AB, Jarfalla, Sweden
Lines: 15
Posted: Sat Nov 4 15:57:54 1989
In article <13...@pur-ee.UUCP> c...@pur-ee.UUCP (Craig S Hughes) writes:
>Does anyone know of commericial implementations of bus-based
>multiprocessor RISC machines?
.....
>I think machines based on these processors could give their CISCi
>counterparts (eg multimax, sequent etc.) a real run for the money.
Maybe not. What if one of the current CISC parallel machine vendors should
decide to make a RISC parallel machine?
--
Robert Claeson E-mail: rclae...@erbe.se
ERBE DATA AB
Path: gmdzi!unido!mcsun!ukc!strath-cs!jim
From: j...@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.arch
Subject: Re: RISC multiprocessors
Keywords: RISC,multiprocessors,parallel
Message-ID: <516@baird.cs.strath.ac.uk>
Date: 6 Nov 89 14:30:43 GMT
References: <13319@pur-ee.UUCP> <1012@maxim.erbe.se>
Sender: n...@cs.strath.ac.uk
Reply-To: j...@cs.strath.ac.uk
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 27
Posted: Mon Nov 6 15:30:43 1989
In article <1...@maxim.erbe.se> p...@erbe.se (Robert Claeson) writes:
>In article <13...@pur-ee.UUCP> c...@pur-ee.UUCP (Craig S Hughes) writes:
>>I think machines based on these processors could give their CISCi
>>counterparts (eg multimax, sequent etc.) a real run for the money.
>
>Maybe not. What if one of the current CISC parallel machine vendors should
>decide to make a RISC parallel machine?
A RISC based multiprocessor machine would be an exciting prospect, but
is likely to be difficult and expensive to build. If it used the same
basic architecture as the Sequents and Encores, it would need a *very*
fast bus. The current machines have backplanes rated at around 100
Mbytes/sec which is good enough for up to 20 or 30 so microprocessors like
the 80386 or 32532. RISC processors require high memory bandwidth. Either
the existing busses would support fewer processors or new busses that are
much faster (and expensive) will be needed. Another option would be to
add loads of cache memory to keep the RISC chips off the system bus.
Of course, fancy cacheing can reduce the demands on bus bandwidth, but
that will make cache consistency harder and also push up the costs:
"lots" of cache memory won't be cheap. Of course, cache consistency for
multiple RISCs isn't exactly easy when the processors use on-chip caches
for speed. Sequent (and no doubt Encore) use off-chip caches that can
snoop on the system bus. How you'd do that with a RISC processor with an
on-chip cache is not immediately obvious.
Jim
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!usc!apple!mips!mash
From: m...@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: RISC multiprocessors
Keywords: RISC,multiprocessors,parallel
Message-ID: <30969@winchester.mips.COM>
Date: 7 Nov 89 20:10:45 GMT
References: <13319@pur-ee.UUCP> <1012@maxim.erbe.se> <516@baird.cs.strath.ac.uk>
Reply-To: m...@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 26
Posted: Tue Nov 7 21:10:45 1989
In article <5...@baird.cs.strath.ac.uk> j...@cs.strath.ac.uk writes:
......
>A RISC based multiprocessor machine would be an exciting prospect, but
>is likely to be difficult and expensive to build. If it used the same
>basic architecture as the Sequents and Encores, it would need a *very*
>fast bus. The current machines have backplanes rated at around 100
>Mbytes/sec which is good enough for up to 20 or 30 so microprocessors like
>the 80386 or 32532. RISC processors require high memory bandwidth. Either
>the existing busses would support fewer processors or new busses that are
>much faster (and expensive) will be needed. Another option would be to
>add loads of cache memory to keep the RISC chips off the system bus.
This is all true, but just to make sure there is no ambiguity,
and to head off a potential argument:
1) FAST processors require faster busses, or else getting away
from busses in the direction of mainframe-style architectures.
2) Whether they're RISC or CISC doesn't matter much, what matters
is how fast they are, to first order effect.
3) Really fast chips indeed need loads ofcache to stay off the bus.
In any case, there are already a bunch of RISC multiprocessors on the market.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR m...@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!
ucbvax!hplabs!hp-ses!hpdml93!sritacco
From: srita...@hpdml93.HP.COM (Steve Ritacco)
Newsgroups: comp.arch
Subject: Re: RISC multiprocessors
Message-ID: <280004@hpdml93.HP.COM>
Date: 9 Nov 89 16:35:47 GMT
References: <13319@pur-ee.UUCP>
Organization: Hewlett Packard - Boise, ID
Lines: 4
The R3000 (mips) has support for necessary multiprocessing features
built in. There is support for reading from the data cache and invalidating
data cache entries. This would allow a snooping system to be built fairly
efficiently.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!
portal!cup.portal.com!mslater
From: msla...@cup.portal.com (Michael Z Slater)
Newsgroups: comp.arch
Subject: Re: RISC multiprocessors
Message-ID: <23963@cup.portal.com>
Date: 12 Nov 89 18:10:05 GMT
References: <13319@pur-ee.UUCP> <280004@hpdml93.HP.COM>
Organization: The Portal System (TM)
Lines: 12
>The R3000 (mips) has support for necessary multiprocessing features
>built in. There is support for reading from the data cache and invalidating
>data cache entries. This would allow a snooping system to be built fairly
>efficiently.
Snooping directly on the primary R3000 cache is indeed possible, but as I
understand it, the degradation on CPU performance due to contention for the
cache is signficant. Plus, the R3000 cache is write-through, and a reasonable
multiprocessor system needs write-back caches. All multiprocessor R3000 system
I'm aware of use second-level write-back caches.
Michael Slater, Microprocessor Report msla...@cup.portal.com
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!
usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!decwrl!sgi!...@patton.sgi.com
From: j...@patton.sgi.com (Jim Barton)
Newsgroups: comp.arch
Subject: Re: RISC multiprocessors
Summary: Some Confusion
Message-ID: <44720@sgi.sgi.com>
Date: 15 Nov 89 18:43:44 GMT
References: <13319@pur-ee.UUCP> <280004@hpdml93.HP.COM> <23963@cup.portal.com>
<1989Nov15.040039.28570@Solbourne.COM>
Sender: j...@patton.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 46
In article <1989Nov15.040039.28...@Solbourne.COM>, ste...@momma.Solbourne.COM
(Steve Cox) writes:
> In article <23...@cup.portal.com> msla...@cup.portal.com (Michael Z Slater) writes:
> >Snooping directly on the primary R3000 cache is indeed possible, but as I
> >understand it, the degradation on CPU performance due to contention for the
> >cache is signficant. Plus, the R3000 cache is write-through, and a reasonable
> >multiprocessor system needs write-back caches. All multiprocessor R3000 system
> >I'm aware of use second-level write-back caches.
>
> second-level write-back caches? so (correct me if i am wrong), there
> is a first level cache that is not connected to the shared memory bus.
> how do these systems support cache coherency for data that is
> cached in the first level cache? sounds pretty hairy to me.
> or am i missing something?
>
>
> --
> steve cox ste...@solbourne.com
> solbourne computer, inc.
> 1900 pike, longmont, co GO BUFFS !!! ...
> (303)772-3400
The Stardent Titan machines snoop directly on the first level cache. The
R3000 has explicit lines (if you give up 128K caches and stick to 64K) to
stall and to allow you to invalidate the caches. These machines also
suffer a significant penalty for invalidate traffic, causing less than
stellar (pun intended) performance. The effect is mitigated by the
dual-bus scheme of the Titan. Instructions and read-only data pass
on a separate bus which is not snooped, and read/write data passes on a bus
which is. For instance, the vector units pick up their operands from
the read-only bus and write them to the read/write bus. Obviously, this
scheme doesn't work too well.
We may note also that there is only one R3000 based multiprocessor
announced and shipping. The Titan III has been announced in Japan,
but not here. The current Titan products are R2000 based.
The SGI POWERSeries has a second level cache which performs all the
snooping operations and does the writeback. In effect, it acts as a
"filter" which operates asynchronously to the processor. When a hit
occurs on an invalidate, and since the first level cache is (necessarily)
a subset of the second level cache, the second level cache turns around
and invalidates the first level cache. So, stevec missed something too.
-- Jim Barton
Silicon Graphics Computer Systems "UNIX: Live Free Or Die!"
j...@sgi.sgi.com, sgi!...@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb
Path: utzoo!attcan!uunet!aplcen!samsung!cs.utexas.edu!rice!uw-beaver!ubc-cs!
alberta!calgary!cpsc!deraadt
From: dera...@cpsc.ucalgary.ca (Theo Deraadt)
Newsgroups: comp.arch
Subject: Re: RISC multiprocessors
Message-ID: <2118@cs-spool.calgary.UUCP>
Date: 20 Nov 89 14:33:54 GMT
References: <13319@pur-ee.UUCP> <280004@hpdml93.HP.COM> <23963@cup.portal.com>
Sender: n...@calgary.UUCP
Lines: 9
In article <23...@cup.portal.com>, msla...@cup.portal.com (Michael Z Slater)
writes:
> Plus, the R3000 cache is write-through, and a reasonable
> multiprocessor system needs write-back caches.
> Michael Slater, Microprocessor Report msla...@cup.portal.com
As long as they are physical write back caches and not virtual. Unless you
like flushing huge virtual writeback caches everytime you context switch
and mapin your next process.
<tdr.