Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!apple!sun-barr!newstop!sun!khb From: khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) Newsgroups: comp.sys.dec Subject: Re: RISC: What did they leave out besides the instructions? Message-ID: Date: 15 Feb 90 06:25:00 GMT References: <60@paradigm.com> Sender: news@sun.Eng.Sun.COM Organization: Sun MegaSystems Lines: 111 In-reply-to: gjc@paradigm.com's message of 4 Feb 90 21:42:04 GMT >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