Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!petunia!news From: araftis@polyslo.CalPoly.EDU (Alex Raftis) Newsgroups: comp.sys.next Subject: Re: RISC vs. CISC -- SPECmarks Message-ID: <27fcdce4.3a0@petunia.CalPoly.EDU> Date: 5 Apr 91 20:24:04 GMT References: <34936@athertn.Atherton.COM> <27fa3350.6bc2@petunia.CalPoly.EDU> Organization: Cal Poly State Univ,CSC Dept,San Luis Obispo,CA 93407 Lines: 71 In article melling@cs.psu.edu (Michael D Mellinger) writes: > >Look at the SPECmarks for the chips. RISC chips are outperforming >CISC chips. > I'm mainly trying to make the point that CISC is not dead. Most RISC chips are outperforming CISC, and I'd would say that it's mainly because of their simpler hardware design. Yes, someone had an excellent idea when they decided to design the first RISC chip. CISC on the other hand is benefiting greatly from advances in hardware design. They're beginning to approach RISC through put. I guess the real decission maker will be price and support. > >SPARC isn't a very good RISC. Look at what MIPS is doing. They make >the best CPUs. And that 1.3 cycles/instruction is optimal. Do you >think that's what we're getting on the NeXT? > I can't comment on this one, as I've never seen a really good comparrison of RISC to RISC processors, and I'm aware that RISC is generally out- performing CISC. Also, I'd say 1.3 is not as "optimal" as you think. Motorola was being optimal when they said the chip could do 20 Mips, and NeXT was being minimal when they said 15. Most of what I've seen done to benchmark the NeXT places it somewhere in between, showing that it is doing 1.3 cycles per instr. If you've done much work with pipe-line theory, you'd see that pipe lining is very strong in programs that don't branch constantly. Assuming that you never branch, a good pipe-line should be able to perform at 1 cycle per instruction. If every statement is a branch, you fall way off the mark, and would perferm at your slowest. With normal code, you only brach periodically, and with the 040 code, you can often predict and follow the branch (ie, dbxx statement will usually branch). This produces their performance of about 1.3. > >All most companies would have to do is type 'make' to recompile their >programs if NeXT switched to a RISC chip. > Not really. How much porting of software have you done? I've noticed that when porting between architectures that yes, you only have to recompile, but then you often have to go twiddle with code to make it work with the new architecture. This is often true with C since it allows you to work at such a low level. There's also the problem of the operating system. Do you remember the days of NeXTstep 0.8? We'd have to go through all those bugs again as we waited for Mach on the new architecture to get bug free. We'd also have to work with a compiler that hasn't been as well tested as 680x0 based compilers. Personally, I'd rather see NeXT support a multiprocessor enviroment like Mach is suppose to be able to do. This would allow a user who needs more performance to get it with a second board. Also, there's no one stopping third party developers from make RISC based add in cards for the NeXT. These could be used by people needing lots of number crunching or other specialty applications. I mean, that's basically what the NeXTdimension does. >-Mike -- -------------------------------------------------- Internet: alex@cosmos.ACS.CalPoly.EDU or araftis@data.ACS.CalPoly.EDU for NeXTmail