⚡ Profile and optimize target compilation for long narrow circuits

[simon1hofmann]

🤖 AI text below 🤖

Problem

Target compilation is slow for long, narrow gate streams. With the explicit production-representative profile below, two fresh profiled runs of the 16-qubit hwb10 circuit on a sparse 133-site target completed in 29.74 and 29.93 seconds, excluding parsing, target construction, QC-to-QCO conversion, export, and validation.

The fully validated run attributed most of its 29.93-second target-compilation time to two independent stages:

• MappingPass: 16.69 seconds, with 29,870 inserted SWAPs.
• Final RemoveDeadValues: 7.77 seconds, including 4.09 seconds in liveness analysis.

The resulting target-native program passed Benchpress validation and contained 80,868,732 bytes of textual QCO IR.

Reproduction profile

• Core revision: 0858f109cc58ee527cab094e04eeee52849f1f3a
• Build: Release, MLIR timing and statistics enabled
• Workload: hwb10.qasm (16 logical qubits, 31,764 source operations)
• Target: Qiskit FakeTorino (133 sites, 150 undirected couplings, CZ native basis)
• nlookahead = 15
• alpha = 1.0
• lambda = 0.5
• niterations = 1
• ntrials = 4
• seed = 42
• Preservation of unobserved quantum operations enabled

Goal

Add a deterministic, production-shaped benchmark for long, narrow target compilation. Use it to improve the mapping/layout and final cleanup stages separately while preserving route quality and target conformance.

The benchmark should exercise the complete target-compilation pipeline with production-representative mapping settings rather than only an isolated synthetic mapping pass. All mapping parameters must be selected explicitly and recorded so that results do not silently depend on low-level pass defaults.

Benchmark shape

• Approximately 16–20 active qubits and a long deterministic gate stream.
• A sparse target graph large enough to exercise placement and routing.
• Production-representative mapping settings with nlookahead >= 15.
• Record the exact nlookahead, ntrials, niterations, alpha, lambda, and seed used.
• Preservation of unobserved quantum operations enabled.
• Separate pass timing plus routed SWAP count or an equivalent route-quality metric.

Acceptance criteria

• A reproducible benchmark records total target-compilation time, mapping time, final cleanup/liveness time, and route quality.
• Measurements use nlookahead >= 15 and publish every relevant mapping parameter.
• Mapping/layout improvements reduce repeated full-circuit work without silently increasing invalid routes or materially degrading route quality.
• Cleanup improvements retain the final target-native and conformance guarantees established by #1687.
• Tests cover semantic equivalence, target conformance, and preservation of observed and explicitly preserved unobserved operations.
• Performance changes include before/after measurements for both sparse and all-to-all targets.

Related work: #1866 is the general mapping umbrella; #1868 discusses mapping data size; draft #1955 adds mapping-only synthetic benchmarks but does not cover this full-pipeline workload or final liveness cleanup.

[MatthiasReumann]

Unfortunately, the performance of the mapping pass (at least in terms of runtime) strongly depends on the runtime of the topological sort (sortTopologically). For some reason, this function is really slow for larger programs. I think there are two options to fix this:

• (Simple; but effective): Extend the driver logic to include 1-q gates and reorder based on that iteration. The implementor must make sure that this doesn't add too much overhead to the existing routing logic (The current driver only calls the callback on multi-qubit ops)
• (Harder; potentially faster): Re-order the operations while inserting SWAPs.

[burgholzer]

Unfortunately, the performance of the mapping pass (at least in terms of runtime) strongly depends on the runtime of the topological sort (sortTopologically). For some reason, this function is really slow for larger programs. I think there are two options to fix this:

• (Simple; but effective): Extend the driver logic to include 1-q gates and reorder based on that iteration. The implementor must make sure that this doesn't add too much overhead to the existing routing logic (The current driver only calls the callback on multi-qubit ops)
• (Harder; potentially faster): Re-order the operations while inserting SWAPs.

Including single-qubit gates in the routing may make a lot of sense mid- to long-term as we move from simple gate-count/depth towards fidelity-aware routing where single-qubit gates make a real difference.
So I'd rather go that way, I believe. We have the full DAG of the program available to us; we should not need the topological sorting for our purposes (although it was a convenient fix for now).