GPU Computing for Quant Workloads

A CPU has a handful of powerful cores, each capable of running a complex, branching sequence of instructions quickly. A GPU has thousands of much simpler cores, each individually slower and less flexible, but able to run the same instruction across thousands of pieces of data simultaneously. This architectural difference means the question "is a GPU faster?" doesn't have one answer — it depends entirely on whether the workload is shaped like "do this one identical calculation a million times over independent inputs" (a GPU's specialty) or "make a long chain of decisions where each one depends on the last" (where a CPU's flexibility wins and a GPU's thousands of simple cores mostly sit idle).

The workloads that benefit most from a GPU in quant finance are large, embarrassingly parallel numerical computations where the same operation applies to every element independently. Pricing a large batch of options via Monte Carlo simulation is a textbook case: each simulated path is computed independently of every other path, so thousands of paths can run at once across the GPU's cores, and a computation that takes minutes on a CPU can take seconds on a GPU. Training a neural network is another — the core operation, matrix multiplication across large batches of data, is exactly the pattern GPUs were built to accelerate.

The workloads that don't benefit, or actively suffer, are ones with heavy branching or a strict sequential dependency — each step needs the previous step's output before it can start. A backtest that walks through a time series day by day, where today's position depends on yesterday's position, is inherently sequential; there's no way to parallelize "compute day 500" before "compute day 499" is done, so a GPU offers no advantage no matter how many cores it has sitting idle. There's also a fixed cost to using a GPU at all — data has to be transferred from regular system memory to the GPU's own memory and back, which takes real time; for a small or quick computation, that transfer overhead can dwarf the actual computation time, making the GPU slower overall than just running the small task on a CPU.

Worked example: Monte Carlo option pricing, CPU vs GPU

Pricing one option via Monte Carlo with 100,000 simulated paths on a CPU, one path at a time in a loop, might take on the order of a few seconds. The same 100,000 paths on a GPU, where the simulation logic for one path is written once and applied across thousands of paths simultaneously, can complete in a fraction of that time — the GPU's thousands of cores each handle a chunk of paths in parallel instead of the CPU working through them one core at a time. The speedup grows with the number of paths and shrinks (or disappears) if the number of paths is small enough that the fixed cost of moving data to the GPU and back dominates the actual computation.

What this means in practice

Reach for a GPU when a workload is large, parallel, and free of sequential dependencies — Monte Carlo pricing, model training, large batch numerical operations. Stick with a CPU for anything inherently sequential, branch-heavy, or small enough that data-transfer overhead would eat the gains. Many production quant systems use both: GPUs for offline research and calibration workloads that are naturally parallel, CPUs for the sequential, low-latency decision logic of live trading.