PaperlayerView exact revision on arXiv

Source-linked AI summary

Hybrid Programming for Near-term Quantum Computing Systems

Alexander McCaskey, Eugene Dumitrescu, Dmitry Liakh, Travis Humble

arXiv:1805.09279v1quant-ph

TL;DR

Near-term hybrid quantum computing faces software-tooling, portability, and workflow challenges alongside noise and remote-access constraints. This paper presents XACC as a hardware- and language-agnostic framework and illustrates its use in nuclear-physics computations. The demonstrations include portable programming across QPUs and automated readout-error mitigation, while the compilation workflow’s tightly coupled layers remain a challenge.

  • Problem

    Near-term hybrid quantum applications lack broadly understood software tooling and portable workflows, while access models and proprietary QPU programming stacks constrain use across platforms.

    Source: §I · p. 1, C. Portability · p. 4

  • Method

    The paper presents XACC, a hardware- and language-agnostic quantum compilation and execution framework with extensible workflows for programming and error mitigation.

    Source: §I · p. 1, B. XACC and Error Mitigation · p. 6

  • Results

    Using XACC, a Quil nuclear-physics program was portable to IBM and simulators, and an IR preprocessor enabled readout-error mitigation in the deuteron-energy computation.

    Source: A. Nuclear Binding Energy · pp. 7–8

  • Takeaways & Limitations

    The authors present XACC as a generalized approach to quantum programming alongside specialized vendor stacks, with close hardware-software co-design still required.

    Source: §VI · p. 8

    Compilation layers are tightly coupled, and operations across preprocessors, optimizers, and transformations may not commute or remain valid after earlier IR changes.

    Source: E. Quantum Compilation Workflow · p. 5

Abstract

from arXiv · show

Recent computations involving quantum processing units (QPUs) have demonstrated a series of challenges inherent to hybrid classical-quantum programming, compilation, execution, and verification and validation. Despite considerable progress, system-level noise, limited low-level instructions sets, remote access models, and an overall lack of portability and classical integration presents near-term programming challenges that must be overcome in order to enable reliable scientific quantum computing and support robust hardware benchmarking. In this work, we draw on our experience in programming QPUs to identify common concerns and challenges, and detail best practices for mitigating these challenge within the current hybrid classical-quantum computing paradigm. Following this discussion, we introduce the XACC quantum compilation and execution framework as a hardware and language agnostic solution that addresses many of these hybrid programming challenges. XACC supports extensible methodologies for managing a variety of programming, compilation, and execution concerns across the increasingly diverse set of QPUs. We use recent nuclear physics simulations to illustrate how the framework mitigates programming, compilation, and execution challenges and manages the complex workflow present in QPU-enhanced scientific applications. Finally, we codify the resulting hybrid scientific computing workflow in order to identify key areas requiring future improvement.

I. INTRODUCTION

Near-term QPU applications face noise, access, portability, and software-tooling challenges despite promising scientific demonstrations. The paper examines hybrid computing systems and presents XACC as a hardware- and language-agnostic framework for addressing these challenges.

I. INTRODUCTION

  • Near-term QPU demonstrations have varied success and limited simulation accuracy, while remote execution can require months of work for a computation a classical computer performs in microseconds,,,.One remote variational hybrid computation achieved 3 percent simulation accuracy.Source: §I · p. 1
  • XACC provides a hardware- and language-agnostic framework and model workflow intended to improve access to near-term quantum computing for scientific applications.The paper discusses hybrid-programming challenges and best practices, then illustrates XACC with nuclear-physics applications.Source: §I · p. 1

II. HYBRID COMPUTING SYSTEMS

  • Hybrid computing systems integrate conventional classical and quantum machine models, whose computational powers are not equivalent.The paper specializes its discussion to classical Turing machines programming and controlling quantum Turing machines.Source: §II · p. 2
  • Classical-to-quantum control requires an interface that transmits and receives physical fields between the two systems.The paper describes the shared language in terms of fields that define operations issued by the conventional model and implemented in the quantum domain.Source: Figure 1 · p. 2, §II · p. 2
  • The central programming concern is controllability: how accurately quantum instructions are realized and how precisely results reflect their intended effects.This concern applies to the conventional and quantum machines in the hybrid system.Source: §II · p. 2

A. Client-Server Model for Hybrid Computing Systems

Most hybrid systems use a networked CPU-client and QPU-server model. The server parses incoming instructions and translates them into control fields for the quantum register, then returns a digital response.

A. Client-Server Model for Hybrid Computing Systems

  • The server’s execution units apply shaped and scheduled fields to the quantum register, whose response fields are collected and converted into binary representations of its state.The control fields drive an addressable array of quantum physical subsystems.Source: A. Client-Server Model for Hybrid… · p. 2
  • In the client-server model, the QPU acts as a layer of language parsers translating client Boolean logic into control fields for the quantum register.The server partitions this work between a control unit, execution units, and the register itself.Source: A. Client-Server Model for Hybrid… · p. 2
  • Most hybrid systems use a CPU-based client that interacts over a network with a QPU-based server presenting a classical control interface.The interface can be customized to a variety of programming styles.Source: Figure 2 · p. 2
  • The QPU server parses client instructions into a local representation that generates the requested sequence of control fields.Its conventional CPUs can parse digital instructions and detect and discriminate response fields.Source: Figure 2 · p. 2, A. Client-Server Model for Hybrid… · p. 2

B. Programming and Execution Model

The QPU programming model separates client-selected instructions from server-side execution, but noise and restricted access limit reliable circuit execution. Proprietary instruction sets and tightly coupled workflows also hinder portability, verification, and benchmarking.

B. Programming and Execution Model

  • The client selects instructions from a predefined QPU instruction set, whose ISA defines the QPU’s functionality and control-unit language.Instructions are transmitted as character strings and mapped by the server to pre-compiled functions that trigger execution units.Source: B. Programming and Execution Model · pp. 2–3
  • The server’s control unit, execution units, and quantum register separate instruction logic from field generation, but this architecture still poses programming challenges for noisy processors.The ISA carries the program logic, while execution units translate instructions into fields applied to the register.Source: Figure 3 · p. 3, B. Programming and Execution Model · p. 3

III. PROGRAMMING CHALLENGES FOR NOISY QPUS

  • Near-term QPUs have substantial noise that limits reliable circuit depth, while client-server access models hamper the repeated sampling needed for noisy circuits.The cited systems had register capacities up to 20 addressable elements.Source: §III · p. 3
  • Vendor-specific frameworks tied to proprietary instruction sets require users to retool code for each QPU, impeding portability.These barriers also hinder software verification, hardware benchmarking, and numerical-simulation validation.Source: §III · p. 3

A. Gate Noise and Execution Errors

Gate noise and state-preparation and measurement errors divert execution from intended outcomes. The paper describes why these errors are difficult to characterize and mitigate within current programming models.

A. Gate Noise and Execution Errors

  • For pure states, quantum state fidelity is the squared magnitude of the inner product between observed and expected register states, and noisy gates yield fidelity below unity.A corresponding fidelity measure for mixed states can be defined using trace distance.Source: A. Gate Noise and Execution Errors · p. 3
  • Gate noise diverts the computational state from the intended algorithm, and current hardware cannot rely on quantum error correction or fault-tolerant gate protocols.Programs may instead use repeated execution for sampling or redesign compiled circuits to mitigate known errors.Source: A. Gate Noise and Execution Errors · p. 3
  • Noise characterization currently falls largely outside the programming workflow, making manual analysis increasingly untenable as circuit complexity grows.The paper identifies a lack of device-aware programming models for automating circuit rewriting against noisy gates.Source: A. Gate Noise and Execution Errors · p. 3
  • State-preparation and measurement errors can misinitialize or misread register states, and reported SPAM error rates approach an order of magnitude above typical gate errors.The passage notes that SPAM errors dominate QPU performance across multiple technologies.Source: A. Gate Noise and Execution Errors · p. 4
  • SPAM mitigation may require many executions and accurate error characterization, while cross-talk can invalidate calibration assumptions and larger registers make inline calibration intractable.Repeated sampling can decode results using maximum-likelihood statistics, but adds execution complexity.Source: A. Gate Noise and Execution Errors · p. 4

B. Access Models

Remote access and platform-specific programming frameworks constrain near-term hybrid applications: iterative QPU workflows incur communication and queue overhead, while nonportable code complicates comparative testing and validation.

B. Access Models

  • Remote QPU access commonly uses REST APIs, job queues, or web portals for manual or batch-style program execution.Source: B. Access Models · p. 4
  • Remote access supports small-scale executions, but iterative hybrid algorithms are impractical because network calls, parsing, and queue latency add overhead.Source: B. Access Models · p. 4
  • QPU job queues schedule individual serial executions rather than complete applications, leaving related circuits uncollated and slowing variational sampling.Source: B. Access Models · p. 4

C. Portability

  • Vendor-specific programming frameworks require users to retool for each QPU, slowing productivity and potentially impeding adoption of new software or hardware.Source: C. Portability · p. 4
  • Nonportable code complicates software verification, hardware benchmarking, and validation against numerical simulations; noise and errors also undermine application testability.Source: C. Portability · p. 4

D. Classical-Quantum Integration

Classical-quantum integration remains limited despite available quantum languages, while quantum compilation requires coupled processing layers that translate programs for hardware and account for post-execution analysis.

D. Classical-Quantum Integration

  • Remote access and limited code portability leave QPU resources poorly integrated with conventional workflows, although integration is needed to develop and test hybrid algorithms.Source: D. Classical-Quantum Integration · p. 4
  • Quantum languages often target programmers versed in quantum logic, while embedding them in host languages can obscure functionality, device behavior, and information flow.Source: D. Classical-Quantum Integration · pp. 4–5

E. Quantum Compilation Workflow

  • Quantum compilation includes register allocation, instruction scheduling and layout, and noisy-QPU pre- and post-processing to prepare programs for hardware and address errors.Source: E. Quantum Compilation Workflow · p. 5
  • The workflow parses quantum code into an IR, preprocesses and optimizes it, transforms it for hardware topology, maps it to machine instructions, and may post-process results.Source: E. Quantum Compilation Workflow · p. 5, Figure 4 · p. 5
  • Compilation layers should be tightly coupled through a common IR, but multiple noncommuting passes can change the IR so later preprocessing becomes invalid.Source: E. Quantum Compilation Workflow · p. 5

IV. XACC

XACC provides a hybrid classical-quantum programming model with language- and hardware-agnostic abstractions. Its intermediate representation supports portability across quantum models and integration into classical workflows.

IV. XACC

  • XACC provides a high-level API for classical applications to offload quantum kernels to accelerators independently of quantum language or hardware.Source: §IV · p. 5
  • Its abstractions include quantum kernels, an intermediate representation, compilers, and accelerators, with extensions for preprocessing and post-processing.Source: §IV · pp. 5–6
  • XACC supports Scaffold, Quil, and domain-specific fermionic Hamiltonian languages, along with Rigetti and IBM systems and the D-Wave annealer.Source: §IV · p. 6
  • XACC aims to integrate near-term quantum architectures into existing classical workflows and support benchmarking, verification, and profiling across QPU types.Source: §IV · p. 6

A. XACC and Portability

  • XACC's polymorphic IR can map code across languages and hardware models; user-specified transformations can insert swap gates for differing qubit connectivity.Source: A. XACC and Portability · p. 6

B. XACC and Error Mitigation

XACC supports extensible error-mitigation workflows and access models, and its compilation pipeline preprocesses, optimizes, transforms, and maps quantum programs before execution and post-processing.

B. XACC and Error Mitigation

  • XACC readout mitigation adds kernels that estimate per-qubit bit-flip probabilities, then uses them to shift and scale observable estimates after execution.Source: B. XACC and Error Mitigation · p. 6
  • The pre- and post-processing interfaces can support other error-mitigation schemes that modify quantum IR and process QPU measurement results.Source: B. XACC and Error Mitigation · p. 6

C. XACC and Access Models

  • XACC offers C++-based access with Python bindings and a client-server model for remote REST-based or locally hosted QPU access.Source: C. XACC and Access Models · p. 6

D. XACC Compilation Workflow

  • The compilation pipeline accepts quantum kernels, produces IR, and can apply requested preprocessors, including readout mitigation or logical-to-physical qubit mapping.Source: D. XACC Compilation Workflow · pp. 6–7
  • XACC then optimizes and transforms IR for hardware constraints, maps it to low-level instructions, executes it, and passes returned bit strings to queued post-processors.Source: D. XACC Compilation Workflow · p. 7

V. APPLICATION EXAMPLES

This section reviews a recent XACC application that used VQE to compute a quantum system’s minimal-energy state. The example illustrates hardware-agnostic implementation across layers of the quantum compilation workflow.

V. APPLICATION EXAMPLES

  • The reviewed XACC example implemented the layers of a quantum compilation workflow in a hardware-agnostic manner.It used the variational quantum eigensolver (VQE) algorithm.Source: §V · p. 7
  • VQE uses variational principles to find the minimal-energy quantum state under a given Hamiltonian.Source: §V · p. 7
  • Even short-depth circuits can address interesting application scenarios with VQE.Source: §V · p. 7

A. Nuclear Binding Energy

The deuteron binding-energy computation used XACC to program and target multiple QPUs, with compiler-assisted mitigation of readout errors. The example also exposed remote execution queues as a practical hindrance.

A. Nuclear Binding Energy

  • XACC enabled hardware-agnostic deuteron VQE targeting of IBM and Rigetti QPUs, while remote execution queues hindered the work.The authors identify local access models using application job queues as a needed alternative to individual QPU execution queues.Source: A. Nuclear Binding Energy · p. 7
  • The deuteron calculation used a pionless effective field theory in a discrete variable representation with a harmonic-oscillator basis, considering cutoffs N = 2 and 3.The section discusses the N = 2 case for brevity.Source: A. Nuclear Binding Energy · p. 7
  • For the N = 2 Hamiltonian, measurements followed a single-parameter unitary coupled-cluster circuit, while a classical nonlinear optimizer varied θ until convergence.Source: A. Nuclear Binding Energy · p. 7
  • The Quil-language XACC kernels were immediately portable to IBM and multiple simulators.The passage identifies this portability as overcoming a challenge for near-term quantum programming and computation.Source: A. Nuclear Binding Energy · p. 7
  • Readout-error mitigation compares energy across variational parameters with and without correction.The figure presents the deuteron N = 2 Hamiltonian; the XACC preprocessor appends calibration measurements and postprocesses observable expectation values.Source: Figure 5 · p. 8, A. Nuclear Binding Energy · p. 8

VI. CONCLUSION

The conclusion identifies developer obstacles in remote hybrid computing and positions XACC as a hardware-agnostic framework for interoperability and local QPU access. It also stresses continued hardware-software co-design.

VI. CONCLUSION

  • Noisy hybrid systems accessed through client-server models present challenges involving device information, portability, tool integration, validation, and workflow development.Source: §VI · p. 8
  • XACC offers interoperable program and tool development and support for local-QPU client-server access models as a generalized, hardware-agnostic approach.Source: §VI · p. 8
  • The authors expect specialized vendor stacks and generalized approaches both to support ecosystem growth, alongside continued hardware-software co-design for noise and execution errors.Source: §VI · p. 8

Related papers

Loading 1805.09279v1…