PaperlayerView exact revision on arXiv

Source-linked AI summary

XACC: A System-Level Software Infrastructure for Heterogeneous Quantum-Classical Computing

Alexander J. McCaskey, Dmitry I. Lyakh, Eugene F. Dumitrescu, Sarah S. Powers, Travis S. Humble

arXiv:1911.02452v1quant-phcs.PL

TL;DR

Existing quantum software largely targets high-level remote APIs, while scaling architectures require lower-level infrastructure for tighter quantum–classical integration. XACC addresses this gap with a modular, service-oriented, hardware-agnostic framework for programming, compilation, and execution, demonstrated through representative quantum-classical applications.

  • Problem

    Quantum computing’s increasing integration with classical systems requires lower-level software infrastructure beyond predominantly high-level frameworks targeting remote REST APIs.

  • Method

    XACC provides a modular, service-oriented, hardware-agnostic framework exposing interfaces for quantum programming, compilation, execution, and extensible device integration.

  • Results

    XACC demonstrates a layered architecture connecting high-level kernels to low-level hardware through a polymorphic intermediate representation and supports representative hybrid quantum-classical applications.

  • Takeaways & Limitations

    XACC provides a foundation for compilers, runtimes, tools, and benchmarks that integrate quantum and classical workflows across quantum hardware models.

Abstract

from arXiv · show

Quantum programming techniques and software have advanced significantly over the past five years, with a majority focusing on high-level language frameworks targeting remote REST library APIs. As quantum computing architectures advance and become more widely available, lower-level, system software infrastructures will be needed to enable tighter, co-processor programming and access models. Here we present XACC, a system-level software infrastructure for quantum-classical computing that promotes a service-oriented architecture to expose interfaces for core quantum programming, compilation, and execution tasks. We detail XACC's interfaces, their interactions, and its implementation as a hardware-agnostic framework for both near-term and future quantum-classical architectures. We provide concrete examples demonstrating the utility of this framework with paradigmatic tasks. Our approach lays the foundation for the development of compilers, associated runtimes, and low-level system tools tightly integrating quantum and classical workflows.

I. INTRODUCTION

XACC addresses the need for lower-level infrastructure as quantum processors become more tightly integrated with classical systems. It provides a hardware-agnostic, modular framework for quantum programming, compilation, and execution.

  • Motivation: As QPUs scale, tighter CPU–QPU integration requires system software, compilers, and tools beyond interpreted remote-access workflows.The paper identifies scheduling, memory management, device-driver execution, benchmarking, profiling, and debugging as important system-level capabilities.
  • Contribution: XACC provides a low-level, hardware-agnostic framework for programming, compiling, and executing quantum-accelerated programs across multiple back-ends.Its service-oriented architecture supports a plug-and-play quantum programming, compilation, and execution workflow.
  • Design goals: XACC manages QPUs as co-processors, off-loading selected classically intractable kernels and returning results for continued classical computation.Its accelerator back-end defines common operations and communication protocols for abstract quantum computers.
  • Design goals: XACC exposes low-level CPU–QPU interfaces through a C++ infrastructure extensible to higher-level languages such as Python and Julia.The C++ foundation is intended to support tighter in-process, in-memory device-driver access.
  • Design goals: Hardware agnosticism lets users compose and compile applications for multiple quantum platforms using one common language.The paper links this portability to comparative analyses of commonly defined benchmarks.
  • Design goals: XACC’s service-oriented plugin architecture lets researchers replace hardware, programming, compilation, and error-mitigation components with problem-specific implementations.The architecture is presented as modular and extensible across the workflow.

III. FRAMEWORK ARCHITECTURE

XACC uses a layered architecture in which front-end code is transformed into hardware-agnostic IR and then executed through extensible back-ends. Accelerator buffers connect register allocation, execution, measurements, and metadata across the workflow.

  • Front-end: The front-end translates quantum kernel source strings into IR for middle-layer transformations and analysis.XACC front-ends can support dialects including IBM OpenQASM, Rigetti Quil, and higher-level languages.
  • Middle-end: The middle layer provides a hardware-agnostic IR object model and transformation extension points for synthesis, error mitigation, and correction.The IR generalizes programming approaches across multiple quantum devices.
  • Back-end: The back-end accepts compiled IR and an AcceleratorBuffer, then executes the program on local or remote physical or virtual quantum hardware.Back-ends persist measurement results and can store execution metadata such as readout errors, T1, T2, and expectation values.
  • III. FRAMEWORK ARCHITECTURE: The layered architecture reduces N-language by M-device mapping work to N + M implementations by using IR as the central connector.The front-end produces IR, while the back-end maps IR to hardware-specific instruction sets and controls.
  • Accelerator Buffer: AcceleratorBuffer is a runtime memory object for addressing quantum registers and retaining measurement results and heterogeneous execution metadata.XACC tracks buffer state across host–QPU interactions and supports both remote and local execution models.
  • Accelerator Buffer: Child buffers form an execution-data tree suited to variational methods, with each iteration retaining its own results and metadata.The root buffer is extended as circuits are refined across iterations.

B. Kernels and Compilers

XACC expresses quantum programs as annotated C-like kernels that receive an AcceleratorBuffer and compile into a common intermediate representation. This model supports source-level flexibility while preserving a standard execution interface.

  • Kernels: XACC quantum kernels are C-like functions annotated for compilation, uniquely named, and required to take an AcceleratorBuffer first.Additional parameters may follow the buffer, and the body must use a language supported by an XACC compiler.
  • Kernels: The qalloc(3) utility allocates a three-qubit AcceleratorBuffer that is passed to execution and later queried for measurement results.The example persists execution results and metadata in the buffer.
  • Compilers: XACC compilers map kernel source strings to IR while using the target accelerator to incorporate information such as connectivity and noise models at compile time.Compilers can support languages with different abstraction levels.
  • Kernels: The prototypical XACC kernel example uses XASM as the function-body language.The XACC programming model represents quantum code as standard C-like quantum-kernel functions.

C. Intermediate Representation

XACC’s intermediate representation connects front-end quantum programs to back-end execution through a polymorphic, manipulable model. Its instruction, composite-instruction, and IR interfaces support construction, transformation, optimization, persistence, and hardware-specific compilation.

  • The XACC IR connects front-end programs to back-end native assembly through a polymorphic representation that supports transformation and optimization.It integrates multiple languages with different hardware instruction sets.
  • Instruction, CompositeInstruction, and IR form the three primary interfaces for representing quantum programs across back-ends.Instructions model operations, composites organize them into trees, and IR aggregates composite programs.
  • CompositeInstructions organize concrete instructions as dynamic n-ary trees whose children can be added, removed, replaced, expanded, evaluated, and mapped to graphs.Expansion can generate runtime-dependent children from heterogeneous key-value inputs.
  • IR transformations produce modified IR instances for compilation, optimization, error mitigation, and adaptation to hardware connectivity.The IRProvider further creates instructions, composites, and IR objects without exposing concrete underlying types.
  • The Quil compiler parses source lines into concrete Instructions, places them in a parameterized CompositeInstruction, and stores the result in an IR instance.The example includes X, parameterized Ry, and CNOT instructions.

D. Observable and Observable Transform

XACC represents observables through interfaces that transform unmeasured quantum programs into measured circuits. Observable transformations provide extension points for mappings and symmetry reductions, while examples include Pauli and chemistry observables.

  • XACC supports observable construction from subclasses, including general Pauli observables and more complex chemistry observables.The example retrieves a Pauli observable and initializes it from the string “X0 X1”.
  • The observable concept specifies an observe() operation that appends measurement-basis circuits to an input program.The specification leaves circuit and kernel data structures to implementors.
  • XACC’s Observable interface converts an unmeasured CompositeInstruction into a list of measured CompositeInstructions.The resulting circuits reflect the observable’s algebraic structure and measurement bases.
  • ObservableTransform maps one Observable to another, supporting fermion-to-spin mappings and operator symmetry reductions.Examples include Jordan-Wigner and Bravyi-Kitaev mappings.

E. Accelerator

XACC’s Accelerator interface abstracts local, remote, physical, and virtual quantum back-ends behind a common execution model. Accelerator decorators add pre- and post-processing, enabling extensible execution workflows such as error mitigation, while algorithm services use these back-ends for quantum-classical tasks.

  • Accelerators execute compiled CompositeInstructions on physical or virtual, local or remote quantum back-ends and persist measurement results in an AcceleratorBuffer.They can execute multiple CompositeInstructions together to reduce remote process invocations.
  • Accelerators accept heterogeneous execution options and expose hardware connectivity and hardware-dependent IR transformations for compilation.Options can configure shot counts, remote back-ends, and other execution parameters.
  • Accelerator decorators wrap execution with extensible pre-processing and post-processing of program inputs, measurement results, and metadata.The decorator delegates execution to a concrete Accelerator.
  • Decorator-based post-processing provides an extension point for automated error-mitigation strategies, including qubit measurement readout-error mitigation.The strategy can post-process computed expectation values and related execution data.
  • XACC’s Algorithm interface injects pre-defined quantum-classical algorithms, including variational eigensolvers, reduced-density-matrix generation, and data-driven circuit learning.The interface reduces the need for programmers to implement these algorithms from scratch.

G. Optimizer

XACC exposes optimization as a general service for multivariate functions whose evaluations may invoke quantum back-ends. Its Optimizer interface accepts parameter and gradient data, supports configuration, and has implementations backed by NLOpt and mlpack within a modular service architecture.

  • The Optimizer interface provides a general extension point for optimizing multivariate functions that may call a quantum back-end.Its optimize() method accepts an OptFunction representing the objective evaluation.
  • OptFunction receives current parameters and a mutable gradient vector, then returns the objective value at those parameters.Derivative-free optimizers may ignore the gradient argument.
  • Optimizer implementations expose setOptions() with heterogeneous configuration data and may delegate to NLOpt or mlpack.The extension point is demonstrated through the optimizer example associated with Fig. 13.
  • XACC’s service-oriented design keeps implementations behind interfaces and shared pointers, allowing functionality to change without rebuilding the framework.Runtime registration and loading are supported through CppMicroServices and plugins.

I. Heterogeneous Map

XACC's heterogeneous map supports string-keyed values of arbitrary types in C++14, while its public API initializes services, allocates quantum buffers, retrieves implementations, and compiles enhanced kernel strings into XACC IR.

  • I. Heterogeneous Map: The HeterogeneousMap maps string keys to heterogeneous value types using C++14 static template class members.This provides Python-dict-like behavior in a statically typed C++ system.
  • J. XACC Framework API: XACC initialization loads and registers service plugins, while Finalize tears down the registry and cleans allocated memory.
  • J. XACC Framework API: The public API allocates AcceleratorBuffers through qalloc, with qbit serving as an interchangeable readability typedef.
  • J. XACC Framework API: Named service getters return shared pointers to accelerators, compilers, IR providers, algorithms, transformations, and observables.A templated getService<T>(name:string) call provides a generic alternative.
  • J. XACC Framework API: The qasm() function compiles enhanced kernel strings into XACC IR using compiler, circuit, parameter, and optional qbit metadata.Compiled CompositeInstructions are stored in an internal database and retrieved through getCompiled().

IV. INTERFACE IMPLEMENTATIONS FOR QUANTUM COMPUTING

XACC implements hardware-agnostic quantum interfaces across gate-model and annealing systems, with compilers, remote accelerators, observables, and dynamic instructions connected through extensible IR abstractions.

  • IV. INTERFACE IMPLEMENTATIONS FOR QUANTUM COMPUTING: Gate and Circuit classes implement instruction and composite-instruction abstractions, with QuantumIRProvider hiding concrete types from programmers.Dynamic circuits can expand into concrete gates at runtime using heterogeneous input data.
  • IV. INTERFACE IMPLEMENTATIONS FOR QUANTUM COMPUTING: The XASM compiler maps a dynamic C/C++-style quantum assembly language into XACC IR, while OpenQasm and Quil use vendor grammars.XASM supports runtime instruction plugins, gate parameters, heterogeneous inputs, and simple loops.
  • IV. INTERFACE IMPLEMENTATIONS FOR QUANTUM COMPUTING: XACC supports IBM, Rigetti, D-Wave, and IonQ accelerators alongside simulators through shared accelerator interfaces and remote REST functionality.Physical QPU implementations subclass RemoteAccelerator, which provides common remote-access operations.
  • IV. INTERFACE IMPLEMENTATIONS FOR QUANTUM COMPUTING: PauliOperator and FermionOperator represent algebraic observable terms and support parsing from strings through a shared observable interface.Both expose addition, subtraction, and multiplication operations.
  • IV. INTERFACE IMPLEMENTATIONS FOR QUANTUM COMPUTING: D-Wave support models biases and couplers with annealing instructions and provides an EmbeddingAlgorithm interface for minor-graph embedding.

V. DEMONSTRATION

XACC demonstrations span low-level API usage and program construction, illustrating complete working programs across its abstraction levels.

  • V. DEMONSTRATION: The demonstrations progress from low-level XACC API examples toward higher-level quantum-classical algorithms using custom observables and algorithms.The examples are intended as complete, working programs.
  • V. DEMONSTRATION: A parameterized quantum program can be constructed as XACC IR and evaluated at concrete angles for execution on the TNQVM simulator.

A. Base API

XACC's base API supports initialization, accelerator and buffer management, direct or compiled quantum programs, and higher-level VQE and circuit-learning workflows.

  • A. Base API: XACC's layered API connects program construction, compilation, accelerator execution, and hybrid algorithms through reusable abstractions.The examples include direct IR construction, compiler-based kernels, VQE, and data-driven circuit learning.
  • A. Base API: Direct IR execution evaluates one parameterized CompositeInstruction at concrete variable values without reconstructing the circuit at each value.Accelerator::execute() persists execution results in the supplied buffer.
  • A. Base API: The VQE example combines an Observable, Optimizer, xacc::qasm(), and dynamic exp i theta instructions to compute a three-qubit deuteron ground-state energy.The modeled Hamiltonian includes the terms −2.143304 (X0X1 + Y0Y1), −9.625Z2, and −3.913119 (X1X2 + Y1Y2).
  • A. Base API: The DDCL algorithm trains a parameterized quantum circuit to reproduce a target probability distribution using an optimizer and a selected accelerator.The example requests Jensen-Shannon divergence between circuit and target distributions.
  • A. Base API: A gradient strategy evaluates the parameterized circuit at x + π/2 before executing it on a two-qubit buffer.

VI. DISCUSSION

XACC offers a modular, hardware-agnostic foundation for heterogeneous quantum-classical computing and future software tools.

  • XACC provides a modular, extensible foundation for hardware-agnostic quantum computation across heterogeneous architectures.The framework is intended to support software tools, compilers, and benchmarks for quantum-accelerated computing.
  • Its dual-source co-processor model expresses quantum code as high-level kernels mapped to a polymorphic intermediate representation.The intermediate representation supports low-level optimizations, reductions, and analysis.
  • XACC supports both gate-model and annealing technologies across processors and simulators from IBM, Rigetti, D-Wave, and IonQ.
Loading 1911.02452v1…