Parallelism with threads

Parallelism with threads

[Jon Harrop]

Is it possible to compute in parallel using separate threads rather than 
separate processes in OCaml, i.e. having multiple threads sharing multiple 
independent GCs?

I'm asking because it looks as though OpenGL contexts can be shared between 
threads but not between processes.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Parallelism with threads

[Daniel Andor]

On Jan 8, 2008 9:56 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> Is it possible to compute in parallel using separate threads rather than
> separate processes in OCaml, i.e. having multiple threads sharing multiple
> independent GCs?

I often wonder about that myself.  I'd like to do very simple OpenMP
style multi-threaded processing.  OcamlP3 is promising, although it is
much more heavyweight.

Does Xavier's "standard lecture on parallelism" still apply?:
  http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html

D.

>
> I'm asking because it looks as though OpenGL contexts can be shared between
> threads but not between processes.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Parallelism with threads

[Brian Hurt]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

Daniel Andor wrote:

>On Jan 8, 2008 9:56 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
>  
>
>>Is it possible to compute in parallel using separate threads rather than
>>separate processes in OCaml, i.e. having multiple threads sharing multiple
>>independent GCs?
>>    
>>
>
>I often wonder about that myself.  I'd like to do very simple OpenMP
>style multi-threaded processing.  OcamlP3 is promising, although it is
>much more heavyweight.
>
>Does Xavier's "standard lecture on parallelism" still apply?:
>  http://caml.inria.fr/pub/ml-archives/caml-list/2002/11/64c14acb90cb14bedb2cacb73338fb15.en.html
>
>D.
>  
>

Actually, something that might be nice to see, now that the flat page 
table has been replaced with a heap that can handle disjoint heap 
spaces, is to allow multiple different Ocaml runtimes to be running in 
seperate threads in the same process.
The heaps wouldn't be able to see each other, but they'd be able to 
communicate via light weight (and strongly typed) message passing, and 
you wouldn't have to dink around with sockets, pipes, MPI, or simiar 
"heavy weight" solutions, so it'd be simpler, and possibly faster.  This 
is not unlike the Erlang model, in fact.

Brian


[-- Attachment #2: Type: text/html, Size: 1879 bytes --]

Re: [Caml-list] Parallelism with threads

[David MENTRE]

Hello,

Brian Hurt <bhurt@janestcapital.com> writes:

>   This is not unlike the Erlang model, in fact.

There was an attempt to adapt the Erlang model to OCaml during the OCaml
Summer Project. See Erlang Style concurrent and Distributed Programming
in OCaml, Benedikt Grundmann, at http://osp2007.janestcapital.com/

I would be interested in any evaluation of this framework, especially
regarding performances.

Yours,
d.
-- 
GPG/PGP key: A3AD7A2A David MENTRE <dmentre@linux-france.org>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A

Re: [Caml-list] Parallelism with threads

[Jon Harrop]

On Tuesday 08 January 2008 20:00:00 Brian Hurt wrote:
> Actually, something that might be nice to see, now that the flat page
> table has been replaced with a heap that can handle disjoint heap
> spaces, is to allow multiple different Ocaml runtimes to be running in
> seperate threads in the same process.
> The heaps wouldn't be able to see each other, but they'd be able to
> communicate via light weight (and strongly typed) message passing, and
> you wouldn't have to dink around with sockets, pipes, MPI, or simiar
> "heavy weight" solutions, so it'd be simpler, and possibly faster.  This
> is not unlike the Erlang model, in fact.

This is exactly the kind of thing I'm interested in!

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Parallelism with threads

[Brian Hurt]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

Jon Harrop wrote:

>On Tuesday 08 January 2008 20:00:00 Brian Hurt wrote:
>  
>
>>Actually, something that might be nice to see, now that the flat page
>>table has been replaced with a heap that can handle disjoint heap
>>spaces, is to allow multiple different Ocaml runtimes to be running in
>>seperate threads in the same process.
>>The heaps wouldn't be able to see each other, but they'd be able to
>>communicate via light weight (and strongly typed) message passing, and
>>you wouldn't have to dink around with sockets, pipes, MPI, or simiar
>>"heavy weight" solutions, so it'd be simpler, and possibly faster.  This
>>is not unlike the Erlang model, in fact.
>>    
>>
>
>This is exactly the kind of thing I'm interested in!
>
>  
>
I take this back- I've just figured out it wouldn't work.  Global 
variables would be seen as the same in both threads.  Basically, if you had
    let foo = ref [ 1; 2; 3 ];;
then the memory location foo would be seen by code in both runtimes, but 
the actual list elements would be in one thread and not the other. Worse 
yet, it's mutable data, so now you've got the possibility of  a list 
going back and force between threads.  Mass pandemonium breaks out.

This is a bad idea.

Brian


[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re: [Caml-list] Parallelism with threads

[Jonathan Bryant]

On Jan 8, 2008, at 3:43 PM, Brian Hurt wrote:

> Jon Harrop wrote:
>> On Tuesday 08 January 2008 20:00:00 Brian Hurt wrote:
>>>
>>> Actually, something that might be nice to see, now that the flat  
>>> page table has been replaced with a heap that can handle disjoint  
>>> heap spaces, is to allow multiple different Ocaml runtimes to be  
>>> running in seperate threads in the same process. The heaps  
>>> wouldn't be able to see each other, but they'd be able to  
>>> communicate via light weight (and strongly typed) message  
>>> passing, and you wouldn't have to dink around with sockets,  
>>> pipes, MPI, or simiar "heavy weight" solutions, so it'd be  
>>> simpler, and possibly faster. This is not unlike the Erlang  
>>> model, in fact.
>> This is exactly the kind of thing I'm interested in!
> I take this back- I've just figured out it wouldn't work.  Global  
> variables would be seen as the same in both threads.  Basically, if  
> you had
>     let foo = ref [ 1; 2; 3 ];;
> then the memory location foo would be seen by code in both  
> runtimes, but the actual list elements would be in one thread and  
> not the other. Worse yet, it's mutable data, so now you've got the  
> possibility of  a list going back and force between threads.  Mass  
> pandemonium breaks out.
>
> This is a bad idea.
>

Yes, this is the problem of not having a truly parallel GC.  OTOH,  
what about adding a spawn command (in addition to Thread.create)  
which created a separate instance of the runtime (like you suggested)  
and used copy-on-write semantics for the heap?  You still get the  
benefits of the same process (lightweight message passing, etc) with  
true SMP support but there is no need for a parallel GC since there  
are separate heaps.  There is, of course, still the problem that  
communication channels still need to be shared between heaps somehow...

As far as the Erlang Concurrency project from OSP, I can't say for  
sure but I'm pretty sure that it uses heavyweight processes to  
emmulate Erlang and doesn't modify the runtime.

--Jonathan Bryant

> Brian
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Parallelism with threads

[Benedikt Grundmann]

2008/1/8, Jonathan Bryant <jtbryant@valdosta.edu>:
> As far as the Erlang Concurrency project from OSP, I can't say for
> sure but I'm pretty sure that it uses heavyweight processes to
> emmulate Erlang and doesn't modify the runtime.
>

That is true.

-- 
Calvin: I try to make everyone's day a little more
surreal.

(From Calvin & Hobbes)

Re: [Caml-list] Parallelism with threads

[Daniel Andor]

On Jan 8, 2008 3:00 PM, Brian Hurt <bhurt@janestcapital.com> wrote:
>  The heaps wouldn't be able to see each other, but they'd be able to
> communicate via light weight (and strongly typed) message passing, and you
> wouldn't have to dink around with sockets, pipes, MPI, or simiar "heavy
> weight" solutions, so it'd be simpler, and possibly faster.  This is not
> unlike the Erlang model, in fact.

Are there any solutions that do not involve message passing?  I have
heaps of data that barely fits into memory, and sharing that memory is
the most straightforward way to process it.

If sharing process space is out, are there other ways to share memory?
 How about sys V SHM or MMAP, or variations -- how would that work
under OCaml?

D.

Re: [Caml-list] Parallelism with threads

[Richard Jones]

On Wed, Jan 09, 2008 at 09:46:39AM -0500, Daniel Andor wrote:
> On Jan 8, 2008 3:00 PM, Brian Hurt <bhurt@janestcapital.com> wrote:
> >  The heaps wouldn't be able to see each other, but they'd be able to
> > communicate via light weight (and strongly typed) message passing, and you
> > wouldn't have to dink around with sockets, pipes, MPI, or simiar "heavy
> > weight" solutions, so it'd be simpler, and possibly faster.  This is not
> > unlike the Erlang model, in fact.
> 
> Are there any solutions that do not involve message passing?  I have
> heaps of data that barely fits into memory, and sharing that memory is
> the most straightforward way to process it.
> 
> If sharing process space is out, are there other ways to share memory?
>  How about sys V SHM or MMAP, or variations -- how would that work
> under OCaml?

Yup, see:

http://merjis.com/developers/ancient

Rich.

-- 
Richard Jones
Red Hat