Hardware Reasoning Signals
Green flags show someone with a working model of the machine. Red flags show a fact remembered without the mechanism behind it.
Green flags
Separates the ISA from the microarchitecture without being asked.
Almost every "x86 versus ARM" performance argument is really about two specific implementations. Someone who keeps the contract and its implementation distinct is reasoning about the right thing.
Reasons about where the data is before reasoning about the arithmetic.
In most real loops the computation is a rounding error next to the memory access. Starting from the data is what distinguishes a useful answer from a plausible one.
Knows the CPU is a throughput machine, not a line-by-line interpreter.
Out-of-order execution, speculation and superscalar issue mean source order is a constraint on results, not a description of execution. Without this, most performance intuitions are wrong.
Thinks in cache lines rather than variables.
The line is the unit of transfer, so it explains prefetching, padding, false sharing and why struct layout matters at all — four separate phenomena from one idea.
Reaches for locality before reaching for a faster algorithm.
A cache-friendly O(n log n) routinely beats a cache-hostile O(n). Complexity bounds the work; locality bounds how fast the work goes.
Asks how big the working set is, not just how big the data is.
It explains cliff-edged behaviour — the same code, one element more input, several times slower — which nothing in the source can account for.
Distinguishes latency from bandwidth.
They are separate resources with separate fixes: overlapping independent misses helps one and does nothing for the other.
Connects thread interference to cache coherence.
False sharing is invisible in the source — the variables genuinely are independent. Only the line-level view explains it.
Knows the hardware memory model is not the language memory model.
It is the difference between code that is correct and code that happens to work on x86. This is the single most common source of "works on my machine" concurrency bugs.
Knows what atomics guarantee and what they do not.
One atomic operation is indivisible; two in sequence are not. Someone who states the boundary has actually thought about it.
Reaches for counters rather than intuition.
IPC, miss rates and misprediction rates turn "it feels slow" into a diagnosis. Intuition about hardware is unreliable even for experts.
Distrusts a microbenchmark by default.
Dead-code elimination, warm caches, frequency scaling and timer overhead all flatter a benchmark. Knowing the failure modes is what makes the number worth anything.
States what a hardware claim is specific to.
Cache sizes, policies, latencies and ordering rules vary by vendor, generation and platform. An unqualified number is folklore.
Counts the transfer when evaluating an accelerator.
A kernel ten times faster loses if you pay two round trips over the interconnect to use it. The kernel is not the program.
Red flags
'Higher GHz means faster.'
Work per second is instructions × IPC × frequency, and all three vary — before memory behaviour, which frequently dominates all of them.
'The CPU executes my source line by line.'
The compiler reordered it, then the CPU renamed, reordered and speculated. What is preserved is the observable result, not the sequence.
'Cache is just faster RAM.'
It is a different structure with lines, sets, associativity and replacement — which is why two programs touching the same amount of data can differ tenfold.
'Both are O(n), so they perform about the same.'
Complexity counts operations and says nothing about what each costs. An array scan and a pointer chase differ by an order of magnitude at identical complexity.
'RAM access time is constant.'
It depends on which cache level answers, whether the DRAM row is open, whether the memory is local to the socket, and whether the TLB hit.
'More cores means proportionally more throughput.'
Shared bandwidth, shared last-level cache, coherence traffic and any serial section all bound it, usually well before the core count.
'Hyper-threading doubles the cores.'
Logical CPUs share one core's execution resources. It helps when threads stall and can hurt when they compete for cache.
'Using atomics makes the code thread-safe.'
An atomic makes one operation indivisible. A read-modify-write across two atomics is still a race, and ordering still needs stating.
'Virtual memory is purely an OS concept.'
The MMU translates and the TLB caches on every single access. The OS owns the mappings; the hardware does the work and enforces the protection.
'The GPU is faster, so use the GPU.'
Only for wide regular work, and only once the transfer is paid for. Small or branchy work is routinely slower than on a CPU.
'Branchless code is faster.'
It is faster when the branch is unpredictable and cheap to replace. On predictable data it loses, and the compiler has often already made the choice.
'The microbenchmark proves it.'
It proves something about the benchmark. Warm caches, eliminated dead code and turbo frequencies routinely produce wins that vanish in the real program.