1. PicsouGrid Viet-Dung DOAN

2. Agenda Motivation PicsouGrid’s architecture –Pricing scenarios PicsouGrid’s properties –Load balancing –Fault tolerance Perspectives

3. Motivation : Option Pricing in Finance “Options” = a contract where the owner has the right but not the obligation to exercise a feature of the contract on a future date → one of the main instrument of financial risk management for multidimensional underlying assets or complex payoffs : numerical simulations are required → in this work: Monte Carlo methods

4. Motivation : Option Pricing in Finance The underlying asset’s price is calculated as a stochastic value S = f(N(0,1)) The option’s price P = E[S] Expectation of a stochastic values S is the sum of the probability of each possible value S (probability theory).

5. PicsouGrid Scenario No1 (1) This scenario is used for pricing the Europeans options, their exotics forms and the portfolio's risk management (pricing the value at risk).

6. PicsouGrid Scenario No1 (2) + reserve pool of PCs ( ε %) Client Server SubServer Worker ProActive Worker BD classical n-tiers architecture ProActive BD JavaSpace virtual shared memory (on demand)

7. PicsouGrid Scenario No2 (1) More communication. This scenario is used for pricing the Americans options, their exotics forms and the Greeks values.

8. PicsouGrid Scenario No2 (2) + reserve pool of PCs ( ε %) Client Server SubServer Worker ProActive Worker BD classical n-tiers architecture ProActive BD JavaSpace virtual shared memory (on demand)

9. Load Balancing (1) Full static strategy (for homogeneous Grid): distribute larger tasks to worker (N/nbWorkers) +less communications –not suited for heterogeneous workers Traditional semi-dynamic (for heterogeneous Grid): each financial computation is split into N elementary tasks statically distributed across the SubServers each worker consume an elementary task from its SubServer until no more tasks are available Dynamic aggressive (for certain algorithms): distribute more tasks than necessary, stop as soon as N results are collected (e.g Monte Carlo method) –more communications +takes advantage of fastest machines

10. Load Balancing (2) influence of tasks size: –small: –high communications +low recovery overhead –big: +few communications –recovery overhead can be as big as the task execution time

11. Fault Tolerance FT mechanisms from underlying middleware: –JavaSpace: transactions: protection from worker process failure activatable service and persistent space: protection from JavaSpace process failure –ProActive: check-pointing protocol to restart the whole application from a previous global state in case of failure → protect from failure of middleware process PicsouGrid FT mechanisms: –hear-beat to detect failure –subservers checkpoint workers, server checkpoints subservers –redeploy failing worker on reserve PC if available –redeploy failing subserver on reserve PC if available, server or on server otherwise → protect from machine failure

12. Performances on Sound Grid interesting speed-up up to 140 workers subServers are bottleneck points: hierarchical architecture leads to better scaling overhead of long-distance communications (4 sites versus 1) is noticeable

13. PicsouGrid Fault Tolerance Performances Experiment: –test: 3 SubServers, 6 Workers per SubServer –disconnect machines right before they return a result –use reserve PCs –measured overhead: Conclusions: –faults are detected –workers and subServers are replaced and there is no need to restart the computation from the beginning, subsequent computations perform without overhead –recovery overhead is acceptable, higher for subServers than for workers + 11.865.52 SubServers + 9.663.31 SubServer + 15.068.76 Workers + 2.456.12 Workers + 0.454.11 Worker -53.7no failure Worse Overhead (s)Average Execution Time (s) Simultaneous Failures most likely failure case dealt with using only ξ reserve PC

14. Failures and Aggressive Load Balancing → need to automatically adjust the task size

15. Perspectives Perspectives: –to build an abstract interface between PicsouGrid and the algorithms. –to experiment with more tightly-coupled applications. –to allow application, PiscouGrid and underlying middleware layers to collaborate to improve fault tolerance. –to dynamically discover and integrate available resources (PiscouGrid). –to allow pluggin of industrial clients and libraries (e.g. Pricing Partners toolkit).