Posted by
Peter Caspers-4 on
Sep 06, 2014; 12:48pm
URL: http://quantlib.414.s1.nabble.com/Re-Openmp-work-on-mcarlo-Dynamic-Creator-MT-tp15832.html
Hi Joseph, all,
I added a wrapper for the dcmt library (Dynamic Creator of Mersenne Twisters).
https://github.com/lballabio/quantlib/pull/132I guess this is a useful building block for multithreaded monte carlo.
Since for bigger p the dynamic creation takes a long time (it feels
more like mining than computing ...), I precomputed 8 independent
instances (i.e. for use in at most 8 parallel threads), for the
"standard" value p = 19937 and word size 32, which one can instantiate
with
MersenneTwisterDynamicRng mt( mtdesc_0_8_19937[i] , seed_i );
for i = 0, ... , 7.
In addition the speed of random number generation seems a bit faster
in the dcmt library than with the original ql twister. I observe
running times scaled by a factor of 0.8 when generating 1E8 numbers.
All this is of course experimental and not well tested, so any
feedback and experiences are very welcome. I'd be very interested in
your opinion on the dcmt library and applications in parallel monte
carlo.
Peter
On 20 October 2013 16:01, Joseph Wang <
[hidden email]> wrote:
> I've done some more parallelization with openmp and quantlib. I've uploaded
> the changes to the
https://github.com/joequant/quantlib. The branch openmp
> has some changes that I've issued a pull-request for. openmp-mcario has
> some changes that need some more work.
>
> I've gotten the MC to work by generating the paths in a critical situation.
> Calculating the prices once I have the path is multithreaded, but right now
> I need to generate the paths in a single thread to make sure that the same
> sequence is generated.
>
> The big issue right now is that there is a race condition in the calculation
> of barrier options which is causing one regression test to fail. The
> problem is that the random number generator is being called in
> BarrierPathPricer, and since that is run multithread, the sequence that is
> being pulled will change from run to run based on whether other paths have
> pulled random numbers already.
>
> I think that fixing this is going to need some code restructuring, but I'd
> like to get some thoughts as to how to do this. Basically, the interface
> needs to be changed slightly so that the random numbers are drawn in a fixed
> order, and that might mean one call to get any additional random numbers in
> a pricer, which gets called in a critical section, and another to run the
> pricer with the random numbers.
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
>
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk> _______________________________________________
> QuantLib-dev mailing list
>
[hidden email]
>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev