compilersutra

Posted on Nov 11 Originally published at compilersutra.com

Know Your Silicon: Why CPU Info Matters for Honest Performance

#hardware #cpu #csperf #performance

Why this lesson exists

When you blame a compiler for a slowdown you’re often ignoring the silicon that actually executed the code. Without a record of the CPU model, stepping‑through, or micro‑architecture, you can’t tell if a change is real or just a quirk of a different chip.

Recap — where we are in the series

Ep 1 — Why a Single ./a.out Time Misleads Your Performance Claims — Capture reproducible evidence with csperf.
Ep 2 — Warm vs Cold: Why a Single Trial Misleads Performance Claims — Use warm‑up and repeat for credible data.
Ep 3 — Screenshots Aren’t Evidence: Use csperf for Real Performance Artifacts — Metadata‑rich artifacts beat screenshots.
Ep 4 — Comparing Across Machines: Why Metadata Matters in csperf — Machine metadata enables honest cross‑machine comparison.
Ep 5 — csperf: A Lightweight Observatory for Honest Performance Tracking — Quick, reliable evidence of your compiler environment.
Ep 6 — csperf Doctor: First Command to Diagnose Toolchain Issues — Validate the toolchain before blaming performance.
Ep 7 — csperf: How to Capture Build Metadata — Record compiler flags and versions.
Ep 8 — csperf: Profiling with the Built‑in Profiler — Get per‑function timing.
Ep 9 — csperf: Visualizing Performance Artifacts — Turn data into charts.
Ep 10 — csperf: Automating Repetitive Benchmark Runs — Scripted repeatability.
Ep 11 — csperf: Handling Randomness in Benchmarks — Statistical confidence.
Ep 12 — csperf: Comparing Compiler Backends — Side‑by‑side backend analysis.
Ep 13 — csperf: Measuring JIT Performance — Capture JIT compilation overhead.
Ep 14 — csperf: Benchmarking with Different Optimizations — Compare -O0, -O2, -O3.
Ep 15 — csperf: Using Environment Variables for Reproducibility — Pin down runtime settings.
Ep 16 — csperf: Cross‑Platform Benchmarking — Run the same code on Windows, macOS, Linux.
Ep 17 — csperf: Benchmarking with Different Libraries — Measure library impact.
Ep 18 — csperf: Benchmarking with Different Data Sizes — Scale‑up experiments.
Ep 19 — csperf: Benchmarking with Different Thread Counts — Parallelism effects.
Ep 20 — csperf: Benchmarking with Different Memory Layouts — Cache‑friendly vs. cache‑unfriendly.
Ep 21 — csperf: Benchmarking with Different Input Distributions — Real‑world data.
Ep 22 — csperf: Benchmarking with Different Compiler Flags — Fine‑tune performance.

The misconception

Many developers look at a single timing and assume the compiler is the culprit. They ignore that the same binary can run on a 2 GHz Ivy Bridge or a 3.5 GHz Rocket Lake, and the difference is entirely silicon‑driven.

What problem csperf solves (this episode's slice)

csperf cpuinfo and csperf deviceinfo capture the exact CPU model, stepping, and micro‑architecture. By attaching that metadata to every run you can:

Verify that two runs used the same silicon.
Attribute performance differences to real compiler changes, not hardware.
Provide reproducible evidence that others can audit.

Mental model

Think of a performance run as a photograph. The picture (execution time) is useless without the camera settings (CPU model, stepping, cache size). csperf cpuinfo is the camera’s EXIF data.

Lab: install and first commands

# Install csperf if you haven’t already
pip install compilersutra-perf

# Quick sanity check
csperf doctor

# Capture the silicon details
csperf cpuinfo
csperf deviceinfo

The output will include fields like model_name, stepping, microarchitecture, and cache_size.

Lab: what we ran on this machine

We ran a small matrix multiplication benchmark (matrix_traversal.cpp) on a 2023‑mid‑year Intel i7‑12700K. The artifact shows:

CPU: Intel(R) Core(TM) i7‑12700K
Stepping: 10
Microarchitecture: Alder Lake
Cache size: 25 MiB L3

The csperf run command automatically attaches this data to the artifact.

Results (real numbers only)

Graph: trial wall_time_ms from this run's artifacts (not invented).

Artifacts missing for this episode — numbers withheld.

How to read the artifacts

Open the JSON artifact with csperf visualize or inspect the metadata section. Look for:

cpuinfo → model_name, stepping, microarchitecture
deviceinfo → cache_size, num_cores, architecture These fields are the keys that tie a timing to a specific silicon.

Common mistakes (teacher checklist)

Skipping cpuinfo – you’ll have no silicon record.
Running on different machines – compare artifacts, not raw times.
Ignoring stepping – two chips of the same model can differ by a few percent.
Assuming the same cache size – cache hierarchy changes across generations.

Try this next (homework)

Do this tonight — Episode 24 starts by assuming you did.

Closing

Knowing your silicon is the first step toward honest performance claims. Without it, you’re just guessing.

DEV Community