http://quantlib.414.s1.nabble.com/Re-Openmp-work-on-mcarlo-Dynamic-Creator-MT-tp15832p15866.html
indeed with msvc I get a slow down with a factor of ~2.8x. As I said,
> Thanks Peter.
>
> Regards,
> Cheng
>
> 发自我的 iPad
>
>> 在 2014年9月13日，13:29，Peter Caspers <
[hidden email]> 写道：
>>
>> I will have a look on monday ( I have a Windows machine at work ) and see how it works there
>>
>> Thanks
>> Peter
>>
>> Von meinem iPhone gesendet
>>
>>> Am 13.09.2014 um 04:41 schrieb Cheng Li <
[hidden email]>:
>>>
>>> I am on Win7 x64bit, using vs 2012 with quantlib 1.4 boost 1.55 under release mode
>>>
>>> 发自我的 iPad
>>>
>>>> 在 2014年9月13日，0:08，Peter Caspers <
[hidden email]> 写道：
>>>>
>>>> Hi Cheng,
>>>>
>>>> no, I get better timings with the dcmt implementation, e.g. for 1E8 numbers
>>>>
>>>> dcmt 0.982s
>>>> quantlib 1.159s
>>>>
>>>> on my computer. Can you post your platform and compiler settings, so
>>>> that I can try to reproduce ?
>>>>
>>>> Thanks
>>>> Peter
>>>>
>>>>> On 12 September 2014 05:29, cheng li <
[hidden email]> wrote:
>>>>> Hi Peter,
>>>>>
>>>>> I have used your wrapper dcmt library and test with following codes: It
>>>>> seems dcmt in single thread is 4X slower than the QL original MT. Is this
>>>>> consistent with your side?
>>>>>
>>>>> #include <ql/quantlib.hpp>
>>>>> #include <boost/timer.hpp>
>>>>> #include <iostream>
>>>>>
>>>>> using namespace QuantLib;
>>>>> using namespace std;
>>>>>
>>>>> int main() {
>>>>>
>>>>> int samples;
>>>>> cin >> samples;
>>>>> boost::timer myTimer;
>>>>>
>>>>> MersenneTwisterUniformRng orignalMT;
>>>>> for(Size i=0; i<samples; ++i)
>>>>> orignalMT.next();
>>>>>
>>>>> cout << myTimer.elapsed() << endl;
>>>>>
>>>>> myTimer.restart();
>>>>>
>>>>> MersenneTwisterDynamicRng mt( mtdesc_0_8_19937[5] , 1);
>>>>>
>>>>> for(Size i=0; i<samples; ++i) {
>>>>> mt.next();
>>>>> }
>>>>>
>>>>> cout << myTimer.elapsed() << endl;
>>>>>
>>>>> int n;
>>>>> std::cin>>n;
>>>>> return 0;
>>>>> }
>>>>>
>>>>> Regards,
>>>>> Cheng
>>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: Peter Caspers [mailto:
[hidden email]]
>>>>> 发送时间: 2014年9月6日 20:48
>>>>> 收件人: Joseph Wang
>>>>> 抄送: QuantLib Mailing Lists
>>>>> 主题: Re: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>>>>>
>>>>> Hi Joseph, all,
>>>>>
>>>>> I added a wrapper for the dcmt library (Dynamic Creator of Mersenne
>>>>> Twisters).
>>>>>
>>>>>
https://github.com/lballabio/quantlib/pull/132>>>>>
>>>>> I 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.c>>>>>> lktrk _______________________________________________
>>>>>> 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>>>>>
Perforce version control. Predictably reliable.