Fw: [Caml-list] How INRIA people envision OCaml's parallel future?

Fw: [Caml-list] How INRIA people envision OCaml's parallel future?

[Frédéric Gava]

----- Original Message -----
From: "Frédéric Gava" <gava@univ-paris12.fr>
To: "David MENTRE" <david.mentre@gmail.com>
Sent: Thursday, June 23, 2005 11:49 AM
Subject: Re: [Caml-list] How INRIA people envision OCaml's parallel future?


> Hello,
>
> >Good question that I did not considered when asking my own question.
> Thanks ;-)
>
> >Right now, I'm writing a user program (with Lablgtk2 user interface)
> >and a server program (network, file and databases I/O, lot of in
> >memory data structures, few computation intensive parts, mostly
> >algorithmic issues). On the user side, I see no real need of
> >parallelism, except if it can improve responsiveness (e.g. user
> >graphical front-end and back-end that interact with the server on the
> >network). On the server side, it is different. If I have a dual core
> >machine (and *I'm going to have* a 2- or 4-core machine), I would like
> >my server to reply as fast as possible to clients, which implies that
> >some tasks must be done in the background, with all the implied
> >synchronization issues.
>
> For tasks parallelism, you can try pGhc or Eden (but it is parallel
> extention of Haskell) or mobile haskell
>
> Herrmann  ( http://www.fmi.uni-passau.de/~hermann ) has also developp a
> tasks parallel extention of MetaOCaml using
> OCamlMPI.
>
>
> >As you see, my programmer profile is quite different from the expected
> >usage of BSMLlib (if I have understood BSMLlib description correctly):
> >no data parallel programming, rather control parallel programming.
>
> yes. Ok. You are in the case of tasks parallelism.
>
> You an try an interface between ocaml and OpenMM but without a parallel
GC,
> it seems (peraps ?) unsafe.
>
>
> >I'm not interested in THE parallel paradigm that will solve all
> >parallel programming issues.
> ok
>
> >After 50 years of research, no consensus
> >have emerged yet.
> Agree
>
>
> >That's said, it does not mean that OCaml should not provide tools to
> >improve the current state of affair. It is already doing that with
> >type inference, GC or sum types.
>
> >Programming parallel code with Posix
> >mutexes and threads is a nightmare.
> Agree, one of our parallel libraries (mspmllib) used massively those
> features and it is too hard to debug...
>
> >I have to say that I had a very
> >pleasant experiment with OCaml typed channels (aka Concurrent ML
> >channels). I'm just wondering if INRIA people consider that unknown
> >(to a wide public) constructs could be offered to ease concurrent
> >programming. And knowing that current ocaml cannot handle real
> >concurrent threads is a real concern.
> ok
>
> Frédéric Gava:
>
> ps: are you a researcher or an ingeneer ?
>