Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!intelca!oliveb!glacier!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: net.arch Subject: Re: Mips / MHz Message-ID: <459@mips.UUCP> Date: Tue, 29-Apr-86 16:41:24 EDT Article-I.D.: mips.459 Posted: Tue Apr 29 16:41:24 1986 Date-Received: Fri, 2-May-86 10:09:12 EDT References: <1363@unc.unc.UUCP> <1712@gitpyr.UUCP> Distribution: net Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 50 Scott Dorsey writes: > In article <1363@unc.unc.UUCP> hedlund@unc.UUCP (Kye Hedlund) writes: > >BUT, a 68010 is about 0.4 mips @ 10MHz, and a 68020 is about 1.5mips @ > >16.67MHz (measured on SUN workstations running C under 4.2 BSD). > >This gives 0.040 mips/MHz for the 68010 and 0.091 mips/MHz for the 68020 > >and suggests that there is better than 2:1 architectural and implementation > >advantage for the 68020 independent of the circuit technology. > > Your point that the mips/Mhz rate is a slightly accurate method of > measuring architectural efficiency is somewhat valid, but it must be > pointed out that there is no good definition of either the MIPS or the > MHz rate. Assuming that MIPS measures the average execution speed of > the average instruction ( and who says what is average? ), and MHz measures > clock cycle time, all you are actually measuring is the number of clock > cycles per instruction. I have a computer that runs at 200 MIPS, and > executes one instruction per cycle. However, because it only has one > instruction, it is not very efficient, although its specs look great. > In addition, you can use some Intelling, and tinker with your MIPS and MHz > rates. By the way, what is a MHz rate? Do you mean the number of cycles > per millionth of a second, and if so, do you include wait cycles and > feed/refresh cycles? The ratio of two meaningless numbers produces a > number which is still pretty meaningless. One more time (I'd swear we've been thru this before in this newsgroup): 1) Measure the performance of a benchmark on machine A, giving time A. 2) Call that performance, arbitrarily, 1 MIPS. 3) Measure the same benchmark's performance on machine B, giving time B. 4) The MIPS rating, on this scale of B, is (time A) / (time B), i.e., one is really defining a "unit of equivalent work". A common unit is a VAX 11/780, which is usually called a 1Mips machine, although it really does about 500,000 VAX instructions / sec. 5) One can legitimately argue about what MHz means. A common way is to take the time to do an ALU operation as 1 cycle. wait cycles and refresh cycles are irrelevant, since you presumably see their effects in actual performance measurement. 6) The general point is that you must be precise enough about what you're using that people can understand what you mean. As usual, comparions of tiny hand-coded instructions sequences are meaningless, and you must measure substantial real code. you must also be exceeding careful to bound the domain of discourse, i.e., comparing scalar and vector machines can be misleading if done using ill-chosen benchmarks. Note that you're usually including effects of compiler performance as well. 7) Subject to all of the above, with enough definition, the Mips/MHz (or its inverse, cycles / equivalent Mip) can be a useful measure, if only because it gives you a somewhat technology independent measure. Like almost anything else in this area, if you get +- 10%, you're lucky. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086