Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!hplabs!pyramid!prls!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: comp.arch Subject: Re: brash micros versus the Big Iron: not yet Message-ID: <640@winchester.UUCP> Date: Sat, 29-Aug-87 19:28:50 EDT Article-I.D.: winchest.640 Posted: Sat Aug 29 19:28:50 1987 Date-Received: Sun, 30-Aug-87 10:15:19 EDT References: <622@winchester.UUCP> <12953@amdahl.amdahl.com> <630@winchester.UUCP> <1202@pdn.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 106 In article <1202@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: >In article <630@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >>mips MHz MHz/mips CPU / System >>2 16.7 8.3 68020 (in Sun-3/160) >...note that Sun's MIPS figures are converted to VAX equivalent, >and the '2' figure widely quoted represents the equivalent VAX MIPS; >the 'native' MIPS figure is about 3... Oops. Having included "using definition 1 mips = VAX 11/780, 4.3BSD" in this newsgroup dozens of times, I forgot to do it this time. Note that on every benchmark we do, we measure the performance on the fastest VAX 11/780 that is relevant to the benchmark and that we can lay our hands on, call that 1, and then comptue any ratios relative to that, specifiyign which one it was. I'm curious: how does someone (other than a person with a complete architectural simulator, or ultra-precise hardware monitors), ever know what the `native mips' rating is, at least one machines that have caches, TLBs, etc? >>5 33 6.6 Fairchild Clipper >>4 25 6.2 68020 (in Sun-3/260; caches help) >...see the comment above for the Sun-3/160... >>6 22.2 3.7 VAX 8700 >>33 66 2.0 Amdahl 5890-190E >>10 15 1.5 MIPS M/1000 > mips* MHz MHz/mips CPU/ System > 6 16.7 2.78 68030 > 4 20 5.0 80386 (assumes native mode 32-bit code) > 10 30 3.0 32532 >*based on manufacturers' claims (Are these the same kinds of mips as the scale I was using? If so, how many people out there believe that a 16.7MHz 030 will be 3X faster than a Sun3/160, or 1.5X a Sun3/260?) >It cannot be denied that a low Mhz/mips ratio is a good thing, and >as the numbers above demonstrate, the major players appear to be >steadily reducing this statistic for their products. >However, as Motorola pointed out in one of their benchmark reports, >a CPU can have fewer MIPS but higher 'performance'. The statistic >that REALLY is important is work-accomplished/time. That is admittedly >much harder to measure. (Could you give a better citation for these reports?) I think we all agree that what is important is real work, not how many actual instructions are being executed. That's why I always use relative performance numbers, as slippery as they are, since "peak mips", "sustained mips", "native mips" really just don't mean much to most people. (Recall that Moto has advertised that a 25MHz 68020 does "12.5 burst mips" and "5 sustained mips".) Most people know that relative performance over a range of benchmarks is seldom a single number, but a range. For example, a "6-mips" VAX 8700 is anywhere from 3X to nearly 8X faster than an 11/780, even using the same software and OS. Thus, at best, the "N-vax-mips" number is a gross approximation to saying "if you run a lot of real programs, some will run faster, and some will run slower, but N is typical, and not too far off the mean (arithmetic, geometric, harmonic, or otherwise). Work-accomplished/time is NOT harder to measure, and the numbers used above were approximations of doing all the detailed work. Here is a table for 3 machines, in same form as the earlier articles: mips MHz MHz/mips CPU / System 1 5 5 VAX 11/780, 4.3BSD 2 16.7 8.3 68020 (in Sun-3/160), SunOS 3.2 5 8 1.6 MIPS M/500, UMIPS-BSD 2.0beta, 1.10 compilers Here is the table of timings for an nroff benchmark (MIPS Performance Brief, April 1987,p.6), which are then normalized to 'vax-mips', and the table above recomputed: Time mips MHz MHz/mips CPU / System 18.8 1 5 5 VAX 11/780, 4.3BSD 9.0 2.1 16.7 7.95 68020 (in Sun3/160) 3.3 5.7 8 1.4 MIPS M/500 To do a complete analysis, one should take hundreds of real benchmarks and do this, but this is sufficiently typical to be useful. (Note that the numbers aren't a lot different for MHz/mips). This approach has pluses and minuses, compared with real cycles/instruction: + mips (this way) gives you some feal for delivered relative performance + it is easy for anybody to compute, unlike cycles/(native instruction) - the base is a moving target that changes with compilers > >It is amusing to see the hardware people champion "simplicity" of design >at the expense of software complexity, while software people clamor >for "simplicity" of design at the expense of hardware complexity >(for example, Niklaus Wirth). Shifting complexity around between >hardware and software is just irresponisble sleight of hand unless >you can prove, on a case-by-case basis, that a given function >is more efficiently handled either in the hardware or the software. I think there's a complaint here, but I'm not exactly sure what it is, or who it's aimed at. If the first part was aimed at RISC fans, it does seem a little misplaced, since many of the most vocal RISC advocates are software people! More specificity would help on the rest: I'd be glad to answer the comments if I knew what they meant. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!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