Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!ncar!gatech!psuvax1!news
From: melling@cs.psu.edu (Michael D Mellinger)
Newsgroups: comp.sys.next
Subject: Re: RISC vs. CISC -- SPECmarks
Message-ID: <yq1Go.$h1@cs.psu.edu>
Date: 5 Apr 91 23:39:55 GMT
References: <34936@athertn.Atherton.COM> <27fa3350.6bc2@petunia.CalPoly.EDU>
	<?paG6lfg1@cs.psu.edu> <27fcdce4.3a0@petunia.CalPoly.EDU>
Sender: news@cs.psu.edu (Usenet)
Organization: Penn State Computer Science
Lines: 78
In-Reply-To: araftis@polyslo.CalPoly.EDU's message of 5 Apr 91 20:24:04 GMT
Nntp-Posting-Host: sunws6.sys.cs.psu.edu


In article <27fcdce4.3a0@petunia.CalPoly.EDU> araftis@polyslo.CalPoly.EDU (Alex Raftis) writes:

   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.

I'm not a microprocessor expert, but I think that the current crop of
CISC chips use at least 4 times as many transisters per chip as the
latest RISC chips.  Motorola had so much extra room on the 88K that
they put a 64K cache on the chip.  Less than 10 years ago, 64K was a
lot of memory.  The RISC people are just getting starting.

   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. 

I think HP has benchmarks that rate the 68040 at around 12 SPECmarks.
I have the results that were posted to comp.arch, if you want them.

   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.

And then there is delayed branching which always executes the
instruction(s) after the branch.  I have had a little theory.  Anyway,
the NeXT generation of processors are going to execute 2 instructions
per cycle, thus giving you 50 mips and 25MHz or 100mips at 50MHz.

   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. 

I think byte alignment is the biggest problem.  The RISC chips insist
that everything be aligned on a word(32 bit) boundary, where as the
CISC chips don't make such a restriction.

struct foo {
	char a;
	int i;
} bus_error;

Try accessing bus_error.i on a SPARCstation and see happens. 

   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.

GCC already runs on MIPS's architecture.  Can you say piece of cake?

   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. 

I rather see 4 50MHz R4000's than 4 68040's.  Can you say Cray in a Cube?

   >-Mike