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