01 · The only chart that matters
Two numbers decide your kernel's best possible speed
Every kernel has an arithmetic intensity: the FLOPs it performs divided by the bytes it moves to and from DRAM. And every GPU has two ceilings: memory bandwidth and compute throughput. The roofline model just puts them together — a kernel can never exceed bandwidth × intensity, never exceed peak FLOPS, so its ceiling is the minimum of the two.
On the 4070: ~29.1 TFLOPS against ~504 GB/s. Draw both limits as lines and they cross where intensity = 29,100 / 504 ≈ 58 FLOPs per byte — the ridge point. Left of it, you're memory-bound and more compute is irrelevant. Right of it, you're compute-bound and more bandwidth is irrelevant. The chart isn't a metaphor; it's the machine's contract, and day 18's profiler reports both axes directly.
INTENSITY
0.25 FL/B
CEILING
126 GFLOPS
OF PEAK
0.43%
REGIME
MEMORY-BOUND
2 FLOPs per 8 bytes — two loads and a store per multiply (day 12's patient).
simplified: the roofline counts DRAM traffic only — L2 hits, instruction mix, and power throttling all bend the real line. It's a ceiling estimate, not a stopwatch.
02 · Reading the placements
Look how far left everything honest lives
Click through the presets and notice the pattern: nearly everything sits left of the ridge, in amber. Vector add at 0.17 FLOP/byte has a ceiling of ~86 GFLOPS — 0.3% of the chip's headline number, forever, no matter how elegantly it's written. That's not a failure of the kernel; it's the nature of the work. It's also why day 07's coalescing discussion was the entire optimization story for such kernels.
Now watch what tiling buys. Moving matmul from naive (0.25) to a 16×16 shared-memory tile (4) multiplies the ceiling by 16 without changing a single FLOP — the same math, reorganized so each byte is used 16 times before it leaves the chip (day 15 does exactly this). Bigger tiles keep climbing until day 09's register budget pushes back. The cuBLAS-class preset is the first to cross the ridge into compute-bound territory — which is why exotic GEMM engineering exists at all.
03 · Using it in practice
Estimate, then compare, then act
The workflow is three moves. Estimate intensity: count FLOPs, count bytes to DRAM, divide — back-of-envelope is fine, you're usually off by 2× at most. Compute the ceiling and place the kernel on the chart. Compare against achieved performance from the profiler. Two outcomes:
ACHIEVED ≪ CEILING
the kernel is leaving performance on the table — fix it. Day 18 tells you which knob.
ACHIEVED ≈ CEILING
the kernel is as good as its data flow allows — the fix is algorithmic: better tiles, fusion, or a new formulation.
This little protocol is the difference between optimizing what's convenient and optimizing what matters. It ends arguments before they start, and it's the first thing experienced kernel engineers do when handed a slow kernel.
- 01Ceiling = min(bandwidth × intensity, peak FLOPS). Arithmetic intensity — FLOPs per byte of DRAM traffic — picks which of the two ceilings applies to you.
- 02The 4070's ridge point is ~58 FLOP/byte. Left of it: memory-bound, bandwidth improvements pay. Right: compute-bound, only more efficient math pays.
- 03Reorganizing data flow moves you rightward without changing the math. Tiling, fusion, and register blocking raise reuse per byte. Day 15 turns naive matmul's 0.25 into 4 with one idea.
- 04Compare achieved vs ceiling before touching code. Far below ceiling: fix the kernel. At ceiling: change the algorithm. This is day 18's profiling loop in miniature.
Next: day 12 — a case study. We take the textbook matmul everyone writes first, walk it through everything from days 7–11, and watch it earn less than half a percent of the chip.