Explaining MIPS and MFLOPS: Throughput Metrics for Computer Performance

MIPS and MFLOPS are commonly used performance indicators that translate execution capability into human-readable rates. However, both metrics can be misleading if you compare systems without accounting for instruction-set differences, work mix, and how operations are counted (e.g., what counts as “one instruction” or “one floating-point operation”).

Conceptually:

• MIPS focuses on integer/overall instruction execution rate.
• FLOPS-based metrics focus on floating-point arithmetic throughput (e.g., adds/muls/FMA counted per the method used).
  These metrics are best understood through relationships to CPU frequency, average cycles per instruction, and functional-unit throughput, rather than as absolute truths about “speed.”

Below is a performance-model view showing how MIPS and MFLOPS relate to clock and execution behavior:

⚠️ Key limitation: Because “instruction” and “floating-point operation” counts depend on the architecture, compiler, and workload, you must interpret MIPS/MFLOPS as metric definitions applied to specific programs, not as universal properties of hardware.

What MIPS really measures

MIPS (Millions of Instructions Per Second) measures instruction throughput: how many (program) instructions complete per second, typically reported as “MIPS.” A common way to relate MIPS to hardware is via average cycles per instruction (CPI).

A simplified relationship is:

• Let $f$ be the clock frequency in cycles/second.
• Let CPI be the average cycles per instruction for the workload.
• Then instructions per second $\approx \frac{f}{\text{CPI}}$.
• Convert to millions per second:
  $\text{MIPS} \approx \frac{f}{\text{CPI}\cdot 10^6}$

This highlights why MIPS comparisons are tricky:

• Different ISAs (ISA types) have different instruction “power” (e.g., one instruction may do more work).
• Different workloads change the mix of instruction types, which changes CPI.
• Microarchitectural effects (pipelining, caches, hazards) change effective CPI.

What MFLOPS really measures

MFLOPS is the same idea, but for floating-point arithmetic. First define FLOPS:

• FLOPS count arithmetic operations (adds, multiplies, fused multiply-add, etc.) over time.
• MFLOPS is FLOPS scaled by $10^6$.

A simplified throughput model uses:

• $f$: clock frequency
• “FLOPs per cycle” (throughput per cycle), which depends on the floating-point units and how the workload is vectorized/unrolled.

Then: $\text{MFLOPS} \approx \frac{f \cdot (\text{FLOPs per cycle})}{10^6}$

Again, interpretation depends on how the benchmark counts operations:

• Some benchmarks count each multiply and add separately.
• Some count fused multiply-add (FMA) as 2 FLOPs, because it performs multiplication + addition in one instruction.
• Real performance is affected by memory bandwidth, vector width, instruction scheduling, and whether operations are fully pipelined.

Practical meaning: throughput vs “real work”

MIPS and MFLOPS are throughput metrics. They do not directly reflect:

• the amount of useful work completed (e.g., algorithmic time),
• energy efficiency,
• stalls caused by cache misses or branch mispredictions,
• instruction mix (for MIPS) or data movement limitations (for MFLOPS).

A helpful mental model is: each metric measures “rate of the thing you counted,” but the thing you counted may not correlate perfectly with end-to-end application performance.

Relationship to execution modeling (why the formulas matter)

To connect these metrics to hardware behavior, consider two execution views:

1. Instruction throughput view (MIPS):

• Effective CPI incorporates pipeline efficiency, hazards, and stalls.
• MIPS increases with clock frequency and decreases with higher CPI.

2. Floating-point throughput view (MFLOPS):

• MFLOPS reflects how many floating-point operations the CPU can retire per unit time when the workload feeds the floating-point units.
• Bottlenecks like memory latency can reduce the effective FLOPs per cycle.

Mermaid visualization of bottlenecks affecting each metric: