[Caml-list] Current state of threading parallelism?

[Caml-list] Current state of threading parallelism?

[Wolfgang Draxinger]

Hi,

I'm a bit out of the loop of the current state of OCaml support for
parallelism. My most recent knowledge on the topic, which dates back
about 3 years, would be, that due to the global garbage collector OCaml
did support only time sharing multithreaded concurrency limited to a
single processing core, i.e. no parallelism at all.

Have there been significant changes in that regard lately? I did notice
that there are now new (inofficial) ocamlopt backends based on LLVM.
Are there any new, as exciting developments regarding the runtime system
as well?


Regards

Wolfgang

Re: [Caml-list] Current state of threading parallelism?

[Francois Berenger]

On 10/4/13 8:46 AM, Wolfgang Draxinger wrote:
> Hi,
>
> I'm a bit out of the loop of the current state of OCaml support for
> parallelism. My most recent knowledge on the topic, which dates back
> about 3 years, would be, that due to the global garbage collector OCaml
> did support only time sharing multithreaded concurrency limited to a
> single processing core, i.e. no parallelism at all.
>
> Have there been significant changes in that regard lately? I did notice
> that there are now new (inofficial) ocamlopt backends based on LLVM.
> Are there any new, as exciting developments regarding the runtime system
> as well?

https://github.com/lucasaiu/ocaml

But I guess there are others working on this too.

Re: [Caml-list] Current state of threading parallelism?

[Francis Dupont]

 In your previous mail you wrote:

>  I'm a bit out of the loop of the current state of OCaml support for
>  parallelism. My most recent knowledge on the topic, which dates back
>  about 3 years, would be, that due to the global garbage collector OCaml
>  did support only time sharing multithreaded concurrency limited to a
>  single processing core, i.e. no parallelism at all.

=> yes, this is the official way (no shared memory, no fine grain
locking, etc). Note this was the way followed by Python too for
the same reasons (to make the intepreter multi-threaded was considered
as too hard for the expected best result, i.e., ~4 time maximum speed up).
You can say OCaml can be compiled to native code but this is far to help
for the garbage collector...

>  Have there been significant changes in that regard lately? I did notice
>  that there are now new (inofficial) ocamlopt backends based on LLVM.
>  Are there any new, as exciting developments regarding the runtime system
>  as well?

=> I can't see where a LLVM backend really helps for multi-core/multi-
processor parallelism... IMHO the best / most reasonable thing you can
do to handle multi-core/multi-processor parallelism is a set of
communicating independent OCaml instances (one per process). The model
is well understood and scales.

Regards

Francis.Dupont@fdupont.fr

PS: my PhD thesis was about Caml and parallelism so the subject is
really not new...

Re: [Caml-list] Current state of threading parallelism?

[Wolfgang Draxinger]

On Fri, 04 Oct 2013 17:44:27 +0200
Francis Dupont <Francis.Dupont@fdupont.fr> wrote:

> => yes, this is the official way (no shared memory, no fine grain
> locking, etc). Note this was the way followed by Python too for
> the same reasons (to make the intepreter multi-threaded was considered
> as too hard for the expected best result, i.e., ~4 time maximum speed
> up).

Well, there are certain problems that can be largely parallelized in a
way that performance scales well with the number of cores. Those
problems usually also perform in constant memory (of course this is all
mutable state then, so not really pure). I'm thinking of problems that
could be put as well on GPUs here, like signal decomposition, error
diffusion models, stuff like that.

> => I can't see where a LLVM backend really helps for multi-core/multi-
> processor parallelism... IMHO the best / most reasonable thing you can
> do to handle multi-core/multi-processor parallelism is a set of
> communicating independent OCaml instances (one per process). The model
> is well understood and scales.

I consider the LLVM backend exciting, because it promises to increase
the range of architectures that can be targeted natively. Me mentioning
it had nothing to do with parallelism.


Wolfgang

Re: [Caml-list] Current state of threading parallelism?

[Philippe Wang]

On Sat, Oct 5, 2013 at 1:25 AM, Wolfgang Draxinger
<wdraxinger.maillist@draxit.de> wrote:
> On Fri, 04 Oct 2013 17:44:27 +0200
> Francis Dupont <Francis.Dupont@fdupont.fr> wrote:
>
>> => yes, this is the official way (no shared memory, no fine grain
>> locking, etc). Note this was the way followed by Python too for
>> the same reasons (to make the intepreter multi-threaded was considered
>> as too hard for the expected best result, i.e., ~4 time maximum speed
>> up).
>
> Well, there are certain problems that can be largely parallelized in a
> way that performance scales well with the number of cores. Those
> problems usually also perform in constant memory (of course this is all
> mutable state then, so not really pure). I'm thinking of problems that
> could be put as well on GPUs here, like signal decomposition, error
> diffusion models, stuff like that.

You might want to get a look at SPOC:
http://www.algo-prog.info/spoc/

N.B. It's even in OPAM!

-- 
Philippe Wang
   mail@philippewang.info

Re: [Caml-list] Current state of threading parallelism?

[Francois Berenger]

On 10/5/13 10:25 AM, Philippe Wang wrote:
> On Sat, Oct 5, 2013 at 1:25 AM, Wolfgang Draxinger
> <wdraxinger.maillist@draxit.de> wrote:
>> On Fri, 04 Oct 2013 17:44:27 +0200
>> Francis Dupont <Francis.Dupont@fdupont.fr> wrote:
>>
>>> => yes, this is the official way (no shared memory, no fine grain
>>> locking, etc). Note this was the way followed by Python too for
>>> the same reasons (to make the intepreter multi-threaded was considered
>>> as too hard for the expected best result, i.e., ~4 time maximum speed
>>> up).
>>
>> Well, there are certain problems that can be largely parallelized in a
>> way that performance scales well with the number of cores. Those
>> problems usually also perform in constant memory (of course this is all
>> mutable state then, so not really pure). I'm thinking of problems that
>> could be put as well on GPUs here, like signal decomposition, error
>> diffusion models, stuff like that.
>
> You might want to get a look at SPOC:
> http://www.algo-prog.info/spoc/

Have someone used SPOC in production or is it just a prototype?

RE: [Caml-list] Current state of threading parallelism?

[Jon Harrop]

Francis Dupont wrote:
> Note this was the way followed by Python too for the same reasons

But not by JVM- and CLR-based languages like Java, Scala, C# and F#.

> Well, there are certain problems that can be largely parallelized
> in a way that performance scales well with the number of cores.

All problems can be parallelized such that performance scales well with the
number of cores. Just add redundant parallel computation of the Mandelbrot
set between each line of code. Consequently, it is important not to consider
scalability alone.

Cheers,
Jon.