Logical vs Physical Resource Costs

A resource estimate written in logical qubits and logical gates describes an idealised, noiseless machine. Real hardware is noisy, so each logical qubit must be encoded across many physical qubits using a quantum error-correcting code, and each logical operation becomes a much longer sequence of physical operations. Converting logical costs to physical costs is the step that turns an abstract estimate into a hardware requirement — and the conversion factors are brutal.

The surface code and code distance

The leading candidate for near-term fault tolerance is the surface code: physical qubits laid out on a 2D grid, with stabiliser measurements detecting errors. Its key parameter is the code distance $d$, the length of the smallest error chain that goes undetected. A distance-$d$ surface code corrects any pattern of fewer than $d/2$ errors, and its logical error rate per round falls roughly exponentially in $d$:

where $p$ is the physical error rate and $p_{\text{th}}$ is the code's threshold (around $1\%$ for the surface code). As long as $p < p_{\text{th}}$, increasing $d$ buys exponentially better protection — at a polynomial cost in qubits.

The qubit blow-up: $2d^2$

A planar surface-code patch encoding one logical qubit at distance $d$ uses about $d^2$ data qubits plus a comparable number of measurement (ancilla) qubits, for a common rule-of-thumb of

This is the heart of the logical→physical conversion. At a modest $d = 15$ that is already $450$ physical qubits for a single logical qubit. An algorithm needing tens of logical qubits crosses into the tens of thousands of physical qubits, and a cryptographically-relevant Shor run lands in the millions — which is exactly why "how many physical qubits?" is the headline number in every serious estimate.

Time cost: surface-code cycles

Width is only half the story. Each round of stabiliser measurement is one surface-code cycle, and a logical operation typically takes about $d$ cycles. So a circuit with $G$ logical gates and distance $d$ takes on the order of $G \cdot d$ cycles; at a cycle time of $\sim 1\,\mu\text{s}$, multiplying out the cycles is how estimates arrive at wall-clock runtimes of hours or days for large algorithms. The deeper the algorithm and the larger the distance, the longer it runs — the same coupling that drives width also drives time.

The two-number takeaway

A physical-cost estimate reduces to two coupled numbers:

1. Physical qubits $\approx (\text{logical qubits}) \times 2d^2$, plus a sizeable overhead for magic-state distillation factories that manufacture the $T$ states counted last lesson.
2. Physical runtime $\approx (\text{logical depth}) \times d \times (\text{cycle time})$.

Both grow with $d$, and $d$ is set by how much error correction the algorithm's length demands. This is why reducing $T$-count and logical depth at the software layer pays off twice over: it shrinks both the factory overhead and the distance you need.

Try it

Convert a logical estimate to physical qubits: an algorithm needs 50 logical qubits at code distance $d = 15$, with $2d^2$ physical qubits per logical qubit. Return the total physical qubit count as an integer. The grader checks the value and that it is a whole number.

Sign in on the full site to ask questions and join the discussion.