cl0@beach.cis.ufl.edu (Chi-Chou Lin) (10/31/88)
Ok, so much for the RISC vs. CISC. How about change to another topic: What would be the features you would add to RISC-like architecture to support OS (either uniprocessor or multiprocessor) functions? Consider the issues of cost, efficiency, flexibility, and other "RISCy" issue. How to justify? Another issue is : Is there any differences between RISC and CISC to support a multiprocessor system? Currently I only know the SPUR architecture at Berkeley is a multiprocessor RISC (any else?). SPUR has a large cache and instruction prefetch buffer for each processor. These features already exist in CISC for a long time. So I wonder if there is any features necessary to support a RISC multiprocessor system, but these features don't exist in a CISC multiprocessor system. cl0@beach.cis.ufl.edu
koopman@a.gp.cs.cmu.edu (Philip Koopman) (11/03/88)
In article <18894@uflorida.cis.ufl.EDU>, cl0@beach.cis.ufl.edu (Chi-Chou Lin) writes: ............ > 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. Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor.
brooks@maddog.llnl.gov (Eugene Brooks) (11/03/88)
In article <3468@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: >> 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. The only place that the memory bandwith requirements for a RISC are validly higher than a CISC is in the instruction stream. The usual cache hit rates for the instruction stream are unreal if you have any loops at all, and the cache size required for these spiffo hit rates is well below the typcial sizes of todays caches. The 16K byte cache chip used on the MOT88K, considered as an INSTRUCTION cache, is just fine. It is a good idea to seperate code and data caches so that cache thrashing caused by data accesses will not adversely impact caching for the instruction stream. RISC poses no problems at all for shared memory multiprocessors. The potential pipeling offered by load/store operations for memory accesses and large register files is a distince advantage. We used a load/store RISC architecture for the Cerberus multiprocessor simulator specifically because the memory subsystem could overlap a large number of requests if the load/store instruction stream was suitably ordered. We intitially started with the very CISC VAX instruction set for this simulator, actually completed a full cpu simulator for it, and then dropped it when we realized that the memory-memory-memory opcodes, where each memory opcode could itself be an indirection of a pointer in memory, were serious trouble for pipelining the memory accesses of multiple instructions through a packet switch based shared memory server.
cosmos@druhi.ATT.COM (Ronald A. Guest) (11/03/88)
In article <3468@pt.cs.cmu.edu>, koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: > you can put into the system. RISC processors need a lot more > memory bandwidth at the CPU chip than CISC processors. You are right in saying that RISC CPUs generate lots of references very quickly, and memory bandwidth is certainly a key to tightly coupled multiprocessors. However, I have not observed any significant difference between high performance CISC micros and high performance RISC micros in sensitivity to memory bandwidth. High performance CISCs we have tested depend just as heavily on caches as the RISCs do, since the RISCs seem to have an inherently higher cache hit rate. The CISCs seem to have lower hit rates so it appears to end up being a wash. The only exception I could see is a workstation type system with only a small memory need that could be met by a limited amount of on board RAM and no 'real' memory bus. Of course, then it also couldn't be a tightly coupled multiprocessor. Ronald A. Guest, Supervisor cosmos@druhi.ATT.COM or att!druhi!cosmos AT&T Bell Laboratories <--- but these are my thoughts, not theirs 12110 N. Pecos St. Denver, Colorado 80234 (303) 538-4896
bartlett@pinocchio.Encore.COM (John Bartlett) (11/05/88)
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.
jmb@patton.SGI.COM (Jim Barton) (11/06/88)
In article <18894@uflorida.cis.ufl.EDU>, cl0@beach.cis.ufl.edu (Chi-Chou Lin) writes: > ... > > Currently I only know the SPUR architecture at Berkeley is a > multiprocessor RISC (any else?). SPUR has a large cache and > instruction prefetch buffer for each processor. These features > already exist in CISC for a long time. So I wonder if there is > any features necessary to support a RISC multiprocessor > system, but these features don't exist in a CISC multiprocessor > system. > > cl0@beach.cis.ufl.edu Have you been living in an igloo for the past year? There are several commerically available RISC based multiprocessors on the market today. Consider the Ardent Titan (MIPS R2000), Apollo DN10000 (PRISM) and the SGI POWERSeries (MIPS R2000 and R3000). The minimum necessary hardware in each seems to be coherent caches, but each has tweaks in other areas. A RISC multiprocessor is not any harder than any other kind of multiprocessor, so it should not be viewed as unique when considering multiprocessor problems and solutions. The harder aspects are simply the faster parts and larger caches needed when dealing with faster (RISC based) processors. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --