mash@mips.COM (John Mashey) (11/01/90)
In article <1172@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: >I have recently hear about an advertisement claiming 60 MIPS for an >88k based machine (from motorola). I find this figure way too high, >at least for a single CPU system. > >So, what is the fastest 88k around? I'd like to know the clockspeed >and some meaningless MIPS figures. The fastest 88K for which SPEC numbers have been published was the 33MHz Motorola 8612, with 2 88200 chips, which was published Winter 1990. (However, note that, unless something has changed recently, neither the Motorola systems products nor any DG products are yet shipped at 33MHz.) Regarding mips-ratings, there is a fairly confusing state. In particular, it is sad, but true, that mips-ratings are pretty arbitrary. Hedre is a small table, taken from "Your Mileage May Vary", Issue 2.0, which summarizes a lot of SPEC data. SPEC Intgr = Integer Subset of SPEC, which corresponds pretty closely to many people's idea of a real-VAX-mip. SPEC Float = FLoat susbset of SPEC SPECmark = SPECmark, all 10 benchmarks, somewhat loaded towards FP. Publ mips = rating the vendor assigns Integer % = SPEC integer / (published mips) Publ data: 2 = Winter 90, 3 = Spring 90, 4 = Summer 90, c = estimated (The 2 MPC numbers were estimated by giving them the same performance as the earlier 8864SP machines, even though those have 4X bigger caches.) SPEC SPEC SPEC Publ Integer Date System Intgr Float mark mips % Publ 11.3 8.3 9.4 16.0 71% 3 DG AV410, 20MHz, 32K cache 15.3 11.3 12.7 20.0 76% 2 DG AV6200, 25MHz, 32K 14.6 10.8 12.2 17.0 86% 2 Motorola 8864SP, 20MHz, 128K 18.3 13.5 15.2 21.0 87% 2 Motorola 8864SP, 25MHz, 128K 21.4 15.8 17.8 25.0 85% 2 Motorola 8612, 33MHz, 32K 14.6 10.8 12.2 27.0 54% c Motorola MPC-100, 20MHz, 32K 18.3 13.5 15.2 33.8 54% c Motorola MPC-200, 25MHz, 32K 19.4 16.8 17.8 20.0 97% 4 MIPS Magnum, 25MHz, 64K Also, there's a new DG product, the AV100, which runs at 16.7MHz, and is now labeled 17 mips, for a new low cost of $235/mips. As illustrated above, when calibrated against realistic integer benchmarks, the industry's idea of a mips varies by factor of almost 2, ranging from 54% to 97%. Above, I picked the two ends of the spectrum. the number of product lines in each % group is as follows: <60% 3 60-70% 3 70-80% 2 80-90% 4 90-100% 3 (There are no existing product lines, for which the SPEC integer number is higher than the claimed vax-mips number. surprise :-) Of course, in such an environment, it is unclear what is meant by 3 digits of accuracy in a cost/mips number.... A little explanation might be need to explain the difference between the earlier Motorola products (whose integer % is around 86%), and the later ones, which are around 54%. The later ones apparently switched to Dhrystone 1.1, probably following IBM, boosting the mips-rating by >50%, although the performance probably stayed about the same (compiler improvements versus smaller cache, probably cancel, within a few percent.) To answer the original question, the 60MIPS number is probably for a two-processor system (MPC-200 with 2 CPUs), gotten by adding the MIPS together. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
mash@mips.COM (John Mashey) (11/01/90)
In article <TOM.90Oct31160947@hcx2.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) writes: >OK, I have been reading these notes on SPEC numbers for the 88k, and my >fingers started twitching out of control with the desire to publish our >SPECtacular numbers, so here they are: In my opinion, this is a GOOD posting: it actually has some useful data, as opposed to random rumor-mongering. >Machine: 25MZ Harris Night Hawk - 1 processor - 128K cache (64I/64D) >Compilers: Harris Common Code Generator (CCG) C and Fortran >SPEC benchmark run times (all times are in seconds): .... >It is also worth noting that many of the above times are better than the >best numbers for 25MHZ MIPS workstations (most of the double precision >intensive benchmarks do much better on MIPS - this should not suprise >anyone, it certainly does not suprise me). Of these times: on 4/10 it beats a Magnum, and loses on 6 (64KB cache). on 3/10 it beats a DS5000/200, and loses on 7 (128KB cache) >Disclaimer: >No these are not the compilers we are shipping in our current release, they >are our inhouse development versions which will eventually filter out into >future releases. We certainly hope that the compilers we eventually release >will do even better. Good disclaimer. Be warned (from past experience!) sometimes people put in optimizations that break things when lots of programs are compiled, and the optimizations have to be pulled back to meet a release schedule. However, this is a fair, and properly-disclaimered posting, and clearly shows the best numbers I've seen for an 88K. Now, just out of curiosity: a) What are the numbers you get using the current production compilers? b) About how far apart (in time) are those two versions? c) Do you feel that tuneups done to improve SPEC numbers carry over into improvements on other programs ... or not? Any comments on those that you'd be willing to make would be good... especially item c) would be interesting to a lot of people. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
mash@mips.COM (John Mashey) (11/02/90)
This seemed worth reposting into comp.arch: the topic (is making your compiler better for SPEC benchmarks SPEC-specific are not) has come up now and then. Here's an additional opinion: In article <TOM.90Nov1072249@hcx2.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) writes: >>>>>> Regarding Re: Fastest 88k; mash@mips.COM (John Mashey) adds: .... >mash> c) Do you feel that tuneups done to improve SPEC numbers carry over >mash> into improvements on other programs ... or not? .... >c) I would say that all the improvements we made are generally useful. We > look at a lot more benchmarks than just SPEC (some of them are rather > large real customer applications, or benchmarks derived from those > applications). We like to pick which optimizations to work on based on > cost/benefit analysis - if we don't see the need for something in a lot > of places, we generally don't work on it. > > Some of the SPEC benchmarks reacted fairly dramatically to some of our > optimizations, but the optimizations were not designed specifically to > get that reaction from SPEC. For example: the biggest single improvement > came from a combination of loop-unrolling, teaching the instruction > scheduler how to safely shuffle some loads past some stores (to keep the > data unit pipeline going), and teaching the register allocator to pick > registers in such a way as to allow the instruction scheduler maximum > flexibility (to keep the floating point pipeline going). All of this is > great stuff and is useful in almost any program. > > The SPEC matrix300 benchmark, however, spends 99.9% of its time in a > single matrix multiply-and-add loop. When the above set of optimizations > hit the matrix300 benchmark, the performance skyrocketed. This does not > mean our optimizations are not generally useful, but it does mean that > real programs which do actual work may not see a similar performance > boost (but they certainly should get better). Can anyone else add any more comments, or examples? -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086