[sdiy] CPUs, was... Simulating a Moog

[Rainer Buchty]

> Ultimately, fastness being measured in mHZ, cycles per second, can be
> very deceptive. This tells you how fast cycles are, but not how many
> operations per cycle. MIPS - million of instructions per second- is I
> think I better guide to gauging performance, but I hear quoted less
> often.

Because MIPS by definition says nothing as well. A bit more than
clock speed, but not very much (MIPS=clock/#instr). Plus, they are
deceptive as well.

A small example from the last computer architecture examn "my" students
had to endure: Processor A runs an application in 2ms. It has a CPI of 7/5
and the application has 3,500,000 instructions. Processor B runs the same
(in function) application also in 2ms. It has a CPI of 3/2 and the
application requires 1,500,000 instructions.

Now do the math: "A" has 1750 MIPS, "B" only 750 MIPS. So "A" is better?

Well, let's look at the frequency which comes down to 2450MHz for "A" and
1125MHz for "B".

Now which processor do you chose?

For this specific task *I* would go with processor B... Although the
common user's (and unfortunately most of the students') reflex is to pick
"A" because it "can process so much more instructions in the same time"
compared to "B"... Or in other words, because it has a highly inefficient
instruction set resulting in 2.3x higher instruction count and needs to be
clocked at more than twice the rate to achieve the same results as "B".

And that's why you don't use MIPS, raw clock rate or any other hardware
parameter anymore for comparison of architectures but standardized
benchmarks (SPEC, EEMBC, etc.), so you can compare performance according
to applications.

Rainer

(Sorry for the CS lesson :)