jaw@eos.UUCP (James A. Woods) (02/04/88)
# "there's only one two." -- local tv station slogan sun touts the new 4/110 as doing seven vax integer mips in the second paragraph of their press release. makes real sense this time, given the clock rate. taking 8.4 as the mashey-measured mips for the 4/280 unix utility run (guess they finally have the compiler tuned), we get an honest 7 coming out of the equation (clock rate 16.67 mhz -> 14 mhz). it still doesn't make the *current* high-end 4/200 series machine an honest ten, so they must be reserving the verity of this figure for a future (cypress chip) member of the line ... personally, i'm waiting for the cut-price 4/60.
mash@mips.COM (John Mashey) (02/05/88)
In article <168@eos.UUCP> jaw@eos.UUCP (James A. Woods) writes: ># "there's only one two." -- local tv station slogan >sun touts the new 4/110 as doing seven vax integer mips >in the second paragraph of their press release. >makes real sense this time, given the clock rate. >taking 8.4 as the mashey-measured mips for the 4/280 >unix utility run (guess they finally have the compiler tuned), >we get an honest 7 coming out of the equation >(clock rate 16.67 mhz -> 14 mhz). >it still doesn't make the *current* high-end 4/200 series >machine an honest ten, so they must be reserving the verity >of this figure for a future (cypress chip) member of the line ... I'm sure James meant some more :-) in his discussion. To correct a possible misimpression, the "MIPS UNIX" utility run James referenced was indeed 8.4, from "MIPS Update for 3.0, Dec 87". However, as it states: "# VAX 11/780 runs 4.3BSD for MIPS UNIX, Ultrix 2.0 (vcc) for Stanford, VAX/VMS for all others. Use of 4.3BSD (no global optimizer) probably inflates the MIPS UNIX column by about 10%." In any case, as I'm sure James knows quite well: a) A mips-claim without realistic backup benchmarks is not tremendously meaningful. b) A clock rate scaling is at best a gross estimate, ESPECIALLY for heavily-cached RISC machines. From the data given, one doesn't know whether or not there's a cache, and if so, how big it is. Likewise, it's conceivable that going to a slower clock, and a different memory system design, might shave clocks off the memory-to-cache latency, so that a 14MHz design might be faster that 14/16.7 of the 16.7MHz design. Presumably everyone may know more when benchmark numbers are available. -- -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
davis@wasp.cs.unc.edu (Mark Davis) (02/06/88)
In article <1503@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: > > b) A clock rate scaling is at best a gross estimate, ESPECIALLY > for heavily-cached RISC machines. From the data given, one doesn't > know whether or not there's a cache, Isn't cache the real issue. Sun 3/200's have different memory systems than sun 3/100's (cache). Maybe to get the correct rating, you should multiply: 10 {sun 4/260 mips} * 14/16.67 {clock ratio} 2 / 4 {sun 3/160 vs 3/260 mips} = 4.2 mips The Sun 3/110 and 3/260 numbers are from MIPS December report (rounded). I agree with John; lets find out more about the architecture and run some benchmarks. Thanks - Mark (davis@cs.unc.edu)