Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!bu.edu!xylogics!world!paradigm!gjc
From: gjc@paradigm.com
Newsgroups: comp.sys.dec
Subject: RISC: What did they leave out besides the instructions?
Message-ID: <60@paradigm.com>
Date: 4 Feb 90 21:42:04 GMT
Organization: Paradigm Associates Inc, Cambridge MA
Lines: 56

The person from MIPS must have thought he was pretty clever
with his posting about number of instructions per user.

But turn his argument around, WHAT HAS THE INSTRUCTION SET OF
A MACHINE have to do with HOW FAST IT RUNS? Perhaps also nothing.

Probably he didn't actually KNOWN ENOUGH to be able to give
an informative answer to what is actually a very reasonable
question.

The question is not about RISC in abstract, but really about
those computers/chips being SOLD under the banner of RISC technology
today. There are only a few different cases to consider.

But let me just make two general points that start to investigate
this area. For further reading look towards authors such as Gordon
Bell and Gene Amdahl. (Anyone who wants to talk about these things
without reading these guys is like an military officer who wants to get
involved in TANK WARFARE without reading Rommel).

First point:

* RISC instruction sets are less efficient in the use of available
  memory bandwith. 

Big deal, right? "Memory is getting cheaper and cheaper"
For most benchmarks on a single user machine the instruction-set
cache size is sufficient so that this is not a problem. But consider
what happens to your instruction set cache with N users.

Second:

* many RISC machines have special handling of "the stack" in some
  form of special registers or frames/displays of registers.

This involves quite a bit of internal state (per context), whereas
a machine like the VAX would use general-purpose memory for "the stack" 
and would hope to let the general-purpose data-cache take care of speeding up
references to the stack. 

In particular a classic VAX has neither instruction cache nor stack
cache.

Both of this points have a lot to do with the cost trade-off points
for a machine that is going to be used to TIMESHARE or do other
general purpose multi-processing or realtime applications.

Not *just* timesharing however, since I also happen to know of some
benchmarks involving a large lisp program, DOE-MACSYMA, solving some 
important non-contrived problems where actual performance on a RISC
machine goes into the toilet compared with the performance one
would expect from small benchmarks such as the RPG suite.

There aint no free lunch.

-gjc