PaperlayerView exact revision on arXiv

Source-linked AI summary

Cross-Backend QIEO: Universal Runtime Portability across OpenMP5, CUDA, HIP, and Multi-Language Interfaces

Aman Mittal, Ferdin Sagai Don Bosco, Kasturi Venkata Srikanth, Abhishek Singh, Aditya Singh, Abhishek Chopra

arXiv:2609.30914v1cs.DCcs.CLmath.OC

TL;DR

Quantum-inspired optimization lacks a unified framework combining performance with hardware portability. Cross-Backend QIEO uses one C++ algorithm with target-specific backends and shared language bindings; reported results include consistent solution quality and substantial GPU speedups.

  • Problem

    QIEO population evaluation and updates involve dense trigonometric operations that scale quadratically with dimensionality, while prior GPU QIEO work lacked a unified multi-backend abstraction.

    Source: A. Quantum-Inspired Evolutionary… · p. 2

  • Method

    The framework uses one QIEO algorithmic source with CPU, OpenMP 5, CUDA, and HIP specializations and thin Python, MATLAB, and Julia bindings.

    Source: §I · p. 2

  • Results

    Solution quality matched across backends and language interfaces within <10^-12 rounding tolerance; geometric mean speedups were 66× on NVIDIA A100 and 58× on AMD MI300X.

    Source: §VI · p. 10, §VII · p. 10

  • Takeaways & Limitations

    Practitioners can use high-level language APIs with results identical to the underlying HPC-optimized solver across the demonstrated application domains.

    Source: §VI · p. 10

Abstract

from arXiv · show

Quantum-inspired algorithms emulate quantum mechanical principles, such as, superposition, interference, and probabilistic amplitude evolution, on classical hardware by representing candidate solutions as qubit vectors and evolving them through rotation-gate operators. This approach offers higher optimization performance without physical qubits, and has been shown to achieve order-of-magnitude speedups (10--80$\times$) over traditional solvers on combinatorial, high-dimensional NP-hard problems. A critical barrier to adoption, however, is the lack of a unified execution framework that delivers both algorithmic performance and hardware portability. We present \textbf{Cross-Backend Quantum Inspired Evolutionary Optimizer (QIEO)}, the runtime core of BQP's BQPhy solver, which addresses this gap through a \emph{single-source-of-truth} architecture. One C++ implementation of the QIEO algorithm is compiled once per hardware target and exposed to multiple high-level languages via thin binding layers. The framework dispatches to CPU (sequential), OpenMP~5 (multi-core), CUDA (NVIDIA), and HIP (AMD) backends at runtime, adapting kernels to each device's memory hierarchy and warp/wavefront execution model. The framework's real-world utility is validated through binding demonstrations that share the identical C++ runtime. BQPhy's Python library is demonstrated on a neural network hyperparameter optimisation achieving 88.60\% test accuracy on MNIST. BQPhy's MATLAB's Toolkit is tested on wind farm layout optimisation attaining $365\,399 \pm 4\,552$~MWh/yr, which is statistically indistinguishable from particle swarm optimisation and $+7.6\%$ above genetic algorithms on a 32-variable constrained engineering problem. The Julia package tackles the Lotka--Volterra parameter estimation where BQPhy replaces native Julia solvers on the same residual, cutting mean SSE by $2.1\times$.

I. INTRODUCTION

Cross-Backend QIEO addresses the challenge of running quantum-inspired optimization efficiently across heterogeneous hardware without maintaining separate algorithm implementations. It combines one QIEO algorithmic source with target-specific native execution and shared language bindings.

I. INTRODUCTION

  • Heterogeneous systems require practitioners to navigate distinct OpenMP, CUDA, and HIP models, often maintaining vendor-specific codebases that erode portability and maintainability.These platforms differ in execution models, memory hierarchies, and concurrency primitives.Source: §I · p. 1
  • One QIEO source supports CPU, OpenMP 5, CUDA, and HIP, with hardware-specific kernels and shared Python, MATLAB, and Julia bindings.The paper also reports up to 72× speedup over sequential baselines and application demonstrations using the identical C++ runtime.Source: §I · p. 2

A. Quantum-Inspired Evolutionary Algorithms

  • QIEAs represent solutions with qubits and update them with rotation gates; population evaluation and updates involve dense trigonometric operations that scale quadratically with problem dimensionality.This computational cost motivates hardware acceleration, while recent GPU QIEO work lacked a unified multi-backend abstraction [25].Source: A. Quantum-Inspired Evolutionary… · p. 2

B. Portability–Performance Trade-off

  • Native CUDA and HIP kernels permit architecture-specific performance engineering but require equivalent QIEO phases to be independently implemented and maintained for each vendor.General performance-portability frameworks abstract execution and memory, but may trade away some native-API performance.Source: B. Portability–Performance Trade-off · p. 2
  • Cross-Backend QIEO specifies QIEO once while instantiating native OpenMP, CUDA, and HIP kernels, avoiding both replicated algorithms and an intervening portability runtime.It aims to retain performance at the vendor-kernel boundary while keeping the algorithmic specification and dispatch interface portable.Source: B. Portability–Performance Trade-off · p. 2

C. Multi-Language Integration

The framework connects established language-binding mechanisms to a shared C++ QIEO runtime. Its computational model represents candidates with qubit amplitudes, samples classical solutions, and updates those amplitudes through rotation-based optimization steps.

C. Multi-Language Integration

  • The framework adopts pybind11, MATLAB MEX, and CxxWrap as thin facades over one C++ QIEO runtime, linking the same compiled library from each binding.Existing binding mechanisms address language integration, while the shared runtime connects that integration with hardware portability.Source: C. Multi-Language Integration · p. 3

A. Computational Model

  • Each candidate is represented by n qubits with normalized amplitude pairs, and the population is stored as a matrix whose rows hold one individual’s amplitudes.The amplitude for observing bit value 1 is |β_k|², giving a continuous representation of the solution space.Source: A. Computational Model · p. 3, 1) State Representation · p. 3

1) State Representation:

  • Measurement collapses qubits into classical bit strings by sampling each bit, a step parallel across individuals and bit positions and suited to GPU acceleration.The probability of sampling 1 is the squared magnitude of the corresponding β amplitude.Source: 1) State Representation · p. 3

2) Core Operators:

  • QIP updates qubit amplitudes with rotation gates, while CIP evaluates fitness, identifies the best individual, and computes the next rotation angles from comparisons with that individual.A controller adaptively scales step sizes to balance exploration and exploitation; the full three-phase loop is summarized in prior work.Source: 2) Core Operators · p. 3

B. System Design Objectives

Cross-Backend QIEO separates the algorithm from hardware-specific execution and exposes the shared runtime through a consistent set of language interfaces. Users configure, run, and retrieve results through the same workflow across supported environments.

1) Performance Portability:

  • The Hardware Abstraction Layer (HAL) selects the highest-ranked backend with a compiled specialization, separating algorithmic phases from execution targets through compile-time policies.Each backend specializes the measure_population, evaluate_fitness, and update_qubits kernel templates.Source: 1) Performance Portability · p. 3
  • CPU kernels provide a sequential correctness reference, OpenMP distributes individuals across threads, and CUDA/HIP map each individual to a GPU thread block.CUDA/HIP use shared memory to cache the best individual’s bit-string and avoid redundant global-memory accesses.Source: 1) Performance Portability · p. 3

2) Algorithm–Architecture Co-Design:

  • QIEO’s algorithmic phases are implemented once, while the HAL supplies hardware-specific specializations for the supported execution modes.The design separates QIP, CIP, and fitness evaluation from target-specific kernels.Source: 2) Algorithm–Architecture Co-Design · p. 3

3) Multi-Language Accessibility via Single Source of Truth:

  • One canonical C++ implementation serves Python, MATLAB, and Julia through thin wrappers, preserving algorithmic consistency and avoiding per-language re-implementation.Figure 1 depicts the layered architecture in which the implementation is compiled per hardware target and shared across bindings.Source: 3) Multi-Language Accessibility via… · p. 3, Figure 1 · p. 4

C. Usage

  • Across languages, users create an optimizer, configure its population, dimensions, bounds, and generation limit, define an objective, select a backend, then retrieve the best design and fitness.The bindings follow a unified interface contract and the same five-step workflow.Source: C. Usage · pp. 3–4

IV. BENCHMARK STUDIES

The benchmark studies cover binary, continuous, and antenna-array optimization across CPU and GPU backends, alongside a Python MNIST hyperparameter-optimization demonstration. They report backend speedups and describe the search methods and mixed-type search space used in the Python study.

IV. BENCHMARK STUDIES

  • The benchmark suite covers 0/1 Knapsack at n={128, 512, 2048}, Rastrigin and Rosenbrock at d={50, 200, 1000}, and an industrial antenna-array synthesis problem.Platforms were an Intel Xeon Gold 6338, NVIDIA A100-SXM4 80 GB, and AMD MI300X.Source: §IV · p. 4
  • 66.1× geometric mean speedup over the sequential baseline was achieved by CUDA; the Rastrigin-200 case reached 72.1×, while HIP reached 87.6% of CPU throughput and OpenMP averaged 13.6×.The benchmarks used population size P = 10,000 and 1,000 generations.Source: §IV · p. 4, Table IV · p. 5

A. BQPhy Python library: Neural Network Hyperparameter Optimisation

  • Table V identifies a hyperparameter search space for MNIST optimization.Source: Table V · p. 5

1) Hyperparameter Optimisation Baselines:

  • The comparison includes Ray Tune, Optuna, and Grid Search; Grid Search exhaustively covers its discrete grid but is intractable for continuous or high-dimensional spaces and does not adapt to results.Optuna uses a TPE sampler with trial pruning and is described as suited to small per-evaluation budgets.Source: 1) Hyperparameter Optimisation Baselines · p. 5

2) Experimental Setup:

The MNIST study compares BQPhy with three baselines under variable and equal evaluation budgets, then examines accuracy, runtime, search choices, and binding behavior. At 240 evaluations, BQPhy is much faster than Ray Tune and is close to Optuna’s accuracy with less wall time.

2) Experimental Setup:

3) Phase 1 — Variable-Budget Results:

  • 87.60% accuracy was achieved by Ray Tune versus 87.40% for BQPhy, but Ray Tune took 4.46× longer overall and 17.24 s per evaluation; Optuna and Grid Search reached 86.40% and 87.00%.The variable-budget comparison used 240 BQPhy evaluations and 12 for each baseline; Table VI reports the results.Source: 3) Phase 1 — Variable-Budget Results · pp. 5–6, Table VI · p. 6

4) Phase 2 — Iso-Budget Results (240 Evaluations):

  • Grid Search exhausted its discrete grid at 216 evaluations (3×2×4×3×3), short of the 240-evaluation target.The passage attributes this shortfall to exhaustive enumeration’s exponential scaling limitation.Source: 4) Phase 2 — Iso-Budget Results (240… · p. 6
  • All methods selected one hidden layer and LeakyReLU; BQPhy chose dropout δ = 0.011 versus Optuna’s δ = 0.398, while Grid Search omitted LeakyReLU from its predefined choices.The passage identifies the accuracy difference between BQPhy and Optuna as 0.60 pp and says it warrants further investigation.Source: 4) Phase 2 — Iso-Budget Results (240… · p. 6
  • Python-generated configurations and fitness traces matched direct C++ invocation to < 10^-12 precision, with no algorithmic side-effects from the pybind11 layer.Averaged over five runs, Python binding overhead was 0.9%; the passage says the 45.05 s runtime was dominated by MNIST training computation.Source: 4) Phase 2 — Iso-Budget Results (240… · p. 6
  • Under the 240-evaluation budget, Optuna led accuracy at 89.20%, followed by BQPhy at 88.60%, Grid Search at 87.60%, and Ray Tune at 87.20%.BQPhy improved by +1.20 pp from its variable-budget result, while Ray Tune declined by −0.40 pp.Source: 4) Phase 2 — Iso-Budget Results (240… · p. 6, Table VII · p. 7
  • 119.6× speedup over Ray Tune came with +1.40 pp higher accuracy; against Optuna, BQPhy’s 88.60% was 0.60 pp lower but took 1.41× less wall time (45.05 s vs. 63.30 s).Table VIII reports iso-budget efficiency metrics.Source: 4) Phase 2 — Iso-Budget Results (240… · p. 6, Table VIII · p. 7

B. BQPhy MATLAB Toolkit: Wind Farm Layout Optimisation

The MATLAB toolkit applies BQPhy to wind-farm layout optimization, maximizing annual energy production under turbine-spacing constraints. Its formulation models wake losses and competing wind directions in a constrained, multimodal search.

B. BQPhy MATLAB Toolkit: Wind Farm Layout Optimisation

  • The benchmark places 16 turbines in a 1000 × 1000 m domain, optimizing 32 coordinate variables to maximize annual energy production.The study uses 20 independent runs with 100 individuals and 500 generations (50,000 function evaluations per solver).Source: 1) Problem Formulation · p. 7, 2) Benchmark Methodology · p. 7

1) Problem Formulation:

  • The Jensen wake model represents upstream turbine effects through velocity deficits, with multiple wakes combined by the sum-of-squares rule.The thrust coefficient is 0.88 and the wake expansion rate is 0.075.Source: 1) Problem Formulation · p. 7
  • A 12-sector wind rose combines a Rayleigh wind-speed distribution with opposing dominant westerlies and easterlies, creating competing directional wake effects.The wind-speed distribution has a mean of 8.5 m/s and is discretized into 20 bins.Source: 1) Problem Formulation · p. 7, Table IX · p. 7
  • Layouts must keep every turbine at least 252 m apart; a quadratic penalty is added to the objective, and feasible solutions minimize negative AEP.The penalty weight is 10.Source: 1) Problem Formulation · p. 7

2) Benchmark Methodology:

Across 20 equal-budget runs, BQPhy and PSO achieve statistically indistinguishable mean annual energy production and both outperform GA. BQPhy overtakes PSO during convergence and finds the highest single-run AEP, while the MATLAB binding is evaluated as a drop-in optimizer.

2) Benchmark Methodology:

  • The comparison uses BQPhy, MATLAB Global Optimization Toolbox GA, and PSO with the same objective and population or swarm size.It averages runtime over 20 trials and excludes MEX-loading latency.Source: 2) Benchmark Methodology · p. 7

3) Results and Analysis:

  • BQPhy overtakes PSO by generation 150 and maintains a modest advantage through generation 500, while GA converges slowest and varies most across restarts.PSO converges fastest in the first 30 generations; BQPhy initially spends about 50 generations in the spacing-penalty region before finding feasible layouts.Source: 3) Results and Analysis · pp. 7–8, Figure 4 · p. 8
  • BQPhy achieved 365 399 ± 4 552 MWh/yr versus PSO’s 367 259 ± 3 647 MWh/yr; their means were statistically indistinguishable, while BQPhy and PSO exceeded GA by 7.6% and 8.1%.BQPhy’s peak was 374 659 MWh/yr; GA averaged 339 673 ± 28 529 MWh/yr and had severe outlier runs.Source: Figure 5 · p. 8, 3) Results and Analysis · p. 8
  • The best layouts differ visibly: BQPhy spreads turbines irregularly across the domain, PSO is grid-like, and GA shows clustering near spacing limits.BQPhy’s staggered positions are described as reducing wake overlap across the competing wind sectors.Source: 3) Results and Analysis · p. 8
  • The MATLAB MEX binding is tested as a drop-in optimizer without workflow modification, and its quantum rotation gate maintains population diversity for the multi-directional wake landscape.The discussion contrasts this sampling breadth with PSO’s contraction around a global-best attractor.Source: 3) Results and Analysis · p. 8

C. BQPhy Julia library: Lotka–Volterra Calibration in Julia

The Julia library exposes the shared C++ QIEO runtime through a drop-in Julia API that accepts native residuals. Its Lotka–Volterra demonstration estimates four rate coefficients from a single noisy trajectory.

C. BQPhy Julia library: Lotka–Volterra Calibration in Julia

  • The Julia binding wraps one shared C++ library with CxxWrap and forwards a native Julia residual into the runtime rather than providing a Julia-specific QIEO rewrite.The high-level module is BQPhy_Optimiser.Source: C. BQPhy Julia library: Lotka–Volterra… · p. 8

1) Problem Formulation:

  • The calibration recovers the four Lotka–Volterra rate coefficients α, β, δ, and γ from a single noisy trajectory.The true coefficients are (1.0, 0.1, 0.075, 1.5), with observations generated over t ∈ [0, 20] using a fixed-step RK4 integrator and Gaussian noise with σ = 0.35.Source: 1) Problem Formulation · pp. 8–9
  • The decision vector uses z = log10 θ, and a restart counts as successful when parameter RMSE is below 0.08.The residual objective’s noise floor is approximately 26.3 for perfect parameter recovery.Source: 1) Problem Formulation · p. 9

2) Native Julia Baselines:

The Julia study compares BQPhy with native Julia optimizers on the same residual under an equal evaluation budget. BQPhy halves NelderMead’s mean SSE at the same success rate, while BlackBoxOptim leads on mean SSE, RMSE, and success rate.

2) Native Julia Baselines:

  • The comparison set comprises Optim.NelderMead, Optim.ParticleSwarm, BlackBoxOptim differential evolution, and CMA-ES; BQPhy is positioned against the solvers Julia users already use.No solver receives gradient information, and the RK4 residual is the sole oracle.Source: 2) Native Julia Baselines · p. 9

3) Experimental Setup:

  • The iso-budget study runs 10 restarts with 2,000 residual evaluations each, using a 25-member QIEO population and 80 generations.Timing includes optimizer overhead after compilation, but recovery reliability—not wall-clock time—is the primary metric because residual evaluation is cheap.Source: 3) Experimental Setup · p. 9

4) Results:

  • BlackBoxOptim records the best mean SSE, RMSE, and success rate at 50%, while Optim.ParticleSwarm has the best median SSE at 1,487.BQPhy’s best restart reaches SSE 381; the figures show BQPhy and Julia population methods in the lower SSE band and BlackBoxOptim as the most consistent parameter recovery.Source: Figure 7 · p. 9, Figure 8 · p. 9, 4) Results · p. 10
  • BQPhy and NelderMead each succeed on 20% of restarts, but BQPhy halves mean SSE to 8,223 versus 17,506 and cuts median SSE by 5.4×.NelderMead reaches the noise floor on two restarts but exceeds SSE 21,000 on the other eight.Source: 4) Results · pp. 9–10, Table X · p. 10
  • The Julia binding passes the same native RK4 residual to every method and translates only the population matrix and fitness vector; the tested library uses the CPU HAL.Mean runtime after compilation is below 0.3 seconds across solvers, so the adoption comparison concerns recovery reliability and API uniformity rather than kernel speedup.Source: 4) Results · p. 10

VI. RESULTS AND DISCUSSIONS

Cross-Backend QIEO reports consistent results across backends and language interfaces, with hardware speedups and application demonstrations in Python, MATLAB, and Julia. The conclusion also identifies future extensions to the hardware abstraction layer and optimization approach.

VI. RESULTS AND DISCUSSIONS

  • Solution quality at convergence was identical across backends and language interfaces to within floating-point rounding tolerance (< 10^-12).The paper attributes this consistency to all interfaces executing the same algorithm.Source: §VI · p. 10

VII. CONCLUSION

  • 66× geometric mean speedup on NVIDIA A100 and 58× on AMD MI300X accompany Python and MATLAB interface overhead below 1.2%.The Julia path uses the same shared library through CxxWrap.Source: §VII · p. 10
  • 365 399 ± 4 552 MWh/yr on the 16-turbine wind farm benchmark was statistically indistinguishable from particle swarm optimization and 7.6% above genetic algorithms.The result used a 12-direction wind rose and Jensen wake model; solution variance was six-fold lower.Source: §VII · p. 10
  • At a 2,000-evaluation iso-budget, BQPhy’s mean residual SSE was 8,223 versus 17,506 for NelderMead, while remaining in Optim.ParticleSwarm’s quality band.BlackBoxOptim retained the best mean among native Julia global solvers.Source: §VII · p. 11
  • The Python, MATLAB, and Julia demonstrations use the same C++ runtime, exposing a language-agnostic interface without per-domain adaptation.The Julia package substitutes for the default Optim.NelderMead workflow rather than providing a second QIEO implementation.Source: §VII · p. 11
  • Future work will add Intel oneAPI/SYCL targets, tensor-network state representations, and Bayesian optimization for tuning rotation step sizes.Source: §VII · p. 11
  • The appendix drivers invoke the identical C++ runtime for a four-variable Rastrigin objective; only host-language syntax differs.The stated bounds are [-5.12, 5.12] in C++ and Python and [-5, 5] in the MATLAB demo.Source: Appendix A · p. 11

APPENDIX B APPLICATION DRIVERS: HPO (PYTHON), WIND FARM

The appendix identifies the language-specific drivers used for the paper’s three application demonstrations.

APPENDIX B APPLICATION DRIVERS: HPO (PYTHON), WIND FARM

Related papers

Loading 2609.30914v1…