Path: utzoo!mnetor!uunet!husc6!hao!ames!lll-tis!lll-ncis!lll-lcc!pyramid!prls!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: comp.arch Subject: Re: Impossible 40MHz R2000 ?? Message-ID: <1193@winchester.UUCP> Date: 20 Dec 87 03:06:46 GMT References: <8252@steinmetz.steinmetz.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 152 Keywords: fast faster fastest micro east of the GaAs :-) The following is a general discussion prompted by Dennis O'Conner's posting, followed by a few detailed comments interspersed with extracts from the posting itself. Dennis alluded many times to a GE 40-native-mips CPU about which he can't say much until after ISSCC. [BTW: I've occasionally confused people by using "we", making them think I speak for MIPS Computer Systems, which I do NOT. I sometimes use the editorial "we" out of personal habit, and sometimes I say "we", in that my comments and opinions may arise from discussions with other people. In this case, mark johnson and craig hansen had useful comments that I've incorporated, but I'm responsible for any errors.] GENERAL 1) Fortunately, it's not long until ISSCC, which will help, since it's hard to have any reasonable discussion without data, and we understand the ISSCC rules that prevent prior publication, so I won't push for details that would cause problems. 2) The statements marked 1 & 2 below (on mips) could use some clarification. a) Remember that we consistently use 1 mips = vax11/780-with-decent compilers-running-variety-of-real-programs-not-dhrystones-or-toy- benchmarks type mips, i.e., something people can actually measure and evaluate. b) 40MHZ is not apriori 40mips (of the kind we described above); statement 1 (way below: "raw machine MIPS") makes it clear that Dennis understands this, but some of the other statements seem to MIX apples and oranges. Note that even getting 40 native-mips from 40MHZ implies certain things about external cache/memory latencies, miss penalties, branch-handling, MMU-interference, etc. I do assume 40MIPS is for something other than a tight-loop of adds or nops in an on-chip cache. (a 25MHZ 68020 is a 12.5MIPS thing by that rule). c)This business has more than once seen spectacular claims,based on peak native-mips-ratings, that had little to do with the actual performance on real benchmarks. Until we see the ISSCC paper, it's hard to guess what actual performance might be. I certainly believe that a machine should be able to do it's clock rates in NOPS or ADDs; doing loads, stores, and branches is harder, especially for real-sized programs that actually miss in caches now and then. 3) After ISSCC, if the paper itself doesn't reveal such information, perhaps you can post some real benchmark numbers. We'd be glad to send you a copy of the MIPS benchmark tape for a nominal cost (not me: mail to ....!mips!mannos), and we'll be glad to compare notes. 4) Can you say more on what you're asserting the actual performance is? If not now, at least after ISSCC? For example, do you think that, in a real system, that people can build, is it: a) 40X faster than 11/780 (4X MIPS M/1000) b) 30X "" ...(3X) c) 2X "" ...(2X) Also, you haven't mentioned floating point. Can you at least say if the ISSCC paper will discuss it? 5) There are several ways of convincing somebody that a computer can achieve a given performance: REALITY: Here's the machine. Benchmark it and see. HINT: For a future machine, here are some hints about the ways in which it might be done. DESIGN: Here is what the future design looks like, and here are the innovations and sneaky designs we use to make it work. REALITY is always preferable: existence is a virtue: if I see a system remake the UNIX kernel, boot it, and then compile/run Spice, I believe it might even be a Real Machine, subject to any evidence to the contrary. This is hard to do with future designs, unless someone has really great simulators and can convince me of that. We often tell people under nondisclosure a lot of HINT, and even some DESIGN. Sometimes HINT alone can sound like hand-waving, which we dislike, but DESIGN inevitably discloses details that are highly proprietary, and this is something we can't do in a forum like comp.arch. Anway, we look forward to seeing the GE ISSCC paper, and even more, to some live benchmark numbers to give appropriate perspective to the 40-mips characterization. SPECIFIC NOTES ON POSTING -------------------------- In article <8252@steinmetz.steinmetz.UUCP> sunray!oconnor@steinmetz.UUCP writes: >An article by hansen@mips.UUCP (Craig Hansen) says .... >-]For speeds well above 40 MHz in CMOS technology,our studies suggest that this >-]will not be a limiting factor at all ... >You missed the point. The relevent number isn't 40MHz, it's 40MIPS. To >achieve that, you'll need 80 MHz. Mr. Jesup ( hi Randell ) has >personal knowledge of a 40MHz 40MIPS CMOS microprocessor, as do I, >that is real silicon, really working, right now. Those are of course >raw machine MIPS, not equivalent anything MIPS. Check out the upcoming -------------^^^^ statement 1: >ISSCC conference for more details. .....bunch of discussion on clock-rates.... >Actually, GE's 1.25 micron AVLSI CMOS process is one of the best going >(ask IBM about it) and never had anything to do with RAMs. Oh since >you brought it up, the machine Randal and I know of uses 20ns CMOS RAMs >to run at 40MIPS with no wait states. What will you need? >-]The real problem with the other RISC designs ... >-] [massive generalization deleted] >What limited-omniscience you must have, to be able to tell all of us >the ONE TRUE PROBLEM with "other" RISC designs. :-) Baloney. >What do you know about MY RISC machine? Nothing. So pay >attention at ISSCC and learn a few things. Just before "The real problem..", craig had referred to 2 specific other RISC designs, and was discussing cache issues, by context. He never stated that this was the ONE TRUE PROBLEM of ALL other risc designs. >No No NO, 40 _MIPS_, not MHz. 80MHz for you guys. And since it is >already here, your changes better happen yesterday. Randel, you >shoulda said 40MIPS, you know how easily confused people get :-) ....much EE stuff deleted... >Sure, but when YOU use 20ns RAM you get what, 20MIPS? And when I >use 20ns RAM I get (am getting) 40MIPS. So who is better positioned ---------------------------------^^^^^^ statement 2 >to take advantage of new RAM technology?..... >Sure, and warp drive may be safer than skiing. Cutting edge NOW is >40MIPS at 40MHz-2-phase using 20ns RAMs. The future may belong to >GaAs. Are you in the present or the past ? It's hard to tell when we are. We think we're going along the edge of of what's practical for us to build, sell, and quickly improve for the commercial marketplace, and we think what we do will scale well in the better technologies that we're now getting access to. It's quite possible that the chip you speak of will indeed blow everyone's socks off, and that we are indeed living in the past. On the other hand, if you haven't done exceedingly careful performance modeling of this in realizable system environments, you might get surprised, as have numerous other people. Perhaps you could describe your performance simulation environment, and what kinds of programs are simulated to predict performance? >Gee, I wish I could tell you more about our chip. Maybe after >ISSCC I'll be able to. Like, knock off your socks, fur sure. Many people here will look forward to the ISSCC paper with strong interest, and even more to seeing some good benchmarks. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086