roofline model

The roofline model is a one-picture performance framework: it plots attainable compute throughput against arithmetic intensity, so you can see at a glance whether a kernel is limited by the chip's math units or by its memory bandwidth.

Two ceilings, one plot. The y-axis is performance (FLOP/s); the x-axis is arithmetic intensity (FLOPs done per byte moved from memory). A sloped line — the memory roof — rises at the machine's peak bandwidth, and a flat line — the compute roof — caps out at peak FLOP/s. Every kernel sits under whichever roof is lower at its intensity.

The ridge point splits the world. Where the two roofs meet is the ridge, at arithmetic intensity = peak FLOPs / peak bandwidth. Left of it a kernel is memory-bound: it starves the math units, and only faster memory (HBM) helps. Right of it a kernel is compute-bound: the pipes are full, and only more or faster FLOPs help. On an H100-class GPU the FP16 ridge sits near a few hundred FLOP per byte — which is exactly why so much LLM inference lands on the memory-bound side.

RegimeWhereLimited byLever that helpsExample
Memory-boundleft of ridgeHBM bandwidthfaster memory, more reuseattention, GEMV, decode
Balancedat the ridgebothmatched tilingtuned GEMM
Compute-boundright of ridgepeak FLOP/smore/faster tensor coreslarge GEMM, big-batch training
Roofline Model — Am I Compute-Bound or Memory-Bound? plot attainable FLOPS vs arithmetic intensity — one chart answers where your bottleneck is Arithmetic Intensity (FLOPs / Byte loaded) Attainable GFLOPS (log) 10 100 1K 10K 100K 1 10 100 1000 BW ceiling (3.35 TB/s) peak compute = 990 TFLOPS (BF16) ridge point AI = 295 ops/byte memory-bound region compute-bound region LLM decode (AI≈1) attention small GEMM large batch GEMM training matmul How to Read It below sloped line → memory-starved (increase AI or BW) below flat line → compute-limited (need more FLOPS) H100 Roofline Numbers peak BF16: 990 TFLOPS · HBM BW: 3.35 TB/s ridge point: 990T / 3.35T = 295 ops/byte The roofline tells you in one glance: is your kernel starved for data or starved for compute?

You move a kernel by changing its intensity. Tiling, kernel fusion, keeping data resident in registers or SRAM, and larger batch sizes all raise arithmetic intensity, sliding a kernel rightward toward the compute roof. This is why FlashAttention is such a large win: by fusing the attention kernel so it never re-reads the big score matrix from HBM, it raises intensity and lifts the kernel off the memory roof.

Read the roofline through a quant lens rather than a tuning-tips lens: it is the single diagram that ties together every other number on this site. HBM bandwidth sets the slope, the tensor core sets the ceiling, and arithmetic intensity — fixed by the algorithm and the memory hierarchy — decides which one you actually hit. Optimizing hardware or software without knowing which side of the ridge you are on is guessing.

Go deeper with CFSGPT

Get AI-powered deep-dives, save terms, and run advanced simulations — free account.

Create Free Account