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…

这是什么东西?一份精心编排的 CPU 性能工程阅读路线:从一条指令在现代 CPU 核心上会经历什么讲起,一直讲到在 CPU 上部署机器学习推理,顺序经过安排,读完每一部分都能让下一部分更容易看懂。
这么说不是作者写的书——我看到的到底是什么?是一份精选清单,不是教程:作者挑选并排好了现有的第一手资料(论文、厂商手册、规格文档、亲历者的报告),每一条都配了一句话说明为什么选它,还加了各节的基准测试。
我该怎么学这份内容?先把第 1 节(Start here)从头到尾读一遍——它是贯穿整个清单的路线;之后各编号章节就可以当参考手册,按主题随用随查。
开始之前需要准备什么,要花钱吗?清单本身免费(MIT 许可),但前十个阅读材料里有两本是付费书;作者还建议搭配 Performance Ninja 的练习一起做,因为光靠读书练不出手感。
这里找不到哪些内容?编程语言运行时、数据库内部实现,以及超出单颗处理器范围的内容都明确不在讨论范围内——重点放在 x86 和 Arm 服务器 CPU 上。
它只讲 Intel,还是 AMD 和 Arm 也覆盖?三家都有:Intel Xeon、AMD EPYC 和 Arm Neoverse 服务器芯片各有专门一节,另外还有一节讲如何独立做跨厂商的测量。当厂商给出的延迟估计和实测数据表不一致时,这份清单站在实测数据一边。
内容有多新?这个仓库创建于 2026 年 9 月,还设了一个 Watchlist(观察名单)小节,收录那些暂时没有公开实测数据的 ISA 扩展和服务器芯片,一旦有了证据,这些条目就能升级进正式章节。
一个 typical 条目长什么样?一份第一手资料加上选它的理由——比如《What Every Programmer Should Know About Memory》之所以入选,是因为它可以用来测量每一级缓存边界处的开销,仓库里还附带一个基准测试,能精确复现那条曲线。
Creator
usamahz
Size
1.9 MB
Stars
1.2K
Age
1mo
Commits · 90 Days