Re: [Caml-list] Efficient OCaml multicore -- roadmap?

[Alain Frisch <alain.frisch@lexifi.com>]

On 04/21/2011 09:48 AM, Fabrice Le Fessant wrote:
> You think the programmers in the world that are only interested in
> floating-point intensive computations, with fine-grain concurrency, are
> a huge majority. I think they are not so many. Can we do a better job of
> quantifying this ?

I don't know how to quantify this. I can only explain how the kind of 
things we do at LexiFi can benefit from multicore (in the current state 
of OCaml).

We do some heavy floating-point computations related to the pricing and 
risk analysis of financial products. We use mainly two families of 
pricing algorithms: Partial Differential Equation (PDE) solvers and 
Monte Carlo (MC) simulations. A MC simulation consists in drawing many 
(quasi)random trajectories generated by a model and computing the payoff 
for each of them. Running such a simulation of several cores or machines 
is quite easy. We only need to be able to distribute the (quasi)random 
number generator and there are good ways to do this. Making a single PDE 
job benefit from multicore is more challenging. If some matrix 
primitives that could exploit multicore were available, we might benefit 
from them (we don't need them to be implemented in OCaml).

But anyway, the real scaling issue is not about making a single pricing 
job run in parallel. Indeed, we need to run many independent jobs in 
order to price many different products, or even for a single product, in 
order to run some risk analysis that require many pricing jobs. We can 
easily benefit from multi cores or distribute computations to several 
machines (single pricing jobs are expensive enough to justify tiny 
communication costs between processes or machines; the amount of data to 
be exchanged is rather small).

I guess we are in the nice niche of "embarassingly parallel" tasks.
Again, not so much because of the structure of the numerical problem 
itself, but because we need to run many independent instances of the 
problem.


Alain