Parallel Monte Carlo Pricing in QuantLib Requires Independent State
Summary
The document considers how to parallelize Monte Carlo pricing in a custom QuantLib engine derived from McSimulation. It compares running separate deals in parallel with modifying the MonteCarloModel sampling loop to use multiple threads. The answer favors parallelizing deals when development effort should remain limited, while warning that parallelizing paths inside the engine is a substantial engineering task.
The key issue is mutable or non-parallel state in the simulation components. Random number generators may produce overlapping draws if independently instantiated without a suitable parallel design; path generators retain state and cannot safely be shared among threads; and statistics accumulators also retain state. A path-parallel design therefore needs independent per-thread components and result aggregation, or synchronization around shared statistics. The response is qualitative guidance, not a benchmark or a complete implementation. It cautions that copying and replacing QuantLib internals can create ongoing maintenance work when library classes change, while the alternatives and their performance trade-offs are not measured.
Key ideas
- QuantLib’s described Monte Carlo pricing machinery runs in a single thread.
- Parallelizing separate deals is presented as the lower-effort option.
- Path-level parallelism requires careful handling of random-number streams to avoid overlapping draws.
- Path generators and statistics objects retain state and cannot simply be shared unsafely across threads.
- Per-thread state with aggregation or synchronization is needed, and custom copies of library logic create maintenance costs.
Tags
Full text
# Best way to do multithread Monte-Carlo in QuantLib # Best way to do multithread Monte-Carlo in QuantLib QuantLib has great facilities for Monte-Carlo pricing engines, classes McSimulation and MonteCarloModel do a lot of work. But they do it in a single thread. What is best way to introduce parallel run in my custom engine (inherited from McSimulation class, as it is done for some instruments in QuantLib)? Now I see 2 options - Use QuantLib routines as they are present, and handle multiple deals in parallel. - Customize MonteCarloModel 2.1 Make a subclass of MonteCarloModel and overwrite addSamples: insert there OpenMP code 2.2 My engine is already a subclass of McSimulation (I overwrite timeGrid, pathGenerator, pathPricer), I will also overwrite "calculate" - I will copy its current code, but replace instantiation of MonteCarloModel with my implementation. I don't like neither first, nor second options. The first doesn't allow me to price a single deal quickly, the second makes me in trouble in case of amendments in classes MonteCarloModel and McSimulation in QuantLib distributive. ## Answer by Luigi Ballabio (score 6, accepted) https://quant.stackexchange.com/a/18095 Sigh. I'm not sure that there's a best way to do multi-threaded MC in QuantLib. I'm afraid that you're underestimating the amount of development you'd need for option 2. You're not going to get away with some OpenMP code as you suggest, because calculations on different paths are not trivially parallel: - the RNGs we have are not parallel, and even if you use a different instance for each thread, you still risk superposition in the set of random numbers they'll draw; - the path generator keeps state, so you can't use the same one in different threads; - the statistics class keeps state, so you have to either use a different instance per thread and aggregate the results afterwards, or add a lock to the existing one to serialize access. And these are just the problems that just come to mind in the first two minutes without looking too hard. All in all, I'd go for option 1 if you don't want to invest a lot of development time.
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.