I'm considering trying to find a way to run my QuantLib code in parallel, but it doesn't look straightforward. The Settings.instance().setEvaluationDate(date) call is the problem since Settings is a singleton. Unless all of my calls to my QuantLib valuation code use the same settlement date, I can't reliably run my code in parallel.I'm using QuantLib for valuing plain vanilla, American options. I'm moving the settlement date around for stress testing purposes. I see two possible ways to do this in parallel:1) Either run the code in separate processes (instead of threads), or2) If the evaluation date changes, instead change the expiration date and any dividend dates.Both of these solutions are problematic. The first solution may require so much setup, teardown, and inter-process communication that the benefits to running the code in parallel may be lost. The second solution is really a hack; plus it doesn't properly address non-trading days.Is there a way to run QuantLib code in parallel?

No. Unfortunately, it will not work. It is a general concern.Traditional libs are on OOP principles and patterns which are at odds with parallel processing and MT. With MT you _start_ with task and data decomposition. You cannot do MT as an afterthought.QL is a good OOP library (without docs!!) but to develop MT libraries you have to go back to the future and do modular systems as I have done with my MC1 prototype (for example) in Wilmott qfcl open source project. This approach is the only way imo unless there is another solution. And where to find developers who know MT and parallel? It is not something you will learn on a lazy Sunday afternoon. I think it wil take 1-2 years.Conclusion: start all over again. Other bad news is that C++ is not really _as_ suitable for MT as functional programming languages such as F#, ML. The solution is SYSTEM DESIGN, which is kinda 60's. @renorm had arrived at a similar solution.

Do you have any idea why Settings is a singleton?I forgot to mention that one big reason I would need to change the settlement date is so that I can calculate a theta for an option. I am doing a simple numerical derivative to calculate the theta since the binomial, discrete dividend model is unable to do so. I don't know how to do this without changing the settlement date. What I do is:1) Calculate the option's NPV2) Move the settlement date forward one day3) Recalculate the option's NPV4) Theta-Per-Day = NPV1 - NPV05) Theta = Theta-Per-Day * 365I could figure out a way around this in my code, but it will be a hassle.

QuoteOriginally posted by: JRobinsonDo you have any idea why Settings is a singleton?At the time, it seemed a good idea not to have to thread the evaluation date and the other settings through all function calls.Cuch's right, we'll need a redesign to address this.This said, a workaround that might or might work for you is to compile the library with QL_ENABLE_SESSIONS defined. You'll have to provide a bit of code, but you would have one distinct Settings instance per thread. I've got to run now, but I'll try and give you some more information tomorrow.QuoteI forgot to mention that one big reason I would need to change the settlement date is so that I can calculate a theta for an option. I am doing a simple numerical derivative to calculate the theta since the binomial, discrete dividend model is unable to do so. I don't know how to do this without changing the settlement date. What I do is:1) Calculate the option's NPV2) Move the settlement date forward one day3) Recalculate the option's NPV4) Theta-Per-Day = NPV1 - NPV05) Theta = Theta-Per-Day * 365Yes, that's what we do, too. In our case though, we have to do this for thousands of instruments, so it becomes attractive to do multiprocess (if you spawn jobs with hundreds or thousands of instruments, the setup cost becomes negligible).

I suppose it's logical to have Settings as a Singleton (it is a static variable??) in a single-threaded application and if it is read-only it will not lead to a race condition in MT. If not, some choices are:. Make a copy per thread (thread-local storage).. Make it thread-safe (how often is it accessed?). Singleton is not thread-safe. You can put mutexes around the access code in Singleton.. Design functions as thread start functions, each with its own settings.Ideally, no shared data between threads. Otherwise, one can use shared data pattern http://my.safaribooksonline.com/book/so ... 05lev1sec8 I wonder what the influence is of shared ptrs is on thread-safeness. Global data and MT are considered harmful? QuoteYes, that's what we do, too. In our case though, we have to do this for thousands of instruments, so it becomes attractive to do multiprocess (if you spawn jobs with hundreds or thousands of instruments, the setup cost becomes negligible).(Heavyweight) process have no shared data by default; is it not better to use threads with work-stealing and loop-level parallelism? QuoteI forgot to mention that one big reason I would need to change the settlement date is so that I can calculate a theta for an option. I am doing a simple numerical derivative to calculate the theta since the binomial, discrete dividend model is unable to do so. I don't know how to do this without changing the settlement date.What about FD? The price at levels n, n+1 have already been computed. Maybe run two binomial method at t_now and t_now + delta_t and add the results?

QuoteOriginally posted by: CuchulainnI wonder what the influence is of shared ptrs is on thread-safeness. It has to be thread safe, with perf implications: http://nerds-central.blogspot.com/2012/ ... s-and.html

From a parallel design we would want to avoid/mitigate shared data if at all possible. So, legacy applications using share data (and in particular shared_ptr) are a concern. Using shared_ptr willy nilly (can happen) has major consequences. Singleton pattern being a case in point.Functional languages do not have these side effects. .NET libraries are non-thread-stage by default as the claim this is the responsibility of the user.

QuoteOriginally posted by: lballabio'll try and give you some more information tomorrow.It took more than I thought. Anyway, you can try doing the following (emphasis on "try", since I haven't done it):1) recompile the library with QL_ENABLE_SESSIONS defined. If you're on Windows, uncomment the relevant line in userconfig.hpp. If not, add the --enable-sessions flag to configure.2) write a function Integer sessionId();in namespace QuantLib (the namespace is required) and link it with the library and your code. The function must return a different integer when called from different threads (and of course it must return the same integer when called twice from the same thread). If you can get some kind of thread id you can use it, or you might use thread-local storage.3) there might be a race in the access to the singleton map. See this thread for details and for a fix.If you give it a try, please let me know how it goes.

Quote If you can get some kind of thread id you can use it, or you might use thread-local storage.This is very easy in OpenMP; there are run-time functions for this.And Boost Threads support thread_group. And thread-local storage is also possible in both libraries.

QuoteOriginally posted by: lballabioQuoteOriginally posted by: lballabio'll try and give you some more information tomorrow.It took more than I thought. Anyway, you can try doing the following (emphasis on "try", since I haven't done it):1) recompile the library with QL_ENABLE_SESSIONS defined. If you're on Windows, uncomment the relevant line in userconfig.hpp. If not, add the --enable-sessions flag to configure.2) write a function Integer sessionId();in namespace QuantLib (the namespace is required) and link it with the library and your code. The function must return a different integer when called from different threads (and of course it must return the same integer when called twice from the same thread). If you can get some kind of thread id you can use it, or you might use thread-local storage.3) there might be a race in the access to the singleton map. See this thread for details and for a fix.If you give it a try, please let me know how it goes.Hum yet another convoluted way of doing things in quantlib...

Is that Singleton read-only? If not, then speedup will be compromised.Another reason NOT to use Singleton. Can't say I didn't warn you, so many moons ago