Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!mmshah
From: mmshah@athena.mit.edu (Milan M Shah)
Newsgroups: comp.arch
Subject: Re: Novice question:  measuring speed
Message-ID: <1991Mar13.163720.19778@athena.mit.edu>
Date: 13 Mar 91 16:37:20 GMT
References: <645@ssdc?>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 26

In article <645@ssdc?> jbasara@ssdc (jim basara) writes:
>Here's a novice question for you architecture folks.  Could someone please
>provide me with a descriptive explaination of why MIP ratings are not a 
>good way of comparing processing speed for RISC machines as opposed to MFLOPS?
>s if they are not accurate.  Is it possible that the MIP ratings can be 
>manipulated so that a processor with a higher MIP rating may actually be
>considerably slower than one with a lower MIP rating???  What kinds of things
>do I need to be aware of when comparing processing speeds?
>

To quote from Patterson and Hennessy's _A Quatitative Approach_, pg 40-42,

  o MIPS can vary inversely with performance!

The classic example (of the above point) is the MIPS rating of a machine with
optional floating point hardware. Since it generally takes more clock cycles
per floating-point instruction than per integer instruction, floating point
programs using the optional hardware instead of software floating point
routines take less time but have a *lower* MIPS rating. Software floating
point executes simpler instructions, resulting in higher MIPS rating, but it
executes so many more that overall execution time is longer.

end-of-quote.

Milan
.