GPU and Accelerator Notes

An accelerator is useful when a verified quantum workload exposes enough parallel work, reuses resident data, and achieves the required numerical accuracy in a supported precision. Moving an algorithm to a device changes the execution model and often the arithmetic order. It does not automatically make the calculation faster or more accurate.

Required background. High-performance computing basics introduces memory and throughput models; Precision diagnostics explains precision limits.

Data residency and a break-even model

Separate one-time setup and transfer cost $T_0$ from the repeated step costs $t_C$ on a CPU and $t_A$ on an accelerator. If the state remains resident for $K$ steps, acceleration is favorable in this simplified model when

$$T_0+Kt_A<Kt_C, \qquad K>\frac{T_0}{t_C-t_A},$$

assuming $t_A<t_C$. For illustrative times $T_0=0.2$ s, $t_C=0.004$ s, and $t_A=0.001$ s, at least 67 steps are needed to overcome setup. These are hypothetical values for the model, not hardware benchmarks.

Copying the full state back after every step adds a repeated transfer cost and can erase the gain. For wave-packet propagation, retain states, kinetic phases, and potentials on the device; compute selected observables there and transfer compact outputs when possible. This is an algorithm-design question about what information the experiment requires.

Workloads with different structures

Dense matrix products and batches of small independent systems expose regular parallelism. Split-operator evolution alternates FFTs and diagonal multiplications. Sparse Hamiltonian actions depend on graph structure and index access. Tensor-network contractions may be fast individually but separated by factorizations, reshaping, and communication that dominate the full sweep.

For a batch of driven two-level systems, stack the independent parameter cases so that the same operation acts on many states. Keep each case’s parameters and output labels attached to a stable index. A faster batch that mixes detunings with the wrong initial states is a scientific failure that shape checks alone may miss.

Small tasks can be limited by launch and synchronization overhead. Combining adjacent pointwise operations may reduce memory traffic, but validate the fused calculation against the original expression, especially if compiler transformations alter arithmetic precision or reassociate sums.

Precision as part of the algorithm

Binary32 has much less precision than binary64. An energy error $\delta E$ produces an accumulated phase error

$$\delta\varphi(t)=\frac{t\,\delta E}{\hbar}.$$

For a relative phase between two eigenstates, replace $\delta E$ by the error in their energy difference; a common energy shift changes only the global phase. Thus a spectrum adequate for short-time populations may be inadequate for a long coherent evolution. For a desired phase error below $10^{-3}$ at dimensionless time $10^5$, the relevant dimensionless energy error must be below about $10^{-8}$. This requirement comes from the scientific target, not the device’s preferred dtype.

Mixed-precision methods can compute expensive approximate steps in lower precision and evaluate residuals or corrections in higher precision. They require an error-control mechanism. Replacing all arrays with a smaller dtype is not itself a mixed-precision algorithm with guaranteed accuracy.

Check which precision is used for multiplication, accumulation, and stored results. Complex arithmetic conventions, fused operations, and parallel reductions can differ from a CPU reference. Compare residuals, fidelity, conservation defects, and observables at matched discretization rather than demanding bitwise equality.

Timing asynchronous work

Device calls can enqueue work and return before it finishes. Measuring only the host call may time submission rather than computation. Use the runtime’s documented synchronization or device timing events, include transfers when reporting end-to-end time, and distinguish first-run compilation/setup from repeated execution.

Measure a representative sequence rather than a single tiny kernel. Record problem size, batch size, precision, environment, device, and acceptance results. Do not infer application performance from advertised arithmetic throughput. Device memory capacity and workspace demands may constrain the problem before arithmetic speed does.

A verification route

First compare the accelerator and CPU actions on small complex vectors with known answers. Then test a complete short trajectory against an analytic benchmark. Increase duration and problem size while retaining the physical error criteria. Finally repeat the convergence study in the chosen device precision.

If accuracy fails, determine whether the cause is a porting error, different arithmetic, an unstable algorithm, or insufficient precision. Changing the acceptance threshold to accommodate an unexplained discrepancy does not validate the port. A justified alternative algorithm or dtype should be checked against the same benchmarks and accuracy criteria.

Exercises

Suppose an accelerator step takes 1 ms but transferring the state to and from it takes 5 ms per step. The CPU step takes 4 ms. Can a longer run overcome this repeated transfer cost?

Solution

No. Each accelerated step costs at least 6 ms, already above the 4 ms CPU step. Increasing the number of steps amortizes one-time setup, not a cost repeated every step. Keeping data resident or reducing transfers changes the comparison.

References

• Higham, N. J., Accuracy and Stability of Numerical Algorithms, 2nd ed., SIAM, 2002 — precision, residuals, and reliable numerical corrections.
• NVIDIA, CUDA C++ Best Practices Guide, accessed 13 October 2026 — a concrete runtime reference for transfers, profiling, synchronization, and device arithmetic; the principles above do not depend on a particular vendor.
• Williams, S., A. Waterman, and D. Patterson, “Roofline: An Insightful Visual Performance Model for Multicore Architectures,” Communications of the ACM 52(4), 65–76 (2009), author repository — compute and data-movement limits.