CPU Performance Engineering Reading List: 16 Sections in Order [2026]

By Indie Kings | October 2, 2026

Updated October 2, 2026: This reading list holds 304 curated entries plus 14 runnable C benchmarks with source and build lines and raw numbers and analysis all committed. It orders CPU performance work from one instruction to model serving so you can study in sequence instead of sampling at random.

Image: Reading list banner. Credit: usamahz via GitHub.

What this reading list covers

The list is a curated ordered reading path with 304 entries plus 14 runnable C benchmarks, per the usamahz/cpu-performance-engineering GitHub README. The benchmarks ship with source and build line and machine description and raw numbers and analysis all committed. That combination matters because prose alone lets weak claims survive, while committed code plus committed numbers force each lesson to reproduce or fail in public.

Scope is tight by choice. The coverage spans x86 and Arm server parts from one instruction to CPU model serving, per the usamahz/cpu-performance-engineering GitHub README. It is not language runtimes or database internals. That boundary keeps the page focused on hardware behavior and systems code rather than on garbage collector tuning or query planner lore [NEEDS VERIFICATION].

Project context is small and permissive. The repository is MIT licensed with 396 stars and 41 forks at time of review, per the usamahz/cpu-performance-engineering GitHub README. MIT licensing means teams can reuse checklists and benchmark scaffolds inside commercial engine work with little friction, subject to license text compliance [NEEDS VERIFICATION]. Star and fork counts signal interest, not correctness, so treat them as discovery signal and verify each technical claim against the cited primary source.

Section 1 is the ordered path and sections 2 to 16 are reference, per the usamahz/cpu-performance-engineering GitHub README. That split answers the first navigation question for every reader. New readers start at section 1 and move top to bottom, while returning readers jump into sections 2 to 16 for a specific bottleneck. The arc named in the task brief runs through pipeline stages and microarchitecture and memory hierarchy and measurement method and counters and profilers and lying microbenchmarks and roofline and top down and scaling and queueing models and single thread SIMD and branchless tricks and compilers and codegen and concurrency and NUMA and OS and IO and tail latency and CPU inference including when CPU beats GPU and hardware generations covering Intel Xeon plus AMD EPYC plus Arm Neoverse and benchmark suites and a watchlist of unshipped and unmeasured parts, per the usamahz/cpu-performance-engineering GitHub README.

Evidence discipline is the through line. The rule is primary sources only such as paper and spec and vendor manual and repo and worker report, and every number carries seven fields or is not quoted, per the usamahz/cpu-performance-engineering GitHub README. That discipline is rare in performance blogging, where unattributed bar charts travel far without machine or build flags. Here the demand is explicit that a number without provenance is not a number you should cite.

For Indie Kings readers, the practical payoff is frame time literacy. Game engine and emulator developers chasing CPU bound frame time get our framing in later sections, not a repo promise. The repo supplies the physics of pipelines and caches and queues, while we map those ideas to main thread budgets and draw call submission and physics steps and JIT recompilers [NEEDS VERIFICATION]. Keep that separation clear as you read, because the repo does not claim to tune your engine, it teaches you how to measure your engine without lying to yourself.

How to use it in 5 steps

Do not read 304 entries at random. The value is order plus reproduction plus one model applied to your own bottleneck. Follow these five steps in sequence and finish with a contribution if you find a gap.

1. Step 1: Read section 1 top to bottom. Section 1 is the ordered path and it sets vocabulary for everything after, per the usamahz/cpu-performance-engineering GitHub README. Resist the urge to jump straight to SIMD or tail latency, because pipeline plus memory hierarchy plus measurement chapters give you the mental model that makes later chapters stick. Take notes on terms you cannot yet define from memory, such as front end bound versus back end bound and bandwidth versus latency limits, then reread those pages before moving on [NEEDS VERIFICATION]. Budget several short sessions rather than one long skim, because ordered technical material compounds only when earlier ideas are still fresh.
2. Step 2: Reproduce a benchmark locally. The set includes 14 runnable C benchmarks with source and build line and machine and raw numbers and analysis all committed, per the usamahz/cpu-performance-engineering GitHub README. Pick one benchmark close to your bottleneck, such as a memory bound loop or a branch heavy loop, then build it with the stated flags on your own machine and record your own numbers [NEEDS VERIFICATION]. Compare your result to the committed raw numbers and analysis, and treat divergence as a lesson about compiler version and CPU generation and power limits rather than as proof the repo is wrong. This local run teaches more than ten chapters of passive reading because it forces you to confront frequency scaling and background noise and build flag effects.
3. Step 3: Apply one model to your bottleneck. Choose one model from roofline or top down or scaling or queueing treatments and apply it to your current CPU bound frame time problem, per the usamahz/cpu-performance-engineering GitHub README structure. For example, run top down analysis on your main thread hotspot to learn whether you are front end bound or back end bound or retiring limited, then let that classification pick the next experiment [NEEDS VERIFICATION]. Or sketch a roofline plot for your physics loop to see whether memory bandwidth or peak compute caps your throughput before you rewrite vector code. One model applied with real counters beats five models skimmed, because the discipline of classifying a bottleneck stops random optimization.
4. Step 4: Check the watchlist before buying hardware conclusions. The closing watchlist tracks unshipped and unmeasured parts, per the usamahz/cpu-performance-engineering GitHub README. Before you conclude that a new Intel Xeon or AMD EPYC or Arm Neoverse part settles a purchase or an upgrade plan, read that watchlist to learn what has not yet been measured under the repo evidence rules [NEEDS VERIFICATION]. Hardware conclusions without watchlist context age badly, because early vendor slides and leaked scores rarely carry the seven fields this repo demands. Use the watchlist as a hold on strong claims until independent numbers with full provenance appear.
5. Step 5: Contribute back per repo conventions. The repo is a living curated list, and contributions that follow repo conventions keep it accurate for the next reader [NEEDS VERIFICATION]. If you reproduce a benchmark on a new CPU generation or find a stronger primary source for a weak entry, open a change that cites paper or spec or vendor manual or repo or worker report with full context. Include source and build line and machine and raw numbers and analysis in the same style as the existing 14 runnable C benchmarks, per the usamahz/cpu-performance-engineering GitHub README. Small precise pull requests beat broad opinion issues, because evidence heavy repos merge diffs faster than debates.

Section map from pipeline to serving

The table below maps the 16 section arc to the question each block answers. Section level facts reflect the usamahz/cpu-performance-engineering GitHub README, while the study tips around the table are our framing for engine developers and carry [NEEDS VERIFICATION] where they go beyond the README.

Start with pipeline and microarchitecture if frame spikes confuse you. That block teaches front end versus back end limits and helps you read top down counter output without guessing [NEEDS VERIFICATION]. Engine main threads often stall on instruction cache misses or branch mispredicts during scene graph traversal, and only pipeline literacy turns a profiler flat profile into a fixable cause.

Treat memory hierarchy as the second pillar. Caches reward linear access and punish pointer chasing, while prefetch and DRAM bandwidth shape streaming systems such as animation sampling and asset decompression [NEEDS VERIFICATION]. Emulator authors feel this acutely when guest memory access patterns defeat host cache locality, so study cache line size and associativity before rewriting a recompiler.

Measurement deserves a full pass before optimization. Counters and profilers look authoritative until frequency scaling or throttling or background work skews the run, and lying microbenchmarks teach how dead code elimination and constant folding can make nonsense look fast [NEEDS VERIFICATION]. Learn to pin frequency where possible, warm up state, repeat runs, report variance, and inspect disassembly so the compiler did not delete the work you meant to time.

Models turn data into decisions. Roofline separates memory bound from compute bound kernels, top down classifies pipeline slots into retiring versus bad speculation versus front end bound versus back end bound, scaling models predict thread count returns, and queueing models explain tail growth under load [NEEDS VERIFICATION]. Pick the simplest model that rules out a class of fixes, then drill deeper only when the simple model points that way.

Single thread craft plus compiler awareness close the loop. SIMD plus branchless idioms cut per element cost in tight loops, but only after the compiler output confirms the transform actually happened [NEEDS VERIFICATION]. Check codegen for auto vectorization and inlining and loop unrolling, because source level cleverness that the compiler undoes is just readability cost with no frame time gain.

Concurrency plus NUMA plus OS plus IO plus tail latency cover the system around the core. Thread pools need work partitioning that respects cache and NUMA locality, the OS adds scheduling and syscall and interrupt effects, IO paths add queue depth behavior, and tail latency work shows why average frame time hides the stutter players feel [NEEDS VERIFICATION]. Study these blocks with a console frame graph open, because p95 and p99 spikes map directly to queueing and scheduling lessons.

CPU inference plus hardware generations plus suites plus watchlist keep conclusions portable. CPU inference material covers when CPU beats GPU on small batches or latency sensitive serving, hardware generation notes compare Intel Xeon plus AMD EPYC plus Arm Neoverse server behavior, suites give cross machine comparison method, and the watchlist marks unshipped and unmeasured parts as out of scope for strong claims, all per the usamahz/cpu-performance-engineering GitHub README. Read that final stretch before recommending hardware, because generational cache and interconnect changes can invert last year tuning advice.

Evidence rules that keep numbers honest

The repo evidence bar is stricter than typical performance writing. Every fact in this section is per the usamahz/cpu-performance-engineering GitHub README unless marked [NEEDS VERIFICATION]. The table makes the rules actionable for readers who want to cite numbers without spreading noise.

Primary sources only sounds strict until you see the failure mode it prevents. Secondary summaries often drop compiler flags or microcode versions or power limits that change results by double digit percents [NEEDS VERIFICATION]. Going back to the paper or spec or vendor manual or worker report restores those details and lets you judge whether a result transfers to your machine.

Seven fields or no quote is the most portable habit on this page. The README demands seven fields for every quoted number, per the usamahz/cpu-performance-engineering GitHub README. In practice that means never quoting a bare percent or frames per second score without machine and build and run context attached [NEEDS VERIFICATION]. If a source omits that context, summarize the idea without repeating the number, so your article does not launder a weak measurement into a fact.

Committed runnable proof raises the bar further. The 14 runnable C benchmarks include source and build line and machine and raw numbers and analysis all committed, per the usamahz/cpu-performance-engineering GitHub README. That pattern gives readers a template for their own reports. Copy that shape when you post engine numbers, because a reader with source plus flags plus machine can falsify your claim, which is exactly what makes it trustworthy.

Ordered path first plus scope guard keep study time efficient. Section 1 as ordered path prevents topic hopping, sections 2 to 16 as reference support lookup, and the x86 and Arm server scope from one instruction to CPU model serving keeps out language runtime and database internals debates, per the usamahz/cpu-performance-engineering GitHub README. When a forum thread pulls you toward runtime internals, note the boundary and return to CPU behavior first [NEEDS VERIFICATION]. Most frame time wins live inside that boundary.

Game engine and emulator framing

This framing is ours, not the repo claim. The repo teaches CPU performance engineering in general, per the usamahz/cpu-performance-engineering GitHub README, while the mapping below translates those lessons to CPU bound frame time for game engine and emulator developers [NEEDS VERIFICATION]. Keep that attribution split explicit when you share notes with a team.

Main thread budgets map to pipeline and top down thinking. A 60 fps target leaves about 16.6 ms per frame and a 120 fps target leaves about 8.3 ms, so every millisecond of front end or back end stall is visible [NEEDS VERIFICATION]. Use top down counters on your hottest update function to learn whether scene traversal is fetch bound or branch bound, then fix the classified cause instead of micro tuning random loops. That single classification step often saves a week of speculative rewrites.

Draw submission maps to queueing and concurrency lessons. Command list building across threads looks scalable until synchronization and allocator contention serialize the work [NEEDS VERIFICATION]. Study scaling models before adding threads, because Amdahl style limits plus lock overhead can flatten gains after two or four submission threads on some scenes. Measure per thread active time plus wait time rather than total CPU percent, since high CPU percent with high wait time is congestion, not progress.

Physics and animation sampling map to SIMD and memory hierarchy lessons. Linear arrays of transforms vectorize cleanly, while linked structures with scattered access waste both vector units and cache lines [NEEDS VERIFICATION]. Convert hot structures to flat arrays where ownership allows, then verify auto vectorization in disassembly and measure with counters rather than assuming wider vectors always win. Memory bound loops often gain more from layout changes than from instruction level tricks.

Emulator CPU cores map to branchless plus codegen plus tail latency lessons. Interpreters with large switch statements stress branch prediction, while recompilers stress code cache locality and host codegen quality [NEEDS VERIFICATION]. Branchless dispatch tables and careful block linking can smooth the common path, but only profiler plus counter data shows whether the bottleneck is prediction or instruction cache or data cache. Tail latency matters because one slow translated block per frame can ruin p99 even when average emulation speed looks fine.

Asset streaming and IO map to OS and IO plus NUMA lessons. Decompression threads placed on the wrong NUMA node can pay extra latency on every buffer touch, while synchronous file IO on a gameplay thread injects stalls that no SIMD rewrite can hide [NEEDS VERIFICATION]. Move blocking IO off gameplay threads, batch submissions, respect NUMA locality on multi socket servers used for build farms or dedicated servers, and track p95 load hitches separately from steady state frame cost.

When CPU beats GPU thinking enters engine planning, keep it narrow. The repo CPU inference material covers when CPU beats GPU for model serving, per the usamahz/cpu-performance-engineering GitHub README. For games, the analog is small batch work such as UI layout or pathfinding or audio mixing where GPU launch overhead exceeds compute savings [NEEDS VERIFICATION]. That is our analogy, not a repo claim about game rendering, so validate it per title with measurements rather than citing the inference chapter as proof.

Hardware generations to track

Hardware generation notes cover Intel Xeon plus AMD EPYC plus Arm Neoverse server parts, per the usamahz/cpu-performance-engineering GitHub README. Generational detail matters because cache sizes and core interconnects and memory controllers change the answer to what is fast, even when source code stays identical [NEEDS VERIFICATION]. A loop tuned for one Xeon generation can behave differently on a newer EPYC or Neoverse part for reasons that have nothing to do with code quality.

Track Xeon generations for front end and memory controller evolution. Vendor manuals document decode width and micro op cache behavior and supported memory speeds that shape throughput ceilings [NEEDS VERIFICATION]. When comparing Xeon results across years, normalize for frequency and core count and memory configuration before praising an architecture, because platform differences often exceed core differences in server benchmarks.

Track EPYC generations for chiplet and interconnect and cache scaling. Core complex layouts and Infinity Fabric behavior and stacked cache options change latency and bandwidth tradeoffs in ways that reward locality aware threading [NEEDS VERIFICATION]. Server game backends and build systems that scale across many cores should test thread placement explicitly rather than assuming linear scaling from a desktop Ryzen result.

Track Arm Neoverse generations for efficiency and predictable throughput. Neoverse cores power a growing share of cloud instances where dedicated game servers and CI runners now live, so x86 only tuning can miss the platform players actually rent [NEEDS VERIFICATION]. Validate alignment and prefetch assumptions on Arm hardware directly, because x86 lessons transfer in principle but not always in magnitude.

Use benchmark suites for cross generation comparison rather than single microbenchmarks. Suites give broader coverage across compute and memory patterns, per the usamahz/cpu-performance-engineering GitHub README structure. Run the same suite version with the same flags on each machine, record full provenance for every score, and be explicit when a suite stresses a path your game never exercises [NEEDS VERIFICATION]. That caution keeps suite wins from becoming false engine promises.

Watchlist before you conclude

The watchlist tracks unshipped and unmeasured parts, per the usamahz/cpu-performance-engineering GitHub README. Its job is to stop readers from turning rumors or vendor previews into purchase advice before independent numbers exist [NEEDS VERIFICATION]. Check it before you publish a conclusion that names a winner.

Treat unshipped parts as planning context, not as benchmarks. Pre launch disclosures often show favorable configurations without full power or memory or compiler disclosure, which fails the seven fields test by construction [NEEDS VERIFICATION]. Note the claimed direction, list what remains unknown, and wait for committed source plus build line plus machine plus raw numbers plus analysis before updating guidance.

Treat unmeasured parts as homework, not as losses. A part with no repo grade measurement is simply outside current evidence, not proven slow [NEEDS VERIFICATION]. If you own that hardware, the most useful contribution is a clean reproduction with full provenance, following the 14 runnable C benchmark pattern with source and build line and machine and raw numbers and analysis all committed, per the usamahz/cpu-performance-engineering GitHub README. That single report can move a part from watchlist to measured.

For engine teams, the watchlist has a budget implication. Delaying a server upgrade or a minimum spec change until measured data lands is often cheaper than reversing the call after launch [NEEDS VERIFICATION]. Keep current generation tuning in the main branch, gate next generation paths behind measured flags, and revisit the watchlist each quarter rather than reacting to each headline.

FAQ

What is this CPU performance reading list?
It is a curated ordered reading path with 304 entries plus 14 runnable C benchmarks, per the usamahz/cpu-performance-engineering GitHub README, covering x86 and Arm server parts from one instruction to CPU model serving.

How should I read sections 1 to 16?
Read section 1 top to bottom as the ordered path, then use sections 2 to 16 as reference for your bottleneck, per the usamahz/cpu-performance-engineering GitHub README.

What evidence rule applies to numbers?
Use primary sources only and quote a number only when it carries seven fields, per the usamahz/cpu-performance-engineering GitHub README, otherwise summarize the idea without the digits.

Is this list about game engines?
No, the game engine and emulator framing here is ours, not the repo claim, while the repo scope is CPU performance from one instruction to model serving, per the usamahz/cpu-performance-engineering GitHub README [NEEDS VERIFICATION].

When does CPU beat GPU according to the list?
The CPU inference block covers when CPU beats GPU on serving cost or latency or batch shape, per the usamahz/cpu-performance-engineering GitHub README, and engine analogies beyond that need local measurement [NEEDS VERIFICATION].

What should I check before buying hardware?
Check the watchlist of unshipped and unmeasured parts before drawing hardware conclusions, per the usamahz/cpu-performance-engineering GitHub README, and wait for numbers with full provenance [NEEDS VERIFICATION].

Bottom Line

Order plus evidence is the whole method. Read section 1 top to bottom, reproduce one of the 14 runnable C benchmarks locally, apply roofline or top down or scaling or queueing thinking to your bottleneck, check the watchlist before hardware claims, and contribute back with primary sources and full provenance. That loop turns 304 entries from a bookmark pile into frame time skill.

Keep scope and attribution clean as you share results. Scope stays on x86 and Arm server parts from one instruction to CPU model serving, not language runtimes or database internals, and verified facts stay attributed to the usamahz/cpu-performance-engineering GitHub README while game engine mappings stay labeled as our framing. Numbers without seven fields stay out of quotes, unmeasured parts stay on the watchlist, and every claim a teammate might act on ships with source and build line and machine and raw numbers and analysis.

Sources

All verified facts above are per the usamahz/cpu-performance-engineering GitHub README unless marked [NEEDS VERIFICATION]. License and scale facts reflect MIT plus 396 stars plus 41 forks at time of review.

• usamahz/cpu-performance-engineering GitHub README