From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3L99NKb006669 for ; Thu, 21 Apr 2011 11:09:25 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkDAFvzr03B/BfVkWdsb2JhbACYAI1cAQEBAQkLCwcUJcR/hXYEjiuEBQ X-IronPort-AV: E=Sophos;i="4.64,250,1301868000"; d="scan'208";a="81469637" Received: from msa04.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.213]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Apr 2011 11:09:24 +0200 Received: from [192.168.1.63] ([83.204.179.232]) by mwinf5d16 with ME id a99P1g00L51EXVP0399Pp4; Thu, 21 Apr 2011 11:09:24 +0200 Message-ID: <4DAFF442.8000806@lexifi.com> Date: Thu, 21 Apr 2011 11:09:22 +0200 From: Alain Frisch Organization: LexiFi User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: caml-list@inria.fr References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr> <4D8C73C8.6020801@inescporto.pt> <1301055903.8429.314.camel@thinkpad> <341494683.237537.1301057887481.JavaMail.root@zmbs4.inria.fr> <4D8C944A.9060601@inria.fr> <4D8CB859.9040709@inescporto.pt> <4D8CDDCC.4010000@ens-lyon.org> <029701cbff90$7a874510$6f95cf30$@ffconsultancy.com> <76544177.594058.1303341821437.JavaMail.root@zmbs4.inria.fr> <4DAFE141.7080003@inria.fr> In-Reply-To: <4DAFE141.7080003@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Validation-by: alain@frisch.fr Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap? 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