Computational Bottlenecks in Quantitative Trading and Derivatives Pricing
Summary
The discussion distinguishes computational limits by workload. For real-time trading, it argues that network throughput is often the constraint, while historical analysis is more commonly limited by memory capacity or bandwidth; ordinary CPU use may not be the main bottleneck. It identifies data interpretation tasks such as feed handling and FIX message parsing as potential CPU-heavy work because they transform many small pieces of data.
The answers suggest GPU acceleration could be useful for parsing structured messages, though support and venue adoption are practical constraints. A separate example points to exotic options valuation, where FFT calculations and Monte Carlo simulation can demand substantial computation even when the working dataset fits in cache. These are practitioner observations rather than measured benchmarks, and bottlenecks depend on the system and workload. The document does not quantify expected gains or establish that GPUs outperform other hardware for the examples discussed.
Key ideas
- Real-time trading workloads may be constrained by network performance more often than CPU capacity.
- Historical research workloads can be limited by memory rather than raw processing speed.
- Feed handling and FIX parsing involve many small data transformations that may tax CPUs.
- FFT and Monte Carlo calculations in exotic options pricing are possible GPU acceleration targets.
- The examples are practitioner observations and do not provide comparative performance measurements.
Tags
Full text
# What are some computational bottlenecks that quants face? # What are some computational bottlenecks that quants face? What are the current computational (non-network) bottlenecks now in a quant's workflow? What computational tasks would be revolutionary with a 10-100x improvement in performance using general purpose GPUs? ## Answer by chrisaycock (score 7) https://quant.stackexchange.com/a/515 Coming from an HPC background myself, I know too well the feeling of owning a hammer and yet having no nail. Your question is about computational bottlenecks that can be relieved with GPGPU, though I'm afraid to admit that there aren't many in finance. For realtime applications, the network is the bottleneck; for historical applications, the memory is the bottleneck. The CPU is rarely saturated in my line of work. However, there is one particular area that does appear to be CPU bound: interpretation. Namely, the feed handler and the FIX parser both require many small amounts of data to be transformed from one representation to another. FPGA-based feed handlers are starting to become more popular; I haven't seen anything similar for FIX parsers though. If you could show how to parse a FIX message with a GPU off the wire, then that might be interesting. FIXT 1.1 can support InfiniBand, so NVIDIA / Mellanox's GPU Direct set-up would be especially noteworthy, though not required. (There aren't many trading venues supporting FIXT right now anyway, so there's no rush there.) If you wanted to generalize your work for all key-value pairs communicated over a network, you might be able to apply some of your findings to parsing HTTP headers in realtime. No doubt many cloud vendors would be pleased to see that. By the way, the reason I advocated FIX parsing instead of feed handling is that most data vendors ship their own proprietary API. Good luck getting Wombat to cooperate with you until you have some results of your own to show. ## Answer by quant_dev (score 2) https://quant.stackexchange.com/a/517 In exotics options pricing, there are lots of CPU bottlenecks -- for example the calculation of Fast Fourier Transform or Monte Carlo simulation. When I price a range accrual in Libor Market Model, I don't use a lot of data (carefully optimized, everything should fit in a few MB of L2 cache), but I do a lot of calculations. This is where, I think, a GPU may be useful.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.