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

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

On 04/21/2011 09:03 PM, Christophe TROESTLER wrote:
> On Thu, 21 Apr 2011 11:09:22 +0200, Alain Frisch wrote:
>>
>> 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 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.
> 
> May you say why Functory is not good enough for this ?
> http://www.lri.fr/~filliatr/functory/About.html

I did not say Functory is not good enough for this. Actually, I did not
know about this project. Although my message was not explicit about it,
we have implemented our own solution, based on a multi-process approach,
and we are quite happy with it. That said, we follow with a lot of
interest all the projects and discussions about making it easier to
write distributed computations in OCaml.

After quickly reading the API and the technical report, I think the
library would indeed be a good match for the kind of computations we are
dealing with. Actually, it has a lot in common with the solution we have
implemented. Some difference between Functory and our solution:

- Functory's Cores module relies on system calls which are not available
under Windows. Our solution is based on a different technique: external
worker processed are spawned by the main program
by executing argv[0] with a special command-line argument (to
distinguish from a regular invocation). Our "Computations" library
intercepts this argument and runs a loop that waits for new tasks
(similar to Functory's Network solutions).

- Functory's external worker processes execute a single task and die.
In our solution, we maintain a pool of available worker processes; when
a worker process has finished computing a task, it notifies the
scheduler explicitly. This avoids some non-negligible start-up costs
(especially under Windows) and allows workers to keep some in-memory
caches and database connections. Again, this looks similar to Functory's
Network approach.

- Our API allows workers to notify the caller with intermediate results
and progress feedback (typically, to display some progress bar and
status to the user).  For instance, a single Monte Carlo pricing task
reports progress percentage in the GUI, together with the current price
estimate and observed variance.  Similarly, a "portfolio" pricing task
reports the percentage (number of contracts already priced). The API
also allows the caller to kill a running task (typically when the user
clicks on "Stop" in the GUI). We do this by asking the OS to kill the
worker process. The caller can still use intermediate results to do
something useful.

- We also have some solution for distributing computations across the
network (not in use in production yet), but we go through our
application's database instead of direct TCP networking. Any connected
client makes its cores available to take some tasks from the task pool;
and it can itself submit new tasks. (This also give a cache to share the
result of computations between different clients.)


Cheers,

Alain