Browse thread
How INRIA people envision OCaml's parallel future?
[
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 (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. Regards, Frédéric Gava