MPO + Unswapping on a laptop CPU for peaked_circuit_P9_Hqap_56x1917

[alexgalda-m]

Name

mpo_unswapping_cpu_laptop_56_1917

Circuit

peaked_circuit_P9_Hqap_56x1917

Value

100

Method

MPO + Unswapping (CPU)

Method proof

Peaked MPO Solver: CPU-Oriented Implementation

• Code: alexgalda-m/peaked-mpo-solver (Apache-2.0)
• Reference: Kremer & Dupuis 2026 (arXiv:2604.21908)

Overview & Enhancements

This is a CPU-oriented implementation of the midpoint MPO + greedy-unswapping strategy from Kremer & Dupuis (as applied in IBM's GPU submission #106). While the high-level approach is the same, this repository extends it with several optional features optimized for the CPU regime:

• Symmetric (Both-Sided) Unswapping: Evaluates swap candidates from the left, the right, and from both sides simultaneously, keeping the variant that maximally reduces the bond dimension.
• Additional Optimizations:
  • Cached SWAP-layer MPO construction
  • Full parity-swap probe reuse
  • Route-aware unswap candidate selection
  • Faster Sabre-based local rerouting
  • Fail-fast stall guard
• Production Configuration: The verified production path keeps the unswap-select-mode at "bond" with the pass order set to "both, left, right".

Repository Artifacts

See BENCHMARKS.md in the repository for the full per-machine data table. The run folders under runs/ contain the following artifacts for each measurement:

• summary.json
• stats.csv
• samples.tsv
• plot.png
• samples.png

---

Benchmarks

Verified-clean runs executed at --cutoff 0.0006.

Apple Silicon SKU	Model Number	Execution Time	Peak counts	#2 bitstring counts
M5 Pro	T6050	734.2 s	92/1000	10/1000
M4	T8132	747.2 s	96/1000	9/1000
M2 Pro	T6020	973.0 s	46/1000	28/1000
M1 Max	T6000	1339.5 s	36/1000	6/1000

Run Validation:
All four benchmark runs successfully hit the following target states:

• last_work_consumed = 1885
• termination_reason = completed
• matches_expected_bitstring = true

---

Comparison to the Original GPU Baseline (#106)

The original Kremer & Dupuis result on this exact circuit (submission #106, verified) used the same MPO + unswapping method on a single datacenter GPU. The headline improvement is the compute class — the same simulation runs here on a consumer laptop CPU with no GPU:

Implementation	Hardware	Runtime	Peak counts
Kremer & Dupuis (#106)	1× Nvidia A100 80 GB GPU	4059 s	~100/1000
This work (M5 Pro)	Apple M5 Pro laptop CPU	734.2 s	92/1000

Wall-clock is also ~5.5× faster.

---

📝 Note on Gate Counts

The initial QASM circuit consists of 1,917 rzz and 3,890 u gates. During preprocessing, Qiskit's Collect2qBlocks and ConsolidateBlocks passes fuse these losslessly into 1,885 generic 2q-unitary blocks before MPO compression begins.

Progress is reported in these consolidated-block units (0..1885), directly matching the "Total 2q Unitaries Consumed" convention established in the Kremer & Dupuis reference notebook.

Authors

Alexey Galda

Institutions

Moderna

Quantum runtime (seconds)

No response

Classical runtime (seconds)

734

Compute resources (quantum)

No response

Compute resources (classical)

Apple M5 Pro (T6050) laptop, single Python process, Apple Accelerate BLAS

Notes

12 min on a consumer Apple Silicon laptop CPU

[minhctran]

Hi @alexgalda-m. Would it be possible to add the performance of Kremer & Dupuis on the table for comparison? It is not obvious to me what the improvement is qualitatively. Thanks.

[alexgalda-m]

Thanks @minhctran — good point. I've added the original Kremer & Dupuis baseline (#106) to the submission table above.

The short version: #106 ran the same circuit and method on a single Nvidia A100 80 GB datacenter GPU in 4059 s (~68 min). This submission reproduces the same outcome (matches_expected_bitstring: true, comparable ~10% peak) on a consumer Apple Silicon laptop CPU with no GPU at all — 734 s on an M5 Pro. So the qualitative improvement is the compute class: the same simulation moves off a datacenter GPU onto a commodity laptop CPU. It's also ~5.5× faster in wall-clock, though since the two runs use different compression cutoffs that gap is partly configuration-dependent — the GPU→CPU shift is the robust comparison.

[d-kremer]

Hi @alexgalda-m this looks interesting, thank you for the contribution!

I'm trying to run the code on an M5 mac with the default settings

uv run p9solve --qasm circ/peaked_circuit_P9_Hqap_56x1917.qasm --outdir runs --tag test1m5 --samples 1000 --cutoff 0.0006 --no-parallel-rewire

but I got this after a few iterations:

"sampling_skipped_reason": "terminated: no_progress_cycle_limit"

is there any specific settings I need to use?

[alexgalda-m]

Hi @d-kremer, thanks for trying the run.

That error is the fail-fast stall guard. It means the MPO compression hit two consecutive unswap cycles where no additional consolidated 2q blocks could be consumed, so sampling was skipped because compression had not finished.

The run is somewhat cutoff-sensitive. --cutoff 0.0006 completed on my M5 Pro benchmark, but small differences in the local SVD / Apple Accelerate / NumPy / SciPy path can send the greedy unswap + reroute trajectory into a no-progress branch.

I would keep the same benchmark settings and first retry with only the cutoff changed:

uv run p9solve \
  --qasm circ/peaked_circuit_P9_Hqap_56x1917.qasm \
  --outdir runs \
  --tag test1m5_cutoff001 \
  --samples 1000 \
  --cutoff 0.001 \
  --no-parallel-rewire

If 0.001 also stalls, I would try a small cutoff sweep before changing any algorithmic flags:

• --cutoff 0.0008
• --cutoff 0.0012
• --cutoff 0.0015
• --cutoff 0.002

No --parallel-rewire setting is required for the submitted benchmark path. The M5 Pro artifact I submitted used --no-parallel-rewire, seed=123, max_bond=512, and completed all 1885/1885 consolidated blocks at --cutoff 0.0006; your run appears to have landed on a different numerical truncation trajectory at the same cutoff.

If the cutoff sweep still fails, please share the failing run's summary.json and stats.csv so I can see where the no-progress cycle starts and whether the run is pinned at the max_bond=512 cap.