What is arithmetic intensity (operational intensity)?

Arithmetic intensity, also called operational intensity, is a kernel's floating-point work divided by the bytes it moves to and from DRAM: I = W / Q, measured in FLOP/byte. It captures how much compute you do per byte fetched. High intensity means the kernel reuses data heavily; low intensity means it is dominated by memory traffic.

How do I know if my kernel is compute-bound or memory-bound?

Compare its arithmetic intensity I to the machine's ridge point I_ridge = π/β. If I is at or above the ridge, the flat compute roof binds and the kernel is compute-bound. If I is below the ridge, the sloped bandwidth roof binds and it is memory-bound. On the chart, kernels left of the ridge are memory-bound; those on or to the right are compute-bound.

What is the ridge point in the Roofline model?

The ridge point is the arithmetic intensity where a machine switches from memory-bound to compute-bound: I_ridge = π/β, where π is peak compute (FLOP/s) and β is peak bandwidth (bytes/s). An A100 at 312 TFLOP/s and 2039 GB/s has a ridge near 153 FLOP/byte — a kernel needs at least that much reuse to have any chance of saturating the tensor cores.

How do you calculate operational intensity of a GEMM?

For a dense matrix multiply C[M,N] = A[M,K]·B[K,N], the work is W = 2·M·N·K FLOPs and the DRAM traffic (one read of A and B, one write of C) is Q = (M·K + K·N + M·N)·bytes-per-element. Intensity is W/Q. Large square GEMMs have very high intensity, so they are almost always compute-bound.

What is the Roofline model used for?

It tells you which optimisation matters before you spend hours on a kernel. If you are memory-bound, chasing more FLOP/s is pointless — fuse kernels, increase reuse, or lower precision to cut bytes. If you are compute-bound, memory tuning will not help — raise occupancy and tensor-core utilisation. It turns 'what should I optimise' from a guess into a one-line answer.

Which bandwidth should I use — peak or achieved?

The presets use each GPU's peak DRAM bandwidth from its datasheet, because that is the theoretical roof. Real kernels reach 70–90% of peak. For a tighter upper bound, replace β with the bandwidth your profiler actually measures (for example from Nsight Compute), then re-read the ridge point and attainable performance.

Why does the compute roof change with precision?

A GPU's peak FLOP/s depends on the datatype and whether tensor cores are used. An A100 does 312 TFLOP/s in FP16/BF16 tensor, 156 in TF32, and only 19.5 in FP32 on the CUDA cores. Picking a precision sets the flat compute roof accordingly, which also moves the ridge point. The V100 has no TF32 path, so that option falls back to its FP16 tensor peak.

Does this model cache reuse or multiple ceilings?

No. This is the classic single-roof Roofline: one DRAM bandwidth roof and one compute roof for the chosen precision. It does not add L1/L2 cache-aware roofs, no-FMA or no-vectorisation ceilings, or CPU/TPU preset libraries. Custom mode lets you enter any machine's two numbers, so you can model non-NVIDIA hardware by hand.

GPU performance · Roofline

Roofline Model Calculator — Arithmetic Intensity & Ridge Point

Enter a GPU's peak compute and memory bandwidth (or pick a preset) plus your kernel's FLOPs and bytes moved. In one step it gives the arithmetic intensity, the ridge point, the attainable performance, and whether you are compute-bound or memory-bound — plotted on a log-log roofline chart.

By Induwara Ashinsana— Executive Director, Ryzera TechnologiesUpdated Jul 9, 2026

Roofline modelintensity · ridge · attainable

Williams et al. 2009

Hardware preset

312 TFLOP/s · 2,039 GB/s · 80 GB. Peaks seed the fields below and stay editable.

Precision (compute roof)

Half-precision tensor-core peak (dense).

Peak compute (π)

Machine's peak FLOP/s at the selected precision.

Peak memory bandwidth (β)

Machine's peak DRAM bandwidth.

Kernel work (W)

Total floating-point operations the kernel performs.

Data moved (Q)

Total bytes read from + written to DRAM.

Try a scenario

Arithmetic intensity

2,750FLOP/byte

I = work ÷ data moved

Ridge point

153.02FLOP/byte

I_ridge = π ÷ β

Attainable performance

312 TFLOP/s

P = min(π, β·I)

Fraction of peak

100%

P ÷ π (upper bound)

Compute-bound(I ≥ ridge)Raise tensor-core utilisation / occupancy — memory is not the limiter.

Roofline chart

Roofline & ridge pointYour kernel — compute-bound

Single DRAM-bandwidth roof and one compute roof per precision, exactly as in Williams, Waterman & Patterson (2009). GPU peak compute and bandwidth are from NVIDIA datasheets (dense, no sparsity); specs last verified 2026-07-09. Full sources are listed below the calculator.

How it works

The Roofline model, introduced by Williams, Waterman and Patterson in 2009, bounds a kernel's achievable performance with just two machine numbers and two kernel numbers. The machine is described by its peak compute π (FLOP/s) and its peak DRAM bandwidth β (bytes/s). The kernel is described by its work W (total FLOPs) and the data it moves Q (total bytes to and from DRAM).

Operational (arithmetic) intensity. I = W / Q, in FLOP/byte. It measures how much compute the kernel performs per byte it fetches.
Ridge point. I_ridge = π / β. This is the intensity at which the machine stops being limited by memory and starts being limited by compute.
Attainable performance. P = min(π, β·I). Left of the ridge the sloped bandwidth roof β·I binds; right of it the flat compute roof π binds.
Classification. If I < I_ridge the kernel is memory-bound; if I ≥ I_ridge it is compute-bound. The boundary itself counts as compute-bound, since that is where the flat roof takes over.
Percent of peak. P / π — the best fraction of peak FLOP/s the kernel can reach on this machine given only its intensity. It is an upper bound; real kernels sit at or below it because of occupancy, launch overhead, and imperfect overlap.

Everything is normalised internally to FLOP/s and bytes, then converted back for display, so you can mix units (TFLOP/s with GB/s, GFLOP with MB) without doing the conversions yourself. The same result is confirmed two independent ways: the single min(π, β·I) expression, and a piecewise branch that classifies the kernel first and then picks the roof — they agree to the FLOP because at the ridge β·I_ridge = π. The GPU presets carry each card's peak dense compute (per precision) and peak bandwidth straight from the NVIDIA datasheets cited below; they seed the fields but remain editable, so you can drop in your profiler's achieved bandwidth for a tighter bound.

Worked examples

Large FP16 GEMM on A100 → compute-bound

π = 312 TFLOP/s · β = 2039 GB/s · M=N=K=8192, fp16

Work: W = 2·M·N·K = 2·8192³ = 1.0995×10¹² FLOP (≈ 1.10 TFLOP)
Data: Q = (M·K + K·N + M·N)·2 = 3·8192²·2 = 4.0265×10⁸ B (≈ 0.40 GB)
Intensity: I = 1.0995×10¹² / 4.0265×10⁸ = 2730.7 FLOP/byte
Ridge: I_ridge = 312×10¹² / 2.039×10¹² = 153.0 FLOP/byte
I (2730.7) ≥ ridge (153.0) → compute-bound
Attainable: P = min(π, β·I) = π = 312 TFLOP/s = 100% of peak
Read: big GEMMs are compute-bound — optimise tensor-core utilisation, not memory traffic.

Element-wise SAXPY on RTX 4090 → memory-bound

π = 82.6 TFLOP/s (FP32) · β = 1008 GB/s · N = 1×10⁹ fp32

Work: W = 2·N = 2×10⁹ FLOP (one multiply + one add per element)
Data: Q = 3·N·4 = 1.2×10¹⁰ B (read x, read y, write y)
Intensity: I = 2×10⁹ / 1.2×10¹⁰ = 0.1667 FLOP/byte
Ridge: I_ridge = 82.6×10¹² / 1.008×10¹² = 81.9 FLOP/byte
I (0.1667) < ridge (81.9) → memory-bound
Attainable: P = β·I = 1.008×10¹² × 0.1667 = 0.168 TFLOP/s ≈ 0.2% of peak
Read: SAXPY is the textbook memory-bound kernel — fuse and cut data movement; the ALUs sit nearly idle.

Exactly at the ridge → boundary counts as compute-bound

π = 100 TFLOP/s · β = 1 TB/s → ridge = 100 FLOP/byte

Kernel with I set exactly at the ridge: W = 100, Q = 1 → I = 100 FLOP/byte
Ridge: I_ridge = 100×10¹² / 1×10¹² = 100 FLOP/byte
I (100) ≥ ridge (100) → compute-bound (the boundary belongs to the flat roof)
Attainable: P = min(100, 1×100) = 100 TFLOP/s = 100% of peak
Off-by-one guard: a kernel sitting precisely on the ridge is classed compute-bound, never memory-bound.

Frequently asked questions

Sources & references

The Roofline formulas are implemented exactly as published in Williams et al. (2009). The GPU preset specs (peak dense compute per precision and peak DRAM bandwidth) were last cross-checked against the NVIDIA datasheets on 2026-07-09.

Related tools

LiveAI

LLM VRAM Calculator

Estimate the GPU VRAM needed to run or fine-tune any open LLM (Llama 3, Mistral, Qwen, Gemma, DeepSeek) at a given precision, context, and batch size — and check whether it fits your GPU. Formulas cited, runs in your browser.

Open tool

LiveAI

LLM Training Time Calc

Estimate the wall-clock days, GPU-hours, and cloud cost to train a language model from its parameter count and token budget, using the standard 6ND compute law and a chosen GPU's throughput. Includes a GPT-3 cross-check and a same-run-on-other-GPUs comparison.

Open tool

LiveAI

AI Inference Speed Calculator

Estimate how fast an LLM will run on a given GPU — decode tokens/second, prefill throughput, time-to-first-token, and total generation time — from model size, quantization, and published memory bandwidth. Formulas and GPU specs cited.

Open tool

Rate this tool

Be the first to rate

Comments & feedback

Spotted a bug or want an improvement? Tell us — our team reviews every comment, and good ideas get built. Comments are public and anonymous.

Found a bug, edge case, or want another GPU preset added?

Email me at [email protected] — most fixes ship within 24 hours.