Note: torch.compile / Graph Compilation, Why a JIT-Compiled Graph Beats Eager Mode

The problem, from first principles

PyTorch's default execution mode is "eager": each line of Python that calls a tensor operation runs, and finishes, immediately, before Python even reaches the next line — exactly 01-kernel-fusion's "unfused" case, since nothing has the chance to look ahead at what's coming next and fuse anything together. torch.compile changes this: it traces a whole chunk of computation into a graph first, then compiles that entire graph, giving its compiler (TorchInductor) the opportunity to fuse chains of operations it can see coming.

From theory to code

Implement eager_mode_traffic(n_elements, n_ops, bytes_per_element=4), compiled_graph_traffic(n_elements, n_ops, bytes_per_element=4), and compiled_speedup_estimate(...) — directly reusing 01-kernel-fusion's unfused_memory_traffic/fused_memory_traffic, since eager-vs-compiled execution is exactly unfused-vs-fused kernels applied to a whole model instead of just two ops.

Constraints

• eager_mode_traffic is 01-kernel-fusion's unfused_memory_traffic, called with the same arguments.
• compiled_graph_traffic is 01-kernel-fusion's fused_memory_traffic — note it does not actually use n_ops internally, even though it accepts the parameter (for a fair, same-signature comparison against eager_mode_traffic).
• compiled_speedup_estimate returns eager_mode_traffic / compiled_graph_traffic.

Hints

Open one at a time. Each gives away a little more than the last.