Path: utzoo!attcan!uunet!husc6!bu-cs!encore!pinocchio!bartlett
From: bartlett@pinocchio.Encore.COM (John Bartlett)
Newsgroups: comp.arch
Subject: Re: Multiprocessor RISC
Message-ID: <4098@encore.UUCP>
Date: 4 Nov 88 21:35:40 GMT
References: <18894@uflorida.cis.ufl.EDU> <3468@pt.cs.cmu.edu>
Sender: news@encore.UUCP
Reply-To: bartlett@pinocchio.UUCP (John Bartlett)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 31

In art. <3468@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes:
>In art.<18894@uflorida.cis.ufl.EDU>, cl0@beach.cis.ufl.edu (Chi-Chou Lin) :
>> Another issue is :
>> 	Is there any differences between RISC and CISC to
>> 	support a multiprocessor system?
>
>Memory Bandwidth problems!  If you are using a shared memory model,
>memory bandwidth is often the limiting factor to how many processors
>you can put into the system.  RISC processors need a lot more
>memory bandwidth at the CPU chip than CISC processors.
>That means a RISC multiprocessor has to be a lot more careful about
>getting good cache hit rates across a wide range of software execution
>profiles to avoid saturating the system bus.

I don't believe this is true.  I believe that the locality of a processors 
reference is dependent on the algorithm being run, not on the granularity of
the instruction set.  Since a RISC processor has a reduced instruction set, a
slightly larger cache is required to obtain the same hit ratio as on the
equivalent power CISC processor.

The real 'problem' with RISC processors is the additional MIPage they provide
loads the system bus, and hence requires larger and smarter caches to support
them.  But please note the problem is there inherent performance, not their
architecture. 

John Bartlett           UUCP:  {necntc,talcott,bu-cs,decvax}!encore!bartlett
Encore Computer Corp.   Internet:       bartlett@multimax.ARPA
257 Ceder Hill Street
Marlboro, Mass.  01752  N.E.Telephone    (508) 460-0500

Opinions are not necessarily those of Encore Computer Corp.