quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] yield calculation failing when resulting yield should be less than -54.4%

[ltorjul <lt...@ho...>]

Hi,

Thanks for your answer!

I tested your suggestion and changed line 968 in the cashflows.cpp file to:
return solver.solve(objFunction, accuracy, guess, -10.0 , 10.0); 

This causes the error:
root not bracketed: f[-10,10] -> [-1.#IND00e+000,5.999990e+004]

I guess the reason is that a root of -10 cannot exist. If you look at the
question from a financial perspective, you can off course loose you entire
investment (Which would give a yield of -100%), but you could never get in
the situation where you owe money (i.e. yield cannot be < -100%). Not sure
if this makes any sense to you.

Anyway I tested with:
return solver.solve(objFunction, accuracy, guess, -1.0 , 10.0);
and this seems to work. I'm able to calculate yield in those extreme cases
where yield is less than -54.4%.

I have also tested the unmodified yield function with a difference initial
guess, e.g.
yield(frb, cleanPrice, dayCounter, QuantLib::Compounded, coupCompfrequency,
settlementDate, 1e-8, 100, *-0.80*)

and it seems that using an initial guess of -.8 (-80%) "moves" the limit
where the problem occures to about -91%. This however this causes the solver
to work about 15% slower :-(

Anyway I like the solution where you sets the upper and lower limits better.

I'm good with this solution. But if you have other ideas or remarks I would
be very grateful.

Regards Laurtiz




--
View this message in context: http://quantlib.10058.n7.nabble.com/yield-calculation-failing-when-resulting-yield-should-be-less-than-54-4-tp15932p15952.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] yield calculation failing when resulting yield should be less than -54.4%

[Peter C. <pca...@gm...>]

Hi,

I did not reproduce your case, but I know that in extreme situations
the yield bracketing fails to work, although a sensible solution
exists (e.g. if you have a cashflow -100 in a few days and +0.1 in 10
years, -69% continously compounded yield is a solution, but the
bracketing gives +147398 because then all discount factors are
numerically zero).

So my question is if the problem disappears if you replace line 968 in
cashflows.cpp from

        return solver.solve(objFunction, accuracy, guess, guess/10.0);

to (for example)

        return solver.solve(objFunction, accuracy, guess, -10.0 , 10.0);

This is not meant as a solution, only to understand your problem
better before suggesting anything.

Best regards
Peter


On 1 October 2014 16:26, ltorjul <lt...@ho...> wrote:
> Hi,
>
> I have a problem it seems that BondFunctions::Yield(...) is failing when the
> yield should be -54.4% or less (more negative). The yield function throws
> the exception: "unable to bracket root in 100 function evaluations(last
> bracket attempt: f[-2.29538e+025,5.968e+025] -> [-1.#END, 51.1682])".
>
> I have adjusted the price gradually and it seams that the most negative
> resulting yield I can compute without getting this error is -54,40688%.
>
> I have tested this with various types of bonds, both fixed rate and floating
> rate. And look to be that the error occurs at a prices that gives yields
> exactly this yield or less (more negative).
>
> Now, it may seem like a minor problem, when will prices be high enough to
> give such a negative yield?
>
> 1. What causes this error, and why at this point, logically yield should be
> able to anywhere from -100% to infinite positive)?
>
> 2. My scenario is that I want to compute duration and convexity for floating
> rate bonds. The street convention is to compute these with yield to next
> coupon date. Since I have not found any way to calculate yield to other
> dates than maturity, I fix this by creating a second floating rate bonds
> object with maturity equal to next coupon date for the first. Then using
> this to calculate yield to next coupon. In this situation the yield is often
> quite a bit negative, so this problem do occur quite often.
>
> Could somebody please look into this?
> Perhaps I can omit the entire problem by calculating yield to next coupon
> differently, but I cannot see how.
>
> Thanks in advance.
>
> Regards Lauritz
>
>
>
>
>
>
>
> --
> View this message in context: http://quantlib.10058.n7.nabble.com/yield-calculation-failing-when-resulting-yield-should-be-less-than-54-4-tp15932.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] MDRS Support

[Peter C. <pca...@gm...>]

Hi,

I am wondering if we want support classes in the core library to
interface commercial systems' market data and termstructures.
Specifically I am thinking about Murex which has a standardized XML
interface to export and import virtually all kind of market data
across all market data sets in its financial database.

The first step would be a class that represents the contents of such a
file and providing easy access to its market data points (in a more
user friendly way than a "stupid" general XML parser could do). To
keep the dependencies simple, I'd rely on RapidXML as the XML parser
for this part.

A second layer built on that would provide functionality to create
quantlib termstructures populated with that market data, based on meta
data (instruments in a curve, their conventions etc.) provided in
additional specification files (where parts of the necessary meta data
is even available in the Mx export and could - optionally - taken from
there). The other direction - create a MDRS file based on quantlib
termstructure objects that can be uploaded to Murex - can also be
interesting for certain applications.

All that should be done on an abstract level with specific
implementations for different source systems, of which one beneath
Murex MDRS could also be a simple "quantlib-proprietary" one, which
would allow to share reference / test market data and meta data for
associated concrete termstructure objects.

I am quite sure that this is both doable and useful (because I have
done parts of it and use it in my daily work). However it is some work
to set up the framework in a clean way and maintain it, for several
MDRS versions (some details sometimes change from release to release,
but the general structure seems stable).

So my questions are

- does that belong into the core library, like under ql / io / ... (
well, for a start under ql / experimental / io / ... ;-) )
- anyone else that would be interested in that functionality and maybe
willing to contribute to such a development ?
- maybe other systems that could be of interest (maybe the MarkIt CDS
market data files ?)

Thanks a lot
Peter

[Quantlib-dev] yield calculation failing when resulting yield should be less than -54.4%

[ltorjul <lt...@ho...>]

Hi,

I have a problem it seems that BondFunctions::Yield(...) is failing when the
yield should be -54.4% or less (more negative). The yield function throws
the exception: "unable to bracket root in 100 function evaluations(last
bracket attempt: f[-2.29538e+025,5.968e+025] -> [-1.#END, 51.1682])".

I have adjusted the price gradually and it seams that the most negative
resulting yield I can compute without getting this error is -54,40688%.

I have tested this with various types of bonds, both fixed rate and floating
rate. And look to be that the error occurs at a prices that gives yields
exactly this yield or less (more negative).

Now, it may seem like a minor problem, when will prices be high enough to
give such a negative yield?

1. What causes this error, and why at this point, logically yield should be
able to anywhere from -100% to infinite positive)?

2. My scenario is that I want to compute duration and convexity for floating
rate bonds. The street convention is to compute these with yield to next
coupon date. Since I have not found any way to calculate yield to other
dates than maturity, I fix this by creating a second floating rate bonds
object with maturity equal to next coupon date for the first. Then using
this to calculate yield to next coupon. In this situation the yield is often
quite a bit negative, so this problem do occur quite often.

Could somebody please look into this?
Perhaps I can omit the entire problem by calculating yield to next coupon
differently, but I cannot see how.

Thanks in advance.

Regards Lauritz







--
View this message in context: http://quantlib.10058.n7.nabble.com/yield-calculation-failing-when-resulting-yield-should-be-less-than-54-4-tp15932.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] help to cover quantlib domains renewal costs

[Ferdinando M. A. <fer...@am...>]

Hi all,

in almost 14 years nobody has ever asked for money in order to support
QuantLib, mainly because we used free resources and I personally paid for
the web domains (quantlib, quantlibbook, quantlibconsulting, quantlibxl, in
their com/org/net variety)

Between now and next March it's time to renew half of them including
quantlib.org, for about USD300. So this is the right time to test if there
is some gratitude and generosity in the QuantLib community that could help
cover these costs.

All donations are welcome, regardless of the amount:
bitcoins to 37Hz4jTS4rmBFrJNwhTKj4JmnuMKdUvbwe
PayPal to ferdinando AT ametrano DOT net

Bitcoin donations are preferred because they are without fees and (in case
you missed it) http://ssrn.com/abstract=2425270 :-)

In the case I'll receive more than USD300, I will set the extra amount
aside for the 2017 second batch of renewals and/or consult with Luigi and
Eric about how to use them.

thank you in advance
Nando

[Quantlib-dev] 答复: 答复: 答复: 答复: 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[cheng l. <scr...@gm...>]

Hi Peter,

On my side the performance is also improved. Now around 2.5 slow down. Thanks for your help.

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 2014年9月22日 16:05
收件人: cheng li
抄送: QuantLib Mailing Lists
主题: Re: 答复: 答复: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

yes, please. The slowdown on Windows on my office computer is around 1.6 now.
best regards
Peter

On 22 September 2014 03:48, cheng li <scr...@gm...> wrote:
> Hi Peter,
>
> Thanks for your effort. I'll definitely have a try:)
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月21日 23:11
> 收件人: cheng.li
> 抄送: QuantLib Mailing Lists
> 主题: Re: 答复: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic 
> Creator MT
>
> Hi Cheng,
>
> I switched to a template class for precomputed twisters, which is 
> faster by a factor of 2 (450ms instead of 870ms). This can be 
> instantiated with
>
> MersenneTwisterCustomRng<Mtdesc19937_5> mt(42);
>
> with 5 replaceable by 0 to 7 as before. The other is only needed now if you want to create a mt during runtime.
>
> The pull request is updated accordingly.
>
> Best regards
> Peter
>
>
>
>
> On 21 September 2014 08:11, cheng.li <scr...@gm...> wrote:
>> Hi Peter,
>>
>> Thanks for your hard work. I think our results are consistent.
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: Peter Caspers [mailto:pca...@gm...]
>> 发送时间: 2014年9月21日 0:33
>> 收件人: cheng li
>> 抄送: QuantLib Mailing Lists
>> 主题: Re: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic 
>> Creator MT
>>
>> Hi Cheng,
>>
>> sorry, this was my fault, I messed up the timings, because I did not use consistent optimizer flags when compiling the library and the test program.
>>
>> Actually on Windows (same machine on which I run Ubuntu, which 
>> doesn't really matter, because my computer in office gives very 
>> similar
>> timings) I get for 1E8 random numbers generated (with O2)
>>
>> 400ms / 1100ms
>>
>> for the original ql mt / dynamic creator mt. The ql mt is just as 
>> fast as the boost mt implementation by the way. On Ubuntu with gcc 
>> 4.8.1 and O3 I get
>>
>> 290ms / 870ms
>>
>> and with O2 a close value, for the creator mt 910ms. Also it makes no difference if I use gcc 4.9.1 or clang 3.6.0.
>>
>> If I directly call the original C routine without using the wrapper object, I get 720ms.
>>
>> If I use the original library and a C example (both compiled with O3, this is the configuration how the library is shipped (it has a hardcoded make file)) => 730ms.
>>
>> This means, the wrapper introduces a slow down by 20% which seems not too bad.
>>
>> Otherwise the dcmt is slower by a factor of around 2-3 compared to the original mt in all cases. Since this is already the case with the original library, I wouldn't try to do anything about it at the moment.
>>
>> What is your opinion on this ?
>>
>> Peter
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I compared dfiferent platforms again, but now on the _same_ machine - Original MT / Dynamic Creator MT (generation of 1E8 numbers, single threaded, with O2 (MSVC) and O3 (gcc, clang)). I also checked the boost implementation mt19937, which is very close to the ql original mt in all cases.
>>
>> Winodws / MSVC 2010 => 400ms / 1100ms Ubuntu / gcc 4.9.1 => 1200 ms / 
>> 1050 ms Ubuntu / gcc 4.8.1 => 1180 ms / 1040 ms Ubuntu / clang 3.6.0 
>> => 1340 ms / 1150 ms
>>
>> clang
>> 290
>> 720
>> 870
>>
>> (c 730)
>>
>> so it looks like MSVC does a specific optimization for the QL and boost mt19937, which does not apply on the other platforms and not the the dynamic creator mt.
>>
>> At the moment I stil don't know what it is.
>>
>> On 18 September 2014 03:33, cheng li <scr...@gm...> wrote:
>>> Let me try your statement once I have a time.
>>>
>>> Regards,
>>> Cheng
>>>
>>> -----邮件原件-----
>>> 发件人: cheng li [mailto:scr...@gm...]
>>> 发送时间: 2014年9月18日 9:18
>>> 收件人: 'Peter Caspers'
>>> 抄送: 'QuantLib Mailing Lists'
>>> 主题: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic 
>>> Creator MT
>>>
>>> Hi Peter,
>>>
>>> I used gcc 4.8.2.
>>>
>>> My result with O3 optimization is still not good. Similar 
>>> performance of new MT ( about 3~4X speed down)
>>>
>>> I used such statement to turn on o3 optimization before I do 
>>> ./configure for QuantLib,
>>>
>>> Export CXXFLAGS="-g -O3"
>>>
>>> Am I right?
>>>
>>> Regards,
>>> Cheng
>>>
>>> -----邮件原件-----
>>> 发件人: Peter Caspers [mailto:pca...@gm...]
>>> 发送时间: 2014年9月18日 0:36
>>> 收件人: cheng li
>>> 抄送: QuantLib Mailing Lists
>>> 主题: Re: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic 
>>> Creator MT
>>>
>>> with gcc 4.9.1 and O2 the new mt is a bit slower than the original one (but only by a factor of 1.1).
>>> I have to add both -frename-registers, -finline-functions to -O2 to get the speed up back I mentioned before.
>>>
>>> Which compiler do you use on Ubuntu ?
>>>
>>> Peter
>>>
>>>
>>>
>>> On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
>>>> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>>>>
>>>> I'll try -O3 on my machine also with Ubuntu.
>>>>
>>>> Regards,
>>>> Cheng
>>>>
>>>> -----邮件原件-----
>>>> 发件人: Peter Caspers [mailto:pca...@gm...]
>>>> 发送时间: 2014年9月17日 0:32
>>>> 收件人: Cheng Li; QuantLib Mailing Lists
>>>> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator 
>>>> MT
>>>>
>>>> Hi Cheng,
>>>>
>>>> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>>>>
>>>> Does anyone have an idea where the different behaviour under gcc / 
>>>> linux and msvc might come from (and how to improve the msvc side if
>>>> possible) ?
>>>>
>>>> Kind regards
>>>> Peter
>>>>
>>>>
>>>>
>>>> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>>>>> Thanks Peter.
>>>>>
>>>>> Regards,
>>>>> Cheng
>>>>>
>>>>> 发自我的 iPad
>>>>>
>>>>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>>>>
>>>>>> 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 <scr...@gm...>:
>>>>>>>
>>>>>>> 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 <pca...@gm...> 写道：
>>>>>>>>
>>>>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>>>>> 发送时间: 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 <joe...@gm...> 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=/41
>>>>>>>>>> 4
>>>>>>>>>> 0 / o stg.c lktrk
>>>>>>>>>> _______________________________________________
>>>>>>>>>> QuantLib-dev mailing list
>>>>>>>>>> Qua...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> ----------
>>>>>>>>> --
>>>>>>>>> Slashdot TV.
>>>>>>>>> Video for Nerds.  Stuff that matters.
>>>>>>>>> http://tv.slashdot.org/
>>>>>>>>> _______________________________________________
>>>>>>>>> QuantLib-dev mailing list
>>>>>>>>> Qua...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>>>
>>>>
>>>
>>>
>>
>

Re: [Quantlib-dev] 答复: 答复: 答复: 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[Peter C. <pca...@gm...>]

yes, please. The slowdown on Windows on my office computer is around 1.6 now.
best regards
Peter

On 22 September 2014 03:48, cheng li <scr...@gm...> wrote:
> Hi Peter,
>
> Thanks for your effort. I'll definitely have a try:)
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月21日 23:11
> 收件人: cheng.li
> 抄送: QuantLib Mailing Lists
> 主题: Re: 答复: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>
> Hi Cheng,
>
> I switched to a template class for precomputed twisters, which is faster by a factor of 2 (450ms instead of 870ms). This can be instantiated with
>
> MersenneTwisterCustomRng<Mtdesc19937_5> mt(42);
>
> with 5 replaceable by 0 to 7 as before. The other is only needed now if you want to create a mt during runtime.
>
> The pull request is updated accordingly.
>
> Best regards
> Peter
>
>
>
>
> On 21 September 2014 08:11, cheng.li <scr...@gm...> wrote:
>> Hi Peter,
>>
>> Thanks for your hard work. I think our results are consistent.
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: Peter Caspers [mailto:pca...@gm...]
>> 发送时间: 2014年9月21日 0:33
>> 收件人: cheng li
>> 抄送: QuantLib Mailing Lists
>> 主题: Re: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic
>> Creator MT
>>
>> Hi Cheng,
>>
>> sorry, this was my fault, I messed up the timings, because I did not use consistent optimizer flags when compiling the library and the test program.
>>
>> Actually on Windows (same machine on which I run Ubuntu, which doesn't
>> really matter, because my computer in office gives very similar
>> timings) I get for 1E8 random numbers generated (with O2)
>>
>> 400ms / 1100ms
>>
>> for the original ql mt / dynamic creator mt. The ql mt is just as fast
>> as the boost mt implementation by the way. On Ubuntu with gcc 4.8.1
>> and O3 I get
>>
>> 290ms / 870ms
>>
>> and with O2 a close value, for the creator mt 910ms. Also it makes no difference if I use gcc 4.9.1 or clang 3.6.0.
>>
>> If I directly call the original C routine without using the wrapper object, I get 720ms.
>>
>> If I use the original library and a C example (both compiled with O3, this is the configuration how the library is shipped (it has a hardcoded make file)) => 730ms.
>>
>> This means, the wrapper introduces a slow down by 20% which seems not too bad.
>>
>> Otherwise the dcmt is slower by a factor of around 2-3 compared to the original mt in all cases. Since this is already the case with the original library, I wouldn't try to do anything about it at the moment.
>>
>> What is your opinion on this ?
>>
>> Peter
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I compared dfiferent platforms again, but now on the _same_ machine - Original MT / Dynamic Creator MT (generation of 1E8 numbers, single threaded, with O2 (MSVC) and O3 (gcc, clang)). I also checked the boost implementation mt19937, which is very close to the ql original mt in all cases.
>>
>> Winodws / MSVC 2010 => 400ms / 1100ms
>> Ubuntu / gcc 4.9.1 => 1200 ms / 1050 ms Ubuntu / gcc 4.8.1 => 1180 ms
>> / 1040 ms Ubuntu / clang 3.6.0 => 1340 ms / 1150 ms
>>
>> clang
>> 290
>> 720
>> 870
>>
>> (c 730)
>>
>> so it looks like MSVC does a specific optimization for the QL and boost mt19937, which does not apply on the other platforms and not the the dynamic creator mt.
>>
>> At the moment I stil don't know what it is.
>>
>> On 18 September 2014 03:33, cheng li <scr...@gm...> wrote:
>>> Let me try your statement once I have a time.
>>>
>>> Regards,
>>> Cheng
>>>
>>> -----邮件原件-----
>>> 发件人: cheng li [mailto:scr...@gm...]
>>> 发送时间: 2014年9月18日 9:18
>>> 收件人: 'Peter Caspers'
>>> 抄送: 'QuantLib Mailing Lists'
>>> 主题: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic
>>> Creator MT
>>>
>>> Hi Peter,
>>>
>>> I used gcc 4.8.2.
>>>
>>> My result with O3 optimization is still not good. Similar performance
>>> of new MT ( about 3~4X speed down)
>>>
>>> I used such statement to turn on o3 optimization before I do
>>> ./configure for QuantLib,
>>>
>>> Export CXXFLAGS="-g -O3"
>>>
>>> Am I right?
>>>
>>> Regards,
>>> Cheng
>>>
>>> -----邮件原件-----
>>> 发件人: Peter Caspers [mailto:pca...@gm...]
>>> 发送时间: 2014年9月18日 0:36
>>> 收件人: cheng li
>>> 抄送: QuantLib Mailing Lists
>>> 主题: Re: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic
>>> Creator MT
>>>
>>> with gcc 4.9.1 and O2 the new mt is a bit slower than the original one (but only by a factor of 1.1).
>>> I have to add both -frename-registers, -finline-functions to -O2 to get the speed up back I mentioned before.
>>>
>>> Which compiler do you use on Ubuntu ?
>>>
>>> Peter
>>>
>>>
>>>
>>> On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
>>>> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>>>>
>>>> I'll try -O3 on my machine also with Ubuntu.
>>>>
>>>> Regards,
>>>> Cheng
>>>>
>>>> -----邮件原件-----
>>>> 发件人: Peter Caspers [mailto:pca...@gm...]
>>>> 发送时间: 2014年9月17日 0:32
>>>> 收件人: Cheng Li; QuantLib Mailing Lists
>>>> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator
>>>> MT
>>>>
>>>> Hi Cheng,
>>>>
>>>> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>>>>
>>>> Does anyone have an idea where the different behaviour under gcc /
>>>> linux and msvc might come from (and how to improve the msvc side if
>>>> possible) ?
>>>>
>>>> Kind regards
>>>> Peter
>>>>
>>>>
>>>>
>>>> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>>>>> Thanks Peter.
>>>>>
>>>>> Regards,
>>>>> Cheng
>>>>>
>>>>> 发自我的 iPad
>>>>>
>>>>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>>>>
>>>>>> 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 <scr...@gm...>:
>>>>>>>
>>>>>>> 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 <pca...@gm...> 写道：
>>>>>>>>
>>>>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>>>>> 发送时间: 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 <joe...@gm...> 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=/414
>>>>>>>>>> 0 / o stg.c lktrk
>>>>>>>>>> _______________________________________________
>>>>>>>>>> QuantLib-dev mailing list
>>>>>>>>>> Qua...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> ----------
>>>>>>>>> --
>>>>>>>>> Slashdot TV.
>>>>>>>>> Video for Nerds.  Stuff that matters.
>>>>>>>>> http://tv.slashdot.org/
>>>>>>>>> _______________________________________________
>>>>>>>>> QuantLib-dev mailing list
>>>>>>>>> Qua...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>>>
>>>>
>>>
>>>
>>
>

[Quantlib-dev] 答复: 答复: 答复: 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[cheng l. <scr...@gm...>]

Hi Peter,

Thanks for your effort. I'll definitely have a try:)

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 2014年9月21日 23:11
收件人: cheng.li
抄送: QuantLib Mailing Lists
主题: Re: 答复: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

Hi Cheng,

I switched to a template class for precomputed twisters, which is faster by a factor of 2 (450ms instead of 870ms). This can be instantiated with

MersenneTwisterCustomRng<Mtdesc19937_5> mt(42);

with 5 replaceable by 0 to 7 as before. The other is only needed now if you want to create a mt during runtime.

The pull request is updated accordingly.

Best regards
Peter




On 21 September 2014 08:11, cheng.li <scr...@gm...> wrote:
> Hi Peter,
>
> Thanks for your hard work. I think our results are consistent.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月21日 0:33
> 收件人: cheng li
> 抄送: QuantLib Mailing Lists
> 主题: Re: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic 
> Creator MT
>
> Hi Cheng,
>
> sorry, this was my fault, I messed up the timings, because I did not use consistent optimizer flags when compiling the library and the test program.
>
> Actually on Windows (same machine on which I run Ubuntu, which doesn't 
> really matter, because my computer in office gives very similar
> timings) I get for 1E8 random numbers generated (with O2)
>
> 400ms / 1100ms
>
> for the original ql mt / dynamic creator mt. The ql mt is just as fast 
> as the boost mt implementation by the way. On Ubuntu with gcc 4.8.1 
> and O3 I get
>
> 290ms / 870ms
>
> and with O2 a close value, for the creator mt 910ms. Also it makes no difference if I use gcc 4.9.1 or clang 3.6.0.
>
> If I directly call the original C routine without using the wrapper object, I get 720ms.
>
> If I use the original library and a C example (both compiled with O3, this is the configuration how the library is shipped (it has a hardcoded make file)) => 730ms.
>
> This means, the wrapper introduces a slow down by 20% which seems not too bad.
>
> Otherwise the dcmt is slower by a factor of around 2-3 compared to the original mt in all cases. Since this is already the case with the original library, I wouldn't try to do anything about it at the moment.
>
> What is your opinion on this ?
>
> Peter
>
>
>
>
>
>
>
>
>
>
>
>
> I compared dfiferent platforms again, but now on the _same_ machine - Original MT / Dynamic Creator MT (generation of 1E8 numbers, single threaded, with O2 (MSVC) and O3 (gcc, clang)). I also checked the boost implementation mt19937, which is very close to the ql original mt in all cases.
>
> Winodws / MSVC 2010 => 400ms / 1100ms
> Ubuntu / gcc 4.9.1 => 1200 ms / 1050 ms Ubuntu / gcc 4.8.1 => 1180 ms 
> / 1040 ms Ubuntu / clang 3.6.0 => 1340 ms / 1150 ms
>
> clang
> 290
> 720
> 870
>
> (c 730)
>
> so it looks like MSVC does a specific optimization for the QL and boost mt19937, which does not apply on the other platforms and not the the dynamic creator mt.
>
> At the moment I stil don't know what it is.
>
> On 18 September 2014 03:33, cheng li <scr...@gm...> wrote:
>> Let me try your statement once I have a time.
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: cheng li [mailto:scr...@gm...]
>> 发送时间: 2014年9月18日 9:18
>> 收件人: 'Peter Caspers'
>> 抄送: 'QuantLib Mailing Lists'
>> 主题: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic 
>> Creator MT
>>
>> Hi Peter,
>>
>> I used gcc 4.8.2.
>>
>> My result with O3 optimization is still not good. Similar performance 
>> of new MT ( about 3~4X speed down)
>>
>> I used such statement to turn on o3 optimization before I do 
>> ./configure for QuantLib,
>>
>> Export CXXFLAGS="-g -O3"
>>
>> Am I right?
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: Peter Caspers [mailto:pca...@gm...]
>> 发送时间: 2014年9月18日 0:36
>> 收件人: cheng li
>> 抄送: QuantLib Mailing Lists
>> 主题: Re: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic 
>> Creator MT
>>
>> with gcc 4.9.1 and O2 the new mt is a bit slower than the original one (but only by a factor of 1.1).
>> I have to add both -frename-registers, -finline-functions to -O2 to get the speed up back I mentioned before.
>>
>> Which compiler do you use on Ubuntu ?
>>
>> Peter
>>
>>
>>
>> On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
>>> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>>>
>>> I'll try -O3 on my machine also with Ubuntu.
>>>
>>> Regards,
>>> Cheng
>>>
>>> -----邮件原件-----
>>> 发件人: Peter Caspers [mailto:pca...@gm...]
>>> 发送时间: 2014年9月17日 0:32
>>> 收件人: Cheng Li; QuantLib Mailing Lists
>>> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator 
>>> MT
>>>
>>> Hi Cheng,
>>>
>>> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>>>
>>> Does anyone have an idea where the different behaviour under gcc / 
>>> linux and msvc might come from (and how to improve the msvc side if
>>> possible) ?
>>>
>>> Kind regards
>>> Peter
>>>
>>>
>>>
>>> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>>>> Thanks Peter.
>>>>
>>>> Regards,
>>>> Cheng
>>>>
>>>> 发自我的 iPad
>>>>
>>>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>>>
>>>>> 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 <scr...@gm...>:
>>>>>>
>>>>>> 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 <pca...@gm...> 写道：
>>>>>>>
>>>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>>>> 发送时间: 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 <joe...@gm...> 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=/414
>>>>>>>>> 0 / o stg.c lktrk 
>>>>>>>>> _______________________________________________
>>>>>>>>> QuantLib-dev mailing list
>>>>>>>>> Qua...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> -
>>>>>>>> ----------
>>>>>>>> --
>>>>>>>> Slashdot TV.
>>>>>>>> Video for Nerds.  Stuff that matters.
>>>>>>>> http://tv.slashdot.org/
>>>>>>>> _______________________________________________
>>>>>>>> QuantLib-dev mailing list
>>>>>>>> Qua...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>>
>>>
>>
>>
>

Re: [Quantlib-dev] 答复: 答复: 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[Peter C. <pca...@gm...>]

Hi Cheng,

I switched to a template class for precomputed twisters, which is
faster by a factor of 2 (450ms instead of 870ms). This can be
instantiated with

MersenneTwisterCustomRng<Mtdesc19937_5> mt(42);

with 5 replaceable by 0 to 7 as before. The other is only needed now
if you want to create a mt during runtime.

The pull request is updated accordingly.

Best regards
Peter




On 21 September 2014 08:11, cheng.li <scr...@gm...> wrote:
> Hi Peter,
>
> Thanks for your hard work. I think our results are consistent.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月21日 0:33
> 收件人: cheng li
> 抄送: QuantLib Mailing Lists
> 主题: Re: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>
> Hi Cheng,
>
> sorry, this was my fault, I messed up the timings, because I did not use consistent optimizer flags when compiling the library and the test program.
>
> Actually on Windows (same machine on which I run Ubuntu, which doesn't really matter, because my computer in office gives very similar
> timings) I get for 1E8 random numbers generated (with O2)
>
> 400ms / 1100ms
>
> for the original ql mt / dynamic creator mt. The ql mt is just as fast as the boost mt implementation by the way. On Ubuntu with gcc 4.8.1 and O3 I get
>
> 290ms / 870ms
>
> and with O2 a close value, for the creator mt 910ms. Also it makes no difference if I use gcc 4.9.1 or clang 3.6.0.
>
> If I directly call the original C routine without using the wrapper object, I get 720ms.
>
> If I use the original library and a C example (both compiled with O3, this is the configuration how the library is shipped (it has a hardcoded make file)) => 730ms.
>
> This means, the wrapper introduces a slow down by 20% which seems not too bad.
>
> Otherwise the dcmt is slower by a factor of around 2-3 compared to the original mt in all cases. Since this is already the case with the original library, I wouldn't try to do anything about it at the moment.
>
> What is your opinion on this ?
>
> Peter
>
>
>
>
>
>
>
>
>
>
>
>
> I compared dfiferent platforms again, but now on the _same_ machine - Original MT / Dynamic Creator MT (generation of 1E8 numbers, single threaded, with O2 (MSVC) and O3 (gcc, clang)). I also checked the boost implementation mt19937, which is very close to the ql original mt in all cases.
>
> Winodws / MSVC 2010 => 400ms / 1100ms
> Ubuntu / gcc 4.9.1 => 1200 ms / 1050 ms
> Ubuntu / gcc 4.8.1 => 1180 ms / 1040 ms
> Ubuntu / clang 3.6.0 => 1340 ms / 1150 ms
>
> clang
> 290
> 720
> 870
>
> (c 730)
>
> so it looks like MSVC does a specific optimization for the QL and boost mt19937, which does not apply on the other platforms and not the the dynamic creator mt.
>
> At the moment I stil don't know what it is.
>
> On 18 September 2014 03:33, cheng li <scr...@gm...> wrote:
>> Let me try your statement once I have a time.
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: cheng li [mailto:scr...@gm...]
>> 发送时间: 2014年9月18日 9:18
>> 收件人: 'Peter Caspers'
>> 抄送: 'QuantLib Mailing Lists'
>> 主题: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator
>> MT
>>
>> Hi Peter,
>>
>> I used gcc 4.8.2.
>>
>> My result with O3 optimization is still not good. Similar performance
>> of new MT ( about 3~4X speed down)
>>
>> I used such statement to turn on o3 optimization before I do
>> ./configure for QuantLib,
>>
>> Export CXXFLAGS="-g -O3"
>>
>> Am I right?
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: Peter Caspers [mailto:pca...@gm...]
>> 发送时间: 2014年9月18日 0:36
>> 收件人: cheng li
>> 抄送: QuantLib Mailing Lists
>> 主题: Re: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator
>> MT
>>
>> with gcc 4.9.1 and O2 the new mt is a bit slower than the original one (but only by a factor of 1.1).
>> I have to add both -frename-registers, -finline-functions to -O2 to get the speed up back I mentioned before.
>>
>> Which compiler do you use on Ubuntu ?
>>
>> Peter
>>
>>
>>
>> On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
>>> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>>>
>>> I'll try -O3 on my machine also with Ubuntu.
>>>
>>> Regards,
>>> Cheng
>>>
>>> -----邮件原件-----
>>> 发件人: Peter Caspers [mailto:pca...@gm...]
>>> 发送时间: 2014年9月17日 0:32
>>> 收件人: Cheng Li; QuantLib Mailing Lists
>>> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>>>
>>> Hi Cheng,
>>>
>>> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>>>
>>> Does anyone have an idea where the different behaviour under gcc /
>>> linux and msvc might come from (and how to improve the msvc side if
>>> possible) ?
>>>
>>> Kind regards
>>> Peter
>>>
>>>
>>>
>>> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>>>> Thanks Peter.
>>>>
>>>> Regards,
>>>> Cheng
>>>>
>>>> 发自我的 iPad
>>>>
>>>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>>>
>>>>> 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 <scr...@gm...>:
>>>>>>
>>>>>> 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 <pca...@gm...> 写道：
>>>>>>>
>>>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>>>> 发送时间: 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 <joe...@gm...> 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
>>>>>>>>> / o stg.c lktrk _______________________________________________
>>>>>>>>> QuantLib-dev mailing list
>>>>>>>>> Qua...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -
>>>>>>>> -
>>>>>>>> ----------
>>>>>>>> --
>>>>>>>> Slashdot TV.
>>>>>>>> Video for Nerds.  Stuff that matters.
>>>>>>>> http://tv.slashdot.org/
>>>>>>>> _______________________________________________
>>>>>>>> QuantLib-dev mailing list
>>>>>>>> Qua...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>>
>>>
>>
>>
>

[Quantlib-dev] 答复: 答复: 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[cheng.li <scr...@gm...>]

Hi Peter,

Thanks for your hard work. I think our results are consistent. 

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 2014年9月21日 0:33
收件人: cheng li
抄送: QuantLib Mailing Lists
主题: Re: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

Hi Cheng,

sorry, this was my fault, I messed up the timings, because I did not use consistent optimizer flags when compiling the library and the test program.

Actually on Windows (same machine on which I run Ubuntu, which doesn't really matter, because my computer in office gives very similar
timings) I get for 1E8 random numbers generated (with O2)

400ms / 1100ms

for the original ql mt / dynamic creator mt. The ql mt is just as fast as the boost mt implementation by the way. On Ubuntu with gcc 4.8.1 and O3 I get

290ms / 870ms

and with O2 a close value, for the creator mt 910ms. Also it makes no difference if I use gcc 4.9.1 or clang 3.6.0.

If I directly call the original C routine without using the wrapper object, I get 720ms.

If I use the original library and a C example (both compiled with O3, this is the configuration how the library is shipped (it has a hardcoded make file)) => 730ms.

This means, the wrapper introduces a slow down by 20% which seems not too bad.

Otherwise the dcmt is slower by a factor of around 2-3 compared to the original mt in all cases. Since this is already the case with the original library, I wouldn't try to do anything about it at the moment.

What is your opinion on this ?

Peter












I compared dfiferent platforms again, but now on the _same_ machine - Original MT / Dynamic Creator MT (generation of 1E8 numbers, single threaded, with O2 (MSVC) and O3 (gcc, clang)). I also checked the boost implementation mt19937, which is very close to the ql original mt in all cases.

Winodws / MSVC 2010 => 400ms / 1100ms
Ubuntu / gcc 4.9.1 => 1200 ms / 1050 ms
Ubuntu / gcc 4.8.1 => 1180 ms / 1040 ms
Ubuntu / clang 3.6.0 => 1340 ms / 1150 ms

clang
290
720
870

(c 730)

so it looks like MSVC does a specific optimization for the QL and boost mt19937, which does not apply on the other platforms and not the the dynamic creator mt.

At the moment I stil don't know what it is.

On 18 September 2014 03:33, cheng li <scr...@gm...> wrote:
> Let me try your statement once I have a time.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: cheng li [mailto:scr...@gm...]
> 发送时间: 2014年9月18日 9:18
> 收件人: 'Peter Caspers'
> 抄送: 'QuantLib Mailing Lists'
> 主题: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator 
> MT
>
> Hi Peter,
>
> I used gcc 4.8.2.
>
> My result with O3 optimization is still not good. Similar performance 
> of new MT ( about 3~4X speed down)
>
> I used such statement to turn on o3 optimization before I do 
> ./configure for QuantLib,
>
> Export CXXFLAGS="-g -O3"
>
> Am I right?
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月18日 0:36
> 收件人: cheng li
> 抄送: QuantLib Mailing Lists
> 主题: Re: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator 
> MT
>
> with gcc 4.9.1 and O2 the new mt is a bit slower than the original one (but only by a factor of 1.1).
> I have to add both -frename-registers, -finline-functions to -O2 to get the speed up back I mentioned before.
>
> Which compiler do you use on Ubuntu ?
>
> Peter
>
>
>
> On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
>> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>>
>> I'll try -O3 on my machine also with Ubuntu.
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: Peter Caspers [mailto:pca...@gm...]
>> 发送时间: 2014年9月17日 0:32
>> 收件人: Cheng Li; QuantLib Mailing Lists
>> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>>
>> Hi Cheng,
>>
>> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>>
>> Does anyone have an idea where the different behaviour under gcc / 
>> linux and msvc might come from (and how to improve the msvc side if
>> possible) ?
>>
>> Kind regards
>> Peter
>>
>>
>>
>> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>>> Thanks Peter.
>>>
>>> Regards,
>>> Cheng
>>>
>>> 发自我的 iPad
>>>
>>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>>
>>>> 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 <scr...@gm...>:
>>>>>
>>>>> 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 <pca...@gm...> 写道：
>>>>>>
>>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>>> 发送时间: 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 <joe...@gm...> 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
>>>>>>>> / o stg.c lktrk _______________________________________________
>>>>>>>> QuantLib-dev mailing list
>>>>>>>> Qua...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> -
>>>>>>> -
>>>>>>> ----------
>>>>>>> --
>>>>>>> Slashdot TV.
>>>>>>> Video for Nerds.  Stuff that matters.
>>>>>>> http://tv.slashdot.org/
>>>>>>> _______________________________________________
>>>>>>> QuantLib-dev mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>
>>
>
>

Re: [Quantlib-dev] 答复: 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[Peter C. <pca...@gm...>]

Hi Cheng,

sorry, this was my fault, I messed up the timings, because I did not
use consistent optimizer flags when compiling the library and the test
program.

Actually on Windows (same machine on which I run Ubuntu, which doesn't
really matter, because my computer in office gives very similar
timings) I get for 1E8 random numbers generated (with O2)

400ms / 1100ms

for the original ql mt / dynamic creator mt. The ql mt is just as fast
as the boost mt implementation by the way. On Ubuntu with gcc 4.8.1
and O3 I get

290ms / 870ms

and with O2 a close value, for the creator mt 910ms. Also it makes no
difference if I use gcc 4.9.1 or clang 3.6.0.

If I directly call the original C routine without using the wrapper
object, I get 720ms.

If I use the original library and a C example (both compiled with O3,
this is the configuration how the library is shipped (it has a
hardcoded make file)) => 730ms.

This means, the wrapper introduces a slow down by 20% which seems not too bad.

Otherwise the dcmt is slower by a factor of around 2-3 compared to the
original mt in all cases. Since this is already the case with the
original library, I wouldn't try to do anything about it at the
moment.

What is your opinion on this ?

Peter












I compared dfiferent platforms again, but now on the _same_ machine -
Original MT / Dynamic Creator MT (generation of 1E8 numbers, single
threaded, with O2 (MSVC) and O3 (gcc, clang)). I also checked the
boost implementation mt19937, which is very close to the ql original
mt in all cases.

Winodws / MSVC 2010 => 400ms / 1100ms
Ubuntu / gcc 4.9.1 => 1200 ms / 1050 ms
Ubuntu / gcc 4.8.1 => 1180 ms / 1040 ms
Ubuntu / clang 3.6.0 => 1340 ms / 1150 ms

clang
290
720
870

(c 730)

so it looks like MSVC does a specific optimization for the QL and
boost mt19937, which does not apply on the other platforms and not the
the dynamic creator mt.

At the moment I stil don't know what it is.

On 18 September 2014 03:33, cheng li <scr...@gm...> wrote:
> Let me try your statement once I have a time.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: cheng li [mailto:scr...@gm...]
> 发送时间: 2014年9月18日 9:18
> 收件人: 'Peter Caspers'
> 抄送: 'QuantLib Mailing Lists'
> 主题: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>
> Hi Peter,
>
> I used gcc 4.8.2.
>
> My result with O3 optimization is still not good. Similar performance of new MT ( about 3~4X speed down)
>
> I used such statement to turn on o3 optimization before I do ./configure for QuantLib,
>
> Export CXXFLAGS="-g -O3"
>
> Am I right?
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月18日 0:36
> 收件人: cheng li
> 抄送: QuantLib Mailing Lists
> 主题: Re: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>
> with gcc 4.9.1 and O2 the new mt is a bit slower than the original one (but only by a factor of 1.1).
> I have to add both -frename-registers, -finline-functions to -O2 to get the speed up back I mentioned before.
>
> Which compiler do you use on Ubuntu ?
>
> Peter
>
>
>
> On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
>> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>>
>> I'll try -O3 on my machine also with Ubuntu.
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: Peter Caspers [mailto:pca...@gm...]
>> 发送时间: 2014年9月17日 0:32
>> 收件人: Cheng Li; QuantLib Mailing Lists
>> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>>
>> Hi Cheng,
>>
>> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>>
>> Does anyone have an idea where the different behaviour under gcc /
>> linux and msvc might come from (and how to improve the msvc side if
>> possible) ?
>>
>> Kind regards
>> Peter
>>
>>
>>
>> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>>> Thanks Peter.
>>>
>>> Regards,
>>> Cheng
>>>
>>> 发自我的 iPad
>>>
>>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>>
>>>> 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 <scr...@gm...>:
>>>>>
>>>>> 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 <pca...@gm...> 写道：
>>>>>>
>>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>>> 发送时间: 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 <joe...@gm...> 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/
>>>>>>>> o stg.c lktrk _______________________________________________
>>>>>>>> QuantLib-dev mailing list
>>>>>>>> Qua...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> -
>>>>>>> ----------
>>>>>>> --
>>>>>>> Slashdot TV.
>>>>>>> Video for Nerds.  Stuff that matters.
>>>>>>> http://tv.slashdot.org/
>>>>>>> _______________________________________________
>>>>>>> QuantLib-dev mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>>
>>
>
>

[Quantlib-dev] 答复: 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[cheng l. <scr...@gm...>]

Let me try your statement once I have a time.

Regards,
Cheng

-----邮件原件-----
发件人: cheng li [mailto:scr...@gm...] 
发送时间: 2014年9月18日 9:18
收件人: 'Peter Caspers'
抄送: 'QuantLib Mailing Lists'
主题: 答复: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

Hi Peter,

I used gcc 4.8.2.

My result with O3 optimization is still not good. Similar performance of new MT ( about 3~4X speed down)

I used such statement to turn on o3 optimization before I do ./configure for QuantLib,

Export CXXFLAGS="-g -O3"

Am I right?

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...]
发送时间: 2014年9月18日 0:36
收件人: cheng li
抄送: QuantLib Mailing Lists
主题: Re: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

with gcc 4.9.1 and O2 the new mt is a bit slower than the original one (but only by a factor of 1.1).
I have to add both -frename-registers, -finline-functions to -O2 to get the speed up back I mentioned before.

Which compiler do you use on Ubuntu ?

Peter



On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>
> I'll try -O3 on my machine also with Ubuntu.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月17日 0:32
> 收件人: Cheng Li; QuantLib Mailing Lists
> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>
> Hi Cheng,
>
> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>
> Does anyone have an idea where the different behaviour under gcc / 
> linux and msvc might come from (and how to improve the msvc side if
> possible) ?
>
> Kind regards
> Peter
>
>
>
> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>> Thanks Peter.
>>
>> Regards,
>> Cheng
>>
>> 发自我的 iPad
>>
>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>
>>> 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 <scr...@gm...>:
>>>>
>>>> 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 <pca...@gm...> 写道：
>>>>>
>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>> 发送时间: 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 <joe...@gm...> 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/
>>>>>>> o stg.c lktrk _______________________________________________
>>>>>>> QuantLib-dev mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -
>>>>>> ----------
>>>>>> --
>>>>>> Slashdot TV.
>>>>>> Video for Nerds.  Stuff that matters.
>>>>>> http://tv.slashdot.org/
>>>>>> _______________________________________________
>>>>>> QuantLib-dev mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>
>

[Quantlib-dev] 答复: 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[cheng l. <scr...@gm...>]

Hi Peter,

I used gcc 4.8.2.

My result with O3 optimization is still not good. Similar performance of new MT ( about 3~4X speed down)

I used such statement to turn on o3 optimization before I do ./configure for QuantLib,

Export CXXFLAGS="-g -O3"

Am I right?

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 2014年9月18日 0:36
收件人: cheng li
抄送: QuantLib Mailing Lists
主题: Re: 答复: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

with gcc 4.9.1 and O2 the new mt is a bit slower than the original one (but only by a factor of 1.1).
I have to add both -frename-registers, -finline-functions to -O2 to get the speed up back I mentioned before.

Which compiler do you use on Ubuntu ?

Peter



On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>
> I'll try -O3 on my machine also with Ubuntu.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月17日 0:32
> 收件人: Cheng Li; QuantLib Mailing Lists
> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>
> Hi Cheng,
>
> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>
> Does anyone have an idea where the different behaviour under gcc / 
> linux and msvc might come from (and how to improve the msvc side if
> possible) ?
>
> Kind regards
> Peter
>
>
>
> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>> Thanks Peter.
>>
>> Regards,
>> Cheng
>>
>> 发自我的 iPad
>>
>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>
>>> 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 <scr...@gm...>:
>>>>
>>>> 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 <pca...@gm...> 写道：
>>>>>
>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>> 发送时间: 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 <joe...@gm...> 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/
>>>>>>> o stg.c lktrk _______________________________________________
>>>>>>> QuantLib-dev mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -
>>>>>> ----------
>>>>>> --
>>>>>> Slashdot TV.
>>>>>> Video for Nerds.  Stuff that matters.
>>>>>> http://tv.slashdot.org/
>>>>>> _______________________________________________
>>>>>> QuantLib-dev mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>
>

Re: [Quantlib-dev] 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[Peter C. <pca...@gm...>]

with gcc 4.9.1 and O2 the new mt is a bit slower than the original one
(but only by a factor of 1.1).
I have to add both -frename-registers, -finline-functions to -O2 to
get the speed up back I mentioned before.

Which compiler do you use on Ubuntu ?

Peter



On 17 September 2014 03:26, cheng li <scr...@gm...> wrote:
> Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.
>
> I'll try -O3 on my machine also with Ubuntu.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年9月17日 0:32
> 收件人: Cheng Li; QuantLib Mailing Lists
> 主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT
>
> Hi Cheng,
>
> indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).
>
> Does anyone have an idea where the different behaviour under gcc / linux and msvc might come from (and how to improve the msvc side if
> possible) ?
>
> Kind regards
> Peter
>
>
>
> On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
>> Thanks Peter.
>>
>> Regards,
>> Cheng
>>
>> 发自我的 iPad
>>
>>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>>
>>> 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 <scr...@gm...>:
>>>>
>>>> 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 <pca...@gm...> 写道：
>>>>>
>>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>>> 发送时间: 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 <joe...@gm...> 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/o
>>>>>>> stg.c lktrk _______________________________________________
>>>>>>> QuantLib-dev mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> ----------
>>>>>> --
>>>>>> Slashdot TV.
>>>>>> Video for Nerds.  Stuff that matters.
>>>>>> http://tv.slashdot.org/
>>>>>> _______________________________________________
>>>>>> QuantLib-dev mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>>
>

[Quantlib-dev] 答复: 答复: Openmp work on mcarlo : Dynamic Creator MT

[cheng l. <scr...@gm...>]

Thanks Peter. I test on Ubuntu also, about 3~4X lower with -O2 optiomization.

I'll try -O3 on my machine also with Ubuntu.

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 2014年9月17日 0:32
收件人: Cheng Li; QuantLib Mailing Lists
主题: Re: 答复: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

Hi Cheng,

indeed with msvc I get a slow down with a factor of ~2.8x. As I said, under gcc it is a speed up ~ 0.8x (with -O3).

Does anyone have an idea where the different behaviour under gcc / linux and msvc might come from (and how to improve the msvc side if
possible) ?

Kind regards
Peter



On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
> Thanks Peter.
>
> Regards,
> Cheng
>
> 发自我的 iPad
>
>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>
>> 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 <scr...@gm...>:
>>>
>>> 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 <pca...@gm...> 写道：
>>>>
>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>> 发送时间: 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 <joe...@gm...> 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/o
>>>>>> stg.c lktrk _______________________________________________
>>>>>> QuantLib-dev mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ----------
>>>>> --
>>>>> Slashdot TV.
>>>>> Video for Nerds.  Stuff that matters.
>>>>> http://tv.slashdot.org/
>>>>> _______________________________________________
>>>>> QuantLib-dev mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>

Re: [Quantlib-dev] 答复: Openmp work on mcarlo : Dynamic Creator MT

[Peter C. <pca...@gm...>]

Hi Cheng,

indeed with msvc I get a slow down with a factor of ~2.8x. As I said,
under gcc it is a speed up ~ 0.8x (with -O3).

Does anyone have an idea where the different behaviour under gcc /
linux and msvc might come from (and how to improve the msvc side if
possible) ?

Kind regards
Peter



On 13 September 2014 08:27, Cheng Li <scr...@gm...> wrote:
> Thanks Peter.
>
> Regards,
> Cheng
>
> 发自我的 iPad
>
>> 在 2014年9月13日，13:29，Peter Caspers <pca...@gm...> 写道：
>>
>> 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 <scr...@gm...>:
>>>
>>> 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 <pca...@gm...> 写道：
>>>>
>>>> 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 <scr...@gm...> 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:pca...@gm...]
>>>>> 发送时间: 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 <joe...@gm...> 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
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>
>>>>> ----------------------------------------------------------------------------
>>>>> --
>>>>> Slashdot TV.
>>>>> Video for Nerds.  Stuff that matters.
>>>>> http://tv.slashdot.org/
>>>>> _______________________________________________
>>>>> QuantLib-dev mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>>>

Re: [Quantlib-dev] 答复: Openmp work on mcarlo : Dynamic Creator MT

[Peter C. <pca...@gm...>]

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 <scr...@gm...> 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:pca...@gm...]
> 发送时间: 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 <joe...@gm...> 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
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>
> ----------------------------------------------------------------------------
> --
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Quantlib related project at bitquant-devel

[Joseph W. <joe...@gm...>]

While I'm here.  The people on the quantlib project might be
interested in a related project that I'm working on
(http://www.bitquant.com.hk/).  The goal is to create an open source
web/python frontend for quantlib that would be useful to individual
investors and small prop shops/family offices.

Most of my time over the past few months have been trying to get the
infrastructure together, and quantlib is important because it provides
and industry grade derviatives backend.  Now the goal is to create a
frontend, and the one I'm building is focused on python.

We need all of the help we can get.  So feel free to join the group

https://groups.google.com/forum/#!forum/bitquant-devel

I'm especially interested in getting people that are working for small
firms.  The entire system is open source, and I'm hoping that we can
pull efforts to build a nice GUI frontend to quantlib.

One thing that I'd like to get out before the end of the year is a
python notebook that shows ordinary investors why the
callable-bull/bear certificates that the banks here in HK love to sell
are such terrible investments.  The are one touch knockout options,
and I think most naive punters in HK don't realize how much the one
touch kills the value of the option.

I've noticed that retail brokers in HK don't provide charts that are
really useful to invidivual investors, and I'd like to use quantlib to
even the odds.

Re: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

[Joseph W. <joe...@gm...>]

Yes.  It would it be nice if we could get it in.

My experience with MC is that the big bottleneck with parallel
applications is a testing issue (i.e. how to you verify that the
number is correct).  The approach that is industry standard involved
using an RNG that can be started at a given location and to generate
the same random number for parallel and standard paths.  I know of one
bank where they ended up using mesenne twister for this.

[Quantlib-dev] 答复: Openmp work on mcarlo : Dynamic Creator MT

[cheng l. <scr...@gm...>]

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:pca...@gm...] 
发送时间: 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 <joe...@gm...> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

----------------------------------------------------------------------------
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Python OISRateHelper

[KK <the...@gm...>]

Thanks Luigi

Your repository looks good. 

As advised in a side-chat - I was using an incorrect QL_DIR value.

After running 
python setup.py wrap 
and
python setup.py build 
the new Quantlib library seems to have compiled correctly.

Many thanks


Luigi Ballabio wrote
> Hi,
>     I did it some time after the 1.4 release. You can retrieve the
> updated interface from the Git repository at
> <https://github.com/lballabio/quantlib/>.
> 
> Luigi
> 
> On Sun, Sep 7, 2014 at 4:50 PM, KK <

> theonlykhalid@

> > wrote:
>> Hi
>>
>> Are there any plans on adding OISRateHelper to quantlib in python?
>>
>> Is there any easy way of doing this myself?
>>
>> Thanks
>>
>> KK
>>
>>
>>
>> --
>> View this message in context:
>> http://quantlib.10058.n7.nabble.com/Python-OISRateHelper-tp15835.html
>> Sent from the quantlib-dev mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> QuantLib-dev mailing list
>> 

> QuantLib-dev@.sourceforge

>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 
> 
> -- 
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list

> QuantLib-dev@.sourceforge

> https://lists.sourceforge.net/lists/listinfo/quantlib-dev





--
View this message in context: http://quantlib.10058.n7.nabble.com/Python-OISRateHelper-tp15835p15844.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Python OISRateHelper

[Luigi B. <lui...@gm...>]

Hi,
    I did it some time after the 1.4 release. You can retrieve the
updated interface from the Git repository at
<https://github.com/lballabio/quantlib/>.

Luigi

On Sun, Sep 7, 2014 at 4:50 PM, KK <the...@gm...> wrote:
> Hi
>
> Are there any plans on adding OISRateHelper to quantlib in python?
>
> Is there any easy way of doing this myself?
>
> Thanks
>
> KK
>
>
>
> --
> View this message in context: http://quantlib.10058.n7.nabble.com/Python-OISRateHelper-tp15835.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

[Quantlib-dev] Python OISRateHelper

[KK <the...@gm...>]

Hi

Are there any plans on adding OISRateHelper to quantlib in python?

Is there any easy way of doing this myself?

Thanks

KK



--
View this message in context: http://quantlib.10058.n7.nabble.com/Python-OISRateHelper-tp15835.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Openmp work on mcarlo : Dynamic Creator MT

[Peter C. <pca...@gm...>]

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 <joe...@gm...> 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
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] wing volatility model

[Yu, H. <hy...@ho...>]

Attached please find the wing model specification document I used in 2011. 
I do keep the R and EXCEL work for that small project.  However, those 
not-well-organized code usually let you hard to follow  and may not fit your 
specific needs, thus earn me no good comments, even if I kindly give you for 
free.

So as this is not brand new nor tough theory, if you or your team will work 
on it, I shall be happy to provide suggestions from my past experiences.  Or 
if you would like me to do for your inquiry, can discuss.

Hong Yu



-----原始邮件----- 
From: Jonathan.issan
Sent: Sunday, August 31, 2014 11:03 AM
To: qua...@li...
Subject: Re: [Quantlib-dev] wing volatility model

Hi wong Hu

And do you have some simple code for arbitrage free wing model?

Thanks

Jonathan



--
View this message in context: 
http://quantlib.10058.n7.nabble.com/wing-volatility-model-tp15820p15822.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev