kludge%gitpyr@gitpyr.UUCP (04/27/86)
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. -- ------- Disclaimer: Everything I say is probably a trademark of someone. But don't worry, I probably don't know what I'm talking about. Scott Dorsey " If value corrupts kaptain_kludge then absolute value corrupts absolutely" ICS Programming Lab (Where old terminals go to die), Rich 110, Georgia Institute of Technology, Box 36681, Atlanta, Georgia 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge
Unknown@hplabs.UUCP (04/27/86)
This message is empty.
apn%gilbbs@gilbbs.UUCP (04/28/86)
In article <1712@gitpyr.UUCP>, kludge@gitpyr.UUCP (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. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ I agree, the numbers are essentially meaningless. Even among members of the same CPU family, care must be taken to actually compute the real time to do a given task ( i.e. tight delay loop ) for example a HD64180 executes most z80 instructions in 25% less time running at the *same* clock speed. A similiar comparison can be made between Intel's x86 cpu's and NEC Vx0 parts, but only on certain instructions. However, in the 68010/68020 we simply maybe comparing bus sizes and respective bandwidths. The claims I really enjoyed reading were when Apple quoted there Mac - thing as having a 32 bit cpu. Maybe those of use with 80n87's should claim to have 80 bit cpu's ? GIVE ME A BREAK GUYS.... -- ============================================== Alex Paul Novickis (707) 575 8672 Fulcrum Computers, Inc. 1635 Ditty Ave. Santa Rosa, CA 95401-2636 {ihnp4, dual}!ptsfa!gilbbs!apn "Almost doesn't count... but it almost does" DISCLAIMER: The opinions contained herein may not be of anyone that I know.
mash%mips@mips.UUCP (04/30/86)
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: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
kissell%garth@garth.UUCP (05/01/86)
In article <1363@unc.unc.UUCP> hedlund@unc.UUCP (Kye Hedlund) writes: >When comparing the perofrmance of microprocessor architectures, it would >be desirable to separate architectural factors from technological >factors. For example, if machine A has performance 1.0 and machine B >has performance 2.0, does B have a "faster architecture?" The answer of >course is "it depends." It depends on many factors including the >underlying technology used to fabricate the chip. If B was implemented >in 1.0um CMOS and runs off a 20MHz clock whereas A was fabricated with >4um nMOS and runs at 5MHz then perhaps the architects (and >implementors) of A did an excellent job with a slower technology. >Perhaps A will run circles around B if implemented with similar >technology. > >This leads us to making a first attempt at factoring out the technology >speed out of performance estimates of microprocessors by computing >performance/MHz. Mips/MHz immediately comes to mind but one could >also compare Drystones/MHz, Whetstones/Mz, etc. > >This measure is clearly far from precise. Performance ratings are subject >to interpretation and variation. MHz is by no means a complete >measure of the underlying circuit technology. Indeed, if cycle time is truly a function of circuit technology, one wonders how Seymour Cray has managed to get such fast cycle times with technology that he gleefully admits was a generation behind the state of the art. Cycle time is as much a function of architecture as of technology - it's not just how fast your transistors switch, it's also how few of them you can get away with stringing together in each logic stage. Kevin D. Kissell Fairchild Advanced Processor Division
brooks%lll-crg@lll-crg.UUCP (05/02/86)
In article <315@garth.UUCP> kissell@garth.UUCP (Kevin Kissell) writes: >Indeed, if cycle time is truly a function of circuit technology, >one wonders how Seymour Cray has managed to get such fast cycle times >with technology that he gleefully admits was a generation behind the >state of the art. Cycle time is as much a function of architecture >as of technology - it's not just how fast your transistors switch, >it's also how few of them you can get away with stringing together in >each logic stage. Seymour Cray gets fast cycle times the good old fashioned way, no microde and pipeline everything in sight, including the channel to main memory. Now that Micro makers have finally started picking up on the fundamentally important load/store RISC ideas, they had better start looking at pipelining the functional units of the cpu along with the channel to main memory if they want more speed.
kludge@gitpyr.UUCP (Scott Dorsey) (05/12/86)
In article <459@mips> mash@mips writes: >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. This is a comparative rate, which is extremely useful. However, it varies depending on the machine that you use for comparison. The state of the art comparison machine will change quite rapidly as technology advances, and this is not good. My MIPS will not be the same as his MIPS. You can say 'my machine runs at '.3 Vax Dhrystones', or some such thing, but DON'T CALL IT MIPS! MIPS means one specific thing, namely a not-very-useful measure. -- ------- Disclaimer: Everything I say is probably a trademark of someone. But don't worry, I probably don't know what I'm talking about. Scott Dorsey " If value corrupts kaptain_kludge then absolute value corrupts absolutely" ICS Programming Lab (Where old terminals go to die), Rich 110, Georgia Institute of Technology, Box 36681, Atlanta, Georgia 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge