Source-linked AI summary
Full-Stack, Real-System Quantum Computer Studies: Architectural Comparisons and Design Insights
Prakash Murali, Norbert Matthias Linke, Margaret Martonosi, Ali Javadi Abhari, Nhung Hong Nguyen, Cinthia Huerta Alderete
TL;DR
QC lacks a settled device technology, while current platforms differ in gates, connectivity, and noise, creating a need for cross-technology evidence. The paper builds TriQ, a portable full-stack compiler and evaluates it on seven real systems from three vendors. The study finds that device-specific gates and noise-aware compilation improve performance and reliability, although limited connectivity cannot be fully overcome.
Problem
QC prototypes use divergent technologies with different gates, topologies, and noise, leaving cross-technology hardware–software design questions unresolved.
Method
TriQ compiles high-level programs through device-specific optimizations for seven real QC platforms from three vendors and two qubit technologies.
Results
TriQ shows that exposing natural device gates and using noise-aware compilation improve QC program performance and success rates across superconducting and trapped-ion systems.
Takeaways & Limitations
QC architecture and compiler design should preserve device-specific information within a portable toolflow rather than force a single uniform abstraction.
Takeaways & Limitations
Limited machine availability and qubit counts prevented some experiments and left placement improvements unable to fully overcome connectivity constraints.
Abstract
from arXiv · showhide
In recent years, Quantum Computing (QC) has progressed to the point where small working prototypes are available for use. Termed Noisy Intermediate-Scale Quantum (NISQ) computers, these prototypes are too small for large benchmarks or even for Quantum Error Correction, but they do have sufficient resources to run small benchmarks, particularly if compiled with optimizations to make use of scarce qubits and limited operation counts and coherence times. QC has not yet, however, settled on a particular preferred device implementation technology, and indeed different NISQ prototypes implement qubits with very different physical approaches and therefore widely-varying device and machine characteristics. Our work performs a full-stack, benchmark-driven hardware-software analysis of QC systems. We evaluate QC architectural possibilities, software-visible gates, and software optimizations to tackle fundamental design questions about gate set choices, communication topology, the factors affecting benchmark performance and compiler optimizations. In order to answer key cross-technology and cross-platform design questions, our work has built the first top-to-bottom toolflow to target different qubit device technologies, including superconducting and trapped ion qubits which are the current QC front-runners. We use our toolflow, TriQ, to conduct {\em real-system} measurements on 7 running QC prototypes from 3 different groups, IBM, Rigetti, and University of Maryland. From these real-system experiences at QC's hardware-software interface, we make observations about native and software-visible gates for different QC technologies, communication topologies, and the value of noise-aware compilation even on lower-noise platforms. This is the largest cross-platform real-system QC study performed thus far; its results have the potential to inform both QC device and compiler design going forward.
1 INTRODUCTION
Quantum-computing prototypes span distinct technologies with different gates, topologies, and noise characteristics, motivating cross-platform hardware–software study. TriQ evaluates these differences on seven real systems and shows that device-specific compilation improves performance and reliability without sacrificing portability.
- Motivation: Current QC prototypes have not converged on one device technology, with superconducting and trapped-ion systems differing in gates, connectivity, and noise.These physical differences create distinct software and architectural design points.
- Approach: TriQ provides a full-stack toolflow that compiles high-level programs into device-specific code for seven platforms from three vendors and two qubit technologies.The flow incorporates gate sets, communication topologies, and empirical error data.
- Study scope: The study compares QC systems across vendors and technologies to inform architecture and compiler design without selecting a single winning technology.The authors frame the comparison as an early design study rather than a technology ranking.
- Architectural insights: Making natural device gates software-visible avoids runtime and error overheads and enables additional single-qubit compile-time optimizations.The study specifically identifies abstracting trapped-ion XX gates into CNOTs as costly for NISQ systems.
- Results: TriQ achieves portability without a performance or reliability tradeoff, outperforming vendor compilers across IBM and Rigetti systems and improving UMD ion-trap success rates by up to 1.47x.Reported gains include geomean 3x on IBM, geomean 1.45x on Rigetti, and up to 1.47x on UMDTI.
2 QC BACKGROUND
Quantum computers encode information in qubits whose states can be manipulated with quantum gates and read out classically. NISQ systems use diverse technologies and remain constrained by limited scale, coherence, and operation accuracy.
- Qubits: A qubit is the fundamental information unit, with basis states |0⟩ and |1⟩ and superposition states represented as α |0⟩+β |1⟩.Measurement collapses the qubit state to a classical |0⟩ or |1⟩ outcome.
- Program execution: Quantum programs map algorithms to gates on initialized qubits, evolve their amplitudes, and measure them to produce classical output.The execution flow proceeds from initialization through gate operations to readout.
- Quantum gates: Quantum gates are physical operations on one or more qubits, and universal systems compose complex operations from single-qubit and two-qubit gates.Gates are implemented through physical interactions such as microwave or laser pulses.
- Single-qubit operations: Single-qubit operations act as rotations such as Rx(θ), Ry(φ), and Rz(λ), while composite gates include X, Hadamard, and Z.The Hadamard gate generates superposition in the described representation.
- Two-qubit operations: Two-qubit operations generate entanglement and non-classical correlations; CNOT flips its target when the control is |1⟩.Entanglement can make the state space grow exponentially with qubit count.
- NISQ systems: NISQ systems typically have fewer than 500–1000 qubits, cannot generally implement quantum error correction, and require coherence and precise operations for useful computation.The background describes superconducting, trapped-ion, and other qubit technologies.
3 DEVICE, ARCHITECTURE TRADEOFFS
QC platforms differ substantially in native gates, software-visible operations, connectivity, and noise, motivating cross-technology measurements and device-tailored compilation.
- Native Gate Choices: IBM and Rigetti use superconducting qubits, while UMD uses trapped ions with distinct native two-qubit interactions.
- Native Gate Choices: Software-visible operations may expose native gates or composite gates, raising whether unified interfaces or device-tailored operations better support performance and reliability.
- Noise Characteristics: IBMQ14 two-qubit error rates average 7.95% and vary 9x across qubits and days.
- Communication Characteristics: IBM and Rigetti require routing for non-adjacent two-qubit operations, whereas ion traps can provide full connectivity without physical adjacency.
- Cross-Technology Study: The study uses TriQ to measure how gates, communication topologies, and noise affect applications on seven implementations using superconducting and trapped-ion technologies.
- Noise Characteristics: Across IBM and Rigetti systems, two-qubit and readout error rates vary up to 9x across qubits and calibration cycles.
4 DESIGN AND OVERVIEW OF TRIQ
TriQ is a multi-target compiler that combines device-specific inputs with common analyses to map high-level programs onto heterogeneous quantum systems while optimizing reliability and communication.
- Overview: TriQ exposes device-specific qubit counts, connectivity, native gates, and noise characteristics throughout a common compiler flow.
- Overview: Scaffold programs and inputs are lowered to LLVM IR containing one- and two-qubit gates before mapping, optimization, and device-specific code generation.
- Reliability Matrix Computation: TriQ constructs an end-to-end two-qubit reliability matrix that includes communication routing between hardware qubits.
- Reliability Matrix Computation: Noise-aware mapping uses measured gate reliabilities, while noise-unaware mapping assigns every edge the system-average error rate.
- Qubit Mapping: The mapper maximizes the minimum reliability of mapped operations, enabling arbitrary topologies and earlier pruning than product-based reliability objectives.
- Qubit Mapping: TriQ’s routing method improves program success likelihood by up to 50% on IBMQ16 while retaining acceptable success rates and greater scalability than prior mapping work.
- Gate Implementation, Optimization and Code Generation: TriQ decomposes operations into device-visible gates, handles directed IBM CNOTs, and optimizes continuous single-qubit rotation sequences.
5 EXPERIMENTAL SETUP
The evaluation uses established NISQ benchmarks and scaling circuits across seven operational machines, comparing compiler configurations under calibration-aware experimental conditions.
- Benchmarks: The benchmark suite includes Bernstein-Vazirani, Hidden Shift, Quantum Fourier Transform, adder, Toffoli, and Fredkin programs.
- Benchmarks: Supremacy circuits are reserved for scaling studies and reach 72 qubits, 2032 two-qubit gates, and depth 128.
- Compilers: The study compares TriQ-N, TriQ-1QOpt, TriQ-1QOptC, and TriQ-1QOptCN, progressively adding gate-set, communication, topology, and noise-aware optimizations.
- Real-System Experiments: Experiments run on seven operational machines from IBM, Rigetti, and UMD, spanning superconducting and trapped-ion systems.
- Experimental Constraints: Machine time and availability constrained compiler configurations, and several machines lacked enough qubits for BV6, BV8, and HS6.
- Experimental Procedure: Experiments recompiled benchmarks with the latest calibration data and used 8192 trials for IBM and Rigetti versus 5000 for UMDTI.
6 RESULTS
The evaluation shows that device-specific gate sets, communication topology, and noise-aware placement strongly affect operation counts and success rates across real quantum systems.
- 6.1 Gate Specificity and Optimizations: 1.4x, 1.4x, and 1.6x geomean reductions in 1Q operation count occur on IBMQ14, Rigetti, and UMDTI, respectively, with up to 1.26x success-rate improvement.TriQ-1QOpt exploits native gates and error-free Z rotations.
- 6.1 Gate Specificity and Optimizations: UMDTI’s software-visible arbitrary Rx,yθ,φ rotation gate compresses long single-qubit sequences into one low-error operation.
- 6.2 Importance of Qubit Connectivity: 22x fewer 2Q operations on IBMQ14 and 3.5x fewer on Rigetti result from topology-aware communication optimization.The reductions are up to 22x on IBMQ14 and up to 3.5x on Rigetti Agave.
- 6.2 Importance of Qubit Connectivity: Rigetti’s line topology requires more 2Q operations than IBMQ14’s grid, although good placements mitigate but do not eliminate the difference.
- 6.3 Importance of Noise-Adaptivity: TriQ-1QOptCN succeeds on all 12 benchmarks, reaches up to 28x improvement over Qiskit, and achieves up to 2.3x over Quil.The corresponding geomean improvements are 3.0x over Qiskit and 1.45x over Quil.
- 6.3 Importance of Noise-Adaptivity: Noise-adaptive compilation improves UMDTI success rates by up to 1.47x despite its low error rates and fully connected topology.The experiment adapts to 1–3% error-rate fluctuations in ion-trap control.
- 6.4 Cross-System Comparison: Application-device topology matching improves success: IBMQ5’s triangular topology favors 3-qubit triangle benchmarks, while IBMQ16’s grid does not.
7 ARCHITECTURE IMPLICATIONS
The architectural implications are that software-visible native gates and noise-aware, topology-aware compilation are central to reliable NISQ execution across diverse devices.
- Cross-system performance: Success rates vary widely across systems because of error rates, qubit connectivity, and application-machine topology match.
- Native gates and software-visible operations: Software-visible native gates let compilers optimize programs for underlying devices, often reducing error rates and execution cost.
- Architecture and noise: Communication topology and contiguous low-error regions jointly shape application success, making current noise data important for recompilation.
8 RELATED WORK
Prior work addressed selected compiler or communication problems, whereas this study combines device-specific optimization and noise data in a cross-platform real-system toolflow.
- Prior experimental comparisons: Earlier experimental comparison used four hand-optimized benchmarks on two 5-qubit machines and identified the importance of program-device topology matching.
- Quantum programming frameworks: Existing frameworks target individual systems or provide limited topology support, while TriQ applies common optimization passes across diverse platforms using device characteristics.
- Noise-aware compilation: Prior communication optimizers generally omit noise data; TriQ reports 2X better BV4 success rate than a prior noise-aware result across varying machine conditions.TriQ’s BV4 success rate ranged from 0.43 to 0.51, averaging 0.47.
9 CONCLUSIONS
The diversity of 5–50-qubit NISQ machines creates an opportunity for cross-platform studies linking device technologies, topologies, error rates, and compiler choices.
- 9 CONCLUSIONS: 5–50-qubit prototypes represent widely divergent design points in qubit technologies, topologies, and error rates.
- 9 CONCLUSIONS: This diversity enables studies of how device technologies influence hardware choices and how compilers mitigate difficult hardware characteristics.