English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
How INRIA people envision OCaml's parallel future?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-06-23 (08:30)
From: Frédéric_Gava <gava@u...>
Subject: Re: [Caml-list] How INRIA people envision OCaml's parallel future?
>More generally, do you plan to introduce new language constructs to
>support parallelism? I'm thinking of Jocaml and Skeleton approach for
>example. Or simply some libraries?

Developing a new programming language is a difficult task. JoCaml is a good
example. Hard for the maintenance. Also JoCaml is not a parallel language
but a concurrent language <=> if you create two "tasks" in a concurrent
language, you can't know if there are on two different processors or
sequentials tasks; in a parallel language, when you create two tasks, you
want that those two tasks to be in two different processors.

Skeleton (OcamlP3L) is a good way but there is also Data-Parallel languages
sush as HirondML, Ocaml-Flight, BSMLlib (a library for BSP computing; BSP is
a parallel model with a cost model; no deadlock, no undeterministic results;
it is thus a good candidat for developping parallel algorithms) and many
others. An advantage of Data-Parallel languages is that you have the "same
programs" in each processors and thus a sequential GC is sufficient: the
maintenance of the libraries is "easier".

>I know that predictions are quite difficult, especially about the
>future, :) but I suppose INRIA people are thinking about those issues.
>OCaml is a very exciting experiment of pragmatism and theory and I'm
>curious of what might appear on the parallel topic.

It is hard to work on the maintenance of a parallel library (see MPI, PVM,
PUB for examples) and thus parallel peoples do not want to deal (in general)
with the sequential parts of the languages...

There is also the fact that you do not develop parallel programs for the
same things than sequential ones: what is the interest to have a parallel
language for just an application that play a MP3 ?  Using parallelism is
good for some specific cases and thus need specifics libraries. Developping
a "big language" that is good for parallel computing and sequential
computing seems (it is my opinion) to be a too much harder work.

Frédéric Gava