Reading CUDA release notes like a systems engineerDraft
What actually changes between CUDA toolkits, which of it matters for latency-bound code, and a running log of the releases I've tracked.
Every CUDA toolkit ships with a release-notes page long enough to hide the two paragraphs that matter. This post is my filter: the categories of change I look for, why, and a dated log of what each release moved for the kind of code I write — pricing kernels, Monte Carlo paths, and the glue around them.
The four questions I ask of any release
1. Did the compilation model change? New nvcc defaults, deprecated architectures, changes to -arch / -gencode handling, or anything touching link-time optimisation. These break builds silently in CI long before they break performance.
2. Did the memory model move? Unified memory behaviour, async copies (cp.async, TMA on Hopper-class parts), memory pools, or L2 persistence controls. For Monte Carlo the bottleneck is almost never FLOPs; it is moving random numbers and path state through the hierarchy.
3. What happened to the math libraries? cuBLAS, cuRAND, cuSPARSE, and now the tile-level libraries. A faster cuRAND Philox path or a new batched GEMM shape is worth more to a risk engine than any language feature.
4. Is Python becoming first-class? NVIDIA has been steadily moving CUDA toward native Python entry points (cuda.core, cuda.bindings, tile-based programming). For quant work this matters because the research loop lives in Python and the production loop does not; anything that shrinks the gap is leverage.
What I ignore
- Marketing numbers for new silicon unless I can run on it.
- Anything only relevant to graphics interop.
- Sample code updates. The samples are documentation, not news.
Release log
| Toolkit | Date | What moved for me | Action |
|---|---|---|---|
How I benchmark a release
Three kernels, pinned to one GPU, run before and after the toolkit bump:
- Philox path generation — 1M paths × 252 steps, measures cuRAND and memory bandwidth.
- Cholesky-correlated GBM — the same paths through a correlated shock step, measures small-matrix throughput.
- Sort + quantile — the VaR/ES aggregation step, measures CUB/Thrust changes.
If the median of five runs moves by more than 3% in either direction, the release gets a line in the table above. Otherwise it is a no-op and I move on.