Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: RPM40 Message-ID: <1709@winchester.mips.COM> Date: 28 Feb 88 20:53:05 GMT References: <9682@steinmetz.steinmetz.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 60 Keywords: rose by any other In article <9682@steinmetz.steinmetz.UUCP> sunset!oconnor@steinmetz.UUCP writes: >I'm AMAZED no one has asked what "RPM40" stands for ! I mean, >aren't you all just DYING to know ? I'm sure you are, you're >probably just too polite to ask. >RPM40 stands for "RISC Pipelined Microprocessor 40MHz". >So now you know. And knowing is half the battle ! After the TREMENDOUS buildup, in which people were advised to look at this and see how to do it RIGHT: a) There is still not even a single actual benchmark number published to let people evaluate the actual performance. [The DAIS mix is not a benchmark, even a synthetic one. Rather, you compute a number by specifying the cycle counts for each of a large number of operations [32-bit add, load, store, etc], then computing a weighted sum of these. This needs special care for heavily-pipelined machines, especially those with compiler-schedulable latencies, and it takes no account of cache-miss effects. For example, is a load: 1 cycle (if one can initiate a load every cycle), or 1 + n (where n is the max number of load-latency slots), or 1 + xn (where x is the average number filled), or 1+ (cache-miss rate * miss penalty)? Anyway, peak-risc-mips numbers are of minimal interest without real benchmarks (remember: the Fairchild Clipper is a 33-mips-peak machine). b) We still haven't seen a single statistical study to back up the feature set chosen: many people believe the essence of RISC design is in carefully selecting features and analyzing their properties to choose the design and instruction set. Certainly, if you ask people from HP, MIPS, and at least some other companies, as well as universities involved in such efforts, they are able to tell you tons of statistics about program behavior to justify their design choices. [For competitive reasons, companies may or may not wish to disclose such info (i.e., let the competitors make their own mistakes).] It would be helpful to see some of this for the RPM to justify some of the decisions, rather than saying "this feature is good." Some of us have tried very hard to help this newsgroup be a forum for careful, scientific analysis of computer architecture and computer design. There are some interesting choices in the RPM, but if no data gets presented, it drops down into the noise of a zillion other things. c) It is instantly obvious from the ISSCC paper and later net postings that this chip was designed (as GE folks have said) for specific embedded environments [not workstations or general-purpose systems], and specific tradeoffs have been made in that direction. THERE IS NOTHING WRONG WITH THIS, but it means that it's only of interest to a subset of people who watch this newsgroup. Anyway, 1987, and even more, 1988 are years of mipsinflation, and further-and-further pre-announcements, including announcing aggressive products whose design has not even been completed. Claims unsupported by data will tend to get ignored pretty quickly, which is probably good! -- -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