Noise-adaptive compiler mapping for NISQ devices

Short answer: A noise-adaptive compiler chooses which physical qubits run a program using the device's latest calibration data. A 2019 ASPLOS paper proposes such mappings for NISQ machines and reports, on real IBM hardware, an average 2.9x improvement in program success rate over the baseline it compares against, and up to 18x in some cases. This is a research result from one group, tested on small devices.

The Challenge of NISQ Resource Constraints

At the time of the 2019 paper, quantum computing prototypes faced a significant gap between their available scale and the requirements of many proposed algorithms. These implementations are prone to noise and variability, which negatively affect their reliability. The authors say that with fewer than 80 qubits total, such systems are too resource-constrained to implement error correction. The term Noisy Intermediate-Scale Quantum (NISQ) refers, in the authors' definition, to current and near-term systems of 1000 qubits or less.

The authors argue that, given the severe resource constraints, low reliability, and high variability in physical characteristics such as coherence time or error rates, it is important to map computations onto these systems efficiently. The goal is to maximize the likelihood of successful runs. Without adaptive mapping, the inherent variability in hardware parameters makes reliable execution difficult. The proposed techniques address this by optimizing how computations are placed on the physical hardware to mitigate these specific reliability issues.

Compiler Architecture and Intermediate Representation

The proposed techniques start from an LLVM intermediate representation of the quantum program. This representation is generated from high-level quantum computing languages, such as Scaffold. The compiler framework then generates quantum computing executables that are runnable on the IBM Q public quantum computing machine. This architecture allows the compiler to operate on a standardized intermediate form before targeting specific hardware.

The framework implements and evaluates several optimal and heuristic mapping methods. These methods vary in how they account for the availability of dynamic machine calibration data. They also differ in the relative importance assigned to various noise parameters. Additionally, the methods explore different possible routing strategies. Finally, they balance the relative importance of compile-time scalability versus runtime success. This flexibility allows the compiler to adapt to different operational constraints and hardware states.

Exploiting Dynamic Calibration Data

The approach utilizes real-system measurements to demonstrate the effectiveness of the mapping strategies. Fine-grained spatial and temporal variations in hardware parameters can be exploited to improve performance. By accounting for dynamic machine calibration data, the compiler can adjust its mapping decisions based on the current state of the hardware. This is critical because noise parameters are not static; they vary over time and across different physical locations on the device.

The evaluation shows that these adaptive techniques yield significant improvements in program success rates. Specifically, the authors report an average 2.9x improvement over what they call the industry standard, and up to 18x in some cases. The authors read this as showing that ignoring dynamic calibration data gives worse mappings. Conversely, leveraging this data allows the compiler to route operations through less noisy regions or times, thereby increasing the probability of a successful execution.

Distinction from Error Correction

The proposed mapping methods are distinct from error correction techniques. The paper says NISQ systems with fewer than 80 qubits are too resource-constrained to implement error correction. Therefore, the compiler must rely on mapping strategies that maximize reliability without the overhead of full error correction codes. The focus is on using resources efficiently within the existing constraints.

The variability in physical characteristics, such as coherence time or error rates, necessitates this adaptive approach. Static mappings cannot account for the high variability present in NISQ devices. By optimizing the placement of operations based on real-time or recent calibration data, the compiler addresses the low reliability inherent in these systems. This approach is essential for making computations executable with high reliability on diverse hardware characteristics.

FAQ

What is the definition of NISQ?

In the paper, NISQ refers to current and near-term systems of 1000 qubits or less. These systems are characterized by severe resource constraints, low reliability, and high variability in physical characteristics like coherence time. They are prone to noise that affects execution reliability.

How does the compiler handle hardware variability?

The compiler uses dynamic machine calibration data to account for spatial and temporal variations in hardware parameters. It employs optimal and heuristic mapping methods that adjust routing strategies based on the relative importance of various noise parameters to maximize runtime success.

What performance improvements were observed?

The authors report, from real-system measurements, an average 2.9x improvement in program success rate over the industry standard. In specific cases, the improvement reached up to 18x. These gains result from exploiting fine-grained variations in hardware parameters through adaptive mapping.

Does the system implement error correction?

No. The paper's methods do not implement error correction. The authors say implementations with fewer than 80 qubits are too resource-constrained for error correction. Instead, the compiler focuses on mapping computations to use resources efficiently and maximize the likelihood of successful runs without correction overhead.

What intermediate representation is used?

The techniques start from an LLVM intermediate representation of the quantum program. This representation is typically generated from high-level quantum computing languages like Scaffold. The compiler then generates executables runnable on the IBM Q public quantum computing machine from this intermediate form.