Quantum runtime policies improve HPC search by using problem parts
SemQBench: Benchmarking Decomposition-Aware Runtime Policies for Quantum-HPC Search
Emerging Technologies
Summary
Quantum processors can speed up high-performance computing tasks, but deciding how to run quantum circuits efficiently is tricky. The authors tested seven different ways to organize and repeat these circuit runs on a real quantum device. They found that breaking problems into parts and sharing results across runs can reduce how many circuit runs are needed by up to four times. However, fewer runs don’t always mean less time on the quantum processor. This work helps guide deciding when it’s best to use complex or simple strategies in quantum computing workflows.
What this means in practice
- •For quantum software engineers: Optimize quantum workflow runtimes by exposing problem structure to reduce total circuit runs and resource use on actual quantum hardware.
- •For cloud quantum service operators: Improve job scheduling and retry policies to lower quantum device time and overhead for remote quantum job providers.
Authors
Chandrachud Pati, Yogesh Simmhan
Abstract
Quantum processors are increasingly used as accelerators inside high-performance computing (HPC) workflows. A workflow runtime decides which quantum circuits to run, how to group them into provider jobs, and what to repeat after a failed attempt. Many search problems split into independent parts, but the runtime can use that structure only when the workflow exposes the parts and a validity check for each one. SemQBench measures what a runtime gains from this visibility. It compares seven execution policies for the same search problem, including two controls without amplitude amplification. The policies change one runtime choice at a time: whether to amplify, whether partial results may be combined across runs, whether the parts share one circuit, and what a retry keeps. We run them on the 20-qubit IQM Garnet processor using 106 distinct circuits in three jobs, and report circuit executions, active device time, and provider jobs separately before combining them in a cost model. Amplifying the problem as one whole circuit shows no statistically clear gain over random sampling and uses 6.7-104$\times$ more active device time. Exposing the parts and collecting valid partial results across a fixed batch of runs cuts the executions needed for 95% completion confidence by 2.20-4.00$\times$, and this policy is never worse than the other amplified policies in executions, device time, or jobs; it is selected in 99 of 108 overhead settings. Fewer executions do not always mean less device time: on one workload, executions fall from thirteen to four while active device time rises from 7.44 to 9.81 $μ$s. Exposing problem structure therefore gives the runtime a strong default policy and the measurements needed to decide when the simpler unamplified option is cheaper.