Source-linked AI summary
Advancing Hybrid Quantum-Classical Computation with Real-Time Execution
Thomas Lubinski, Cassandra Granade, Amos Anderson, Alan Geller, Martin Roetteler, Andrei Petrenko, Bettina Heim
TL;DR
Disjoint classical and quantum execution incurs latency that can keep classical decisions from influencing a quantum state before decoherence. The paper embeds classical computation in quantum programs through QIR and demonstrates random walk phase estimation on quantum hardware, with hardware and simulator results reported as nearly equivalent.
Problem
Disjoint classical and quantum processors require repeated data exchange, whose latency limits classical decisions from influencing quantum-state evolution before decoherence.
Source: §I · p. 1Method
The paper uses QIR to represent quantum operations and embedded classical computation, enabling measurement-conditioned real-time calculation and adjustment of program variables.
Source: §I · p. 2, B. Scaling Up the Software Stack · p. 8, §VII · p. 13Results
The random walk phase-estimation implementation produced nearly equivalent simulator and QCI hardware results, with a prominent peak at µ = 0.5.
Source: D. Execution on Quantum Hardware · p. 12, §VII · p. 13Takeaways & Limitations
The demonstrated real-time hybrid pattern reduces the need for external round-trips and supports algorithms that use classical computation during quantum-program execution.
Source: §I · p. 2, §VII · p. 13Detailed error analysis and quantitative comparison of the hardware and simulator results were deferred to future work.
Source: D. Execution on Quantum Hardware · p. 12
Abstract
from arXiv · showhide
The use of mid-circuit measurement and qubit reset within quantum programs has been introduced recently and several applications demonstrated that perform conditional branching based on these measurements. In this work, we go a step further and describe a next-generation implementation of classical computation embedded within quantum programs that enables the real-time calculation and adjustment of program variables based on the mid-circuit state of measured qubits. A full-featured Quantum Intermediate Representation (QIR) model is used to describe the quantum circuit including its embedded classical computation. This integrated approach eliminates the need to evaluate and store a potentially prohibitive volume of classical data within the quantum program in order to explore multiple solution paths. It enables a new type of quantum algorithm that requires fewer round-trips between an external classical driver program and the execution of the quantum program, significantly reducing computational latency, as much of the classical computation can be performed during the coherence time of quantum program execution. We review practical challenges to implementing this approach along with developments underway to address these challenges. An implementation of this novel and powerful quantum programming pattern, a random walk phase estimation algorithm, is demonstrated on a physical quantum computer with an analysis of its benefits and feasibility as compared to existing quantum computing methods.
I. INTRODUCTION
Existing hybrid algorithms alternate classical and quantum computation, but processor handoffs and data exchange impose latency that limits decisions from influencing a live quantum state. The paper motivates real-time hybrid programs that embed classical computation in quantum execution, while reviewing existing hybrid methods and their trade-offs.
I. INTRODUCTION
- Current gate-model devices have limited qubit counts and instruction budgets, motivating VQE and QAOA approaches that divide work between classical and quantum processors.In these approaches, the classical program supplies data and makes decisions between quantum executions.Source: §I · p. 1
- Embedding classical computation in quantum programs targets the latency and repeated data exchange that constrain disjoint hybrid execution.The embedded computation can run without terminating the quantum program or returning to an external classical processor.Source: §I · pp. 1–2
A. Hybrid Quantum Applications
- VQE uses classical optimization to tune an ansatz while quantum execution estimates a cost function, trading circuit size against repetitions needed for target accuracy.The quantum state need not remain coherent during classical optimization.Source: A. Hybrid Quantum Applications · p. 2
- QAOA alternates classical optimization with quantum cost evaluation, trading circuit depth against solution quality without requiring coherence during optimization.The number of rounds affects circuit depth; with few rounds, the method is not more powerful than classical methods.Source: A. Hybrid Quantum Applications · pp. 2–3
- Alternating classical and quantum execution creates time-to-solution challenges from circuit composition, execution startup, and processor communication.Parameter values and co-located processors can reduce some of this latency, but near-time approaches still incur initialization and data-transfer delays.Source: A. Hybrid Quantum Applications · p. 3
B. Mid-Circuit Measurement
Mid-circuit measurement enables qubit reuse and branching, but hard-coded paths can grow exponentially with the number of branch points. The paper presents real-time classical computation as a further step, allowing measurements to drive arithmetic and adaptive changes to subsequent operations.
B. Mid-Circuit Measurement
- Mid-circuit measurement enables qubit reset and reuse, while branching can encode different circuit paths within one quantum-program execution.Branching alone can require enumerating all subsequent paths, which can grow exponentially with the number of branch points.Source: B. Mid-Circuit Measurement · p. 3
- Iterative phase estimation, semi-classical Fourier transforms, quantum sieving, and quantum rejection use measurement, reset, or branching to adapt quantum computation.These approaches can trade qubit requirements against classical processing or use measurement outcomes to regroup registers and implement non-unitary operations.Source: B. Mid-Circuit Measurement · p. 4
C. Real-Time Classical Computation
- Earlier adaptive iterative phase estimation selected a new angle from a lookup table after measurement, but still required programming the possible branch paths.The paper identifies this as a step toward real-time computation, while calling for a more efficient solution that avoids enumerating paths.Source: C. Real-Time Classical Computation · p. 4
- Real-time hybrid programs can use measurement results as arithmetic inputs that modify gate angles during execution, reusing parameterized operations across iterations.Each iteration may refine the computation rather than select among hard-coded subsequent operations.Source: C. Real-Time Classical Computation · p. 4
- Embedded classical computation has been demonstrated for generating random gates in randomized benchmarking and for real-time feedback in quantum error correction.The paper also describes OpenQASM 3.0 as a human-readable representation for programs that include classical computation, and QIR as a machine-manipulable representation for interleaved quantum and classical computation.Source: C. Real-Time Classical Computation · p. 4
III. ENABLING A NEW FORM OF HYBRID PROGRAM
The paper proposes an end-to-end software stack that represents quantum operations and classical control together, then compiles that representation for hardware targets. It builds on QIR and LLVM tools while noting that each target profile limits the constructs a device can execute.
III. ENABLING A NEW FORM OF HYBRID PROGRAM
- An end-to-end stack should let applications express solutions portably and enable backends to translate an intermediate representation into hardware-specific execution.The proposed approach introduces a compilation stage from a holistic, hardware-agnostic representation to a backend-specific profile.Source: §III · p. 5
A. The Quantum Software Stack
- Existing applications such as VQE and QAOA alternate optimization and quantum execution, but data-exchange latency limits their practicality.Symbolic parameters and processor co-location can help, but tightly integrated processing requires support throughout the hardware and software stack.Source: A. The Quantum Software Stack · p. 5
- A program representation for live classical processing must capture data exchange, classical computation, and control flow alongside quantum operations.This requirement applies whether applications use a domain-specific language or a metaprogramming framework.Source: A. The Quantum Software Stack · p. 5
B. Quantum Intermediate Representation
- Figure 2 depicts teleportation as control flow between quantum-instruction blocks, with measurement-conditioned branches represented in QIR.The figure pairs a schematic, Q# source, and the generated QIR control-flow graph.Source: Figure 2 · p. 6
- QIR builds on LLVM IR and is intended to support interoperability across quantum languages, libraries, optimization passes, and hardware code generation.The paper describes QIR as language- and hardware-agnostic and notes LLVM's type safety, flexibility, and support for representing high-level languages.Source: B. Quantum Intermediate Representation · p. 6
- QIR is an integrated representation for quantum instructions and classical concepts such as branching, memory management, and variables.A common representation can support different source languages and execution platforms without redundant development.Source: B. Quantum Intermediate Representation · pp. 5–6
- A compilation stage maps QIR programs to target-specific profiles, enabling hardware capabilities without requiring source languages to specialize for each device.A device profile limits the gate set, measurement capabilities, control flow, and classical computation; unsupported logic may need pre- or post-processing, while unique features require compatible hardware.Source: B. Quantum Intermediate Representation · p. 6
C. Hardware Challenges
Quantum control systems must coordinate pulse generation and programmable control on nanosecond timescales, but specialized hardware limits the classical computation available during execution. The section describes arithmetic, compilation, and scaling constraints for adaptive hybrid programs.
C. Hardware Challenges
- Specialized control hardware meets stringent timing requirements but sacrifices general-purpose features, including instruction-set size and runtime memory.Quantum operations use precisely coordinated nanosecond-scale pulses, with control flow often implemented on specialized hardware such as AWGs or FPGAs.Source: C. Hardware Challenges · p. 7
- Fixed-point arithmetic can overflow or underflow, has limited non-periodic range, and loses one precision bit when multiplied by 0.5.The authors advise developers to account for target-hardware constraints when using arithmetic in hybrid programs.Source: C. Hardware Challenges · p. 7
- Gate arguments known at compile time allow efficient hardware-specific code generation, whereas runtime-variable arguments require more complex compiler sequences.A virtual RZ gate can accept runtime-variable arguments only when the classical processor supports arithmetic and trigonometry.Source: C. Hardware Challenges · p. 7
- Adaptive programs face multiple early-stage constraints, including variable return-data structures and possible bandwidth, latency, and connectivity bottlenecks among distributed control processors.The authors say future quantum control systems should account for these challenges.Source: C. Hardware Challenges · p. 7
IV. THE PATH TO SCALABLE AND RELIABLE APPLICATIONS
The paper presents adaptive hybrid programming, where classical and quantum operations are interwoven, and illustrates its use in a qubit-reset algorithm. In that example, measurement-driven classical control adjusts execution during the quantum program.
IV. THE PATH TO SCALABLE AND RELIABLE APPLICATIONS
- Adaptive hybrid programming interweaves quantum and classical primitives, making repeated transfer of quantum measurement data across computer interfaces optional.The paper frames this approach as enabled by a quantum software stack with classical computation and a portable intermediate representation.Source: §IV · p. 7
A. Resetting a Quantum System
- The paper illustrates embedded classical control with a reset protocol seeking a desired fidelity in the shortest time, since a single operation cannot reset an unknown qubit state with certainty.Tutorial examples describe repeated reset operations as a way to achieve high success probability, with their number affecting fidelity.Source: A. Resetting a Quantum System · p. 7
- The reset loop succeeds after two consecutive measurements of 0; if it has not succeeded after four measurements, it exits with failure.A nonzero measurement triggers an X operation and resets the success count.Source: A. Resetting a Quantum System · p. 8
- Measurement-based arithmetic can update variables and gate values on the fly, making the program adaptive to the changing quantum state.The reset example highlights variables, classical loop execution, and simple arithmetic during quantum-program execution.Source: A. Resetting a Quantum System · pp. 7–8
B. Scaling Up the Software Stack
The software-stack model interleaves quantum operations with in-program classical computation, enabling variables, arithmetic, and conditional loops to run while qubits remain coherent. Random walk phase estimation (RWPE) uses these capabilities to update phase estimates during execution, avoiding lookup tables that grow exponentially with measurement history.
B. Scaling Up the Software Stack
- The software model supports parameterized quantum operations interleaved with classical computation and control flow, with iterations able to maintain the quantum state.Classical variables can change during execution and serve as rotation angles, loop counters, or returned values; arithmetic must finish quickly enough to avoid decoherence.Source: B. Scaling Up the Software Stack · p. 8
- The integrated model requires hardware-side arithmetic and synchronized low-level instructions, while compilers and intermediate representations must support variables and conditional loops.The arithmetic and measurement routing must complete quickly enough to avoid decoherence; high-level languages used by external drivers are not suitable for these time-critical operations.Source: B. Scaling Up the Software Stack · p. 8
- Q# and QIR represent the integrated program, while the compiler separates its classical and quantum portions to generate backend instructions.The paper describes these as the first programming tools capable of representing this advanced form of hybrid computation.Source: B. Scaling Up the Software Stack · p. 8
C. Random Walk Phase Estimation
- RWPE is motivated by the difficulty of running iterative phase estimation on noisy devices, where deep gate sequences can outlast qubit coherence.Bayesian inference supports online phase estimates from partial measurement records, while particle filtering and rejection filtering reduce computational cost.Source: C. Random Walk Phase Estimation · p. 9
- RWPE uses a random walk to compute online estimates with only a few arithmetic expressions per iteration.The algorithm updates its mean and standard deviation based on measurement outcomes and uses the updated values in subsequent operations.Source: C. Random Walk Phase Estimation · pp. 9–10
- RWPE must update µ and σ during execution so new values can feed later quantum operations without returning to a remote classical processor.Reconstructing these variables from measurement histories instead requires exponentially growing lookup tables; practical runs may require 20–60 iterations, corresponding to relative accuracies of 10^-2 to 10^-6.Source: C. Random Walk Phase Estimation · p. 10
- RWPE demonstrates the need for adaptive hybrid programming, and the paper uses it to assess the approach’s practical viability.Classical updates, branching on measurement outcomes, and maintaining program state without a remote processor are central to the algorithm’s execution.Source: C. Random Walk Phase Estimation · p. 10
V. EXECUTION ON QUANTUM COMPUTING SYSTEMS
The authors executed RWPE on a simulator and a physical quantum system, focusing on interpreting its intermediate representation and selecting execution parameters. The physical system was provided by QCI and designed to support the hybrid capabilities RWPE requires.
V. EXECUTION ON QUANTUM COMPUTING SYSTEMS
- The study ran RWPE on both a quantum simulator and a physical quantum computing system.The physical system was provided by Quantum Circuits Inc. (QCI).Source: §V · p. 10
- The execution analysis focuses on interpreting the RWPE intermediate representation and the parameters controlling program execution.Source: §V · p. 10
- The QCI system provides control-system capabilities integral to the enhanced hybrid programming model and needed to execute RWPE.Source: §V · p. 10
A. Compiling RWPE and Interpreting QIR
The compilation workflow starts from target-independent QIR produced from Q#, then transforms it into QCI’s native representation. Hardware data types and arithmetic impose constraints, so the authors recommend validating behavior with a simulator that models those limits.
A. Compiling RWPE and Interpreting QIR
- QIR provides a target-independent representation generated from Q# and transformed by QAT for hardware, then parsed by QCI’s compiler into its native program representation.The mapping is mostly one-to-one, with exceptions for QCI-specific gates and numeric division behavior.Source: A. Compiling RWPE and Interpreting QIR · p. 10
- Hardware maps integer and boolean values to 18-bit signed integers and doubles to Q2.16 fixed-point integers.Angles are expressed in units of π across a range of two full periods; division uses interpolation-table approximation, while addition, subtraction, and multiplication are native operations.Source: A. Compiling RWPE and Interpreting QIR · p. 10
- The compiler rejects out-of-range QIR assignments, but hardware has no runtime underflow or overflow check; RWPE’s σ underflows after about 20 iterations.The program’s runtime wrapping of 1/σ as an angle is acceptable for this example and was validated in simulations.Source: A. Compiling RWPE and Interpreting QIR · p. 11
- Because hardware data types may differ from QIR types, users should validate behavior with a simulator that reproduces the target system’s classical limitations.The same QIR can target different hardware without changing the algorithm.Source: A. Compiling RWPE and Interpreting QIR · p. 11
B. Parameterizing RWPE Program for Execution
The execution parameters set the oracle and iteration limit, and make eigenstate refresh frequency a user-selectable trade-off. An enhanced simulator validates RWPE under ideal conditions and models hardware noise and fixed-point computation; its ideal run produces a peak at the expected eigenvalue.
B. Parameterizing RWPE Program for Execution
- The demonstration hard-codes an oracle with true eigenvalues ±0.5 and is expected to produce an estimate near 0.5.The algorithm favors 0.5 because it is closer to the initial prior estimate.Source: B. Parameterizing RWPE Program for… · p. 11
- Each shot runs 24 iterations, and the program refreshes the eigenstate every other iteration to illustrate the selectable refresh trade-off.More frequent refresh can improve accuracy when the eigenstate decoheres faster, while costly state preparation favors less frequent refresh; here the eigenstate is prepared with reset and an X gate.Source: B. Parameterizing RWPE Program for… · p. 11
C. Execution on an Enhanced Quantum Simulator
- The custom simulator executes control flow and classical operations in Python and can model fixed-point computation, quantum noise, and readout noise.It uses statevector or density-matrix simulation for quantum operations and can model three infidelity sources: finite shots, quantum noise, and hardware-specific classical computation.Source: C. Execution on an Enhanced Quantum… · p. 11
- The ideal simulation uses full-precision classical registers and no quantum noise, leaving finite-shot randomness as its only error source.The authors use it to check that the algorithm performs as designed.Source: C. Execution on an Enhanced Quantum… · pp. 11–12
- The hardware histogram’s µ = 0.5 peak is lower than in the ideal simulation because noise makes convergence there less likely.The hardware and noisy simulation histograms use the same x-axis bounds and number of bins; the peak’s location, not its height, indicates correctness.Source: Figure 5 · p. 12, C. Execution on an Enhanced Quantum… · p. 12
- The ideal 10,000-shot simulation produced a distinct histogram peak at the expected eigenvalue µ = 0.5.The histogram records the value after 24 iterations; other outcomes reflect the random walk and can occur even with perfect execution.Source: Figure 4 · p. 11, C. Execution on an Enhanced Quantum… · p. 12
D. Execution on Quantum Hardware
The RWPE program produced closely matching results on QCI hardware and a noisy simulator, with a prominent peak at the expected eigenvalue. The discussion then outlines limits of the present analysis and directions for extending real-time hybrid computation.
D. Execution on Quantum Hardware
- Both hardware and noisy simulation show a prominent peak at μ = 0.5, matching the ideal simulation and suggesting successful QIR translation.The authors defer detailed error analysis and quantitative comparison to future work.Source: D. Execution on Quantum Hardware · p. 12
- RZ and ESWAP accept run-time variable arguments; RZ is much faster than a pulse-based gate, and the gate fidelities sufficed for a well-defined RWPE solution.The authors identify gate fidelity as likely the largest factor influencing peak height.Source: D. Execution on Quantum Hardware · p. 12
VI. FUTURE WORK
- The RWPE study considered only inferences much shorter than qubit lifetimes, although real-time phase estimates under this constraint can validate noise-mitigation hypotheses.The authors suggest that reanalyzing intermediate measurements afterward could relax this restriction; the measurement sequence, evolution times, and inversion angles determine the likelihood, and particle-filter postprocessing reduced outlier impact in prior work.Source: §VI · pp. 12–13
- Future workflows could use intermediate measurements for online experiment design, then refine estimates offline with classical data processing beyond qubit lifetimes.The paper also identifies error correction, chemistry simulation, and entirely new algorithms as possible applications of in-program classical arithmetic.Source: §VI · p. 13
VII. SUMMARY AND CONCLUSIONS
The paper presents QIR-backed, tightly integrated quantum-classical processing and demonstrates random walk phase estimation using simulation and physical hardware. It frames this work as an initial step toward expanding quantum algorithms and identifies software resources for QIR development.
VII. SUMMARY AND CONCLUSIONS
- The authors use QIR to express hybrid programs for translation to hardware-specific assembly and demonstrate RWPE with supporting software, simulation, and physical hardware.They describe this as an initial step toward fully general, tightly integrated quantum-classical processing.Source: §VII · p. 13
- If computational models have limited progress toward new, more efficient quantum algorithms, this work offers progress toward addressing that gap.The authors hope the results will prompt a broader reconsideration of what quantum algorithms can look like.Source: §VII · p. 13
- The authors argue that quantum computing also depends on innovative, extensible software components alongside advances in qubits and control electronics.They suggest their work may help narrow the gap and accelerate development of new techniques.Source: §VII · p. 13
CODE AVAILABILITY
- The QIR Alliance provides specification-development information and tools, while PyQIR and QAT source code is available online.The paper also directs readers to Cross et al. for the OpenQASM 3.0 specification.Source: CODE AVAILABILITY · p. 13
1. Source Code
The Q# source implements random-walk phase estimation, with a main operation that updates parameters and calls a phase-estimation iteration. Its compiled QIR is shown as LLVM code and a control-flow graph.
1. Source Code
- The Q# implementation invokes a custom ActiveReset instruction because QCI’s multi-qubit reset protocol is more effective than multiple single-qubit resets.ActiveReset is only usable when all qubits are included, so it is not appropriate for the circuit’s single-qubit reset.Source: §1 · p. 14
- Each Iterate call applies Rz and controlled-Rz operations, then measures the auxiliary qubit and returns that result.The implementation identifies Rz as the oracle U and uses ActiveReset and Prepare on the target between iterations.Source: §1 · pp. 14–15
- The entry-point operation initializes 24 iterations with µ = 0.7951 and σ = 0.6065, then passes values derived from them to each iteration.The iteration arguments are 1.0 − (µ / σ) and 0.5 / σ; the code comment identifies 0.5 as setting the oracle scale so φ = 0.5 is the target eigenvalue.Source: §1 · p. 14
- The project targets QCI’s machine1 execution target and uses the netcoreapp3.1 framework.The source code is compiled into QIR, an LLVM intermediate representation for processing by different hardware providers.Source: §1 · pp. 14–15
- The compiled program is represented as LLVM code, with the control-flow graph showing the loop’s current µ and σ values feeding iteration parameters and two random-walk branches.The graph labels those branches then0__1 and else__1.Source: §1 · p. 14, Figure 6 · p. 16