SERVING THE QUANTITATIVE FINANCE COMMUNITY

 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 15th, 2014, 7:06 pm

Some may remember MC1 in C++. Now in C# so we compare apples with apples.Long story short: C++ is ~ 3 times faster than C#.Remove the RNG factor: C++ is 2 times faster than C#.Delegates seem to be slower than std::function/signals?More later.
Last edited by Cuchulainn on January 14th, 2014, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 15th, 2014, 7:24 pm

Recall: here is the wiring diagram that we implemented in C++. Now we have exactly the same design as in C#.Now you can test C++ vs C# to your heart's content. Plug in your own stuff and run.
Last edited by Cuchulainn on January 14th, 2014, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 15th, 2014, 7:40 pm

Exx. sitmo prmg vs C+11 in MC1<C++>. TBDIn MC1<C#> prng is 14% slower than .NET Random (dll C# -> Managed C++ -> native C++). Figures, data conversions.
Last edited by Cuchulainn on January 14th, 2014, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 17th, 2014, 7:39 am

QuoteOriginally posted by: outrunThanks for the feedback. 14% slower makes sense indeed, there is probably various things going on besides rng (like box muller etc) so the performance diff in the pure rng is expected to be much worse.I'm also curious to see the MC1 performance differce between C# and C++ (any rng, but in release mode). I still have trouble believing that C# is so much slower than C++.I am documenting up and I just published these initial findings to get a feel. 2-3 slower is to be expected? Function calls are an attention point. QuoteI still have trouble believing that C# is so much slower than C++. We don't have enough information yet to draw a general conclusion.
Last edited by Cuchulainn on January 16th, 2014, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 17th, 2014, 8:56 am

It would be relatively easy (I reckon...) to implement this design in Python if you know the appropriate syntax.
 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 18th, 2014, 5:48 am

QuoteOriginally posted by: outrunThese designs are highly purpose specific even though it's very modular.Eg, the meaning of SDE bit is difficult to understand for me (in general, as a design element). And there are generic properties that can be merged, a random number, a random path, a payoff of a path all have a generic "draw sample from distribution" interface. That makes me thing that payoff should be merged with SDE and "numerical path generator" into something "distribution like", to which you then connect the rng like you do with the standard distributions in C++11.The main difficulty if how to handle multiple payoffs connected to the same St path. I see two clearly distinct approaches with implications to how you can distribute the MC job across machines1) generate a full features St path, that contains the union of time steps needed so that *all* payoff functions can be evaluated from that single path2) have each payoff evaluator create its own path and somehow correlate / synchronize the pathsThanks for the feedback.I am open to design changes of course. That's the whole point .. to elicit response.0) the SDE is just a class that models sdes with drift, diffusion etc. More detailed layered designs allows you to initialise them using MLE etc. (like your OU calibration paper). Is that what you mean? 1) That's the current idea, yes. Each pricer decides what it wants to do with the path.2) That's possible as well. But then I would create a complete program for each kind of pricer. Then indeed you will need another component to manage the paths. Which is also a common scenario. I's probably easier to parallelise as well I suppose. If you view each pricer as a separate 'order' as it were then this would be correct.I see two clearly distinct approaches with implications to how you can distribute the MC job across machinesIn this case 2) is probably a better design? 3) I think payoff (market data) and SDE(model data) should be independent of each other, because it is 1:N (same payoff for PDE, MC, lattice, numerical integration).
Last edited by Cuchulainn on January 17th, 2014, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 18th, 2014, 7:01 am

Looking at it another way; describe the problem (requirements) and then find the design that is the best fit. Is it an N:N:N:N multiplicity problem?
Last edited by Cuchulainn on January 17th, 2014, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 18th, 2014, 10:15 am

A practical case: how can use sitmo OU calibration?You calibrate the parameters of OU using MLE ad OLS using exact paths. So, to use it we need some levels?1. low: market/simulated data of the params2. models and paths3. option pricing Seems that choices can be made at each level. e.g. @ level 2 switch between FDM and exact simulation.Then the SDE will not be hard-coded but will use MLE, OLS or time series etc.What do you think?
Last edited by Cuchulainn on January 17th, 2014, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Topic Author
Posts: 59684
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

MC Common Framework in C++ versus C#

January 20th, 2014, 5:54 am

QuoteOriginally posted by: outrunThe payoff is indeed self contained. It should capture all the information needed to compute conditional cashflow.* European call option: Cashflow at time t of St - K if St>K* American call option: ... Or earlier if it's optimal. Also dependent on a future unknown dividend payment -> needs to be added to the MC simulationbut you also use payoff to capture info about the bonds, swaps, simple deposits.. Maybe "Instrument" or "Instrument cash flow definition" is a name that captures that? That definition can also provide automatic configuration information for the numerical engine. It gives you the list of underlyings you need to simulate, the points in time you need simulated underlying values for.Thoughts?Good points. 'K" is not always a simple number but the result of a computation. So, for 2nd order contract (chooser, compound, bond option) we need a separation between cintract declaraton and calculation. It is recursive.So, a better name is needed.Early exercise? One option it to define it as a unarypredicate applied to the MC path similar to checking a barrier?
Last edited by Cuchulainn on January 19th, 2014, 11:00 pm, edited 1 time in total.
 
User avatar
Polter
Posts: 2526
Joined: April 29th, 2008, 4:55 pm

MC Common Framework in C++ versus C#

January 20th, 2014, 1:40 pm

Quote1. low: market/simulated data of the params2. models and paths3. option pricing Quote"Instrument definition" or "contract definition" instead of payoff?market_data / Marketmodel_data / Modelcontract_data / Contract?
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


Twitter LinkedIn Instagram

JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...


GZIP: On