Page 1 of 3

MC Common Framework in C++ versus C#

Posted: January 15th, 2014, 7:06 pm
by Cuchulainn
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.

MC Common Framework in C++ versus C#

Posted: January 15th, 2014, 7:24 pm
by Cuchulainn
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.

MC Common Framework in C++ versus C#

Posted: January 15th, 2014, 7:40 pm
by Cuchulainn
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.

MC Common Framework in C++ versus C#

Posted: January 17th, 2014, 7:39 am
by Cuchulainn
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.

MC Common Framework in C++ versus C#

Posted: January 17th, 2014, 8:56 am
by Cuchulainn
It would be relatively easy (I reckon...) to implement this design in Python if you know the appropriate syntax.

MC Common Framework in C++ versus C#

Posted: January 18th, 2014, 5:48 am
by Cuchulainn
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).

MC Common Framework in C++ versus C#

Posted: January 18th, 2014, 7:01 am
by Cuchulainn
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?

MC Common Framework in C++ versus C#

Posted: January 18th, 2014, 10:15 am
by Cuchulainn
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?

MC Common Framework in C++ versus C#

Posted: January 20th, 2014, 5:54 am
by Cuchulainn
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?

MC Common Framework in C++ versus C#

Posted: January 20th, 2014, 1:40 pm
by Polter
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?