Pith. sign in

REVIEW 4 major objections 4 minor 43 references

Toolchain for Faster Iterations in Quantum Software Development

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read The paper reports that a plug-and-play Jupyter kernel offloading quantum-circuit simulation to GPU-equipped Kubernetes clusters gives up to 10x faster execution for 29-qubit QAOA circuits and extends practical range to 29 qubits.

desk verdict A real batch-submission tool for remote GPU simulation, but the Jupyter-kernel framing overclaims: cells are stateless Kubernetes jobs, so the iterative workflow promise is unmet. read the letter →

arxiv 2507.07448 v1 pith:DWF6JDTH submitted 2025-07-10 quant-ph cs.SE

Otso Kinanen , Andrés D. Muñoz-Moller , Vlad Stirbu , Tommi Mikkonen This is my paper · ORCID
classification quant-phcs.SE
keywords quantumsoftwaredevelopmentdeveloperexperienceKubernetesJupyternotebookscircuitsimulationGPUaccelerationiterativeQiskitAer
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

The paper is trying to establish that the real bottleneck in quantum software development is not only raw simulation power but the friction of moving between local and accelerated execution. It presents a custom Jupyter kernel that packages each notebook cell as a Kubernetes job and runs it on a remote GPU-equipped cluster, so the developer never leaves the notebook interface. In benchmarks with QFT, Quantum Volume, and QAOA circuits, the paper reports up to 5x faster circuit execution overall, a 10x speedup for 29-qubit QAOA simulator time, and practical execution of circuits in the 21-to-29-qubit range from a 16 GB CPU-only laptop. If the claims hold, this lowers the barrier to GPU-class simulation and makes rapid iteration on larger circuits possible for developers without a specialized infrastructure background.

What carries the argument

The load-bearing object is a custom Jupyter kernel, named q8s in the paper, which bridges the notebook and a Kubernetes cluster. On each cell execution, the kernel inspects declared dependencies, builds a container image containing the quantum libraries and CUDA runtime, pushes it to a registry, creates a Kubernetes Job and a ConfigMap holding the code, polls until the job completes, collects logs, and returns the result to the notebook. The image is rebuilt only when dependencies change, keeping the per-run overhead close to job scheduling and pod startup. The remote side runs a GPU-accelerated state-vector simulator, Qiskit Aer with cuQuantum and cuStateVec, and the same job mechanism can target quantum hardware by changing the resource request in the job specification.

What would settle it

Reproduce the paper's QFT, Quantum Volume, and QAOA benchmarks on a 16 GB CPU-only laptop against a single-GPU Kubernetes node, measuring wall-clock time from cell run to displayed result; the central claim fails if the 29-qubit QAOA circuit is not several times faster end-to-end on the remote GPU, or if the laptop already completes it within interactive iteration time.

Watch

Extended reading notes

Core claim

The paper claims that execution-platform switching can be made nearly invisible to the developer: with the kernel selected, a local Jupyter cell is executed remotely on a GPU simulator, and returning to local CPU execution is one kernel selection away. Benchmarks against a CPU-only business laptop show that remote execution is slower for small circuits because of network and scheduling overhead but becomes faster once circuits exceed roughly 24 qubits. For 29-qubit QAOA circuits the paper reports a 10x speedup in simulator time, and for the complete cell execution including overhead it reports speedups up to 5x. The same remote setup runs a noisy QAOA benchmark with the FakeAuckland noise model up to 12 qubits, with speedups appearing from about 10 qubits. The underlying claim is that a Kubernetes-backed Jupyter kernel is a practical way to give quantum developers GPU-class simulation without exposing them to cluster complexity.

Load-bearing premise

The claimed speedups and the 21-to-29-qubit range assume the developer starts from a CPU-only business laptop with 16 GB RAM working in a Jupyter notebook; if typical developers already have local GPUs or prefer other editors, the benefit does not transfer.

Editorial extensions

If this is right

  • Developers on CPU-only laptops can iterate on 21-to-29-qubit circuits from a notebook once a GPU-equipped Kubernetes cluster is reachable, without manually configuring CUDA or a GPU simulator.
  • For circuits below roughly 24 qubits, local CPU execution remains the faster default, so the toolchain changes where the developer chooses to execute rather than removing the choice.
  • Because the kernel packages code and dependencies as containers, the same job specification can be pointed at QPU resources by editing the resource limits, which the paper illustrates as a path to covering the whole development lifecycle.
  • Noisy simulation with a realistic backend shows speedups from about 10 qubits, so the benefit appears earlier for noise-aware development than for ideal state-vector simulation.
  • The workflow shifts quantum simulation from batch-style submissions toward an interactive loop, which the paper argues is what iterative software development requires.

Reading between the lines

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

  • An implication the paper leaves implicit: because the kernel rebuilds its container image only when dependencies change, repeated runs of the same cell with different parameters amortize setup cost, so the toolchain is most valuable in exactly the iterative tuning workflow it targets.
  • A testable extension the paper does not undertake is applying the same job mechanism to tensor-network simulators or multi-GPU backends, which would likely move the speedup crossover below 24 qubits or extend the range beyond 29 qubits.
  • A practitioner's fair evaluation would measure end-to-end iteration time, including image building, scheduling, execution, and result retrieval, because the paper's workflow claim is about iteration cadence rather than simulator-only time.
  • The observed crossover near 24 qubits is tied to the specific baseline laptop; weaker local machines would see the crossover earlier, and machines with local GPUs would see it later or not at all.
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

4 major / 4 minor

Summary. The paper presents q8s, a custom Jupyter kernel that submits notebook cell code as Kubernetes Jobs to a cluster with GPU-accelerated quantum simulators (Qiskit Aer with cuQuantum), allowing a developer to switch between local CPU execution and remote GPU execution from the same notebook interface. The authors evaluate the tool with QFT, Quantum Volume, and QAOA circuits (plus a noisy QAOA variant using FakeAuckland) on three scenarios: a laptop baseline, a self-managed cluster with a mobile workstation, and a commercial cloud GPU cluster. They report speedups for circuits above roughly 24 qubits, claim up to 5x faster runtime in the abstract and a 10x speedup for 29-qubit QAOA in Section 5.4, and state that the tool enables qubit ranges from 21 to 29 qubits. The paper also proposes an iterative development workflow aligned with existing quantum SDLC models and provides a GitHub repository for the kernel.

Significance. If the central claims hold, the tool is a useful practical contribution for quantum software developers who use Jupyter notebooks and need to scale simulations beyond a local laptop: it hides Kubernetes and GPU configuration behind a familiar kernel abstraction, and the reported speedups for large circuits are plausible because remote GPUs provide far more memory bandwidth and compute than a CPU-only laptop. Strengths of the paper include its open-source artifact, the use of two independent cluster scenarios, a testbook-based benchmark harness that separates simulator time from overhead, and honest reporting of failed 30-qubit runs. The main weakness is that the kernel's execution model appears stateless, which directly conflicts with the claimed iterative notebook workflow and with the benchmark's use of notebook state retrieval; this issue is load-bearing and must be addressed before the contribution can be assessed as advertised.

major comments (4)
  1. [§4.6, Fig. 6, Listing 1] The described execution model is stateless across notebook cells: each `do_execute` request builds/pushes an image (only when dependencies change), creates a Kubernetes Job running `python /app/main.py` with the cell code mounted via a ConfigMap, polls for completion, collects logs, and deletes the Job and ConfigMap. No Python objects, variables, imports, or data are retained between cells. A normal Jupyter notebook relies on shared kernel state across cells, so this kernel cannot support multi-cell iterative development as claimed in §4.4, §5.5, and the abstract. The single-cell benchmark in §5.2 never exercises multi-cell state, so all reported measurements are consistent with a stateless batch submission tool rather than with the claimed notebook workflow. This is a functional gap in objective O1, not a mere implementation detail; the paper should either implement persistent state (e.g., a long-lived remote session) or explicitly reframe the contribution as a batch-execution tool.
  2. [§5.2, Listing 2] The benchmark uses `func = tb.get("test_function")` to retrieve a Python function object from the notebook kernel's namespace. If the q8s kernel executes cell code only remotely and does not maintain a local Python namespace, this retrieval cannot succeed as described; the kernel would have no `test_function` object to return. Either the kernel maintains a local namespace in a way not documented in §4.6, or the benchmark is not measuring what the text claims. This internal inconsistency affects the validity of every speedup reported in §5.4 and must be clarified in the revised manuscript.
  3. [Abstract vs. §5.4, Figs. 7 and 9] The abstract states "up to 5 times faster circuit execution runtime, and enabled qubit ranges from 21 to 29 qubits," but §5.4 reports a 10x speedup for 29-qubit QAOA circuits and Fig. 7(c) shows speedups well above 5x for QAOA. Moreover, the "21 to 29 qubits" range applies only to noiseless QFT, QV, and QAOA; the noisy QAOA benchmark with FakeAuckland stops at 12 qubits on both GPU environments (Fig. 9), so the headline claim overstates the range for noisy simulation. The claims in the abstract and the body need to be reconciled, and the qubit-range claim should be qualified by routine type and noise model.
  4. [§5.1, Table 1, §5.7] The baseline is a single Dell Latitude 7440 business laptop with 16 GB RAM and no GPU. The speedup numbers and the "enabled qubit ranges from 21 to 29" benefit are computed against this specific weak baseline. The threats-to-validity section does not discuss the representativeness of this baseline; if a typical quantum software developer uses a GPU-equipped workstation or has access to an existing remote simulator, the reported advantages may not transfer. The paper should either provide evidence that the baseline is representative of the target user group or temper the external-validity claims.
minor comments (4)
  1. [§4.2] The phrase "Overview of arcitechtural structure" contains a typo; it should be "architectural structure."
  2. [§4.1] "leveraging Nvidia CPUs" should read "leveraging NVIDIA GPUs," since the surrounding text discusses CUDA-capable GPU acceleration.
  3. [§5.2, Listing 2] The function name `benckmark` is a typo for `benchmark`, and the `import timeit` at the top of the listing is unused in the shown code.
  4. [Fig. 7 caption] The dotted line is described as "the maximum speedup that can be achieved with the raw processing power of the GPU," but the manuscript does not explain how this upper bound is computed or what hardware assumptions it makes; the caption should reference a methodology section or state the calculation.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the speedup and qubit-range claims rest on external measurements, not on the tool's own definitions; the Qubernetes self-citation is contextual and not load-bearing.

full rationale

This paper is an empirical benchmarking study, not a derivation. The central claims ('up to 5 times faster circuit execution runtime', '10x speedup for 29-qubit circuits', and the 21-29 qubit range) are supported by measurements of actual Qiskit Aer executions on a local laptop, a mobile workstation, and a cloud GPU cluster, with simulator time and overhead time measured separately in Section 5.2. There is no fitted parameter later renamed as a prediction, and no equation in which the output quantity is defined in terms of the claimed result. The only notable self-citation is Qubernetes [32], used to position the cluster execution model; the speedup evaluation does not depend on accepting Qubernetes's correctness. The paper's own Limitations (Section 5.6) and Threats to Validity (Section 5.7) concede missing QPU/multi-GPU support and limited representativeness, which further shows the claims are framed as empirical observations rather than forced by construction. The skeptical observation that the q8s kernel is stateless per cell (Sections 4.6 and Listing 1) is a functional workflow gap, not circular reasoning: the benchmark measured single-cell execution, but that does not make the measured speedup an input to the conclusion. Overall, no circular step can be exhibited where a prediction reduces to an input by construction, and the paper is self-contained against external benchmarks.

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

The central claim rests on the availability and behavior of the q8s kernel, which the authors provide on GitHub, and on the representativeness of the benchmark scenarios. There are no fitted free parameters; the speedups are direct measurements. The main burden is the domain assumption that GPU-accelerated simulation is faster for large circuits and that the chosen benchmarks represent real development workflows.

assumptions (4)
  • domain assumption State vector simulation memory usage scales exponentially with qubit count (2^n complex amplitudes).
    The paper relies on this in Section 2.3 to motivate the need for more powerful hardware; it is a well-established property of state vector simulators.
  • domain assumption GPU-accelerated simulators using cuQuantum/cuStateVec are faster than CPU-only simulators for large state vectors.
    Underlies objective O2 and the entire speedup measurement; the benchmarks confirm it for the tested configurations, but the generalization to all circuits and hardware is assumed.
  • ad hoc to paper The three benchmark circuits (QFT, QV, QAOA) and the FakeAuckland noise model represent typical iterative quantum development workloads.
    The paper selects these circuits in Section 5.3 to stand in for real development tasks; if real workloads differ substantially, the workflow benefit claims weaken.
  • domain assumption Kubernetes and Jupyter kernel APIs behave as documented, and the cluster scheduler will schedule GPU jobs with the requested resources.
    The kernel's job submission and polling logic in Section 4.6 depends on these platform behaviors; the evaluation assumes no undocumented scheduler interference beyond measured overhead.
invented entities (1)
  • q8s kernel independent evidence
    purpose: A Jupyter kernel that packages notebook cell code into Kubernetes jobs for remote GPU simulation and returns results to the notebook.
    The kernel is open source at https://github.com/torqs-project/q8s-kernel, and its behavior is demonstrated through the benchmark experiments in Section 5. It is a software artifact, not a postulated physical entity, but it is the paper's main introduced component.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Toolchain for Faster Iterations in Quantum Software Development." pith.science (2026). https://pith.science/paper/DWF6JDTH

@misc{pith2026250707448,
  author       = {Pith},
  title        = {Pith review of: Toolchain for Faster Iterations in Quantum Software Development},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DWF6JDTH}},
  note         = {Machine review of arXiv:2507.07448}
}
read the original abstract

Quantum computing proposes a revolutionary paradigm that can radically transform numerous scientific and industrial application domains. To realize this promise, these new capabilities need software solutions that are able to effectively harness its power. However, developers may face significant challenges when developing and executing quantum software due to the limited availability of quantum computer hardware, high computational demands of simulating quantum computers on classical systems, and complicated technology stack to enable currently available accelerators into development environments. These limitations make it difficult for the developer to create an efficient workflow for quantum software development. In this paper, we investigate the potential of using remote computational capabilities in an efficient manner to improve the workflow of quantum software developers, by lowering the barrier of moving between local execution and computationally more efficient remote hardware and offering speedup in execution with simulator surroundings. The goal is to allow the development of more complex circuits and to support an iterative software development approach. In our experiment, with the solution presented in this paper, we have obtained up to 5 times faster circuit execution runtime, and enabled qubit ranges from 21 to 29 qubits with a simple plug-and-play kernel for the Jupyter notebook.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

43 extracted references · 21 canonical work pages

  1. [1]

    Sanders, B. C. Quantum leap for quantum primacy. Physics 14, 147 (2021)

    work page 2021

  2. [2]

    & Wilhelm, F

    Clarke, J. & Wilhelm, F. K. Superconducting quantum bits. Nature 453, 1031– 1042 (2008). URL https://doi.org/10.1038/nature07128

    doi:10.1038/nature07128 2008

  3. [3]

    Debnath, S. et al. Demonstration of a small programmable quantum computer with atomic qubits. Nature 536, 63–66 (2016). URL https://doi.org/10.1038/ nature18648

    work page 2016

  4. [4]

    Noiri, A. et al. Fast universal quantum gate above the fault-tolerance thresh- old in silicon. Nature 601, 338–342 (2022). URL https://doi.org/10.1038/ s41586-021-04182-y

    work page 2022

  5. [5]

    Peruzzo, A. et al. A variational eigenvalue solver on a photonic quantum pro- cessor. Nature Communications 5, 4213 (2014). URL https://doi.org/10.1038/ ncomms5213

    work page 2014

  6. [6]

    Chen, S., Cotler, J., Huang, H.-Y. & Li, J. The complexity of nisq. Nature Com- munications 14, 6001 (2023). URL https://doi.org/10.1038/s41467-023-41217-6

    doi:10.1038/s41467-023-41217-6 2023

  7. [7]

    Quantum computing 40 years later (2023)

    Preskill, J. Quantum computing 40 years later (2023). URL https://doi.org/10. 48550/arXiv.2106.10522. 2106.10522. 25

    arXiv doi:10.48550/arxiv.2106.10522 2023

  8. [8]

    Gill, S. S. et al. Quantum computing: A taxonomy, systematic review and future directions. Software: Practice and Experience52, 66–114 (2022). URL https: //doi.org/10.1002/spe.3039

    doi:10.1002/spe.3039 2022

Show all 43 references
  1. [9]

    & Markidis, S

    Faj, J., Peng, I., Wahlgren, J. & Markidis, S. Quantum computer simulations at warp speed: Assessing the impact of gpu acceleration: A case study with ibm qiskit aer, nvidia thrust cuquantum (IEEE, 2023). URL http://dx.doi.org/10. 1109/e-Science58273.2023.10254803

    2023

  2. [10]

    & De Raedt, H

    Willsch, D., Willsch, M., Jin, F., Michielsen, K. & De Raedt, H. Gpu-accelerated simulations of quantum annealing and the quantum approximate optimization algorithm. Computer Physics Communications278, 108411 (2022). URL https: //www.sciencedirect.com/science/article/pii/S0010...

    2022

  3. [11]

    Piattini, M. et al. The talavera manifesto for quantum software engineering and programming, 1–5 (2020)

    2020

  4. [12]

    A., Cruz-Lemus, J

    P´ erez-Castillo, R., Serrano, M. A., Cruz-Lemus, J. A. & Piattini, M. Guidelines to use the incremental commitment spiral model for developing quantum-classical systems. Quantum Information and Computation24, 0071–0088 (2024)

    2024

  5. [13]

    & Mikkonen, T

    Stirbu, V., Haghparast, M., Waseem, M., Dayama, N. & Mikkonen, T. Full- stack quantum software in practice: ecosystem, stakeholders and challenges, Vol. 2, 177–180 (IEEE, 2023). URL https://doi.org/10.1109/QCE57702.2023.10205

    2023

  6. [14]

    & Vietz, D

    Weder, B., Barzen, J., Leymann, F. & Vietz, D. Quantum Software Development Lifecycle, 61–83 (Springer International Publishing, Cham, 2022). URL https: //doi.org/10.1007/978-3-031-05324-5 4

    2022 doi

  7. [15]

    Guti´ errez, E., Romero, S., Trenas, M. A. & Zapata, E. L. Quantum computer sim- ulation using the cuda programming model. Computer Physics Communications 181, 283–300 (2010). URL https://doi.org/10.1016/j.cpc.2009.09.021

    2010 doi

  8. [16]

    & Muff, J

    Stirbu, V., Meijer-van de Griend, A. & Muff, J. Exposing the hidden layers and interplay in the quantum software stack(IEEE, 2024). URL https://doi.org/10. 48550/arXiv.2403.16545

    2024 doi arXiv

  9. [17]

    & Zhang, P

    Xu, X., Benjamin, S., Sun, J., Yuan, X. & Zhang, P. A herculean task: Classi- cal simulation of quantum computers (2023). URL https://arxiv.org/abs/2302. 08880. 2302.08880

    2023 arXiv

  10. [18]

    Bravyi, S. et al. Simulation of quantum circuits by low-rank stabilizer decompositions. Quantum 3, 181 (2019). URL http://dx.doi.org/10.22331/ q-2019-09-02-181

    2019

  11. [19]

    A practical introduction to tensor networks: Matrix product states and projected entangled pair states

    Or´ us, R. A practical introduction to tensor networks: Matrix product states and projected entangled pair states. Annals of Physics 349, 117–158 (2014). URL 26 http://dx.doi.org/10.1016/j.aop.2014.06.013

    2014 doi

  12. [20]

    S., Singh, S

    Patra, S., Jahromi, S. S., Singh, S. & Or´ us, R. Efficient tensor network simulation of ibm’s largest quantum processors. Physical Review Research6 (2024). URL http://dx.doi.org/10.1103/PhysRevResearch.6.013326

    2024 doi

  13. [21]

    & Zhang, P

    Pan, F., Gu, H., Kuang, L., Liu, B. & Zhang, P. Efficient quantum circuit simula- tion by tensor network methods on modern gpus.ACM Transactions on Quantum Computing 5, 1–26 (2024). URL http://dx.doi.org/10.1145/3696465

    2024 doi

  14. [22]

    & Sundaresan, N

    Gannon, D., Barga, R. & Sundaresan, N. Cloud-native applications. IEEE Cloud Computing 4, 16–21 (2017). URL https://doi.org/10.1109/MCC.2017.4250939

    2017

  15. [23]

    Kubernetes in action(Simon and Schuster, 2017)

    Luksa, M. Kubernetes in action(Simon and Schuster, 2017)

    2017

  16. [24]

    & Anderson, M

    Sterling, T., Brodowicz, M. & Anderson, M. High performance computing: modern systems and practices(Morgan Kaufmann, 2017)

    2017

  17. [25]

    & Hoppe, D

    Zhou, N., Zhou, H. & Hoppe, D. Containerization for high performance computing systems: Survey and prospects. IEEE Transactions on Software Engineering49, 2722–2740 (2023). URL https://doi.org/10.1109/TSE.2022.3229221

    2023

  18. [26]

    & Schulz, L

    Schulz, M., Ruefenacht, M., Kranzlmuller, D. & Schulz, L. Accelerating hpc with quantum computing: It is a software challenge too. Computing in Sci- ence & Engineering24, 60–64 (2022). URL https://doi.org/10.1109/MCSE.2022. 3221845

    2022 doi

  19. [27]

    J., Lyakh, D

    McCaskey, A. J., Lyakh, D. I., Dumitrescu, E. F., Powers, S. S. & Humble, T. S. Xacc: a system-level software infrastructure for heterogeneous quantum–classical computing*. Quantum Science and Technology5, 024002 (2020). URL https: //dx.doi.org/10.1088/2058-9565/ab6bf6

    2020 doi

  20. [28]

    Faro, I. et al. Middleware for quantum: An orchestration of hybrid quantum- classical systems, 1–8 (IEEE Computer Society, Los Alamitos, CA, USA, 2023). URL https://doi.ieeecomputersociety.org/10.1109/QSW59989.2023.00011

    2023

  21. [29]

    Decision of the governing board of the eurohpc joint undertaking no 44/2023, adopting the joint undertaking’s work programme and budget for the year 2024 (2023)

    EuroHPC Joint Undertaking. Decision of the governing board of the eurohpc joint undertaking no 44/2023, adopting the joint undertaking’s work programme and budget for the year 2024 (2023)

    2023

  22. [30]

    Peffers, K., Tuunanen, T., Rothenberger, M. A. & Chatterjee, S. A design science research methodology for information systems research. Journal of Man- agement Information Systems 24, 45–77 (2007). URL https://doi.org/10.2753/ MIS0742-1222240302

    2007

  23. [31]

    & Hauswirth, M

    Seidel, R., Tcholtchev, N., Bock, S. & Hauswirth, M. Kutrib, M. & Meyer, U. (eds) Uncomputation in the qrisp high-level quantum programming framework. 27 (eds Kutrib, M. & Meyer, U.) Reversible Computation, 150–165 (Springer Nature Switzerland, Cham, 2023). URL https://doi.org...

    2023 doi

  24. [32]

    & Mikkonen, T

    Stirbu, V., Kinanen, O., Haghparast, M. & Mikkonen, T. Qubernetes: Towards a unified cloud-native execution platform for hybrid classic-quantum computing. Information and Software Technology175, 107529 (2024). URL https://www. sciencedirect.com/science/article/pii/S0950584924001344

    2024

  25. [33]

    W., Bishop, L

    Cross, A. W., Bishop, L. S., Sheldon, S., Nation, P. D. & Gambetta, J. M. Vali- dating quantum computers using randomized model circuits. Phys. Rev. A100, 032328 (2019). URL https://link.aps.org/doi/10.1103/PhysRevA.100.032328

    2019 doi

  26. [34]

    & Gutmann, S

    Farhi, E., Goldstone, J. & Gutmann, S. A quantum approximate optimization algorithm (2014). 1411.4028

    2014 arXiv

  27. [35]

    Bayraktar, H. et al. cuquantum sdk: A high-performance library for accelerating quantum science, Vol. 01, 1050–1061 (2023)

    2023

  28. [36]

    & Bhatotia, P

    Giortamis, E., Rom˜ ao, F., Tornow, N., Lugovoy, D. & Bhatotia, P. Orchestrating quantum cloud environments with qonductor (2024). URL https://arxiv.org/ abs/2408.04312. 2408.04312

    2024

  29. [37]

    Shor, P. W. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM J. Comput. 26, 1484–1509 (1997). URL https://doi.org/10.1137/S0097539795293172

    1997 doi

  30. [38]

    W., Hassidim, A

    Harrow, A. W., Hassidim, A. & Lloyd, S. Quantum algorithm for linear systems of equations. Phys. Rev. Lett. 103, 150502 (2009). URL https://link.aps.org/ doi/10.1103/PhysRevLett.103.150502

    2009 doi

  31. [39]

    Cerezo, M. et al. Variational quantum algorithms. Nature Reviews Physics 3, 625–644 (2021). URL https://doi.org/10.1038/s42254-021-00348-9

    2021 doi

  32. [40]

    van Binsbergen, L. T. et al. A principled approach to repl interpreters, Onward! 2020, 84–100 (Association for Computing Machinery, New York, NY, USA, 2020). URL https://doi.org/10.1145/3426428.3426917

    2020

  33. [41]

    Wohlin, C. et al. Planning, 89–116 (Springer Berlin Heidelberg, Berlin, Heidel- berg, 2012). URL https://doi.org/10.1007/978-3-642-29044-2 8

    2012 doi

  34. [42]

    Jamadagni, A., L¨ auchli, A. M. & Hempel, C. Benchmarking quantum computer simulation software packages (2024). URL https://doi.org/10.48550/arXiv.2401. 09076. 2401.09076

    2024 doi arXiv

  35. [43]

    & Fang, L

    Morino, S., Hehn, A. & Fang, L. Accelerating quantum circuit simula- tion with nvidia custatevec (2022). URL https://developer.nvidia.com/blog/ accelerating-quantum-circuit-simulation-with-nvidia-custatevec. 28

    2022

Pith tools

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