CP∂, our quant library:

  • it often reads like the maths, with less code overhead than any other code base we've seen;
  • it can output MathML and Excel traces of the exact formulas it runs (our "glass box");
  • it can compile that same trace to the GPU.

This blog post is about the last point: where the GPU earns its keep in finance, where it doesn't, and what we measured to find out.

Double trouble

In GPU terms, our entire library is written in f64, double precision. That is the precision Excel uses, and you need it if you want cent accuracy on a billion-notional trade: f64 carries about 16 significant digits, f32 only about 7. Both are scientific notation in binary: a fixed number of significant digits times a power of two, so precision is relative to the size of the number. On $10m, f32 cannot see anything smaller than a dollar; on $1bn, its smallest step is $64. f64 resolves both to well under a millionth of a dollar.

The problem is that consumer GPUs are built for f32 and run f64 at a sixty-fourth of the speed. Data-centre GPUs used to carry serious f64 hardware for scientific computing, but the AI boom has pushed the vendors to spend less silicon on it. NVIDIA's Blackwell Ultra gives f64 barely a single teraflop,1 and its next generation, Rubin, has less native f64 than the four-year-old H100, leaning on emulation for the rest.2

On paper, a $500 16-core Zen 5 desktop CPU running AVX-512 delivers more theoretical double-precision throughput per dollar than any current NVIDIA GPU, consumer or data-centre; only AMD's own Instinct accelerators, built with HPC in mind, do better.3 That is peak arithmetic.

Finance code is also branchy:

  • bootstrapping a curve makes many decisions;
  • pricing a 2Y swap vs a 5Y swap takes different paths;
  • date grids are all decisions.

CPUs handle decisions well; GPUs do not.

Take the ISDA CDS test grid, which we rebuilt to the cent earlier this year. To price it you must:

  1. bootstrap the ISDA-defined discount curve;
  2. solve for the par hazard rate;
  3. back out the upfront price,

all across 7,164 trades. We can do all of this on the GPU (did I mention we can root-find on the GPU?). On an A100 it reprices the whole grid in 3.9 ms in f32 and 19.3 ms in f64, against 36 ms and 85 ms on one core of the host's CPU using SIMD. But first it has to compile.

The ISDA grid: fast to reprice, slow to compile

That compile costs 13.9 s in f32 and 27.3 s in double, against about 0.6 s for the CPU in either. Against the CPU's SIMD engine, the GPU only pays that back after about 420 repricings in f32, or about 410 in f64. Price a trade once and the CPU wins comfortably.

And f32 has a price of its own. Across all 7,164 trades, each on $10m notional, f32 is typically 10 cents out, on the CPU or the GPU alike, but 133 trades are out by more than a dollar and the worst by $2.72. f64 on the GPU, by contrast, agrees with f64 on the CPU to five billionths of a dollar, and the CPU agrees with ISDA's published values to under a millionth.

Because we trace dynamically, we always pay that compile cost. If you are doing intraday or batch processing, you pay it once and forget it.

The GPU strikes back, eventually

There is one workload in finance that suits the GPU: Monte Carlo. We use it to price American and Bermudan payoffs, for CVA and DVA, for asymmetric FBA and FCA, and for VaR and ES.

Tracing does most of the deciding up front, on the CPU; only the root finding stays in the kernel. What remains is the same calculation, run many, many times, which is exactly what a GPU is good at.

Monte Carlo also lets us drop f64. It is a statistical estimate, and its statistical error is far wider than the precision we lose in f32. On our xVA test book at 50,000 paths, f32 moves CVA by 10,750, about a thousandth of the standard error of 9.4m. The f64 GPU result agrees with the CPU to 14 significant digits.

Our xVA test book is a single netting set: 16 trades over 128 exposure dates, 772 outputs. At 50,000 paths the A100 does the sampling in under a tenth of a second, where one CPU thread takes 15 s and 16 vCPUs take a second:

xVA at 50,000 paths: where the time goes

But at 50,000 paths the 4-second compile still dominates, and 16 CPU cores finish first. The compile is fixed; the sampling grows with every path. On the first host the lines would cross at about 150,000 paths; on the second, slower host they cross between 250,000 and 500,000, and at a million paths the A100 in f32 is twice as fast as the best CPU engine, and in f64 it is 3.3 times faster than the CPU in f64:

xVA: more paths, more advantage to the GPU

Keeping the beast fed

With techniques such as loop rerolling, GPU-side random number generation, relaxed-math Metal kernels and pinned, overlapped host-to-device copies, we keep the A100 busy for most of a run in f64. A profile of a million-path run shows the kernels busy for 55% of the sampling window and copying results off the card for another third.

In f32 the kernels are so quick that the bottleneck has moved off the GPU. The run splits roughly into thirds: computing, copying results off the card, and waiting while the host collects them. On our RTX 5070 laptop the profile is starker: collecting on the host took the whole batch, and the GPU sat idle for most of it. That is the next thing to fix, though it matters less than you might think: a GPU kept 100% busy would sample a million paths in 0.13 s instead of 0.42 s, but it would barely move the point where the GPU overtakes the CPU. That point is set by the compile.

1. HPCwire, "Nvidia says it's not abandoning 64-bit computing", 9 December 2025. ↩

2. The Register, on Rubin's FP64 and NVIDIA's emulation, 18 January 2026. ↩

3. Peak FP64 = cores × base clock × 32 FLOP per cycle for full-width Zen 5 AVX-512 (two 512-bit FMA pipes; Chips and Cheese). A Ryzen 9 9950X at $499 street price gives about 4.4 GFLOPS per dollar. The best NVIDIA case, H100 SXM FP64 tensor cores (67 TF, NVIDIA) at an estimated $25,000, gives about 2.7. AMD's MI300X (81.7 TF vector, 163.4 TF matrix, AMD) at an estimated $10,000–15,000 gives 5–16. Data-centre GPU prices are third-party estimates. Peak figures ignore memory bandwidth, where HBM favours the GPU, and branchy code, where the CPU wins. ↩

CP Dynamics builds cpStudio, a cross-asset pricing and risk platform. david.naylor@cpdynamics.co.za