Subject: Hz to MIPS?

From: [email-masked]
Date: Sun, 18 Mar 2001 16:58:29 EST

I know this question is not of direct relevance to this forum - but I 
believe folks may be able to offer some input.

Is there any known procedure (general heuristics?) whereby, given the clock 
speed associated with a specific CISC based x86 processor, the associated 
MIPS rating can be calculated - with a broad level of accuracy?

- Don

---

From: [email-masked]
Date: Sun, 18 Mar 2001 22:54:16 -0500

> MIPS rating can be calculated - with a broad level of accuracy?

Not really.  The problem is that the MIPS rating can even change during
execution, if the integer/floating point mix changes, etc.  Added into
this are issues like cache misses, register reloads (for instance, one
reason why the rule of thumb for a LONG time that PowerPC chips had 30% more
throughput than an x86 chipset of the same clock speed was that the PowerPC
has 32 integer and 32 floating point registers, and the x86 has (effectively)
only 4-8 of each depending how you count, so the x86 ended up doing alot
more load/store operations).  The effective MIPS will vary based on whether
you have a long/short loop, how ell that x86 core implements branching,
what size and geometry L2 cache you have, and a lot of other factors that
aren't on the actual CPU.

It's *LONG* been known that Intel and Athlon chipsets perform differently
for different instruction mixes at the same clock speed.

Note that even the Linux kernel BogoMIPS is exactly that - bogus.  Its
sole reason for existing is for calibrating a delay loop in the kernel,
with a known instruction sequence.  The BogoMIPS is basically the answer
to the question "for what value of N will the null loop  for(i=0;i<N;i++) {}
fall out the bottom exactly 1/100th of a second later?"

It would be *highly* suggested that instead of trying to calculate MIPS,
you figure out why you're interested in that value, and find a better
predictor of whatever performance you're trying to measure.  I told one
researcher I know that for *HIS* work, the Seti@Home software was a good
predictor of performance - but *ONLY* because the sort of math and
calculations involved happened to be a good fit to *his* research.
If Seti@Home ran twice as fast on a specific SGI than on a specific Sun,
his code probably would too.  I've told OTHER researchers to stay *far*
away from using that as a benchmark, because signal processing isn't
finite element analysis (for instance).

So the *real* question is "What problem are you trying to solve by coming
up with a MIPS rating"?

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech