Fusion preserves effects and numeric contracts
Remove intermediate traffic only when consumers, side effects, and floating-point semantics remain valid.
On this page
The question for today
What you’ll understand
- Separate mathematical composition from legal executable fusion.
- Estimate an intermediate's traffic under explicit materialization assumptions.
- Explain recomputation, resource, and floating-point tradeoffs.
Fusion puts related computations into one execution region so values can sometimes remain local rather than travel through an intermediate buffer. That can save traffic and launches, but it is not automatically a free algebraic rewrite. Effects, multiple consumers, synchronization, layouts, and numerical rounding still constrain the result. Ask which materialization disappears, which operations move or duplicate, and what semantic permissions make those changes legal.
A producer-consumer edge is only the starting point
For pure elementwise functions, composing g(f(x)) can let each produced element feed its consumer immediately. A producer with several consumers may instead be recomputed after fusion or require retained shared storage. If an operation reads mutable state, advances a random generator, performs I/O, or has ordering effects, duplicating or moving it can change behavior. Compiler effect interfaces and operation contracts supply information for legality; a graph edge alone is not sufficient proof.
Materialization can also provide a synchronization or layout boundary. A later operation may need results from many producer iterations, not just one corresponding element. Moving that consumer inside a producer loop can read incomplete data unless the schedule and synchronization are transformed correctly. Conversely, a legal fused region can still use temporary storage internally. A dump containing one fusion operation does not guarantee zero buffers or one specific hardware implementation; inspect the selected lowering and target behavior.
Real-number equalities do not choose floating-point flags
Reassociating a reduction or contracting multiply-plus-add into a fused operation can change rounding. NaNs, infinities, signed zero, exception behavior, and precision conversions add further constraints. LLVM 20.1.0 spells out fast-math flags rather than declaring all floating operations algebraic real numbers. A pipeline must preserve the source contract or carry explicit permissions for the particular transformation. A tolerance accepted by a model benchmark is not itself permission to silently change unrelated users' numerical semantics.
Fusion that preserves the original operation sequence and required rounding can be legal even when reassociation is not. Distinguish avoiding a memory write from removing a semantic conversion or rounding point. A producer returning a narrower dtype may require that narrowing before its consumer, even if the fused hardware prefers a wider register. Correctness tests should include cancellation and boundary values, while legality follows the documented source and IR contracts rather than only observed error on a convenient input.
Saved bytes compete with recomputation and occupancy
Count the actual intermediate reads and writes removed at a named memory boundary. A value already retained in cache may contribute less main-memory traffic than its logical buffer size suggests. Fusion can increase register pressure, spill, reduce occupancy, or duplicate expensive producer work for multiple consumers. It can also prevent a tuned library call. Compare end-to-end latency and resource use after checking every consumer's values; smaller IR and fewer launches are intermediate observations, not the final outcome.
The Roofline lab supplies a synthetic traffic-bound exercise. Reset and set both I=4 FLOP/byte, B=80 GB/s, predict 320 GFLOP/s. Reset and re-set I=8, B=80, predicting 640 GFLOP/s under its fixed 1000 GFLOP/s compute ceiling; Play traces the roof without changing kernel parameters. The doubled intensity could represent halved boundary traffic only if counted work stays fixed. The instrument does not fuse operations, model spills, or prove the measured speedup of any compiler transformation.
Work it through
Cancellation exposes a changed reduction order
Use IEEE binary64 round-to-nearest ties-to-even with a=10¹⁶, b=−10¹⁶, c=1. Compare(a+b)+c with a+(b+c), requiring each addition to round and permitting no reassociation.
In the first order, a+b cancels exactly to zero and adding c produces 1. The specified intermediate rounding preserves that result.
In the second order, b+c rounds back to−10¹⁶ at this magnitude under ties-to-even. Adding a then produces zero.
Results 1 and 0 differ, so an exact-real associativity argument cannot justify the rewrite under this contract. Fusion may still preserve the first order; changing it needs explicit semantic permission rather than a performance rationale alone.
Fusion and reassociation are different decisions. Preserve required rounding even when an intermediate buffer disappears.
The living notebook
Explore the model
Interactive lab · roofline
A hypothetical traffic saving raises a ceiling
Reset, set I=4, B=80;predict 320 GFLOP/s. Reset and re-set I=8, B=80;predict 640 under fixed 1000 GFLOP/s compute roof. Playback traces a synthetic bound, not fusion, register use, or measured throughput.
- Attainable ceiling
- 640 GFLOP/s
- Ridge intensity
- 12.5 FLOP/byte
- Ceiling regime
- Memory-bound ceiling
Synthetic roofline ceiling min(1000, B·I), in GFLOP/s, with B in decimal GB/s and I in FLOP/byte. Playback traces the roof without changing the selected kernel. This upper-bound model is not a measured throughput prediction, hardware comparison or price model. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA traffic saving can change a resource ceiling only under matching work and boundary assumptions.
Pause & reason
Check your understanding
Your turn
Try it yourself
Two pointwise stages over one million four-byte elements each read one full input and write one full output. Assume an intermediate is written and reread at the selected boundary. Compare traffic with a fused implementation reading only the original input and writing the final output.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Count buffer-sized transfers, keeping the intermediate's write and later read separate.
Compare with the solution
Unfused traffic is four million element transfers, or 16,000,000 bytes: input read, intermediate write, intermediate read, final write. Fused traffic is 8,000,000 bytes under the assumptions, saving 8,000,000 bytes. That is a traffic model, not a guaranteed twofold speedup; spills, reuse, duplicated work, and changed resource occupancy can alter actual boundary traffic and time.
Keep the idea
Take it with you
- Fusion must preserve effects, dependencies, and all consumers.
- Strict IEEE behavior differs from exact-real algebra and explicit fast-math contracts.
- Traffic savings need resource and end-to-end performance verification.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.