Arithmetic Intensity
Definition
Arithmetic intensity is the number of FLOPs performed per byte of HBM traffic — a property of the algorithm and its data movement, independent of hardware. It is the x-axis of the roofline and the central lever deciding whether a kernel is memory-bound (low , ALUs starve) or compute-bound (high , ALUs saturate).
Key math
“Bytes” means traffic across the bottleneck, not footprint. A value re-read from HBM 10× costs 10× the bytes; an intermediate that never leaves on-chip memory (fusion) costs zero HBM bytes. FMA counts as 2 FLOPs.
Square GEMM (, precision bytes):
Grows linearly with — big GEMMs are compute-bound, small ones aren’t. That single fact drives huge amounts of LLM systems design.
Elementwise op (read + write, ~fixed FLOPs/element): e.g. GELU reads/writes FP16 elements ( bytes) doing ~ FLOPs → , independent of . The signature of every elementwise op: constant, tiny always memory-bound.
| Op | Intensity | Regime |
|---|---|---|
| Large GEMM (proj, MLP) | compute-bound | |
| Decode GEMV () | memory-bound | |
| Softmax / LayerNorm | memory-bound | |
| Elementwise (GELU, add) | – | memory-bound |
Why it matters
Classify against the ridge point (~296 FLOP/byte on H100 BF16): memory-bound. The pattern in a transformer — GEMMs are compute-bound; everything gluing them together is memory-bound — is why fusion is the highest-leverage kernel optimization. You raise by reuse (tiling, fusion, larger batch/tile), not by faster math. As the memory wall pushes right, raising matters more each generation.
Taught in
- 03-performance-modeling-roofline — §3 counting FLOPs/bytes, arithmetic intensity.
- 02-gpu-memory-hierarchy — §7 the memory wall.
See also
- roofline-model — where is the x-axis
- memory-wall — ridge point marching right
- gemm —
- gpu-memory-hierarchy — the bytes being counted
- mfu — the run-level utilization number
- gpu-systems-for-llms