Roofline Model
Definition
The roofline model (Williams, Waterman & Patterson, 2009) is a back-of-envelope upper bound on kernel performance derived from two hardware numbers (peak FLOP/s, peak bandwidth) and one kernel number (arithmetic intensity). It plots attainable FLOP/s vs intensity on log-log axes and tells you — before profiling — whether a kernel is memory-bound or compute-bound, hence which knob to turn.
Key math
- Memory-bound (left): , rises with slope . More FLOP/s capability is useless; raise (fusion, reuse) or move fewer bytes (lower precision).
- Compute-bound (right): , flat ceiling. Use faster math units (Tensor Cores, lower precision).
The lines cross at the ridge point:
memory-bound; compute-bound.
H100 SXM5 ridge points ( TB/s):
Peak vs achievable. Vendors quote the most flattering peak (with 2:4 sparsity, lowest precision). Build your roofline from dense peaks in the precision you actually use; a great GEMM reaches ~80–90% of dense peak, most kernels far less. Lower precision raises (memory wall), pushing more ops memory-bound.
Why it matters
“Is this kernel memory- or compute-bound?” organizes nearly every LLM optimization decision — fusion, precision, tiling, recompute vs store. Nsight Compute plots the measured dot against both roofs: on the memory roof → bandwidth-bound; on the flat roof → compute-bound; below both → occupancy/latency/overhead problem. Horace He’s framing (compute vs bandwidth vs overhead) is the canonical mental model, and the roofline is its formalization.
Taught in
- 03-performance-modeling-roofline — §4 the roofline model, ridge point, classification.
See also
- arithmetic-intensity — the x-axis
- memory-wall — ridge point over generations
- tensor-core — the compute roof
- gpu-memory-hierarchy — the memory roof ()
- mfu — utilization at the run level
- gemm — the canonical compute-bound kernel
- gpu-systems-for-llms