[comp.sys.dec] RISC: What did they leave out besides the instructions?

gjc@paradigm.com (02/05/90)

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

paulf@bodega.stanford.edu (Paul Flaherty) (02/15/90)

In article <60@paradigm.com> gjc@paradigm.com writes:
>* 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.

I really don't want to get into the RISC vs CISC jihad; after all, I'm
a networks person, not an architecture hacker.

Bandwidth in the computing domain is measured in bits per second.  Memory
size (of which you speak) is measured in bits, and is not a measure of 
bandwidth.  RISC machines are less efficient in terms of both bandwidth
AND density.  Cheap memory solves the second problem, but is making the
first problem even worse, due to increases in address decoding time.
In any event, modern processors are pushing the envelope when it
comes to memory bandwidth.

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

Odd.  The only classic Vax that didn't have the 8KB cache was the 11/730
(and probably the 725 as well), according to my 1982 Vax Hardware Handbook.

--
-=Paul Flaherty, N9FZX/VK2WYX | "Unix could use a more user-friendly front
->paulf@shasta.Stanford.EDU   |  end.  Does anyone have a card punch handy?"

khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (02/15/90)

>gjc@paradigm.com 

....

>A MACHINE have to do with HOW FAST IT RUNS? Perhaps also nothing.

There is a very large body of evidence to indicate that this isn't the
case. 

>Probably he didn't actually KNOWN ENOUGH to be able to give

Mark is quite hip to the subject.

>what happens to your instruction set cache with N users.

This is simply silly. Look at Gene's big machines (I usually refer
folks to Seymour, but you picked your hero already ;>) the clever
thing about big iron (where one expects to find many users) is that
channel controllers (to use the IBM lingo) off load such tasks from
the main CPU. Also the code 'explosion' has been demonstrated to be
only a few % (typically on the order of 20%) by many researchers ... 

>This involves quite a bit of internal state (per context), whereas

Also already proven to be an uninteresting objection. Most of the cost
of a context switch on a Unix system has nothing to do with the size
of the register file (and the MMU state often costs more, all depends
on flavor of MMU). Again, big iron doesn't have to context switch all
that often. On the late and not so lamented Cydra 5 more than 100
registers were saved in a flash ... Unix overhead took a considerable
chunk of time though. This is fixable, it simply hasn't been
interesting enough for anyone but Cray and Amdahl corps. MIPSco needs
to save at most 64 regs (and usually a lot less) ... I don't recall
the constraints on the VAX FPA, but I vaguely recall that draining it
takes longer than saving 20 regs or so on an R3000. I'm working from
memory on both systems, so I could be off by a bit.

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

None of the current "risc" machines have a stack cache either. Lacking
an instruction cache is something to be ashamed of, not something to
take pride in.

>for a machine that is going to be used to TIMESHARE or do other

No, all of this points a smoking gun in the wrong direction. As I
informed the fellow from Tel Aviv privately (not seeing Mark's posting
until later) the key difference between a typical "risc" workstation
and a timesharing machine is the lack of aux. hw support (like channel
controllers) and some comments about the effects of certain MMU's on
context switching. This has come about because the
"workstation"/individual/small workgroup computing arena is much
quicker to adopt new technology (less risk to the organization, lower
entry cost, etc.) and has been growing faster ... so vendors have
contorted designs to serve small groups (best for one ;>) rather than
large scale timesharing (which the VAX doesn't do half as well as say
an old A-10, for those who remember the "good old days"). Lest we
forget, the VAX was the small box we could all afford last time ...
and was friendlier than the large timeshared beastie guarded by white
jacketed "support" staffers....

>this area. For further reading look towards authors such as Gordon
>Bell and Gene Amdahl. (Anyone who wants to talk about these things

Good guys to bone up on; but it seems very odd to forget analysis of
real machines on the ground as it were. The CDC 6600 and its follow
ons are certainly worthy of close study.

Ditzel's classic paper on the case for RISC (of course Seymour had
gone ahead and bulit one years before ;>), various machines currently
available from MIPSco and Sun also provide examples to peer at.

>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.

And there are _many_ published results which contradict your case. I
conjecture that your case probably misses the cache "a lot" (viz only
90% hits) runs on a machine with a high miss cost (say a Sun 4/330)
(or worse hits paging behavior in some interesting fashion). A Sun
4/490 does better on such codes (by a lot more than the ratio of clock
rates suggests) because of a much lower cache miss cost and IPI
controllers. 

Milage varies, but one can often profit from spending time figuring
out why. 

Note that with IBM's release of RIOS tomorrow (presuming all goes as
rumored) all the major players have come out with their highest
performance (in a given class) machines with "RISC" engines. This
isn't because the engineers at IBM, DEC, DG, HP, MIPSco, Sun, et al
are all asleep at the wheel.

The name RISC is a misnomer, and is very unfortunate.

If this discussion drags on, we should move it to comp.arch.



--
Keith H. Bierman    |*My thoughts are my own. !! kbierman@Eng.Sun.COM
It's Not My Fault   | MTS --Only my work belongs to Sun* kbierman%eng@sun.com
I Voted for Bill &  | Advanced Languages/Floating Point Group            
Opus                | "When the going gets Weird .. the Weird turn PRO"

"There is NO defense against the attack of the KILLER MICROS!"
			Eugene Brooks

terry@sunquest.UUCP (Terry Friedrichsen) (02/16/90)

In article <60@paradigm.com>, gjc@paradigm.com writes:
> The person from MIPS must have thought he was pretty clever
> with his posting about number of instructions per user.
> [ ... ]
> Probably he didn't actually KNOWN ENOUGH to be able to give
> an informative answer to what is actually a very reasonable
> question.
> 
> -gjc

Gawd, some folks have absolutely NO sense of humor whatsoever ...

Terry R. Friedrichsen
TERRY@SDSC.EDU  (alternate address; I live and work in Tucson)

(no humorous quote; someone is BOUND to misunderstand!)

bcw@rti.UUCP (Bruce Wright) (02/16/90)

In article <2010@sunquest.UUCP>, terry@sunquest.UUCP (Terry Friedrichsen) writes:
> In article <60@paradigm.com>, gjc@paradigm.com writes:
> > The person from MIPS must have thought he was pretty clever
> > with his posting about number of instructions per user.
> > [ ... ]
> > Probably he didn't actually KNOWN ENOUGH to be able to give
> > an informative answer to what is actually a very reasonable
> > question.
> 
> Gawd, some folks have absolutely NO sense of humor whatsoever ...

It seems that there are, unfortunately, a fairly large number of people
on the network that can't seem to understand humor unless they are hit
over the head with a 2x4.

That's why the ":-)" was invented - to indicate to such people that
the posting is a joke, and consequently is something they can't
understand, so that they don't clutter things up with flamage about
how stupid the original article was.  I've been burned too by their
ranting when I didn't add the requisite 2x4's to the article.

Non illegitimi carborendum (or however the Italians spell it).

:-) :-) :-)      <-- appropriate 2x4's for the dimwitted.

					Bruce C. Wright

ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) (02/16/90)

In article <3583@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes:
>In article <2010@sunquest.UUCP>, terry@sunquest.UUCP (Terry Friedrichsen) writes:
>> Gawd, some folks have absolutely NO sense of humor whatsoever ...
>It seems that there are, unfortunately, a fairly large number of people
>on the network that can't seem to understand humor unless they are hit
>over the head with a 2x4.
Sheeh!  The guy "got the 'joke'", he just thought that it was a reeeeaal 
longwinded way of getting a point across, and for all that, didn't think it 
was especially funny. I would be inclined to agree. Sadly, he didn't have 
at his disposal a silly symbol, commonly used on the net to hit 
(a fairly large number of) people over the head with an old Lear Siegler 
ADM-3 toilet fixture, thus indicating: "Yeah, yeah right,  but gimme a break". 

-- 
Tom O'Toole - ecf_stbo@jhuvms.bitnet     "Internet is the wide area network
JHUVMS system programmer       protocol packaged with TCP/IP that unix systems
Homewood Computing Facilities  rely on to communicate remotely with each other"
Johns Hopkins University, Balto. Md. 21218                   -Digital Review

bcw@rti.UUCP (Bruce Wright) (02/18/90)

In article <1990Feb15.054555.18223@Neon.Stanford.EDU>, paulf@bodega.stanford.edu (Paul Flaherty) writes:
> In article <60@paradigm.com> gjc@paradigm.com writes:
> >In particular a classic VAX has neither instruction cache nor stack
> >cache.
> 
> Odd.  The only classic Vax that didn't have the 8KB cache was the 11/730
> (and probably the 725 as well), according to my 1982 Vax Hardware Handbook.

He's probably thinking of the MicroVAX, of which the MicroVAX II (and I
think also the MicroVAX I, though I don't know for certain offhand) does
NOT have a cache (that's new with the MicroVAX 3000 series).  You're
right that the older 700 series mostly did have cache;  probably that's
the series that should really be thought of as the "classic VAX" (after
all, that was the first series out!), but it's common anymore to think
of the MicroVAX II as equivalent to the 11/780.  This is probably too
simplistic, but given this it's understandable how the MicroVAX II gets
confused with the "classic VAX".

						Bruce C. Wright

bcw@rti.UUCP (Bruce Wright) (02/18/90)

In article <4260@jhunix.HCF.JHU.EDU>, ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) writes:
> In article <3583@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes:
> >In article <2010@sunquest.UUCP>, terry@sunquest.UUCP (Terry Friedrichsen) writes:
> >> Gawd, some folks have absolutely NO sense of humor whatsoever ...
> >It seems that there are, unfortunately, a fairly large number of people
> >on the network that can't seem to understand humor unless they are hit
> >over the head with a 2x4.
> Sheeh!  The guy "got the 'joke'", he just thought that it was a reeeeaal 
> longwinded way of getting a point across, and for all that, didn't think it 
> was especially funny.

Um, well, if the shoe fits, etc.  I wasn't accusing anyone _in particular_
of being obtuse, and in fact the poster of the article that Terry referred
to did appear to recognize the posting as a joke, but not everyone appeared
to do so.

Unfortunately there seems to be a certain class of people whose ability
to recognize humor is about as limited as that of their computer.  This
may not be a coincidence.  :-)

						Bruce C. Wright

gjc@paradigm.com (02/20/90)

In my original "RISC" posting I talked about *specialized* cache
mechanisms vs general purpose cache mechanisms. That is why I summarized
by saying that a classic vax had NO STACK CACHE and NO INSTRUCTION cache.

Of course there is a general purpose data cache that will serve to
cache instructions or "stack" (by stack let us mean the language procedure
local variables and data structures). 

My copy of the VAX architecture manual is dated 1977, a pretty good
date for setting the classic vax architecture.

Microprocessor VAX implementations have been pretty much along classic
lines.

The failure of special purpose mechanisms for speeding up local
variable reference can be rather dramatic as a complexity
boundary is crossed. 

-gjc