🚀 go-pugleaf

>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