Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!bennett From: bennett@mp.cs.niu.edu (Scott Bennett) Newsgroups: comp.sys.next Subject: Re: RISC vs. CISC -- SPECmarks Message-ID: <1991Apr22.044553.16805@mp.cs.niu.edu> Date: 22 Apr 91 04:45:53 GMT References: <8lbG1vdl1@cs.psu.edu> <1991Apr10.155032.14786@data.com> <1991Apr15.165540.14270@agate.berkeley.edu> Organization: Northern Illinois University Lines: 121 In article <1991Apr15.165540.14270@agate.berkeley.edu> doug@eris.berkeley.edu (Doug Merritt) writes: > >A little while ago (April 6), I saw this: > >In article <27fcdce4.3a0@petunia.CalPoly.EDU> araftis@polyslo.CalPoly.EDU (Alex Raftis) writes: Actually, no, he didn't. I did. >> And, at that, those are 15 or 20 *CISC* MIPS, which get a lot >>more work done than 15 or 20 RISC MIPS. Further, you don't always >>have to up the clock speed to up the processor speed, as the upgrade >>from the 68030 to the 68040 exemplifies, so you don't have to end up >>with a processor that you could fry an egg on or one that has to use >>bulky, expensive SRAM for because the DRAMs available either don't >>run that fast or cost even more. > >Since no one else has rebutted this, I will. This is all just plain wrong. >The issue of "CISC MIPS" versus "RISC MIPS" is a particular instance of >the widely held truth that MIPS == "Meaningless Instrumentation to >Propel Sales", that is, that MIPS is always so vague that it is meaningless. >Nonetheless, in particular cases one can run other, more meaningful benchmarks >to find out something closer to the truth. I agree entirely. The people who take it a step further by saying that they convert "native MIPS" to "VAX 11/780 MIPS" are just making it worse. > >And the truth is that the 68040 is *not* faster than the Sparc/88K/MIPS >processors. Your supposedly more powerful "CISC MIPS" are a phantom. I don't recall saying anything w.r.t. the relative computing speeds of the 68040 and the 88000 series. > >As for "having to up the clock speed to up the processor speed", this >is also without substance, because the improvement seen in going from >the 68030 to the 68040 was basically one of making the most commonly >executed and RISC-like instructions in the 68K operate at RISC-like So they sped up those particular instructions. This merely details exactly what I said. >speeds. You can't get this improvement twice. Oh, sure, everyone will be That's probably true, but doesn't necessarily rule out other kinds of efficiency gains in the 68050. >going for superscalar, where two instructions get executed every clock cycle, >but the RISCs will do this at least as effectively as CISCs (doubtless better, >in fact). Case in point. By executing multiple complex instructions per cycle, the CISC would appear to benefit at least as much as the RISC, not as you state. > >In other words, the playing field is more level now. The 68040 has improved >enough that it will benefit from increased clock speed *almost* as much >as RISCs do. And it will benefit from superscalar almost as much as >RISCs will. It was never the case that the 68K actually had some sort >of advantage there; you've got it backwards. > >Don't forget, CISCs came first, and RISCs were introduced for very good >reasons. Find out what the reasons were/are before take shots in the dark. I am aware of the reasons. I am also aware that these issues are still controversial and unresolved. > >And as for DRAM not being able to keep up with RISCs, that's even further >off the mark. DRAM speeds are as much an issue for CISC *performance* as >for RISCs; it is hardly an advantage to claim that because CISCs waste >cycles, that they therefore aren't limited by DRAM speeds. They certainly This is just silly. First, to say that a CISC chip that can do useful work without having to fetch and decode an instruction every cycle somehow implies that the CISC chip is wasting cycles compared to what a RISC chip would be doing is ludicrous. Quite clearly, the penalty in *this* case falls to the RISC chip, which *must* fetch an instruction every cycle, thereby placing an extra workload on memory. Secondly, it is worth noting here that the extreme case of CISC, the vector processing computer, spends a *much* larger portion of its storage cycles doing work than either a RISC or a more typical sort of CISC. In a vector processor, one instruction fetch and decoding is amortized over the length of the vector upon which the operation is carried out. Amdahl's vector processors had maximum vector lengths of 512 and 1024 items, depending on the hardware model. In other words, it was possible for 1024 floating point adds, for example, to be done eight at a time every 14 ns for the fetch/decode expense of *one* instruction. Neither are Crays noted for their slowness. ;-) >are -- both CISCs and RISCs can either do useful work while waiting on >memory, or they cannot and must wait. > >I have my own doubts about RISC as the ultimate in architecture, but they >are clearly the fastest way to do things in the *near-term*. The other >issues I'm interested in will probably not be competitive for another >5-10 years; we'll likely have to hit a performance plateau with superscalar >RISCs before it makes sense to start building in other directions. You might take a look at IBM's definition of RISC. The RS6000's are pretty fast and have an instruction set that doesn't look like a traditional RISC instruction set. > Doug >-- >-- >Doug Merritt doug@eris.berkeley.edu (ucbvax!eris!doug) > or uunet.uu.net!crossck!dougm Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************