oconnor@sunset.steinmetz (Dennis M. O'Connor) (02/26/88)
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 !
--
Dennis O'Connor oconnor@sunset.steinmetz.UUCP ?
ARPA: OCONNORDM@ge-crd.arpa
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)mash@mips.COM (John Mashey) (02/29/88)
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: <generic disclaimer, I speak for me only, etc> 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
oconnor@sunset.steinmetz (Dennis M. O'Connor) (03/01/88)
An article by mash@winchester.UUCP (John Mashey) says:
] In article <...> 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 !
Why is John Mashey responding to THIS particular OBVIOUSLY HUMOROUS
posting, of the "most-important-thing-is-the-name" variety ?
] After the TREMENDOUS buildup, in which people were advised to look at this
] and see how to do it RIGHT:
Tremendous build-up ? Your kidding. What build-up ? We hinted that
we had some intersting ideas that wouls come out at ISSC. We didn't
particularly brag about it, at least no more than any proud parents.
Oh, the original "see how to do it RIGHT" comment, from long ago,
was intended to be taken with a smile. There is no "one true way",
I thought we all knew that. There ARE clever ideas, however.
] a) There is still not even a single actual benchmark number published
] to let people evaluate the actual performance.
Can you suggest a suite that is applicable to the problem domain ?
That is recognized in the MIL-STD computer community ?
] [The DAIS mix is not a benchmark, even a synthetic one.
This is true. So ? No one said it was a benchmark. But it is used
as a measure of perfromance. Are you saying it has no validity ?
Why not ? And where's the close for this square bracket ? :-)
] 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. [...]
We understood this. In order to have "bullet-proof" figures,
we assumed the worst-case. What was done was this : each
1750A instruction type was translated to RPM40 instructions, with
varients for each addressing mode, et cetera. Then it was assumed that
there was NO filling possible between translated instructions : that
is, the results of a translated instruction had to be available before
the next tranlated-instruction could commence. Cache misses don't
figure on anything but branches, in our system, BTW. Anyway, after all
these "worst-case" translations where done, we weighted-and-sum'ed
them all up. The published DAIS mix numbers are a LOWER BOUND on
RPM40 performance.
] Anyway, peak-risc-mips numbers are of minimal interest without
] real benchmarks (remember: the Fairchild Clipper is a 33-mips-peak
] machine).
What we mean by "PEAK" here is "if there are no NOPS or you count
NOPS as instructions." That's not what Fairchild meant.
] 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).]
Well, actually what we want is for the competitors to MAKE our mistakes
THEMSELVES; we've already learned better. Also, since this is from a
DARPA contract, we can't publish without Government approval. Also,
ISSCC is the FIRST OFFICIAL presentation of the CPU ( the system
was presented at GOMAC, but in very abstract terms ). We've submitted
a paper on design trade-offs to ICCD. If we just blurted it all out
now, we wouldn't be able to get published, would we ? I've yet to see
a published citation to a USENET article :-).
Remember, lack of evidence is NOT evidence of lack. We have trade-off
data, we're just not talking about it YET.
] 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.
MOST of the data we used to design the RPM40 was published by other
people, including the Stanford MIPS group, the Berkely RISC people,
various IBM and DEC groups and some HP people. Surely the net could
discuss many of the various architectural ideas based solely on
already published data.
( BTW, IMHO, posting collected benchmarks of various computers'
performance on a small set of benchmarks is not really "careful,
scientific analysis of computer architecture and design". Other than a
statement of who-can-beat-who, what is learned ? Where's the science ? )
( Yes, this is an UNFORGIVABLE dig at John Mashey. I have sinned! (weep))
] 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.
INSTANTLY OBVIOUS ?? I guess "instantly" means "before you read it". :-)
Nice to know you think about things CAREFULLY before judging them, John.
BTW, I have yet to see a survey of what the readers of this newsgroup are
interested in reading about in it. Have you done one and not told us ?
That wouldn't be very scientific of you, would it ?
Oh, and is there something "special" about the embedded-systems arena
that make the lessons learned in it irrelevant to general-purpose
computer architecture design ?
Just remember, NOBODY needs performance like the real-time guys. If
your UNIX workstation is half as fast as you want, well, things just
get done a little slowly, that's all. But if a real-time system is
half as slow as you need it, the work doesn't get done AT ALL.
] 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!
What has anyone claimed about RPM40 that you don't like? We've been
very clear about our figures, how we got them, and how much we think
they matter. We've been very polite and correct. What's your beef ?
] -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
John, this is so unlike you. Are you having a bad day ? Or are you
just jealous ? Hey, but if you got a gripe, take it to alt.flame.
Me, I'm having an OK day. Take everything above with a smile, please.
--
Dennis O'Connor UUNET!steinmetz!sunset!oconnor
ARPA: OCONNORDM@ge-crd.arpa
(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)