Pith. sign in

REVIEW 3 major objections 6 minor 23 references

Introducing CQ: A C-like API for Quantum Accelerated HPC

T0 review · 3 major / 6 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper proposes CQ, a C-like API that offloads quantum kernels from C and Fortran HPC code, and presents a two-thread reference implementation that simulates the offload.

desk verdict CQ is a clear, honest spec-and-reference-design paper for a C/Fortran quantum offload API; the model is untested on real hardware, but the authors say so themselves. read the letter →

arxiv 2508.10854 v1 pith:M3RXODIB submitted 2025-08-14 cs.DC quant-ph

Oliver Thomson Brown , Mateusz Meller , James Richings This is my paper · ORCID
classification cs.DCquant-ph
keywords quantumacceleratedHPCC-likeAPIruntimeoffloadhybridquantum-classicalCandFortrankernelstatevectorsimulationasynchronousexecution
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

CQ is a specification for a C-like API that lets classical HPC programs offload quantum computation to a device at runtime, from C or Fortran, using only standard compilers and runtime libraries. The paper argues that the field lacks programming models with low toolchain complexity that sit inside the existing HPC ecosystem and let the programmer decide exactly when a kernel is offloaded and when results are synchronised back; CQ is designed to fill that gap. The companion reference implementation, CQ-SimBE, simulates the host and the quantum device as two threads in one process, using a statevector simulator as the quantum device, and shows the API working on a quantum Fourier transform. The paper's claim is that this provides a practical route to incremental quantisation of existing HPC codes, in the style of GPU offload, before dedicated quantum hardware is widely available.

What carries the argument

The executor family plus the host/device control channel it drives. Sixteen `*_qrun` functions whose prefix letters `s`, `a`, `m`, `b`, `p` encode whether offload blocks or overlaps with the host, runs once or many times, uses a chosen backend, and carries a parameter pack; the result buffer and the opaque execution handle define the classical data-movement contract. An opaque `qubit` handle additionally gives register access with C pointer semantics inside a kernel. In the reference implementation, the host pushes integer opcodes onto a device-side FIFO queue and a registry of function pointers simulates remote procedure calls, so these functions are the actual offload plumbing the specific

What would settle it

Attempt to run a synchronous `s_qrun` call from a C program against a currently available cloud-hosted quantum device that exposes only a vendor SDK. If the device cannot accept and execute a user-compiled C binary as its control program, and instead requires circuit submission through the vendor's API, the hardware model fails and CQ would need a translation layer to survive; the two-thread simulation in the paper does not exercise this condition.

Watch

Extended reading notes

Core claim

The paper's central claim: a quantum-accelerated HPC programming model should be a low-toolchain, compiled-language interface inside the existing HPC ecosystem, with the programmer deciding when a quantum kernel is offloaded and when classical results return. CQ is that interface — kernels are ordinary C-callable functions, allocation happens on the host, and an executor family covers synchronous/asynchronous, single/multi-shot, default/selected backend, parameterised or not. The reference implementation, CQ-SimBE, simulates host and device as two threads in one process, using a statevector simulator as the device, with a FIFO control queue and kernel-registration map standing in for remote

Load-bearing premise

The load-bearing premise is that a real quantum accelerator will have an on-device classical processor that can run user-compiled C binaries and a classical connection to the host; if accelerators only respond through vendor cloud APIs, CQ's offload model cannot be implemented as written.

Editorial extensions

If this is right

  • A C or Fortran HPC program can add quantum kernels at runtime without switching to an interpreted language or adding a new toolchain.
  • The synchronous and asynchronous executors allow host and device work to overlap, the same latency-hiding pattern that classical accelerator offload relies on.
  • Single-call multi-shot and parameterised executors cover the structure of variational and combinatorial hybrid algorithms, so those loops do not need to be re-implemented per shot.
  • Because the specification stays minimal and the kernel interface is just a function-pointer contract, backend vendors can extend it — the analogue pulse/channel module is one such extension — without breaking the core API.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The on-device classical co-processor in the hardware model is the assumption most likely to collide with reality: current quantum accelerators are usually accessed through vendor SDKs over a network, and if they cannot run a user-compiled C binary, CQ's offload semantics need a translation layer; the two-thread simulator intentionally does not test this.
  • The split between synchronised and device-local measurements hints at a specific latency-hiding technique, but the paper does not measure its benefit; a timing comparison of synchronous versus asynchronous executors on the same kernel would quantify the overhead saved.
  • The experimental analogue module suggests that one offload API could span gate-based and pulsed (annealing/Hamiltonian-simulation) devices; if it matures into the specification, the same executor contract would cover both modalities.
  • A useful next experiment would be to run the reference implementation with the host and device separated by a message-passing layer (the paper lists this as future work) to measure how the control queue and result-buffer contract behave under realistic data-movement costs.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents CQ, a specification for a C-like API for offloading quantum kernels from classical HPC codes to quantum accelerators, together with CQ-SimBE, a reference implementation written in C99 on top of the QuEST statevector simulator. The specification defines an assumed hardware model (a classical host plus a device containing both quantum hardware and a classical co-processor), APIs for qubit/register allocation, quantum kernels, synchronous/asynchronous and multi-shot executors, and a separate analogue-computing interface. The reference implementation simulates the host/device split using two POSIX threads and a shared-memory FIFO, and includes an experimental Fortran host-side interface. The demonstration is a 10-qubit QFT example run for 10 shots. The paper states that a real-hardware interface is future work.

Significance. If the hardware model is ultimately realized, the API addresses a genuine gap: a low-toolchain, statically typed, compiler-friendly offload interface with explicit host/device synchronization, in contrast to the Python-centric, loosely coupled frameworks that dominate the field. The open-source, MIT-licensed repositories, the clean separation between specification and simulated backend, and the inclusion of an analogue-pulse extension are concrete strengths that make the artifact usable by the community. However, the current contribution is a design plus a simulator, not a validated system on real hardware; the evidence is therefore prospective rather than demonstrated. The paper is a useful systems contribution to the quantum-HPC programming-model discussion, but its claims need to be aligned with the evidence presented.

major comments (3)
  1. [§2.1, §3, §5] The hardware model requires the quantum device to include a classical co-processor that can run user-compiled binaries. CQ-SimBE implements host and device as two POSIX threads in one shared-memory process (§3), and §5 states that a CQ-compliant interface to real quantum hardware is future work. Thus the paper does not demonstrate that its kernel-registration, function-pointer-based qrun executors, and measure/dmeasure synchronization semantics can be realized on current or near-term quantum accelerators, many of which are accessed through host-side vendor SDKs. This is load-bearing for the §1.1 claim that CQ fills a gap in programming models for quantum-accelerated HPC. I recommend either softening the claim to a simulation-validated design or providing an argument/evidence that at least one hardware platform can support the assumed model.
  2. [§4] The only correctness evidence for the reference implementation is the 'similar to' shot output of a 10-qubit QFT initialized to |0...0>. No verification is shown that the output distribution matches the expected uniform superposition over the 2^10 computational basis states, nor is a statevector overlap, chi-squared test, or comparison against direct QuEST output reported. Since CQ-SimBE is presented as a reference implementation, the paper should include a reproducible, machine-checked verification that the API plumbing preserves the intended quantum circuit. Without this, the displayed output does not establish correctness of the implementation.
  3. [§3.1] The Fortran interface is limited to invoking C-defined kernels and does not allow defining kernels in Fortran, which is more restrictive than the abstract and §1.1 suggest when they advertise runtime offloading from Fortran. Moreover, the provided binding example 'function zero_init_full_qft() bind(C)' has no arguments, while the actual C kernel has four parameters (NQUBITS, qreg, creg, registration). As written, this is not an interoperable interface for that C function and would not correctly support passing the function pointer via c_funloc. The section needs a corrected, compilable example and an explicit statement of the Fortran scope.
minor comments (6)
  1. [Abstract, §1.1] The phrase 'strictly and strongly typed' is imprecise for C, which is statically typed but not strongly typed in the usual sense. Consider using 'statically typed' or clarifying the intended meaning.
  2. [§2.1, Fig. 1 caption] The caption says CQ 'does not specify what it means to run a quantum circuit on the device,' but the specification does define measurement and gate interfaces. Clarify that it leaves execution semantics (e.g., compilation, scheduling, error handling) implementation-defined.
  3. [§2.3] There is a typo: 'The opaquecstate type' should read 'The opaque cstate type.'
  4. [§4] The text says the output is 'similar to' the listed shots. For reproducibility, consider fixing the random seed or reporting exact output from a deterministic run.
  5. [§3.1] The Fortran example uses 'endfunction'; standard Fortran spelling is 'end function'. Also, the interface block shown would need to match the C kernel signature for interop; please correct.
  6. [§5.1] The planned 'cq-emulation module' is introduced only as future work; a sentence distinguishing 'simulation' (classical emulation of quantum dynamics) from 'emulation' (SDK-level interface compatibility) earlier in the paper would improve clarity.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: CQ is a spec/implementation artifact with no fitted prediction or self-referential derivation.

full rationale

This paper is an API specification plus a reference implementation. There is no fitted parameter, no numerical prediction, and no equation that reduces to an input. The central claim is that CQ provides an offload interface; it is supported by the open-source CQ-SimBE implementation and an example QFT run, not by citing the authors' own conclusions. The self-citations present — the CQ repositories [4,5], the analogue-computing review [16], and QuEST v4 [10] (which lists one of the authors) — are either pointers to the artifact under discussion or to independent software/review material; none is invoked as a uniqueness theorem or as a substitute for the demonstration. The hardware model of Section 2.1 is an explicit assumption, and Section 5 acknowledges real-hardware support is future work; this is an unvalidated assumption (a correctness/feasibility risk) but not circular because the paper does not define CQ's success in terms of that assumption. No step in the paper is equivalent to its own input by construction.

Assumptions & free parameters 0 free parameters · 4 assumptions · 3 invented entities

No numerical fitting appears in the paper; the load-bearing inputs are modeling assumptions about future quantum hardware and the fidelity of the two-thread simulator rather than fitted constants.

assumptions (4)
  • domain assumption Device classical co-processor can run compiled binaries and has a classical data connection to host.
    Section 2.1 hardware model; the entire offload design depends on the device hosting a standard CPU. If real QPUs only expose cloud SDKs, this model fails.
  • domain assumption Qubits allocated are logical; noise and error correction are out of scope.
    Section 2.2 states 'CQ does not currently have any conception of noise or error correction.' This limits applicability to NISQ-era hardware.
  • domain assumption A device is exclusively controlled by one kernel at a time.
    Section 2.1 states 'only one quantum kernel may run at once on any specific device.' Simplifies resource management but may not match future multi-tenant hardware.
  • ad hoc to paper CQ-SimBE's two-thread shared-memory model faithfully represents intended host-device offload.
    Section 3 states the implementation uses two POSIX threads and local function pointers, and that MPI support is expected but not implemented; the remote-binary assumption is therefore unvalidated.
invented entities (3)
  • qubit opaque handle (registry_index, offset, N) independent evidence
    purpose: Track device-side quantum resources and support pointer indexing within kernels.
    Defined in CQ-SimBE (Section 3) and visible in the public repo, giving an external handle for testing.
  • struct exec execution handle independent evidence
    purpose: Manage asynchronous offload with sync/wait/halt semantics.
    Part of the public CQ-SimBE code; can be exercised by running the async examples.
  • cq-analog pulse and channel abstractions independent evidence
    purpose: Express analogue quantum operations (pulses, waveforms, channel targeting) for annealing and Hamiltonian simulation.
    Implemented in the public cq-analog module with waveform library (Section 3.2); falsifiable via the repo's MAXCUT analogue example.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Introducing CQ: A C-like API for Quantum Accelerated HPC." pith.science (2026). https://pith.science/paper/M3RXODIB

@misc{pith2026250810854,
  author       = {Pith},
  title        = {Pith review of: Introducing CQ: A C-like API for Quantum Accelerated HPC},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/M3RXODIB}},
  note         = {Machine review of arXiv:2508.10854}
}
read the original abstract

In this paper we present CQ, a specification for a C-like API for quantum accelerated HPC, as well as CQ-SimBE, a reference implementation of CQ written in C99, and built on top of the statevector simulator QuEST. CQ focuses on enabling the incremental integration of quantum computing into classical HPC codes by supporting runtime offloading from languages such as C and Fortran. It provides a way of describing and offloading quantum computations which is compatible with strictly and strongly typed compiled languages, and gives the programmer fine-grained control over classical data movement. The CQ Simulated Backend (CQ-SimBE) provides both a way to demonstrate the usage and utility of CQ, and a space to experiment with new features such as support for analogue quantum computing. Both the CQ specification and CQ-SimBE are open-source, and available in public repositories.

Figures

Figures reproduced from arXiv: 2508.10854 by the authors.

Figure 1
Figure 1. The hardware model assumed by CQ. A classical [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 9 canonical work pages

  1. [1]

    R Au-Yeung, B Camino, O Rathore, and V Kendon. 2024. Quantum algorithms for scientific computing. Reports on Progress in Physics 87, 11 (10 2024), 116001. doi:10.1088/1361-6633/ad85f0

    doi:10.1088/1361-6633/ad85f0 2024

  2. [2]

    Sohaib Alam, Guillermo Alonso-Linaje, B

    Ville Bergholm, Josh Izaac, Maria Schuld, Christian Gogolin, Shahnawaz Ahmed, Vishnu Ajith, M. Sohaib Alam, Guillermo Alonso-Linaje, B. AkashNarayanan, Ali Asadi, Juan Miguel Arrazola, Utkarsh Azad, Sam Banning, Carsten Blank, Thomas R Bromley, Benjamin A. Cordier, Jack Ceroni, Alain Delgado, Olivia Di Matteo, Amintor Dusko, Tanya Garg, Diego Guala, Antho...

    arXiv 2022

  3. [3]

    Britt, Fahd A

    Keith A. Britt, Fahd A. Mohiyaddin, and Travis S. Humble. 2017. Quantum Ac- celerators for High-Performance Computing Systems. In 2017 IEEE International Conference on Rebooting Computing (ICRC) . IEEE, Washington, DC, USA, 1–7. doi:10.1109/ICRC.2017.8123664

    work page arXiv 2017

  4. [4]

    Oliver Thomson Brown. 2024. CQ. https://github.com/EPCCed/cq-spec

    work page 2024

  5. [5]

    Oliver Thomson Brown, Mateusz Meller, and James Richings. 2025. CQ Simulated Backend. https://github.com/EPCCed/cq-simbe

    work page 2025

  6. [6]

    Will Cunningham, Alejandro Esquivel, Casey Jao, Faiyaz Hasan, Venkat Bala, Sankalp Sanand, Prasanna Venkatesh, Madhur Tandon, Okechukwu Emmanuel Ochia, Andrew S. Rosen, dwelsch esi, jkanem, Aravind, HaimHorowitzAgnostiq, Ruihao Li, Scott Wyman Neagle, valkostadinov, Ara Ghukasyan, Poojith U Rao, Sayandip Dutta, WingCode, Anna Hughes, RaviPsiog, Udayan, Ak...

    work page doi:10.5281/zenodo.8369670 2023

  7. [7]

    Aniello Esposito and Utz-Uwe Haus. 2025. SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows. arXiv:2506.03846 [cs.DC] https://arxiv. org/abs/2506.03846

    arXiv 2025

  8. [8]

    Wood, Jake Lishman, Julien Gacon, Simon Martiel, Paul D

    Ali Javadi-Abhari, Matthew Treinish, Kevin Krsulich, Christopher J. Wood, Jake Lishman, Julien Gacon, Simon Martiel, Paul D. Nation, Lev S. Bishop, Andrew W. Cross, Blake R. Johnson, and Jay M. Gambetta. 2024. Quantum computing with Qiskit. arXiv:2405.08810 [quant-ph] doi:10.48550/arXiv.2405.08810

    arXiv doi:10.48550/arxiv.2405.08810 2024

Show all 23 references
  1. [9]

    Benjamin

    Tyson Jones, Anna Brown, Ian Bush, and Simon C. Benjamin. 2019. QuEST and High Performance Simulation of Quantum Computers. Scientific Reports 9, 10736 (2019). https://doi.org/10.1038/s41598-019-47174-9

    2019 doi

  2. [10]

    Benjamin

    Tyson Jones, Oliver Thomson Brown, Erich Essmann, Ali Rezaei, Richard Meister, Balint Koczor, and Simon C. Benjamin. 2025. QuEST v4. https://github.com/ QuEST-Kit/QuEST

    2025

  3. [11]

    Mike Karlesky, Mark VanderVoord, and Greg Williams. 2025. Unity Test. https: //github.com/ThrowTheSwitch/Unity

    2025

  4. [13]

    Jin-Sung Kim, Alex McCaskey, Bettina Heim, Manish Modani, Sam Stanwyck, and Timothy Costa. 2023. CUDA Quantum: The Platform for Integrated Quantum- Classical Computing. In 2023 60th ACM/IEEE Design Automation Conference (DAC). ACM/IEEE, San Francisco, CA, USA, 1–4. doi:10.1109...

    2023

  5. [14]

    Joseph K. L. Lee, Oliver T. Brown, Mark Bull, Martin Ruefenacht, Johannes Doerfert, Michael Klemm, and Martin Schulz. 2023. Quantum Task Offloading with the OpenMP API. arXiv:2311.03210 [cs.DC] https://arxiv.org/abs/2311.03210

    2023 arXiv

  6. [15]

    Alexander J McCaskey, Dmitry I Lyakh, Eugene F Dumitrescu, Sarah S Powers, and Travis S Humble. 2020. XACC: a system-level software infrastructure for heterogeneous quantum–classical computing. Quantum Science and Technology 5, 2 (feb 2020), 024002. doi:10.1088/2058-9565/ab6bf6

    2020 doi

  7. [16]

    Mateusz Meller, Vendel Szeremi, and Oliver Thomson Brown. 2025. Programming tools for Analogue Quantum Computing in the High-Performance Computing Context – A Review. arXiv:2501.16943 [quant-ph] https://arxiv.org/abs/2501. 16943

    2025

  8. [17]

    Grace Johnson, Oded Wertheim, Matthew Otten, Navid Anjum Aadit, Kirk M

    Masoud Mohseni, Artur Scherer, K. Grace Johnson, Oded Wertheim, Matthew Otten, Navid Anjum Aadit, Kirk M. Bresniker, Kerem Y. Camsari, Barbara Chap- man, Soumitra Chatterjee, Gebremedhin A. Dagnew, Aniello Esposito, Farah Fahim, Marco Fiorentino, Abdullah Khalid, Xiangzhou Kon...

    2024 arXiv

  9. [18]

    OpenQASM Contributors. 2025. OpenQASM Standard Library. https://openqasm. com/language/standard_library.html#standard-library

    2025

  10. [19]

    Adrian Parra-Rodriguez, Pavel Lougovski, Lucas Lamata, Enrique Solano, and Mikel Sanz. 2020. Digital-analog quantum computation. Phys. Rev. A 101 (Feb 2020), 022305. Issue 2. doi:10.1103/PhysRevA.101.022305

    2020 doi

  11. [20]

    Martin Schulz, Laura Schulz, Martin Ruefenacht, and Robert Wille. 2023. Towards the Munich Quantum Software Stack: Enabling Efficient Access and Tool Support for Quantum Computers . In 2023 IEEE International Conference on Quantum Computing and Engineering (QCE) . IEEE Compute...

    2023

  12. [21]

    Amir Shehata, Peter Groszkowski, Thomas Naughton, Muralikrishnan Gopalakr- ishnan Meena, Elaine Wong, Daniel Claudino, Rafael Ferreira da Silva, and Thomas Beck. 2026. Bridging paradigms: Designing for HPC-Quantum conver- gence. Future Generation Computer Systems 174 (2026), 1...

    2026

  13. [22]

    Seyon Sivarajah, Silas Dilkes, Alexander Cowtan, Will Simmons, Alec Edgington, and Ross Duncan. 2020. t|ket⟩: a retargetable compiler for NISQ devices. Quan- tum Science and Technology 6, 1 (nov 2020), 014003. doi:10.1088/2058-9565/ab8e92

    2020 doi

  14. [23]

    Seyon Sivarajah, Lukas Heidemann, Alan Lawrence, and Ross Duncan. 2022. Tierkreis: a Dataflow Framework for Hybrid Quantum-Classical Computing. In 2022 IEEE/ACM Third International Workshop on Quantum Computing Software (QCS). IEEE/ACM, Dallas, TX, USA, 12–21. doi:10.1109/QCS5...

    2022

  15. [24]

    Robert Wille, Ludwig Schmid, Yannick Stade, Jorge Echavarria, Martin Schulz, Laura Schulz, and Lukas Burgholzer. 2024. QDMI – Quantum Device Manage- ment Interface: A Standardized Interface for Quantum Computing Platforms. In IEEE International Conference on Quantum Computing ...

    2024

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.