Optimized for multi-chip. Across every workload family.

Every benchmark on this page measures the metric that actually matters on multi-chip hardware: cross-chip communication. Fewer cuts mean fewer cross-chip teleportations and a lower cloud bill.

Limbo matches or beats the leading distributed compiler on 19 of 21 cells in our v0.2 matrix, and on 12 of 12 multi-chip-focused cells against TKET. Versus a graph-blind naïve baseline the gap widens to 71%.

Workload coverage

Seven workloads grouped into four families, each run at three scales (16 / 32 / 64 logical qubits) on the same 4-QPU / cap-20 hardware envelope. Cut count = cross-QPU 2-qubit operations = Bell-pair teleportations the runtime must execute. Lower is better; per-row winners highlighted.

Fourier

Variational

Randomized

Application-shaped

"Degenerate" cells are workloads small enough to fit on a single chip, so cut count is zero for one or both compilers and there's no signal either way. "Tie" cells produce identical cut counts. Limbo's advantage grows with circuit size and density: the harder the partition problem, the more our approach pays off relative to simpler heuristics.

Why this matters in a multi-chip world. Every cut on this page is one cross-chip teleportation at runtime. Cross-chip communication is the slowest and most error-prone part of any modular quantum job. Cutting fewer edges means faster jobs, fewer mid-circuit errors, and lower cost. The advantage compounds as multi-chip hardware scales out.

Top partition wins

Five cells where Limbo cut the most communication volume vs the leading alternative. Shorter bars = fewer Bell pairs = lower cloud bill.

Versus TKET on multi-chip workloads

TKET (Quantinuum's flagship quantum compiler) is the strongest general-purpose alternative on the market. Its routing was designed for single-chip hardware and retrofitted for multi-chip layouts, so we restrict this comparison to workloads where multi-chip routing actually has to do work: we drop hardware-efficient ansatze (mostly nearest-neighbor) and n=16 (fits on one chip).

Apples-to-apples setup: both compilers see the same 4-chip × 20-qubit architecture with sparse inter-chip links. Cuts = cross-chip 2-qubit operations in each compiler's compiled output, including any SWAPs TKET inserts.

What's happening. Limbo's hypergraph partitioner is solving the right problem for multi-chip execution: minimize cross-chip 2-qubit operations directly. TKET solves a different problem (minimize SWAPs against a coupling map) and is forced to spend cross-chip operations on routing. On dense Fourier workloads our gate-level pre-optimization pass closes the gap where TKET previously had an edge, and the topology-first partition strategy does the rest. Both compilers run in well under a second on most cells; TKET's compile time grows steeply with circuit size because of its more elaborate routing search.

Where the gains come from

Three independent components feed the final result: the partitioner that places qubits onto QPUs, the scheduler that sequences cross-chip events through limited port capacity, and the template cache that amortizes partitioning across variational iterations. Each one was measured separately so the attribution is clean.

Real-hardware results: coming next

Cloud quantum hardware costs real money per shot, and we want our real-hardware claims backed by signed receipts, not extrapolations. The Limbo SDK already drives IBM Quantum, AWS Braket, and Azure Quantum. The integration tests in tests/integration/ exercise the authenticated submit and poll paths end-to-end against each provider's sandbox.

For our public v0.3 release we will publish, on at least two independent cloud backends:

• Measured wall-clock from submit() to results, including queue time.
• Per-job shot cost in vendor credits / USD, alongside the equivalent baseline cost.
• Output-state fidelity (or proxy fidelity) on simulator-shadowed runs.
• For variational workloads, energy gap from ideal across the full optimizer trajectory.

Until v0.3, the figures on this page are simulation-grounded compiler metrics: cut count, makespan estimator, and wall-clock compile time. Every number on this page is captured by a runnable benchmark; nothing is extrapolated from a different problem size.

Scheduler sensitivity: when does scheduling matter?

64-qubit hotspot workload on a 4-chip linear layout, simulated with realistic link-success probability and retry penalties. Sweeping port capacity shows where the critical-path scheduler earns its keep, and where it ties with simpler FIFO.

Honest read: with very limited port capacity, both policies produce essentially the same schedule because every cycle is contention-bound. The critical-path scheduler's advantage appears as capacity opens up, peaking at about 7% off the makespan. The big win is consistency: it never significantly loses, and wins where it can. Production hardware is moving toward higher port capacity, which is exactly where the scheduler advantage compounds.

Where Limbo fits

Methods

Setup. Every cell uses 4 chips × 20 qubits per chip with a fixed random seed for reproducibility. The same circuit is handed to each compiler. Cut counts come from each compiler's own partition output. Makespan estimators use each compiler's native pass. Compile time is wall-clock through the full pipeline.

Baselines. Three compilers in the matrix: Limbo, the leading distributed alternative, and a naïve baseline that partitions by qubit index with no graph analysis at all. The naïve baseline is there so you can see the graph-aware compilers are doing useful work.

What we did not measure. No real-hardware execution, queue-time wall-clock, or shot-cost figures. These are deferred to v0.3 (see the real-hardware section above). Every figure on this page comes from a reproducible simulation pipeline.

Hardware envelope. c6i.4xlarge EC2 (16 vCPU, 32 GB RAM), Python 3.11. The full v0.2 matrix completes in under 20 seconds wall-clock.