cpu-performance-engineering README

The project's README from github.com/usamahz/cpu-performance-engineering. As one markdown file: README.md.

CPU Performance Engineering

Links Quality Entries Benchmarks License Stars

Making a program fast on a modern CPU means knowing what the core does with each instruction, where the time actually goes, and how to prove a change helped. This is the reading that gets you there, in the order that makes the next piece legible.

Scope. x86 and Arm server parts, from one instruction through to serving a model on CPU. Not language runtimes, database internals, or anything above the socket.

Evidence. Primary sources only: the paper, the specification, the vendor manual, the repository, or a report by the person who did the work. Any number, anywhere in this repository, carries all seven fields set out in What earns a place, or it is not quoted.

Proof. Fourteen of the sections end in a benchmark under misc/benchmarks/: C source, the build line, the machine, the raw numbers and the analysis, all committed. Run them yourself.

Section 1 is a path through the rest; read it top to bottom before using the numbered sections as a reference.

Contents

1. Start here

Each entry assumes only the ones before it. The first and sixth are paid books; the third is a manual to open at the chapters its reason names.

  1. Computer Architecture: A Quantitative Approach, 7th Edition - Its pipelining appendix and memory chapters define the hazard, speculation and cache vocabulary the list assumes.
  2. Optimizing software in C++ - Maps C++ onto pipeline mechanisms and shows why a loop-carried dependency chain, not instruction count, paces a loop.
  3. Intel Optimization Reference Manual - Its opening chapters show how a shipping x86 core implements the textbook pipeline, each rule tied to a mechanism.
  4. What Every Programmer Should Know About Memory - Measures the step in cost per access at each cache boundary and the gap a prefetcher hides.
  5. Memory Barriers: a Hardware View for Software Hackers - Explains why a second core makes loads and stores reorder and what a barrier drains.
  6. Systems Performance: Enterprise and the Cloud, 2nd Edition - Puts the method before the tools: what to measure, in what order, and how benchmarks mislead.
  7. Roofline: An Insightful Visual Performance Model for Multicore Architectures - Places a loop from a byte count and a datasheet bandwidth alone, before any counter is read.
  8. A Top-Down Method for Performance Analysis and Counters Architecture - Defines the split of pipeline slots into front end, bad speculation, back end and retiring, the tree profilers report.
  9. Performance Analysis and Tuning on Modern CPUs - Walks from a noisy timing to counters to a named bottleneck, applying roofline and top-down to whole programs.
  10. What Has My Compiler Done for Me Lately? Unbolting the Compiler's Lid - Shows how to read emitted assembly against its source, so each mechanism is checked in a listing, not assumed.

Work the exercises in Performance Ninja alongside them; reading alone will not build the instinct.

Reproduce it: misc/benchmarks/04-cache-latency, the cost per dependent load stepping up at each cache boundary, the curve the fourth entry measures.

2. One instruction, end to end

Vendors name the same structures differently (Intel's decoded ICache is AMD's op cache, and AMD's macro-op is Arm's MOP), so the stage names below are generic.

Fetch and decode

Reproduce it: misc/benchmarks/02-branch-misprediction, the cost of a mispredicted branch, sorted against unsorted against branchless.

Rename and issue

Execute

Memory access and retire

3. Microarchitecture

Where a design paper, the vendor manual and a measurement disagree about a core, the measurement is the one to trust and re-run.

Limits of ILP and SMT

Branch prediction and speculation

Vendor estimates and measured tables

What the manuals leave out

Reproduce it: misc/benchmarks/03-latency-vs-throughput, one dependency chain against eight independent accumulators.

4. Memory hierarchy

Line size and page size are machine parameters, not constants, so every padding and alignment rule below is applied against the target's own values.

Cache geometry, replacement and misses in flight

Reproduce it: misc/benchmarks/04-cache-latency, dependent-load latency from L1 to DRAM, with and without TLB pressure.

TLBs, page walks and prefetchers

Store buffers, ordering and cache-line contention

Struct layout, software prefetch and page size

5. Measurement

Cloud instances often virtualise the hardware counters away and macOS runs no Linux perf, so perf stat has to show a non-zero cycles count before any counter entry below is trusted.

Method and the whole-system view

Counters, events and precise sampling

CPU profilers and flame graphs

Microbenchmarks that lie

Reproduce it: misc/benchmarks/05-measurement-pitfalls, dead-code elimination, run-to-run spread, cold against warm.

6. Models

A roofline is a bound built from measured roofs and counted bytes, so a point above a roof means a wrong roof or a wrong byte count, not fast code.

Roofline and the execution-cache-memory model

Reproduce it: misc/benchmarks/06-roofline, measured roofs and three kernels of rising arithmetic intensity.

Top-down analysis

Scaling laws

Queueing

7. Single-thread optimisation

A loop the compiler reports as vectorised can still run at scalar speed: a float reduction stays one serial chain until reassociation is permitted.

Data layout and loop transforms

Reproduce it: misc/benchmarks/07-aos-vs-soa-simd, array of structs against structure of arrays, scalar against NEON.

SIMD instruction sets

SIMD libraries and measured kernels

Branchless code and bit manipulation

8. Compilers and codegen

No -O level changes the target instruction set: without -march or -mcpu, every instruction emitted belongs to the default target ISA, so target flags come before any judgement of codegen.

Reading emitted code

Target flags and auto-vectorisation

Reproduce it: misc/benchmarks/08-autovectorization-aliasing, the vectoriser with and without restrict.

Profile-guided and post-link optimisation

9. Concurrency

Every cost below is a cache line moving between cores, so the ordering models and the measured line-transfer cost in the memory hierarchy section come first.

Memory models and atomics

Locks, contention and allocators

Reproduce it: misc/benchmarks/09-false-sharing, adjacent counters against padded counters across threads.

Lock-free structures and RCU

Thread pools and work stealing

10. NUMA and multi-socket

A page's node is decided at first touch, not when memory is allocated or a policy is set, and every vendor table below depends on the BIOS node mode of the machine it ran on.

NUMA and Linux memory placement

Reproduce it: misc/benchmarks/10-first-touch, first touch of fresh pages against the second pass.

Topology and interconnects

Migration, balancing and measured effects

11. OS and I/O

A syscall's cost depends on the mitigation state, the governor and the idle state the core was in, three sysfs settings that change after boot, so each is recorded beside any number below.

Syscalls and asynchronous I/O

Reproduce it: misc/benchmarks/11-syscall-cost, the fixed cost of a kernel crossing across request sizes.

Scheduling, affinity and isolation

Interrupts and kernel bypass

Cache and bandwidth partitioning

12. Tail latency and production systems

A latency figure means nothing without its percentile, its load model and the way it was recorded.

Measuring the tail

Reproduce it: misc/benchmarks/12-coordinated-omission, closed-loop against open-loop p99 under the same stalls.

Where jitter comes from

Load generation and production workloads

Mechanical sympathy

13. Inference on CPU

A decode step at batch one reads every weight once for a few flops, so it runs at the memory system's rate, and a CPU figure compares with a GPU figure only at the same batch and precision.

GEMM and BLAS

Reproduce it: misc/benchmarks/13-sgemm-naive-vs-blas, naive GEMM, a hand microkernel and the vendor BLAS, plus int8 against float32 dot products.

Runtimes

Quantization

Matrix extensions

Threading for inference

When CPU beats GPU

14. Hardware generations

The measurement articles below state no compiler, flags or run count, so each is kept for the structure it exposes and no figure from it is repeated.

Intel Xeon

AMD EPYC

Arm Neoverse server parts

Independent measurement across vendors

Reproduce it: misc/benchmarks/14-pcore-vs-ecore, the same three kernels on a performance core and an efficiency core.

15. Benchmarks

A score means what its suite's run rules say it means, so the rules come before the number.

Standard suites

Microbenchmark suites

Reproduce it: misc/benchmarks/15-stream-bandwidth, triad bandwidth by thread count against the vendor figure.

Methodology and what suites miss

16. Watchlist

Everything below is real but unproven: no item yet has all three of a written specification, a part you can buy, and a public measurement stating every one of the seven fields. Each line says what would promote it. Vendor multiples never qualify. Last checked 2026-09-15.

ISA extensions without a shipped server part

Parts without a public measurement

Memory and interconnect

Kernel paths and generated code

What earns a place

Seven fields, and a number without all of them does not appear here:

1 CPU model and microarchitecture
2 core count used
3 frequency, with turbo and SMT state
4 compiler and flags
5 workload
6 baseline
7 measurement method

Miss one and the number is dropped; if the entry rests on that number, it moves to the watchlist or goes.

An entry itself has to be the thing, not writing about the thing: the paper that first described a mechanism, the specification or manual that defines it, the repository the implementation lives in, or a report from whoever did the work with code and reproducible measurements. Summaries, tutorials, surveys, marketing pages, mirrors and repackagings do not qualify. Every URL points at the live canonical copy, and misc/scripts/check_links.py and misc/scripts/check_format.py prove it on every push and again weekly.

CONTRIBUTING.md has the rules in full.

License

MIT. Maintained by @usamahz.

Format inspired by the GPU-side list at wafer-ai/gpu-perf-engineering-resources.

cpu-performance-engineering (usamahz/cpu-performance-engineering)

Searching Database…

What is this?A curated reading path for CPU performance engineering: it walks you from what one instruction does on a modern core to serving ML inference on CPUs, ordered so each piece makes the next one legible.
So it's not a book the author wrote — what exactly am I looking at?A curated list, not a tutorial: the author selected and ordered existing primary sources (papers, vendor manuals, specs, first-hand reports), each with a one-line reason, and added section benchmarks.
How do I work through it?Read Section 1 (Start here) top to bottom first — it is a path through the rest of the list; after that, the numbered sections work as a reference you dip into by topic.
What do I need before starting, and does any of it cost money?The list itself is free (MIT), but two of the first ten readings are paid books; the author also suggests the Performance Ninja exercises alongside, since reading alone will not build the instinct.
What won't I find here?Language runtimes, database internals and anything above the socket are explicitly out of scope — the focus is x86 and Arm server CPUs.
Does it cover only Intel, or AMD and Arm too?All three: Intel Xeon, AMD EPYC and Arm Neoverse server parts each get a section, plus one on independent cross-vendor measurement. Where a vendor's latency estimates disagree with a measured table, the list sides with the measurement.
How current is the material?The repository was created in September 2026 and keeps a Watchlist section for ISA extensions and server parts that still lack public measurements, so pieces can graduate into the main sections as evidence appears.
What does a typical entry look like?A primary source plus its reason — for example 'What Every Programmer Should Know About Memory' is kept for measuring the cost step at each cache boundary, and the repo ships a benchmark that reproduces exactly that curve.
Creator
usamahz
Size
1.9 MB
Stars
1.2K
Age
29d
Commits · 90 Days