CPU and Memory: Map, Numbers, Estimates
Which boxes one memory access passes through, how big and how fast each box is, and how to combine those numbers to estimate the memory time of a piece of code.
Things to look up at any time: the hardware map, the architecture map, the numbers for each part, how to estimate, how to use perf, and cards for common performance bottlenecks. Unlike posts, these pages keep growing with the series.
Which boxes one memory access passes through, how big and how fast each box is, and how to combine those numbers to estimate the memory time of a piece of code.
Which threads and data structures a market data message passes through on its way from the NIC to an order and back as a fill; roughly how long each stage takes; and how industrial systems split threads, where they put queues, and where they must join.
perf answers two questions: which function and which instruction the time goes to, and whether the CPU is computing or waiting. Four commands, one job each: perf stat for the totals, record plus report for the hot function, annotate for the hot instruction, c2c for threads fighting over a cache line. Before starting, check permissions, the symbol table and the sampling event. IPC, cache-miss rate, branch-miss rate and hot-spot share each come with a reading line (from Intel's open-source intel-performance-skills). Then one real run on a virtual machine with no hardware counters: perf points at a single-accumulator sum, the samples land on the instruction after the add, and four accumulators make it 3.3 times faster.
One card per common performance bottleneck: what perf shows, why it is slow, how to fix it, how to confirm the fix, and a link to the post that explains the mechanism. The last two parts cover the traps to avoid from the start in new code, and letting a program pick its instruction set on each CPU.