Appendix H — Choosing the Machine

Appendix H · Choosing the Machine¶

An appendix in this book is a reference, not a chapter. This one is read once, before you spend any money, and then only to settle an argument with a spec sheet.

Part V is the only part that needs hardware of its own: it is where every number in the book is measured, and ch01 is where you make it work. This appendix covers the decision before that: what the host target has to be able to do, how to check a machine you already own, and what changes if yours differs from the reference. The argument for a second machine at all is in the preface; this is the shopping and the checking.

A Raspberry Pi 5 with 4 GB or more, and an active cooler. That is the whole decision. Every Pi 5 has the counters this book needs — same SoC, same four cores, no variant where they are missing — so there is no specification to compare and nothing to get wrong except the RAM, and only because ch28 wants four cores with room to work.

You also need a development machine for Parts I to IV — anything that runs Homebrew or apt and holds an SSH key. It never measures anything.

The cooler earns its line in the table. A Pi 5 that throttles is running a benchmark at one clock speed and finishing it at another, which is not a slow measurement but a wrong one, and one of the more instructive ways to be wrong. ch24 treats throttling as a measurement hazard and shows how to catch it happening; a cooler means you meet it deliberately rather than in every run you ever take.

Why a separate board, and not the laptop you are reading this on¶

A laptop can almost certainly count and sample — perf on x86-64 is mature, and on Linux you could start Part V this afternoon. Do not, because a laptop is too complicated to learn on. A current laptop has cores of two different kinds, a clock that moves constantly, two threads sharing one core’s execution units, and a scheduler migrating your benchmark across all of it. Each of those makes a measurement harder to attribute. The Pi 5 is four identical cores with one cache hierarchy and no hyper-threading: when a number moves, something you did moved it.

That is the book’s own argument applied to its own tooling — use the instrument that can answer the question. A laptop is a faster machine and a worse instrument. If a Pi is genuinely not possible, Part V still runs on a Linux laptop, and every chapter whose reading depends on the core’s shape says so in its own header.

The Pi is not the most legible instrument. An in-order core — short pipeline, no out-of-order execution, no register renaming — makes microarchitecture plainer still: a dependent load that misses in cache stalls, visibly, for as long as the miss takes. The A76 reorders, so the connection between an instruction you wrote and a cycle that got spent runs through enough machinery that a small experiment occasionally comes out backwards.

Two reasons that is the right trade anyway. The in-order RISC-V option could not sample, which cost more than legibility bought. And every machine you are likely to care about optimising reorders, so learning to attribute cycles on one is the skill that transfers. ch27 is harder for it, says so in its own header, and is more useful as a result. If you want the clean version too, an in-order Cortex-A53 — a Pi 3 or Pi Zero 2 W — costs very little, and running ch24’s experiments on both is an instructive afternoon.

It is an ARM machine, and everything before Part V is RISC-V¶

That is deliberate. The kernel small enough to read in an afternoon is a RISC-V kernel; the hardware whose counters actually work is an ARM one. Those are different machines, and pretending otherwise would mean lying about one of them.

Part V needs perf to do two separate things: count events over a run, and sample — interrupt the program thousands of times a second to ask where it is. Sampling needs the counters to raise an interrupt when they overflow. On ARM that is a standard part of the performance monitoring unit. On RISC-V it is an optional extension, and a 2025 study of the three RISC-V cores you can actually buy Dissecting RISC-V Performance: Practical PMU Profiling and Hardware-Agnostic Roofline Analysis on Emerging Platforms (2025) found that none of them wins:

Read down the columns. Choosing RISC-V for Part V would have made two of its eight chapters unmeasurable — one needs sampling, one needs a vector unit — on boards that are hard to buy, with firmware that has broken perf between distribution releases. A Raspberry Pi costs none of that.

The preface says what that costs a reader. Everything outside the disassembly is method, and method does not have an architecture.

Its SoC is a BCM2712: four Arm Cortex-A76 cores at 2.4 GHz, 64 kB of L1 instruction and data cache each, 512 kB of L2 per core, and 2 MB of L3 shared between them Raspberry Pi Ltd (n.d.). Those are the vendor’s numbers, and the book does not repeat them anywhere else — ch25 measures that hierarchy rather than quoting it, and comparing what it finds against this paragraph is one of the more satisfying results in Part V.

Three levels with a private L2 and a shared L3 is a genuinely good shape to learn on. The private level shows you locality; the shared one is where ch28’s cores collide.

If you already own something else¶

The book recommends one machine because one machine is enough, not because the rest of Part V is about Raspberry Pis. What a machine actually has to do is short:

An old laptop, a spare desktop, a Rock 5B, another single-board computer you have in a drawer: run scripts/verify-setup.py on it and it will tell you. hardware/README.md has the same list in a form you can hand to a search tool, for readers somewhere Raspberry Pis are hard to get.

The requirement to be suspicious about¶

The counters. Everything else is printed on the box; whether perf can read the hardware is not, and it is the one that stops the book dead.

On ARM the PMU is reached directly, but the kernel still has to be told it is there, and this is not hypothetical: the Raspberry Pi kernel’s own 6.12 branch shipped a device tree for the Pi 5 with the arm-pmu node missing raspberrypi/linux issue 6507 (2025). The 6.6 tree had it. On the affected images the hardware was perfectly capable, the armv8_cortex_a76 driver never registered, and perf saw no hardware counters at all — quietly, because that is how this fails.

On RISC-V there is an extra layer: the counters are machine-mode CSRs, the kernel runs in supervisor mode, and the firmware bridges them through the SBI PMU extension RISC-V International (n.d.), so the answer depends on the firmware as much as on the silicon.

Read that regression as the general case rather than a Raspberry Pi anecdote. Whether your counters work is a property of the configuration, not of the board — silicon, device tree, kernel, firmware and perf build all have to agree, and four of those five change under you without the box changing at all.

The reference machine, and why your numbers will differ¶

Every figure in Part V of this repository was measured on the machine that its result names — each one stamps the model, the core and the kernel that produced it, so no figure is ambiguous about where it came from.

So your numbers will not match, and that is expected rather than a problem. The book is about ratios, mechanisms and method, and those transfer.

Which chapters actually depend on the hardware¶

Most do not. Five chapters of Part V do, and rather than let you discover that two hundred pages in, here they are up front. Each of these says the same thing in its own header, so you cannot open one without being told.

A chapter’s mechanism survives a change of hardware; its numbers do not, which is the same split the two targets follow. That is why the book insists on stamping every figure with the machine that produced it, and why ch25 is written as an instruction rather than a table — a cache hierarchy you measured is worth more than one you read.

If none of your numbers resemble the committed ones and you want to know whether that is your board or your method: it is almost always your board, and ch24 is where you learn to tell the difference.

hardware/README.md has the requirements, the prompt and the verification step in one place, for when you are standing in front of a shop rather than reading a chapter.

The reference machine’s own account of itself¶

Every figure in Part V was measured on one board, and what that board says about itself is printed in ch01 rather than here — it is the measurement that chapter takes, and a statement about one piece of silicon rather than about a product line. Read it beside the requirements above if you are comparing a machine you already own.

Where to go next¶

hardware/README.md in the repository carries the same requirements as a checklist, plus the evidence for choosing an ARM board over a RISC-V one: a 2025 study of the three RISC-V cores that can actually be bought Dissecting RISC-V Performance: Practical PMU Profiling and Hardware-Agnostic Roofline Analysis on Emerging Platforms (2025), and the counter-overflow extension a sampling profiler needs RISC-V International (n.d.). Appendix C is what this board turned out to expose once it reported.