CPU Performance Metrics in Embedded Systems: MIPS, DMIPS, CoreMark, MHz, FLOPS, and What Actually Matters

If you have ever compared two microcontrollers and asked “which one is faster?”, you have probably seen a mix of numbers: clock speed in megahertz, marketing slides with DMIPS, benchmark charts with CoreMark, and sometimes floating-point claims in MFLOPS or GFLOPS.

Those numbers are useful, but they are also easy to misuse.

A 240 MHz device can outperform a 400 MHz device in one task, then lose badly in another. A Linux-capable application processor can look “slow” when toggling a GPIO pin, yet completely dominate a bare-metal microcontroller in networking or multimedia. A benchmark score can be accurate and still fail to predict your product’s behavior.

This article gives a practical, beginner-to-intermediate roadmap for embedded CPU performance:

• What each metric actually measures
• Where each metric is useful
• Where each metric is misleading
• How software stack, memory, and architecture shape real speed
• How to compare real devices such as STM32, NXP i.MX RT, ESP32, Raspberry Pi, and TI processors

The goal is not to memorize one “best” metric. The goal is to make correct engineering decisions.

1. Introduction: Why Engineers Compare CPU and MCU Performance

In embedded systems, the processor decision controls:

• Feature set you can deliver
• Latency and control-loop stability
• User interface responsiveness
• Power consumption and thermal design
• Unit cost and long-term maintainability

This is why engineers compare microcontroller unit (MCU) and central processing unit (CPU) performance early in architecture selection.

Why comparing only MHz is often wrong

Megahertz (MHz) tells you clock frequency, not useful work completed per clock cycle. Two processors at the same frequency can have very different instruction throughput and memory behavior.

A simple example:

• A small in-order core with no cache may stall often waiting for memory.
• A larger core with branch prediction and caches may retire more instructions each cycle.

Both may run at 200 MHz, but the second core can finish a task faster.

Why real performance depends on more than the core

CPU speed in products is shaped by an entire execution chain:

flowchart TD
  A[Workload: control loop, DSP, networking, UI, AI inference] --> B[Algorithm and data structure]
  B --> C[Compiler and optimization flags]
  C --> D[CPU microarchitecture]
  D --> E[Cache and memory subsystem]
  E --> F[Bus and DMA activity]
  F --> G[OS stack: Bare Metal, RTOS, Linux]
  G --> H[Observed latency, throughput, energy]

Key contributors include:

• Architecture: ARM Cortex-M, ARM Cortex-A, RISC-V, Xtensa, MIPS, x86
• Compiler: GCC, Clang, vendor compiler, optimization settings
• Memory: flash wait states, tightly coupled memory, static random-access memory (SRAM), dynamic random-access memory (DRAM)
• Cache: instruction/data cache size and policy
• Operating system: bare metal, real-time operating system (RTOS), Linux
• Workload: integer control logic, digital signal processing (DSP), floating-point math, networking, storage, graphics

Section takeaway

Use benchmark numbers as hints, not truth. In embedded CPU performance, workload and system architecture matter more than any single headline metric.

2. What Is MHz?

Clock frequency, defined

MHz means megahertz, or one million clock cycles per second.

$$ 1\ \text{MHz} = 10^6\ \text{cycles/second} $$

A 100 MHz CPU has a 10 ns clock period. A 500 MHz CPU has a 2 ns clock period.

Does higher MHz always mean faster?

No. Higher frequency increases potential throughput, but actual speed depends on instructions per cycle (IPC), stalls, branch behavior, and memory latency.

A useful simplification:

$$ \text{Performance} \propto \text{Frequency} \times \text{Work per cycle} $$

Frequency is only one multiplier.

Practical comparison examples

At a high level:

• ARM Cortex-M0 usually has lower IPC and fewer pipeline features than Cortex-M4 or Cortex-M7.
• Cortex-M7 often executes significantly more work per MHz than Cortex-M3/M4 in many workloads due to deeper pipeline, better memory system options, and cache support in many implementations.
• Cortex-A53 at similar MHz can outperform many MCU cores in complex software workloads because of out-of-order effects, larger caches, and advanced memory systems, especially under Linux.
• RISC-V and MIPS cores vary widely by implementation; instruction set alone does not determine speed.

Real-world analogy

MHz is like engine revolutions per minute (RPM). Higher RPM does not guarantee a faster car if:

• Gear ratio is poor
• Torque is low
• Tires slip
• The road is congested

In CPUs, those equivalents are IPC, memory system, and software overhead.

Section takeaway

Use MHz to estimate timing budgets and peripheral clocks, not to compare absolute cross-platform performance.

3. What Is MIPS?

Definition

MIPS stands for Million Instructions Per Second.

$$ \text{MIPS} = \frac{\text{Instructions executed}}{\text{Execution time} \times 10^6} $$

Historical background

MIPS became popular when systems were simpler and instruction sets were narrower. It gave an intuitive “how many instructions per second” value and was easy to communicate.

Advantages

• Easy to understand
• Useful inside one architecture and toolchain for relative tuning
• Can help detect major regressions in similar code paths

Limitations

• “Instruction” is not comparable across instruction set architectures (ISA).
• One instruction on one core may do more work than one instruction on another core.
• Compiler choices dramatically affect instruction count.
• Memory stalls can hide behind instruction metrics.

Why MIPS cannot compare different CPU architectures

Suppose CPU A executes more instructions but each instruction is simpler. CPU B executes fewer instructions but each does more useful work. Raw MIPS may favor A while application runtime favors B.

This is the core problem in MIPS vs DMIPS discussions: plain MIPS alone ignores instruction quality and workload representativeness.

Section takeaway

MIPS can help for internal, apples-to-apples comparisons. It is weak for comparing different architectures, compilers, or workloads.

4. What Is DMIPS?

Dhrystone benchmark origins

DMIPS means Dhrystone MIPS. Dhrystone is an old synthetic benchmark focused on integer and string-heavy system programming patterns.

Vendors often report:

• DMIPS total score
• DMIPS/MHz normalized score

DMIPS definition

A common convention is:

$$ \text{DMIPS} = \frac{\text{Dhrystone score in dhrystones/sec}}{1757} $$

And:

$$ \text{DMIPS/MHz} = \frac{\text{DMIPS}}{\text{Clock in MHz}} $$

Why ARM vendors still publish DMIPS

Despite age, DMIPS remains common because:

• It has decades of historical data
• It offers quick normalized comparisons inside product families
• Marketing and application notes still reference it

Example DMIPS and DMIPS/MHz values (typical published ranges)

Values below are representative ranges for common cores, not guaranteed per-product numbers.

When DMIPS is useful

• Early filtering of related processors
• Rough sizing for integer-heavy firmware tasks
• Comparing variants of the same family at different clocks

When DMIPS is misleading

• Floating-point heavy DSP tasks
• Cache-sensitive workloads
• Linux user-space applications with system-call overhead
• Modern AI, multimedia, and network packet processing

Section takeaway

DMIPS is still useful as a quick first-pass metric, especially within ARM families. It is not enough to predict modern embedded application performance by itself.

5. What Is CoreMark?

Why CoreMark was created

CoreMark was created by Embedded Microprocessor Benchmark Consortium (EEMBC) to provide a modern, lightweight, open benchmark more representative than Dhrystone for embedded systems.

It mixes operations such as:

• List processing
• Matrix manipulation
• State machine behavior
• Cyclic redundancy check (CRC)

How CoreMark differs from Dhrystone

• Newer workload mix
• Better standardization and run rules
• More common in modern MCU datasheets
• More aligned with real embedded control and data tasks

CoreMark score and CoreMark/MHz

• CoreMark score: total benchmark throughput under defined conditions
• CoreMark/MHz: normalized efficiency per clock

$$ \text{CoreMark/MHz} = \frac{\text{CoreMark score}}{\text{MHz}} $$

Why modern MCU vendors prefer CoreMark

CoreMark tends to correlate better with practical firmware workloads than Dhrystone in many cases, and it is easier to reproduce across toolchains.

Example CoreMark ranges (representative)

Benchmarking concept diagram

flowchart LR
  A[Same benchmark source code] --> B[Compile settings]
  B --> C[Run on target hardware]
  C --> D[Score collection]
  D --> E[Normalize by MHz]
  E --> F[CoreMark and CoreMark/MHz comparison]

Section takeaway

For MCU benchmarks, CoreMark and CoreMark/MHz are generally more informative than plain MIPS and often more representative than DMIPS.

6. What Is FLOPS?

Definition

FLOPS means Floating-Point Operations Per Second.

Common units:

• MFLOPS: million FLOPS
• GFLOPS: billion FLOPS
• TFLOPS: trillion FLOPS

When FLOPS matters

FLOPS matters when your workload is floating-point dominant, for example:

• Fast Fourier transform (FFT)
• Control and estimation with heavy matrix math
• Computer vision kernels
• Neural network inference on floating-point models
• Scientific instrumentation

Why FLOPS is often irrelevant for many MCUs

Many low-cost MCUs:

• Have no hardware floating-point unit (FPU), or
• Have single-precision only, or
• Run integer-optimized fixed-point algorithms in production

In those systems, FLOPS headline values do not predict real firmware throughput.

Common FLOPS pitfalls

• Peak FLOPS assumes ideal instruction mix and full pipeline utilization.
• Real code has memory stalls, branches, and mixed integer-float instructions.
• SIMD (single instruction multiple data) and vector engines can dramatically alter practical results.

Section takeaway

Use FLOPS for floating-point workloads. Ignore it for mostly integer, control, protocol, and state-machine firmware.

7. Comparing Common Metrics

Below is a practical comparison of common embedded CPU performance metrics.

Decision shortcut

• Start with CoreMark/MHz or DMIPS/MHz for quick architectural screening.
• Use absolute CoreMark or DMIPS only after clock and memory assumptions are fixed.
• For floating-point workloads, add FLOPS and FPU/SIMD capability checks.
• Always validate with your own workload profile.

Section takeaway

There is no universal “best” metric. Good engineering uses multiple metrics plus workload profiling.

8. Bare Metal vs RTOS vs Linux Performance

The same silicon can behave very differently depending on software stack.

flowchart TB
  A[Bare Metal] --> B[RTOS]
  B --> C[Embedded Linux]

  A1[Single image, direct register control] --> A
  B1[Task scheduler, priorities, IPC] --> B
  C1[Processes, virtual memory, drivers, services] --> C

Bare metal

Characteristics:

• No scheduler overhead
• Lowest software latency
• Highest determinism (if code is disciplined)
• Minimal memory footprint

Best for:

• Motor control loops
• Ultra-low-latency interrupt handling
• Small safety-critical control tasks

RTOS

RTOS means real-time operating system.

Characteristics:

• Adds scheduler and context-switch overhead
• Predictable priority-based behavior
• Usually deterministic enough for hard or firm real-time applications
• Better modularity than large super-loop designs

Important overhead sources:

• Task context switching
• Interrupt masking and latency interactions
• Timer tick or tickless housekeeping
• Inter-task communication primitives

Embedded Linux

Characteristics:

• Process scheduler with fairness and throughput goals
• Virtual memory and memory management overhead
• User/kernel transitions through system calls
• Dynamic loader and shared libraries
• Larger cache and memory pressure from richer software stacks

Yet Linux also enables:

• Full TCP/IP networking stacks at scale
• TLS, VPN, containers, modern security tooling
• Multimedia frameworks
• Multi-process isolation and easier updates

Why Linux can look slower for GPIO but faster for real applications

A single GPIO toggle loop from user space on Linux includes scheduler effects and system-call boundaries, so it often appears much slower and less deterministic than bare metal.

But for real applications like encrypted networking, video pipelines, database logging, and web services, Linux often wins by a large margin due to mature software ecosystem and better resource management.

Quick overhead comparison

Section takeaway

Choose stack by workload and real-time needs. Bare metal wins micro-latency. Linux wins system functionality. RTOS is often the practical middle ground.

9. CPU Architecture Comparison

ARM Cortex-M

• Intended applications: low-power MCUs, control, sensing
• Typical performance: low to high MCU range, excellent real-time control
• Power: very efficient
• Operating systems: bare metal, RTOS, sometimes lightweight Linux on hybrid SoCs via companion cores

ARM Cortex-A

• Intended applications: application processors, GUI, networking, edge compute
• Typical performance: much higher per-core and system throughput
• Power: higher than Cortex-M class
• Operating systems: Linux, Android, rich OS stacks

ARM Cortex-R

• Intended applications: real-time high-reliability systems (storage controllers, automotive domains)
• Typical performance: strong real-time deterministic behavior with robust memory protection options
• Power: medium
• Operating systems: RTOS, safety-oriented platforms

RISC-V

• Intended applications: from tiny microcontrollers to Linux-capable SoCs
• Typical performance: highly implementation-dependent
• Power: ranges from ultra-low to high
• Operating systems: bare metal, RTOS, Linux (on capable cores)

MIPS

• Intended applications: historically broad embedded usage, still present in networking and legacy ecosystems
• Typical performance: implementation-dependent, less common in new mainstream MCU launches
• Power: varies by family
• Operating systems: RTOS, Linux in some SoCs

x86 (embedded variants)

• Intended applications: industrial PCs, gateways, edge servers
• Typical performance: high single-thread and system performance
• Power: usually higher
• Operating systems: Linux, Windows, virtualization-capable stacks

Section takeaway

Architecture name alone is not enough. Core generation, memory subsystem, and software ecosystem determine practical performance.

10. Real Processor Examples

The table below uses representative values from vendor documentation and commonly measured ranges. Benchmark numbers vary with compiler version, optimization flags, memory placement, and whether cache is enabled.

Common embedded processors comparison

Important note:

• Linux-class SoCs often emphasize application-level benchmarks rather than DMIPS/CoreMark in procurement documents.
• MCU-class parts still commonly highlight DMIPS and CoreMark.

Additional TI examples (for context)

Section takeaway

Real selection should compare processor class, memory system, and software stack together. Raw benchmark numbers are only one part of the decision.

11. How to Choose the Right Processor by Application

Different embedded workloads stress different subsystems.

Sensor reading and simple telemetry

Priorities:

• Low power
• Fast interrupt response
• Adequate analog and communication peripherals

Usually sufficient:

• Cortex-M0+/M3/M4 class
• Small RTOS or bare metal

Motor control

Priorities:

• Deterministic interrupt latency
• Fast control loops (current, speed, position)
• DSP math support

Usually preferred:

• Cortex-M4/M7, TI C2000, or similar real-time cores
• Bare metal or RTOS

Robotics and industrial automation

Priorities:

• Mixed real-time control and high-level planning
• Multiple fieldbuses and networking
• Safety and diagnostics

Common architectures:

• Dual-domain designs (real-time MCU + Linux application core)
• SoCs with Cortex-A + Cortex-M islands

GUI and HMI

HMI means human-machine interface.

Priorities:

• 2D/3D graphics pipeline
• Display bandwidth
• Memory bandwidth
• Framework support (for example, Qt, LVGL, Wayland stacks)

Usually needed:

• Cortex-A class or high-end M7 with dedicated graphics acceleration for simpler HMIs

Networking

Priorities:

• Packet processing
• Security (TLS, secure boot, crypto acceleration)
• Protocol stack maturity

Typically:

• Linux-class processors for complex network services
• MCU class for constrained real-time network edges

Audio processing

Priorities:

• Continuous sample throughput
• Low jitter
• DSP and FPU capability

Common fit:

• Cortex-M4/M7 for embedded effects and voice pipelines
• Cortex-A class when full multimedia frameworks are needed

Video processing

Priorities:

• Dedicated codec hardware
• DRAM bandwidth
• ISP/GPU integration

Typically required:

• Application processors (Cortex-A class, x86 embedded, or specialized SoCs)

AI/ML inference and edge AI

AI means artificial intelligence. ML means machine learning.

Priorities:

• Multiply-accumulate throughput
• Vector/SIMD/NPU acceleration
• Memory bandwidth and model footprint

Common options:

• MCU with tinyML for low-power wake-word and anomaly detection
• SoCs with NPUs for camera and multimodal edge inference

Automotive and medical devices

Priorities:

• Functional safety
• Deterministic behavior
• Long-term supply and certification ecosystem
• Security lifecycle support

Selection focuses as much on safety architecture and tooling as on benchmark score.

Section takeaway

Match processor capabilities to dominant bottlenecks in your application, not to the highest generic benchmark number.

12. Common Misconceptions to Avoid

Myth 1: Higher MHz always means faster

Reality: Higher frequency helps only when architecture and memory can feed the core efficiently.

Myth 2: More cores always improve embedded performance

Reality: Many embedded tasks are latency-bound or hard real-time single-thread loops. Extra cores can increase complexity without improving critical path timing.

Myth 3: Linux is always slower

Reality: Linux is slower for micro-latency register-level tasks, but often far better for networking, security, storage, and multimedia workloads.

Myth 4: MIPS is enough to compare CPUs

Reality: MIPS alone is not cross-architecture meaningful. MIPS vs DMIPS already shows why normalization matters, and even DMIPS is only partial.

Myth 5: Benchmarks represent every real application

Reality: Benchmarks are synthetic snapshots. Real products include interrupts, I/O bursts, DMA contention, thermal throttling, and software stack overhead.

Section takeaway

Treat benchmarks as indicators, not guarantees. Validate with representative end-to-end tests.

13. Practical Engineering Advice: What to Evaluate in Real Projects

When comparing embedded CPU performance, evaluate the whole compute platform.

1. Memory bandwidth and latency

• Check flash wait states, SRAM speed, DRAM controller capability.
• A fast core starved by memory behaves like a slow core.

2. Cache architecture

• Instruction cache and data cache size and associativity matter.
• Cache misses can dominate runtime for data-heavy applications.

3. DMA and bus architecture

DMA means direct memory access.

• Verify if DMA can offload CPU for ADC, SPI, I2S, Ethernet, camera pipelines.
• Check arbitration on AXI/AHB buses under contention.

4. FPU, DSP, SIMD, NEON

• FPU: hardware floating-point unit
• SIMD: single instruction multiple data
• NEON: ARM SIMD extension in Cortex-A class

For signal processing and inference kernels, these features can matter more than DMIPS.

5. GPU, NPU, and accelerators

• GPU: graphics processing unit
• NPU: neural processing unit

Dedicated accelerators can provide order-of-magnitude gains in specific domains (graphics, codecs, AI inference, crypto).

6. Interrupt latency and jitter

Control systems care about worst-case timing, not average throughput. Measure:

• Interrupt response time
• Jitter under full system load
• Behavior with cache misses and DMA bursts

7. Compiler optimization and toolchain quality

Try realistic builds with:

• -O2 and -O3
• Link-time optimization (LTO)
• Profile-guided optimization where supported

Toolchain differences can swing benchmark numbers significantly.

8. Power consumption and thermal envelope

Performance per watt often matters more than peak throughput in battery or fanless designs.

9. Cost and availability

Engineering-optimal parts are not always supply-chain optimal. Verify:

• Long-term availability
• Package options
• Second-source strategy where possible

10. Benchmark and profile your own application

Recommended workflow:

1. Use DMIPS/CoreMark as first filter.
2. Build a representative software prototype.
3. Profile hotspots with real compiler flags and memory placement.
4. Measure latency, throughput, and energy on target hardware.
5. Re-check worst-case behavior under load.

Section takeaway

The best embedded processor comparison is benchmark plus workload profiling plus system-level constraints.

14. Conclusion: When to Use MHz, DMIPS, CoreMark, and FLOPS

Here is a practical summary:

• Use MHz for clock-domain planning and rough timing intuition.
• Use DMIPS or DMIPS/MHz for quick, legacy-friendly integer performance screening.
• Use CoreMark and CoreMark/MHz for modern MCU benchmarking comparisons.
• Use FLOPS for floating-point intensive workloads only.

Most important principle:

Benchmark numbers are starting points. Final processor selection should combine:

• Benchmarks (DMIPS, CoreMark, FLOPS where relevant)
• Real application profiling
• Memory and I/O architecture analysis
• RTOS/Linux stack behavior
• Power, cost, and lifecycle constraints

If you remember one line from this guide, use this:

In embedded systems, the fastest processor is the one that meets your workload, timing, power, and cost targets in the real product, not the one with the biggest marketing number.

FAQ: Quick Answers Engineers Ask

Is CoreMark better than DMIPS?

For many modern MCU benchmarks, yes. CoreMark is generally more representative and better standardized than Dhrystone-based DMIPS, though both are still synthetic.

Should I ignore MHz completely?

No. MHz still matters for cycle-level timing and peripheral planning. It is just not sufficient for cross-device performance ranking.

How do I do a fair MIPS vs DMIPS comparison?

Use DMIPS for normalized legacy comparison and only compare MIPS values when architecture, compiler, and workload are equivalent.

Why does my Linux board lose to an MCU in GPIO toggling?

Linux prioritizes multitasking and system features, so user-space GPIO timing includes scheduler and kernel overhead. That does not reflect Linux strength in complex, feature-rich workloads.

What is the best metric for how to compare microcontrollers?

Use a set: CoreMark/MHz, memory system analysis, interrupt-latency measurement, and your own application profiling.

Final Checklist for Embedded CPU Selection

Before locking a processor, confirm all items:

• Workload class identified (control, DSP, networking, UI, AI)
• Hard real-time constraints measured (not assumed)
• Memory bandwidth validated under realistic load
• DMA offload strategy defined
• Benchmark claims reproduced with your toolchain
• Bare Metal vs RTOS vs Linux decision aligned with product requirements
• Power and thermal margins validated
• Security and lifecycle support reviewed
• Cost and supply stability confirmed

That process is how teams move from benchmark-driven decisions to reliable product performance.