A quantum circuit drawn on a screen can connect any two abstract qubits with a line. A processor cannot necessarily do the same. Real devices support particular operations on particular physical qubits, often only between certain neighboring pairs. Before an algorithm runs, software has to rewrite its neat diagram into instructions the chosen machine can execute.
That rewrite is usually called compilation or transpilation. It may add operations, move the circuit onto a different set of qubits, and change its timing. The result can determine whether an experiment is feasible on noisy hardware, even though the processor’s advertised qubit count has not changed.
One circuit, two kinds of qubits
The qubits in an abstract circuit are virtual placeholders for its work. Today’s hardware exposes physical qubits with locations, connections and device-specific behavior. A compiler first chooses which physical qubit will represent each circuit qubit. In Qiskit this is the layout stage, described in IBM Quantum’s current transpilation guide.
Imagine a circuit whose first and last qubits must interact. If the corresponding physical qubits are far apart on a chip that permits only neighboring two-qubit gates, that requested interaction cannot be issued as drawn. Choosing a better initial placement might bring them together. Otherwise the compiler must route quantum information through allowed connections, commonly by adding SWAP operations or an equivalent rewriting.
This is one reason a larger processor does not automatically give every circuit a better home. Its useful connections and the quality of the available physical qubits matter too. Our earlier article on quantum benchmarks beyond qubit count discusses the broader comparison problem.
The chip’s connection map sets the route
A coupling map is a graph of physical qubits and permitted two-qubit interactions. IBM’s hardware-representation guide shows how a poor layout can require extra SWAPs while a layout that matches the circuit’s structure can avoid them in the illustrated example. Those extra gates are not merely a cosmetic difference on noisy hardware: they add opportunities for error and can lengthen the circuit.
Connectivity is not identical across platforms. Google’s Cirq hardware documentation describes a grid on which two-qubit operations are restricted to adjacent sites. That does not mean every quantum processor has the same grid, or that every possible interaction is available at equal quality. A compilation claim is meaningful only in the context of a particular target device and its supported operations.
Routing itself is an optimization problem. The compiler can search for a path with fewer additional operations, but it may also have to consider which physical links are less noisy. Two compilations of the same abstract circuit can therefore produce different physical circuits without changing the intended computation.
Abstract gates must become native instructions
A circuit library may let a developer express a convenient gate that the processor does not implement directly. Translation decomposes it into the device’s supported basis gates. IBM’s documentation gives examples of a target instruction set that includes specific single-qubit operations, an entangling gate, measurements and resets. The compiler must also respect the target’s connectivity and any supported control-flow rules.
Google’s Cirq documentation likewise notes that unsupported gates need an equivalent decomposition into the device’s available set. A circuit that looks shorter before translation can grow after it is expressed in hardware instructions. Counting high-level gates without showing the compiled result can therefore hide a substantial part of the workload.
Some operations are effectively bookkeeping rather than a physical pulse on particular machines. Google’s documentation describes virtual Z rotations that are tracked in the compiler and generally add no direct gate duration. That detail is device-specific; it is a reminder that two circuits with the same number of symbolic gates need not take the same time.
Scheduling matters after mapping
Once operations are legal, they still need an execution order. Independent gates may run at the same time; gates on the same qubit cannot be scheduled as though they were independent. Idle intervals can matter because a qubit does not wait perfectly while other work proceeds. Qiskit’s staged transpiler includes an optional hardware-aware scheduling stage for making circuit timing explicit.
Optimization can cancel redundant operations, select a different decomposition or search for a better placement. But a higher optimization setting is not a free upgrade. IBM notes that stronger preset optimization generally takes longer to compile, and its SABRE tutorial shows that a specialized rewrite can beat a general-purpose routing heuristic for a circuit with known structure.
Compiler performance therefore has at least two costs: the classical time spent finding a physical circuit and the quantum resources used when that circuit runs. A heavily optimized circuit may be worth the compilation time if reused many times; a one-off experiment may present a different tradeoff. That is an inference from the workflow, not a benchmark result from our own testing.
How to compare compiled circuits honestly
Useful comparisons start with the same algorithmic task and name the target processor. They report physical qubits used, two-qubit gate count, circuit depth, and ideally timing or an error-aware performance measure. They also state whether a result came from real hardware, a noiseless simulator or a simulator using a hardware noise model.
There is no single magic number. Fewer gates may reduce one source of error but place work on a worse physical link. Lower depth may help one processor while increasing another operation that matters more. Device calibration and supported gate sets can change the best route. Google’s device guide explicitly cautions that gate behavior varies by qubit and can drift over time.
For a larger algorithm, the compiled circuit is just one piece of a full quantum resource budget. An attractive diagram that leaves out routing and native-gate translation is not yet a hardware execution plan.
Limits of compilation and what to watch next
A compiler cannot manufacture a missing reliable interaction or turn a noisy device into an error-corrected one. It can choose among available implementations and sometimes make much better use of them. Even then, observed output still needs careful interpretation; error mitigation is a separate layer with different limits.
Watch for clearer reporting of the circuit after compilation, not just its abstract form. Better device models, calibration-aware mapping and specialized rewrites could make more algorithms practical, but claims should be compared on equivalent workloads and measured outcomes. For readers evaluating a quantum demonstration, the useful question is simple: what did the hardware actually execute? This article explains published documentation and does not claim hands-on access to a quantum processor.
Primary and authoritative sources
- IBM Quantum: Introduction to transpilation
- IBM Quantum: Represent quantum computers for the transpiler
- IBM Quantum: Transpilation optimization with SABRE
- Google Quantum AI: Google devices in Cirq
Featured image is an AI-generated editorial metaphor, not a photograph of a named quantum processor.
Leave a Reply