hedlund@unc.UUCP (Kye Hedlund) (04/21/86)
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. Drystones and Whetstones
also measure the quality of code produced by the compiler, etc., etc, etc.
We could generate hundreds of net messages thinking of other shortcomings.
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.
---- Kye S. Hedlund
Dept. of Computer Science
U. of North Carolina
Chapel Hill, NC 27514
CSNet: hedlund@unckludge@gitpyr.UUCP (04/26/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
apn@gilbbs.UUCP (Alex Novickis) (04/27/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.
dollas@uiucdcsb.CS.UIUC.EDU (04/29/86)
Even so, things are usually even more complicated, as to what an
instruction is. The 68010 to 68020 comparison is fair, because of the
instruction set similarity/upward compatibility. Among machines of
different kinds, however, it may not be fair; one instruction may be
'increment the program counter by one', whereas another may be 'divide
by <some number>'. The various benchmarks came to equalize the criteria,
but with the implicit assumption that 'you get what you see'... The Cray
computers don't do exceptionally for example because the pipelining of
operations is not used!!!
Apostolos Dollas
U. of Illinois
USENET: ...!{pur-ee,ihnp4}!uiucdcs!dollas
CSNET: dollas%uiuc@csnet-relay.arpa
ARPA: dollas@uiuc.arpamash@mips.UUCP (John Mashey) (04/29/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
dennisg@sdcrdcf.UUCP (Dennis Griesser) (05/01/86)
In article <206@gilbbs.UUCP> apn@gilbbs.UUCP (Alex Novickis) writes: > 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.... As I recall, Apple only made that claim because IBM was touting the 8088 as a 16-bit CPU. I agree with the "give me a break". It isn't fair to single our Apple, though. Disclaimer: I own a "Mac-thing" and like it.
kissell@garth.UUCP (Kevin Kissell) (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.ARpA (Eugene D. Brooks III) (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.
speck@cit-vax.Caltech.Edu (Don Speck) (05/12/86)
In article <1363@unc.unc.UUCP> hedlund@unc.UUCP (Kye Hedlund) writes: >When comparing the performance 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. >[...] 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.2BSD). >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. The MHz rate entering the clock pin is not necessarily the same as the internal operation rate. All MOS chips derive multiple internal clock phases from the clock input, and some need more phases than others, and so have to divide the input by a larger number to get enough reference points. For example, the 68010 is designed in 3.2um nMOS, a technology which needs dynamic logic to save power, and dynamic logic needs lots of clock edges to get anything done. So, the 68010 uses 4 phases internally, which it derives by dividing the input clock by 2. The 68020 is 2um CMOS, a technology which does not need such extensive precharging, so two phases are adequate and the clock is not divided down. Thus, 10MHz 68010 cycle time = 200ns, 16.67MHz 68020 cycle time = 60ns. This reduction in cycle time is not all due to technology; 2um transistors only switch about twice as fast as 3.2um transistors. It almost looks like the cycle time reduction accounts for all of the performance, but no, the Sun-3 has wait states (memory access = 4.5 cycles) and the Sun-2 doesn't (memory access = 2 cycles). The 68020 does have at least a 2:1 "architectural advantage" over the 68010, but it is in memory cycles, not processor cycles. It bugs me that rational people assign such significance to the clock rate. I have a microprocessor that uses a 60 MHz clock - should you be impressed? No, you shouldn't. The clock rate is so high only because I needed a 5X base clock to generate all the required clock edges (the chip takes precharging to an absurd extreme, which wasn't my idea). Don Speck speck@vlsi.caltech.edu seismo!cit-vax!speck
philm@astroatc.UUCP (Phil Mason) (05/13/86)
It seems to me that this whole situation about the measurement of relative
computing power is directly analogous to the situation when the early
physicists and engineers first attempted to formalize the concept of POWER.
One basic unit of mechanical power is that of Horsepower. A horsepower is the
amount of power necessary to raise 33,000 pounds by one foot in one minute.
Obviously, someone tried to rank every other powerful machine against a horse.
Other units of power were theoretically derived from fundamental units.
I think we should look towards this example in order to get a bearing on the
kind of measurement we all need in the enviroment of computer benchmarking.
Power is defined to be the time rate at which work is done. That leaves us
in a little bit of a quandry. What is a unit of work for computer systems?
It must be related to how the CPU affects the information it processes.
I can think of two methods with which one may approach this :
(1) Use machine independent standard tasks to grade performance between
different computers - The Benchmark Approach
-- or --
(2) Define a fundamental unit of information processing work
- The Theoretical Approach
I am sure that some form of theoretical approach would bear fruit given
enough fruit. My initial guess is that it would have some relation to
Turing machine theory as well as algorithm and information theory works
that already exist.
Comments?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Kirk : Bones ? Phil Mason, Astronautics Technical Center
Bones : He's dead Jim. {Your Favorite System}!uwvax!astroatc!philm
My opinions are mine and not necessarily those of my employer.
(I would like to think that my employer believes in them too.) :-)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=kludge@gitpyr.UUCP (Scott Dorsey) (05/13/86)
In article <384@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >One basic unit of mechanical power is that of Horsepower. A horsepower is the >amount of power necessary to raise 33,000 pounds by one foot in one minute. > >I think we should look towards this example in order to get a bearing on the >kind of measurement we all need in the enviroment of computer benchmarking. > >Power is defined to be the time rate at which work is done. That leaves us >in a little bit of a quandry. What is a unit of work for computer systems? >It must be related to how the CPU affects the information it processes. What about I/O bound tasks? Do you want to measure 'floating-point division power' or 'BCD addition power'. Your analogy with earlier machines is quite apt, except that it must be pointed out that, as mechanical devices do not all perform the same tasks, neither do computers perform the same tasks. Comparing a can opener and a lawnmower is like comparing a System/36 and an array processor. The lawnmower may have more horsepower than the can opener, but it is useless for opening cans. Likewise, the can opener lacks 'lawnmowing power'. The System/36 may do a poor job of Fourier transformation, but I'd hate to see something like a COBOL payroll program running on an array processor. Computing power CANNOT be measured in one scalar number. -- ------- 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
tuba@ur-tut.UUCP (Jon Krueger) (05/13/86)
Keywords: In article <384@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >[analogy between measuring mechanical power and compute power] >I can think of two methods with which one may approach this: >(1) Use machine independent standard tasks to grade performance between > different computers - The Benchmark Approach >(2) Define a fundamental unit of information processing work > - The Theoretical Approach >I am sure that some form of theoretical approach would bear fruit given >enough fruit. My initial guess is that it would have some relation to >Turing machine theory as well as algorithm and information theory works >that already exist. Comments? My guess as to why theoretical approaches haven't emerged as yet: we do different things with our computers. A mechanical task is usually measurable as a single function. A machine performs well for the function for which it was designed, and very badly or not at all for any other function. By contrast, a piece of computer hardware, particularly a processor for a general purpose computer, has many functions. It's hard to predict its performance on different functions based on And of course, as your favorite hardware sales critter will tell you, his hardware will perform better or worse on your application than his benchmarks led you to believe. The theoretical approach must overcome the same problem. My guess is that a "fundamental unit of information processing work" will end up just as relative to an abstract machine as Dhrystone is relative to its particular mix of integer, looping, and subroutine calling. Of course, measuring performance of your own application beats either, and either beats MIPS.
philm@astroatc.UUCP (Phil Mason) (05/15/86)
In article <1774@gitpyr.UUCP> kludge@gitpyr.UUCP (Scott Dorsey) writes: >In article <384@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >> >>Power is defined to be the time rate at which work is done. That leaves us >>in a little bit of a quandry. What is a unit of work for computer systems? >>It must be related to how the CPU affects the information it processes. > > What about I/O bound tasks? Do you want to measure 'floating-point >division power' or 'BCD addition power'. > Your analogy with earlier machines is quite apt, except that it must be >pointed out that, as mechanical devices do not all perform the same tasks, >neither do computers perform the same tasks. Comparing a can opener and a >lawnmower is like comparing a System/36 and an array processor. The lawnmower >may have more horsepower than the can opener, but it is useless for opening >cans. Likewise, the can opener lacks 'lawnmowing power'. The System/36 >may do a poor job of Fourier transformation, but I'd hate to see something >like a COBOL payroll program running on an array processor. > Computing power CANNOT be measured in one scalar number. >-- Yes, I agree. I didn't say it was going to be easy. Let's look at it this way. There are a number of generic information processing functions that a computer performs : Floating point, Integer, Program control flow and I/O operations. There are also subdivisions of these tasks according to the size and type of the operands (i.e., scalar, vector, array - 8, 16, 32, 64+ bits etc.). A matrix of performance parameters could be created in such a way as to give an end user the capability to weigh the various performance figures for his/her major tasks. Careful software simulation and instruction analysis can outline what operations are critical for the application. The performance table can then be weighted with the results of the simulation and a final number derived from the weighted table as to the suitability and performance for a particular computer for a particular task. General comparison between computers can be made in this fashion as well. If a CRAY 2 performs on more types of data and faster in every category than another computer, the CRAY 2 is a higher performance machine. Without application specfic information, there can be some machines that have most of the performance figures greater than another, but there might be some parameter of perfomance that is very heavily utilized by an application that would make the overall majority comparison false. Comments?? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kirk : Bones ? Phil Mason, Astronautics Technical Center Bones : He's dead Jim. {Your Favorite System}!uwvax!astroatc!philm My opinions are mine and not necessarily those of my employer. (I would like to think that my employer believes in them too.) :-) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
kludge@gitpyr.UUCP (Scott Dorsey) (05/16/86)
In article <392@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >A matrix of performance parameters could be >created in such a way as to give an end user the capability to weigh the >various performance figures for his/her major tasks. Careful software >simulation and instruction analysis can outline what operations are critical >for the application. The performance table can then be weighted with the >results of the simulation and a final number derived from the weighted table >as to the suitability and performance for a particular computer for a >particular task. Not only an excellent idea, but my Architecture project. Also not a very easy task, because it is hard to determine the 'smallest possible tasks' to be performed, without abstracting the simulation completely away from the application. It is still well worth trying. -- ------- 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
jack@boring.uucp (Jack Jansen) (05/16/86)
The horsepower analogy shows exactly what is wrong with the approach of trying to compare machines: It doesn't give you *any* information, except for the fact that the engine, when taken out and attached to a winch, will be able to lift so many pounds so high in so many minutes. Frankly, when I buy a boat, I couldn't care less. When I want to buy a boat, there are zillions of factors that are of importance: how fast does it go, how much cargo can I put in it, can it make sharp turns, how far will it go without refuelling, etc. The horsepower of the engine influences a lot of these things, but is useless as a measure of them. In my opinion, the same holds for Mips or Mips/Mhz or whatever measure you try to invent for comparing computers. Computers are just too versatile to be catched in a single performance-figure. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
peters@cubsvax.UUCP (Peter S. Shenkin) (05/16/86)
In article <astroatc.392> philm@astroatc.UUCP (Phil Mason) writes: >In article <1774@gitpyr.UUCP> kludge@gitpyr.UUCP (Scott Dorsey) writes: >>In article <384@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >>> >>>Power is defined to be the time rate at which work is done. That leaves us >>>in a little bit of a quandry. What is a unit of work for computer systems? >>>It must be related to how the CPU affects the information it processes. >> >> Your analogy with earlier machines is quite apt, except that it must be >>pointed out that, as mechanical devices do not all perform the same tasks, >>neither do computers perform the same tasks. >> Computing power CANNOT be measured in one scalar number. >>-- > >Yes, I agree. I didn't say it was going to be easy. > >Let's look at it this way. There are a number of generic information processing >functions that a computer performs : Floating point, Integer, Program >control flow and I/O operations. There are also subdivisions of these tasks >according to the size and type of the operands (i.e., scalar, vector, array - >8, 16, 32, 64+ bits etc.). Is performance on a particular program likely to be measurable as a linear combination of figures of merit for these tasks? For example, suppose you had a "MIPS"-like figure for floating point (FP), integer arithmetic (I), and looping (L). Suppose in some program running on a particular data set there were nfp FP instructions, ni, I instructions and nl times looping took place. Could we say, then, that performance on this program with this data set = nfp*FP + ni*I + nl*L ? What I really mean is, is there a list of "fundamental operations" which would constitute a such a linear space for performance, applicable to all or most machines? Or is the problem essentially non-linear? Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
franka@mmintl.UUCP (Frank Adams) (05/20/86)
In article <332@ur-tut.UUCP> tuba@ur-tut.UUCP (Jon Krueger) writes: >My guess is that a "fundamental unit of information >processing work" will end up just as relative to an abstract machine as >Dhrystone is relative to its particular mix of integer, looping, and >subroutine calling. Of course, measuring performance of your own >application beats either, and either beats MIPS. Of course, what you really want to measure is the performance of your application on the system after you have spent a few man-months optimizing for the environment. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108