- This topic has 1 reply, 2 voices, and was last updated 7 years, 5 months ago by .
-
Posts
-
Hi all,
in this topic I would like to start a discussion on a possible parallelization strategies of the ORE. Everybody is welcome to put his ideas on topic.
As Niall mentioned in a previous topic, ORE was designed to make a parallelization possible. In this case we have to think about a thread safe use of QuantLib and QuantLib-ext library. As far as I know, QuantLib doesn’t thread safe at the moment. I didn’t payed much attention to this, but Klaus Spanderen developed some ideas on this topic and provided some solutions: http://quantlib.org/slides/qlws13/spanderen.pdf
Thinking about ORE itself, we could parallelize some tasks applying a changes to existing for-loops. At this place market data tasks, calibration and scenarios could be done parallel. Maybe someone have a precise idea how to do it best way.
The other possibility for a parallelization would be to use a tool as is and invoke some calls from extern using for example a python code. In this case different netting sets could be computed in parallel using separate instance of ore.exe and ore.xml.
What experience and ideas you have in the context of ORE and QuantLib-Library for the parallelization?
Take care
Alex
Hi Alex,
While some work has been done in some areas of QuantLib it is fundamentally not thread safe, you cannot have two threads asking the same instrument for it’s PV under different scenarios. It is because of this that the ORE libraries all assume a single thread and this is what the ore executable is.
Also, ORE is primarily about bringing transparency to the models and their use, this is best severed by a single threaded framework which is the most accessible to the majority of people.
If you are only interested in speeding it up, then you should see that all the of the time is being spent in the ValuationEngine, there is very little benefit is speeding up market data loading, bootstrapping, etc. So you quickly come to the conclusion that you just need to parallise the three nested loops. Doing this is really an engineering question, it is of course possible to do this using the existing ORE libraries, but this would have to be done at an application and orchestration level (i.e. at a process rather than thread level). It probably makes sense to have a single node process a full path (for path dependant trades) so it’s really a question of splitting the portfolio or samples or both across nodes.
I should point out that Quaternion has an ORE based commercial offering in this area.
Regards,
Niall.
- You must be logged in to reply to this topic.