Browse thread
Fw: [Caml-list] How INRIA people envision OCaml's parallel future?
- Frédéric_Gava
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2005-06-23 (11:38) |
From: | Frédéric_Gava <gava@u...> |
Subject: | Fw: [Caml-list] How INRIA people envision OCaml's parallel future? |
----- 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 ? >