v1.0.0

A reading path for CPU performance engineering, from one instruction to production inference, in the order that makes the next piece legible.

304 entries across 16 sections and 60 subsections, from 288 distinct sources on 117 hosts. Primary sources only: original papers, vendor optimisation manuals and ISA references, creator repositories, kernel and compiler documentation. No blogspam, no listicles, no aggregators, no AI-generated posts. Every entry is one line saying why it earns a place, not what it is.

The evidence rule

Every performance claim carries seven fields:

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

A number missing any one of them is dropped, not softened. If the entry rests on that number it moves to the watchlist, or it goes.

This is deliberately stricter than most lists. A CPU figure quoted without its frequency, its core count or its compiler flags cannot be reproduced, and is therefore not evidence of anything.

misc/notes/changelog.md records the whole sift: 304 included, 541 rejected, 171 numbers examined, each with the rule it failed.

14 runnable benchmarks

One reproducible microbenchmark per major section, in misc/benchmarks/. Each ships bench.c, build.sh, run.sh, the machine it ran on, raw numbers and the analysis. QUICK=1 ./run.sh finishes inside ten seconds, so CI smoke tests every one of them on each push.

All fourteen ran on one machine: Apple M4 Pro, Apple clang 17.0.0, macOS 26.2, with the clock measured rather than assumed. Four of the results:

measurement	result
one dependent load, DRAM against L1	186x, with the L2 step at 8.9 and DRAM at 20.8 on top
8 threads incrementing adjacent atomics	157x slower per increment than 1 thread; padding to 128 B brings it to 1.16
one byte pread from the page cache	281 ns, about 1263 cycles
FMA loop under taskpolicy -c background	12x slower by wall time, on E-cores at 1.04 GHz

These are numbers this repository can defend, on one machine, with the method stated. They are not claims about your machine, which is the point.

What is deliberately absent

A dated watchlist of 14 items whose evidence is still moving. Each names the condition that would promote it: a specification or original paper, a shipped implementation, and a public measurement stating all seven fields. Anything failing the evidence rule lands here rather than in the list.

Checks

Two checkers run on every push, with no third-party dependency:

• check_format.py — entry grammar, reason length, numbering, watchlist promotion conditions, internal anchors, Contents completeness, duplicate URLs, empty subsections, placeholders.
• check_links.py — every URL, and again weekly on a cron. It separates dead from unreachable from blocked, because vendor document libraries and publishers refuse automated clients while serving the page perfectly well to a browser. A dead link fails the build and opens an issue.

Contributing

The bar is in CONTRIBUTING.md. Every entry has to survive one question: would someone working through the list top to bottom be worse off without it?

Full Changelog: https://github.com/usamahz/cpu-performance-engineering/commits/v1.0.0