Part 6 · Speaking performance
The lexicon
A small vocabulary full of ordinary English words with narrow technical meanings — several of which mean roughly the opposite of what they sound like.
What this lesson is trying to break (2)
- The terms mean what the English words mean.
- Sounding knowledgeable means using more jargon.
Part 6 is the third of this course’s concerns: not what the machine does, but how people talk about it. For a tech lead this is where the value gets realised — an accurate model you cannot express is worth very little in a design review.
The trap words
This vocabulary is unusually treacherous because it reuses ordinary words for narrow meanings, and a few are actively misleading.
Varies: the gap between the everyday word and the technical term
| Word | Everyday sense | What it means here |
|---|---|---|
| retire | stop working | The final in-order commit. An instruction can execute and never retire. |
| word | a unit of language | 16 bits on x86 — not the machine width. dword is 32, qword 64. |
| pressure | stress | Contention for a resource: register pressure, port pressure. |
| port | a socket, or a network port | A path to a functional unit inside the core. |
| stall | delay tactics | A cycle in which the pipeline made no progress. |
| issue / dispatch | send out | Specific pipeline stages, in a specific order. |
| speculation | guesswork, financial risk | Executing past an unresolved branch, discarding if wrong. |
| frame | a border | One function call’s region of stack. |
| fusion | merging generally | The decoder combining two instructions into one µop. |
Retire and word are the two that actively mislead. 'It executed but never retired' sounds contradictory and is a precise, ordinary statement.
The Glossary has around seventy terms, each with a definition and a sentence showing it in real use. The usage sentences are the part that matters — you are trying to be able to produce these, not just recognise them.
Things not to say
More useful than a jargon list. These are the overclaims that cause an experienced listener to discount everything else you say.
“Fewer instructions, so it’s faster.” The single most common error, and this whole course argues against it. Dependency chains (4.1) and memory (4.4) dominate. Say instead: “It’s fewer instructions — I haven’t checked whether it’s actually faster.”
“Assembly is what the CPU runs.” µops are (4.5). Say instead: “Assembly is the interface; it decodes to micro-ops.”
“CISC is slower than RISC.” Not for about twenty-five years. x86 decodes to RISC-like µops internally. Say instead: “The cores are more alike than different now. The real differences are decode cost, the memory model, and vector width.”
“Branches are expensive.” A predicted branch is nearly free (4.3). Say instead: “Unpredictable branches are expensive. That one is predictable.”
“The compiler will optimise that.” Sometimes, and the failures are specific and nameable (5.2). Say instead: “It should inline; it won’t vectorise, because it’s a float reduction.”
“This is O(n), so it’s fine.” Complexity ignores constants, and a factor of 50 for cache behaviour is a constant. Say instead: “Same complexity, but the array version has much better locality.”
Being able to correct these gently is worth more than avoiding them, and it is the register a lead needs: precise without being pedantic.
Phrases that carry a lot
Compressions that save a paragraph when used correctly.
- “That’s a dependency chain.” — the operations serialise; instruction count is irrelevant.
- “It’s memory-bound, not compute-bound.” — stop optimising arithmetic.
- “There’s port pressure on the load units.” — a specific resource limit, not general slowness.
- “That branch is unpredictable.” — justifies branchless or a data change.
- “It didn’t vectorise because it’s a float reduction.” — names the exact blocker.
- “Low IPC, so we’re stalling.” — a measurement, not a guess.
- “That’s false sharing.” — the parallel-slower-than-serial diagnosis.
- “Have you profiled it?” — the question that ends most speculative arguments, and it is not rude if you ask it of your own claims first.
Register: how to make a claim credibly
The norm in this field is unusually empirical, and matching it is easy because it is formulaic.
State what you measured. “On my M1, with a 10 MB working set, it was 2.3× faster.” Hardware, data size, and factor. All three, because all three change the answer.
Say when you have not measured. “From the listing I’d expect this to help, but I haven’t measured it” is a stronger position than implying you have. People who work on performance are used to being wrong and respect the distinction.
Give the variance. A single run is a rumour. “2.3× ± 0.1 over 20 runs” is a result.
Name the constraint, not the symptom. “It’s slow” invites argument. “It’s memory-bound at 0.4 IPC” invites agreement or a specific counter.
Reproduce before generalising. Cache effects vary wildly across machines, and your laptop is not the server.
Rewrite each of these to be accurate and appropriately hedged:
- “I rewrote it branchless so it’s faster now.”
- “The ARM build is more efficient — fewer instructions.”
- “It’s the same algorithm so performance should be identical.”
For number 3, name the specific thing that could differ by 50× while the algorithm stays the same.
What you should now be able to say
- The trap words: retire, word, pressure, port, stall, speculation.
- The overclaims and their accurate replacements.
- Compressed phrases that each name a specific constraint.
- The empirical register: hardware, data size, factor, variance — and saying plainly when you have not measured.
Next: 6.2 — Reading a profiler.