[Caml-list] Concurrent/parallel programming

[Caml-list] Concurrent/parallel programming

[Yotam Barnoy]

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

Hi List

So far, I've been programming in ocaml using only sequential programs. In
my last project, which was an implementation of a large machine learning
algorithm, I tried to speed up computation using a little bit of
parallelism with ParMap, and it was a complete failure. It's possible that
more time would have yielded better results, but I just didn't have the
time to invest in it given how bad the initial results were.

My question is, what are the options right now as far as parallelism is
concerned? I'm not talking about cooperative multitasking, but about really
taking advantage of multiple cores. I'm well aware of the runtime lock and
I'm ok with message passing between processes or a shared area in memory,
but I'd rather have something more high level than starting up several
processes, creating a named pipe or a socket, and trying to pass messages
through that. Also, I assume that using a shared area in memory involves
some C code? Am I wrong about that?

I was expecting Core's Async to fill this role, but realworldocaml is fuzzy
on this topic, apparently preferring to dwell on cooperative multitasking
(which is fine but not what I'm looking for), and I couldn't find any other
documentation that was clearer.

Thanks
Yotam

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

Re: [Caml-list] Concurrent/parallel programming

[Yaron Minsky]

This is indeed something that is not well covered in RWO.  That said,
the Async_parallel library is aimed at this kind of target.  No shared
memory region, just some automation around spinning up processes and
communicating jobs between them.

CC'ing Eric Stokes, who is the primary author of the library.

y


On Tue, Jan 7, 2014 at 2:54 PM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> Hi List
>
> So far, I've been programming in ocaml using only sequential programs. In my
> last project, which was an implementation of a large machine learning
> algorithm, I tried to speed up computation using a little bit of parallelism
> with ParMap, and it was a complete failure. It's possible that more time
> would have yielded better results, but I just didn't have the time to invest
> in it given how bad the initial results were.
>
> My question is, what are the options right now as far as parallelism is
> concerned? I'm not talking about cooperative multitasking, but about really
> taking advantage of multiple cores. I'm well aware of the runtime lock and
> I'm ok with message passing between processes or a shared area in memory,
> but I'd rather have something more high level than starting up several
> processes, creating a named pipe or a socket, and trying to pass messages
> through that. Also, I assume that using a shared area in memory involves
> some C code? Am I wrong about that?
>
> I was expecting Core's Async to fill this role, but realworldocaml is fuzzy
> on this topic, apparently preferring to dwell on cooperative multitasking
> (which is fine but not what I'm looking for), and I couldn't find any other
> documentation that was clearer.
>
> Thanks
> Yotam

Re: [Caml-list] Concurrent/parallel programming

[Yaron Minsky]

It's also probably worth trying to understand what went wrong with
parmap.  Might make sense to email their dev list...

y

On Tue, Jan 7, 2014 at 3:12 PM, Yaron Minsky <yminsky@janestreet.com> wrote:
> This is indeed something that is not well covered in RWO.  That said,
> the Async_parallel library is aimed at this kind of target.  No shared
> memory region, just some automation around spinning up processes and
> communicating jobs between them.
>
> CC'ing Eric Stokes, who is the primary author of the library.
>
> y
>
>
> On Tue, Jan 7, 2014 at 2:54 PM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
>> Hi List
>>
>> So far, I've been programming in ocaml using only sequential programs. In my
>> last project, which was an implementation of a large machine learning
>> algorithm, I tried to speed up computation using a little bit of parallelism
>> with ParMap, and it was a complete failure. It's possible that more time
>> would have yielded better results, but I just didn't have the time to invest
>> in it given how bad the initial results were.
>>
>> My question is, what are the options right now as far as parallelism is
>> concerned? I'm not talking about cooperative multitasking, but about really
>> taking advantage of multiple cores. I'm well aware of the runtime lock and
>> I'm ok with message passing between processes or a shared area in memory,
>> but I'd rather have something more high level than starting up several
>> processes, creating a named pipe or a socket, and trying to pass messages
>> through that. Also, I assume that using a shared area in memory involves
>> some C code? Am I wrong about that?
>>
>> I was expecting Core's Async to fill this role, but realworldocaml is fuzzy
>> on this topic, apparently preferring to dwell on cooperative multitasking
>> (which is fine but not what I'm looking for), and I couldn't find any other
>> documentation that was clearer.
>>
>> Thanks
>> Yotam

Re: [Caml-list] Concurrent/parallel programming

[Gerd Stolpmann]

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

There is Netmulticore, a part of Ocamlnet:

http://projects.camlcity.org/projects/dl/ocamlnet-3.7.3/doc/html-main/Intro.html#ch_comp

It utilizes shared memory, and accesses it from several processes. There
is no C code involved, but it is fairly unsafe nevertheless, because you
need to stick to certain programming rules, or the program crashes.
However, if you manage to encapsulate all the unsafe things, it is a
good option. I'm using Netmulticore in the Plasma Map/Reduce
implementation.

Gerd

Am Dienstag, den 07.01.2014, 14:54 -0500 schrieb Yotam Barnoy:
> Hi List
> 
> 
> So far, I've been programming in ocaml using only sequential programs.
> In my last project, which was an implementation of a large machine
> learning algorithm, I tried to speed up computation using a little bit
> of parallelism with ParMap, and it was a complete failure. It's
> possible that more time would have yielded better results, but I just
> didn't have the time to invest in it given how bad the initial results
> were.
> 
> 
> My question is, what are the options right now as far as parallelism
> is concerned? I'm not talking about cooperative multitasking, but
> about really taking advantage of multiple cores. I'm well aware of the
> runtime lock and I'm ok with message passing between processes or a
> shared area in memory, but I'd rather have something more high level
> than starting up several processes, creating a named pipe or a socket,
> and trying to pass messages through that. Also, I assume that using a
> shared area in memory involves some C code? Am I wrong about that?
> 
> 
> I was expecting Core's Async to fill this role, but realworldocaml is
> fuzzy on this topic, apparently preferring to dwell on cooperative
> multitasking (which is fine but not what I'm looking for), and I
> couldn't find any other documentation that was clearer.
> 
> 
> Thanks
> 
> Yotam
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Caml-list] Concurrent/parallel programming

[Yotam Barnoy]

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

Thanks for the links and info, everyone.

Gerd, would it be possible to put netmulticore up on opam? I realize this
is a sensitive topic for you, but from what I can tell, this is the most
comprehensive and efficient solution to parallel programming that exists
for ocaml, so why not make it as easily available as possible?

Also, regarding the ocaml_modify() and ocaml_initialize() regression in
4.01 -- yikes! Is there any way to get support back for writing outside of
the ocaml heap? This seems like a pretty big deal! (Sorry if I'm arriving
late for whatever discussion took place about this before).

-Yotam


On Tue, Jan 7, 2014 at 3:35 PM, Gerd Stolpmann <info@gerd-stolpmann.de>wrote:

> There is Netmulticore, a part of Ocamlnet:
>
>
> http://projects.camlcity.org/projects/dl/ocamlnet-3.7.3/doc/html-main/Intro.html#ch_comp
>
> It utilizes shared memory, and accesses it from several processes. There
> is no C code involved, but it is fairly unsafe nevertheless, because you
> need to stick to certain programming rules, or the program crashes.
> However, if you manage to encapsulate all the unsafe things, it is a
> good option. I'm using Netmulticore in the Plasma Map/Reduce
> implementation.
>
> Gerd
>
> Am Dienstag, den 07.01.2014, 14:54 -0500 schrieb Yotam Barnoy:
> > Hi List
> >
> >
> > So far, I've been programming in ocaml using only sequential programs.
> > In my last project, which was an implementation of a large machine
> > learning algorithm, I tried to speed up computation using a little bit
> > of parallelism with ParMap, and it was a complete failure. It's
> > possible that more time would have yielded better results, but I just
> > didn't have the time to invest in it given how bad the initial results
> > were.
> >
> >
> > My question is, what are the options right now as far as parallelism
> > is concerned? I'm not talking about cooperative multitasking, but
> > about really taking advantage of multiple cores. I'm well aware of the
> > runtime lock and I'm ok with message passing between processes or a
> > shared area in memory, but I'd rather have something more high level
> > than starting up several processes, creating a named pipe or a socket,
> > and trying to pass messages through that. Also, I assume that using a
> > shared area in memory involves some C code? Am I wrong about that?
> >
> >
> > I was expecting Core's Async to fill this role, but realworldocaml is
> > fuzzy on this topic, apparently preferring to dwell on cooperative
> > multitasking (which is fine but not what I'm looking for), and I
> > couldn't find any other documentation that was clearer.
> >
> >
> > Thanks
> >
> > Yotam
> >
>
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> My OCaml site:          http://www.camlcity.org
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> ------------------------------------------------------------
>

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

Re: [Caml-list] Concurrent/parallel programming

[Francois Berenger]

On 01/08/2014 11:35 AM, Yotam Barnoy wrote:
> Thanks for the links and info, everyone.
>
> Gerd, would it be possible to put netmulticore up on opam?

I think it should be included in the ocamlnet package that is in OPAM.

> I realize
> this is a sensitive topic for you, but from what I can tell, this is the
> most comprehensive and efficient solution to parallel programming that
> exists for ocaml, so why not make it as easily available as possible?
>
> Also, regarding the ocaml_modify() and ocaml_initialize() regression in
> 4.01 -- yikes! Is there any way to get support back for writing outside
> of the ocaml heap? This seems like a pretty big deal! (Sorry if I'm
> arriving late for whatever discussion took place about this before).
>
> -Yotam
>
>
> On Tue, Jan 7, 2014 at 3:35 PM, Gerd Stolpmann <info@gerd-stolpmann.de
> <mailto:info@gerd-stolpmann.de>> wrote:
>
>     There is Netmulticore, a part of Ocamlnet:
>
>     http://projects.camlcity.org/projects/dl/ocamlnet-3.7.3/doc/html-main/Intro.html#ch_comp
>
>     It utilizes shared memory, and accesses it from several processes. There
>     is no C code involved, but it is fairly unsafe nevertheless, because you
>     need to stick to certain programming rules, or the program crashes.
>     However, if you manage to encapsulate all the unsafe things, it is a
>     good option. I'm using Netmulticore in the Plasma Map/Reduce
>     implementation.
>
>     Gerd
>
>     Am Dienstag, den 07.01.2014, 14:54 -0500 schrieb Yotam Barnoy:
>      > Hi List
>      >
>      >
>      > So far, I've been programming in ocaml using only sequential
>     programs.
>      > In my last project, which was an implementation of a large machine
>      > learning algorithm, I tried to speed up computation using a
>     little bit
>      > of parallelism with ParMap, and it was a complete failure. It's
>      > possible that more time would have yielded better results, but I just
>      > didn't have the time to invest in it given how bad the initial
>     results
>      > were.
>      >
>      >
>      > My question is, what are the options right now as far as parallelism
>      > is concerned? I'm not talking about cooperative multitasking, but
>      > about really taking advantage of multiple cores. I'm well aware
>     of the
>      > runtime lock and I'm ok with message passing between processes or a
>      > shared area in memory, but I'd rather have something more high level
>      > than starting up several processes, creating a named pipe or a
>     socket,
>      > and trying to pass messages through that. Also, I assume that using a
>      > shared area in memory involves some C code? Am I wrong about that?
>      >
>      >
>      > I was expecting Core's Async to fill this role, but realworldocaml is
>      > fuzzy on this topic, apparently preferring to dwell on cooperative
>      > multitasking (which is fine but not what I'm looking for), and I
>      > couldn't find any other documentation that was clearer.
>      >
>      >
>      > Thanks
>      >
>      > Yotam
>      >
>
>     --
>     ------------------------------------------------------------
>     Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de
>     <mailto:gerd@gerd-stolpmann.de>
>     My OCaml site: http://www.camlcity.org
>     Contact details: http://www.camlcity.org/contact.html
>     Company homepage: http://www.gerd-stolpmann.de
>     ------------------------------------------------------------
>
>


-- 
Best regards,
Francois Berenger.

Re: [Caml-list] Concurrent/parallel programming

[Yotam Barnoy]

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

> Gerd, would it be possible to put netmulticore up on opam?
>>
>
> I think it should be included in the ocamlnet package that is in OPAM.
>
> My mistake.

-Yotam

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

Re: [Caml-list] Concurrent/parallel programming

[Gabriel Scherer]

> Also, regarding the ocaml_modify() and ocaml_initialize() regression in 4.01 -- yikes!
> Is there any way to get support back for writing outside of the ocaml heap?
> This seems like a pretty big deal! (Sorry if I'm arriving late for whatever discussion
> took place about this before).

The change was made to improve performances (and indeed gave a nice
boost to modify-heavy code). Labelling it a yikes-worthy regression is
a bit unfair. You should have look at
- the discussion that prompted the change
http://caml.inria.fr/mantis/view.php?id=6019
- the discussion on the ocamlnet problem
http://caml.inria.fr/mantis/view.php?id=6084

Modifying values outside the heap is still allowed using C primitives,
but is not allowed anymore for OCaml heap-update constructs (x.f <-
foo, x.(f) <- foo, etc.).

On Wed, Jan 8, 2014 at 3:35 AM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
>
> Thanks for the links and info, everyone.
>
> Gerd, would it be possible to put netmulticore up on opam? I realize this is a sensitive topic for you, but from what I can tell, this is the most comprehensive and efficient solution to parallel programming that exists for ocaml, so why not make it as easily available as possible?
>
> Also, regarding the ocaml_modify() and ocaml_initialize() regression in 4.01 -- yikes! Is there any way to get support back for writing outside of the ocaml heap? This seems like a pretty big deal! (Sorry if I'm arriving late for whatever discussion took place about this before).
>
> -Yotam
>
>
> On Tue, Jan 7, 2014 at 3:35 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
>>
>> There is Netmulticore, a part of Ocamlnet:
>>
>> http://projects.camlcity.org/projects/dl/ocamlnet-3.7.3/doc/html-main/Intro.html#ch_comp
>>
>> It utilizes shared memory, and accesses it from several processes. There
>> is no C code involved, but it is fairly unsafe nevertheless, because you
>> need to stick to certain programming rules, or the program crashes.
>> However, if you manage to encapsulate all the unsafe things, it is a
>> good option. I'm using Netmulticore in the Plasma Map/Reduce
>> implementation.
>>
>> Gerd
>>
>> Am Dienstag, den 07.01.2014, 14:54 -0500 schrieb Yotam Barnoy:
>> > Hi List
>> >
>> >
>> > So far, I've been programming in ocaml using only sequential programs.
>> > In my last project, which was an implementation of a large machine
>> > learning algorithm, I tried to speed up computation using a little bit
>> > of parallelism with ParMap, and it was a complete failure. It's
>> > possible that more time would have yielded better results, but I just
>> > didn't have the time to invest in it given how bad the initial results
>> > were.
>> >
>> >
>> > My question is, what are the options right now as far as parallelism
>> > is concerned? I'm not talking about cooperative multitasking, but
>> > about really taking advantage of multiple cores. I'm well aware of the
>> > runtime lock and I'm ok with message passing between processes or a
>> > shared area in memory, but I'd rather have something more high level
>> > than starting up several processes, creating a named pipe or a socket,
>> > and trying to pass messages through that. Also, I assume that using a
>> > shared area in memory involves some C code? Am I wrong about that?
>> >
>> >
>> > I was expecting Core's Async to fill this role, but realworldocaml is
>> > fuzzy on this topic, apparently preferring to dwell on cooperative
>> > multitasking (which is fine but not what I'm looking for), and I
>> > couldn't find any other documentation that was clearer.
>> >
>> >
>> > Thanks
>> >
>> > Yotam
>> >
>>
>> --
>> ------------------------------------------------------------
>> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
>> My OCaml site:          http://www.camlcity.org
>> Contact details:        http://www.camlcity.org/contact.html
>> Company homepage:       http://www.gerd-stolpmann.de
>> ------------------------------------------------------------
>
>

Re: [Caml-list] Concurrent/parallel programming

[Gerd Stolpmann]

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

Am Dienstag, den 07.01.2014, 21:35 -0500 schrieb Yotam Barnoy:
> Thanks for the links and info, everyone.
> 
> Gerd, would it be possible to put netmulticore up on opam? I realize
> this is a sensitive topic for you, but from what I can tell, this is
> the most comprehensive and efficient solution to parallel programming
> that exists for ocaml, so why not make it as easily available as
> possible?

Netmulticore is part of Ocamlnet, and I guess you can get it by simply
installing ocamlnet with opam. I'm not the maintainer, so I don't know
whether it is included or not.

> Also, regarding the ocaml_modify() and ocaml_initialize() regression
> in 4.01 -- yikes! Is there any way to get support back for writing
> outside of the ocaml heap? This seems like a pretty big deal! (Sorry
> if I'm arriving late for whatever discussion took place about this
> before).

There is a workaround in place - so far the OS supports it: thanks to
Xavier the symbols caml_modify and caml_initialize are declared as weak
in 4.01, allowing them to be redefined in executables. Netmulticore
redefines these symbols with their pre-4.01 functions.

This isn't optimal yet, because the old write barriers are a bit slower,
and because this introduces a very low-level dependency on the current
version of Ocaml. Nevertheless, it works for now. (Ideas for a better
solution are highly welcome.)

Gerd




> 
> -Yotam
> 
> 
> 
> On Tue, Jan 7, 2014 at 3:35 PM, Gerd Stolpmann
> <info@gerd-stolpmann.de> wrote:
>         There is Netmulticore, a part of Ocamlnet:
>         
>         http://projects.camlcity.org/projects/dl/ocamlnet-3.7.3/doc/html-main/Intro.html#ch_comp
>         
>         It utilizes shared memory, and accesses it from several
>         processes. There
>         is no C code involved, but it is fairly unsafe nevertheless,
>         because you
>         need to stick to certain programming rules, or the program
>         crashes.
>         However, if you manage to encapsulate all the unsafe things,
>         it is a
>         good option. I'm using Netmulticore in the Plasma Map/Reduce
>         implementation.
>         
>         Gerd
>         
>         Am Dienstag, den 07.01.2014, 14:54 -0500 schrieb Yotam Barnoy:
>         > Hi List
>         >
>         >
>         > So far, I've been programming in ocaml using only sequential
>         programs.
>         > In my last project, which was an implementation of a large
>         machine
>         > learning algorithm, I tried to speed up computation using a
>         little bit
>         > of parallelism with ParMap, and it was a complete failure.
>         It's
>         > possible that more time would have yielded better results,
>         but I just
>         > didn't have the time to invest in it given how bad the
>         initial results
>         > were.
>         >
>         >
>         > My question is, what are the options right now as far as
>         parallelism
>         > is concerned? I'm not talking about cooperative
>         multitasking, but
>         > about really taking advantage of multiple cores. I'm well
>         aware of the
>         > runtime lock and I'm ok with message passing between
>         processes or a
>         > shared area in memory, but I'd rather have something more
>         high level
>         > than starting up several processes, creating a named pipe or
>         a socket,
>         > and trying to pass messages through that. Also, I assume
>         that using a
>         > shared area in memory involves some C code? Am I wrong about
>         that?
>         >
>         >
>         > I was expecting Core's Async to fill this role, but
>         realworldocaml is
>         > fuzzy on this topic, apparently preferring to dwell on
>         cooperative
>         > multitasking (which is fine but not what I'm looking for),
>         and I
>         > couldn't find any other documentation that was clearer.
>         >
>         >
>         > Thanks
>         >
>         > Yotam
>         >
>         
>         
>         --
>         ------------------------------------------------------------
>         Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
>         My OCaml site:          http://www.camlcity.org
>         Contact details:        http://www.camlcity.org/contact.html
>         Company homepage:       http://www.gerd-stolpmann.de
>         ------------------------------------------------------------
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Caml-list] Concurrent/parallel programming

[Mark Shinwell]

On 8 January 2014 11:36, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> There is a workaround in place - so far the OS supports it: thanks to
> Xavier the symbols caml_modify and caml_initialize are declared as weak
> in 4.01, allowing them to be redefined in executables. Netmulticore
> redefines these symbols with their pre-4.01 functions.
>
> This isn't optimal yet, because the old write barriers are a bit slower,
> and because this introduces a very low-level dependency on the current
> version of Ocaml. Nevertheless, it works for now. (Ideas for a better
> solution are highly welcome.)

Jeremie Dimino and myself have a somewhat embryonic proposal
that should permit most of the write barrier to be
circumvented for out-of-heap access, and also avoid the page
table test.  We'll send mail to the list in due course once
we've had time to think about this further.

Mark

Re: [Caml-list] Concurrent/parallel programming

[Gerd Stolpmann]

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

Am Mittwoch, den 08.01.2014, 11:55 +0000 schrieb Mark Shinwell:
> On 8 January 2014 11:36, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> > There is a workaround in place - so far the OS supports it: thanks to
> > Xavier the symbols caml_modify and caml_initialize are declared as weak
> > in 4.01, allowing them to be redefined in executables. Netmulticore
> > redefines these symbols with their pre-4.01 functions.
> >
> > This isn't optimal yet, because the old write barriers are a bit slower,
> > and because this introduces a very low-level dependency on the current
> > version of Ocaml. Nevertheless, it works for now. (Ideas for a better
> > solution are highly welcome.)
> 
> Jeremie Dimino and myself have a somewhat embryonic proposal
> that should permit most of the write barrier to be
> circumvented for out-of-heap access, and also avoid the page
> table test.  We'll send mail to the list in due course once
> we've had time to think about this further.

I'm very curious to hear about that.

So far I have only the idea to override the := operator selectively in
all modules that want to modify out-of-heap values:

let ( := ) = Netmcore_heap.assign h

where Netmcore_heap.assign is a C function that tests whether the
destination address is in the out-of-heap address space of h. If so, the
assignment can be done directly. If not, it just falls back to a normal
caml_modify.

This solution isn't nice, though, because it can be very problematic to
have the extra indirection of ref. So, what I'm searching for is a way
to turn any record mutation into an external C function call (or at
least to parametrize the write barrier somehow).

Gerd

> Mark
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Caml-list] Concurrent/parallel programming

[Markus Mottl]

Though it may not necessarily lend itself to every problem, it is
often a good idea to use vectorization to achieve high performance.
If your machine learning code is mostly numeric, you may want to use
bigarrays and highly optimized C or Fortran routines as building
blocks for your algorithm (e.g. using Lacaml).  Even without threads
this will generally give a very significant performance boost.  The
use of bigarrays also makes it possible to release the OCaml runtime
lock while a basic routine is executing, which would allow you to run
several such routines on multiple cores without having to resort to
more complicated multi-process solutions.  Note, too, that bigarrays
can in principle be used with shared memory if multiple processes are
still required.

Regards,
Markus

On Tue, Jan 7, 2014 at 2:54 PM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> Hi List
>
> So far, I've been programming in ocaml using only sequential programs. In my
> last project, which was an implementation of a large machine learning
> algorithm, I tried to speed up computation using a little bit of parallelism
> with ParMap, and it was a complete failure. It's possible that more time
> would have yielded better results, but I just didn't have the time to invest
> in it given how bad the initial results were.
>
> My question is, what are the options right now as far as parallelism is
> concerned? I'm not talking about cooperative multitasking, but about really
> taking advantage of multiple cores. I'm well aware of the runtime lock and
> I'm ok with message passing between processes or a shared area in memory,
> but I'd rather have something more high level than starting up several
> processes, creating a named pipe or a socket, and trying to pass messages
> through that. Also, I assume that using a shared area in memory involves
> some C code? Am I wrong about that?
>
> I was expecting Core's Async to fill this role, but realworldocaml is fuzzy
> on this topic, apparently preferring to dwell on cooperative multitasking
> (which is fine but not what I'm looking for), and I couldn't find any other
> documentation that was clearer.
>
> Thanks
> Yotam



-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: [Caml-list] Concurrent/parallel programming

[Francois Berenger]

On 01/08/2014 05:03 AM, Roberto Di Cosmo wrote:
> Dear Yotam,
>       speeding up a computation by parallelising part of it, as you are probably
> finding out the hard way, is not an easy task.
>
> Being the main developer of Parmap, I am quite curious to know where the
> "complete failure" you are mentioning actually comes from, and I would like
> to put you in touch with Francois Berenger, that has been using Parmap in
> production for quite a while with excellent results.

Absolutely!

I usually develop a sequential program working on a big list
and using List.iter or List.map.

When I am happy with the sequential program, I add an nprocs parameter
to use the Parmap equivalents when nprocs > 1.

The only problems I have encountered were out of memory
in case the nprocs forks did not fit on my machine when
I handled too big data.

I usually handle independent pieces of data, for example
many proteins or chemical molecules.

More answers follow below.

> All the best
>
> --
> Roberto
>
>
> On Tue, Jan 07, 2014 at 02:54:33PM -0500, Yotam Barnoy wrote:
>> Hi List
>>
>> So far, I've been programming in ocaml using only sequential programs. In my
>> last project, which was an implementation of a large machine learning
>> algorithm, I tried to speed up computation using a little bit of parallelism
>> with ParMap, and it was a complete failure. It's possible that more time would
>> have yielded better results, but I just didn't have the time to invest in it
>> given how bad the initial results were.
>>
>> My question is, what are the options right now as far as parallelism is
>> concerned? I'm not talking about cooperative multitasking, but about really
>> taking advantage of multiple cores. I'm well aware of the runtime lock and I'm
>> ok with message passing between processes or a shared area in memory, but I'd
>> rather have something more high level than starting up several processes,
>> creating a named pipe or a socket, and trying to pass messages through that.

There are MPI bindings for OCaml.

>> Also, I assume that using a shared area in memory involves some C code? Am I
>> wrong about that?

Gerd Stolpman's impressive ocamlnet library has nice pure OCaml wrappers 
for all this I believe.

http://projects.camlcity.org/projects/ocamlnet.html

>> I was expecting Core's Async to fill this role, but realworldocaml is fuzzy on
>> this topic, apparently preferring to dwell on cooperative multitasking (which
>> is fine but not what I'm looking for), and I couldn't find any other
>> documentation that was clearer.

Cf. parallel Vs. concurrent in there:

http://chimera.labs.oreilly.com/books/1230000000929/ch01.html#sec_terminology

I believe Parmap and MPI are for parallelism (what you want
very probably), while Async/Lwt and OCaml threads are for concurrency
(used in webservers, GUIs, etc.).

-- 
Best regards,
Francois Berenger.

Re: [Caml-list] Concurrent/parallel programming

[Roberto Di Cosmo]

Dear Yotam,
    there are regularly discussions on how to perform computations involving
parallelism on this list; a relatively recent and detailed one is 
 
    https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00043.html

And yes, one might be puzzled because there are so many different approaches,
but this is unavoidable, because there are so many different needs which are not
easily covered by a single approach.  If one wants to distribute a computation
that has very little data exchange compared to the local computation on each
node, the best approach is quite different to the one needed when large data
sets need to be shared or exchanged among the workers. And if you can do all on
a single machine, you can obtain significant speedup on a multicore machines by
exploiting OS level mechanisms that are not available if you need a cluster. Not
to mention the fact that in many cases one is looking for concurrency, and not
parallelism: even if at first sight they may look similar, deep down they really
are not.

Since you mention machine learning, it's quite probable that you want to perform
several iterations of relatively inexpensive computations on very large arrays
of integers or floats: if this is the case, Parmap (and not ParMap, that lends
to confusion with a different project in the Haskell world) was specially
designed to provide a highly efficient solution, and avoid boxing/unboxing
overhead of float arrays, *if* you use it properly (in particular, see the notes
at the end of the README file, or look at http://www.dicosmo.org/code/parmap/
and the research article pointed from there, where a precise discussion of the
steps involved in performing parallel computation on float arrays is given).
Actually, feedback from happy users, and synthetic benchmarks indicate that
Parmap should provide one of the best possible performances for this use case on
a multicore machine, short of resorting to using libraries like ancient, that
requires carefulness to avoid core dumps, or external libraries that already
have taken care of parallelism for you (like LaPack, etc.).

But if one performs a map over an array of floats *without* using
the special functions for floats, then all sort of boxing/unboxing and
copying will take place, and the "parallel" version might very well be
even slower than the sequential one, *if* the computation on each float
is fast.

Finally, if the float computations are the bottleneck, then a very interesting
project to keep an eye on is SPOC, that may significantly outperform everything
else on earth: taking advantage of the GPUs in your machine, it can perform
float computations on large arrays in a fraction of the time that your CPU,
even multicore, requires... but of course you need to learn to program a GPU
kernel for that. Learn more about this here http://www.algo-prog.info/spoc

The bottonline is, parallelism is easier than concurrency, but when
one looks for speed, every detail counts, and getting a real speedup
does not come for free.

We would really need a single place where to share ideas, tips and serious
analysis of the various available approaches: multicore machines and GPUs are a
reality, and this issue is bound to come up again and again.

--
Roberto



On Tue, Jan 07, 2014 at 02:54:33PM -0500, Yotam Barnoy wrote:
> Hi List
> 
> So far, I've been programming in ocaml using only sequential programs. In my
> last project, which was an implementation of a large machine learning
> algorithm, I tried to speed up computation using a little bit of parallelism
> with ParMap, and it was a complete failure. It's possible that more time would
> have yielded better results, but I just didn't have the time to invest in it
> given how bad the initial results were.
> 
> My question is, what are the options right now as far as parallelism is
> concerned? I'm not talking about cooperative multitasking, but about really
> taking advantage of multiple cores. I'm well aware of the runtime lock and I'm
> ok with message passing between processes or a shared area in memory, but I'd
> rather have something more high level than starting up several processes,
> creating a named pipe or a socket, and trying to pass messages through that.
> Also, I assume that using a shared area in memory involves some C code? Am I
> wrong about that?
> 
> I was expecting Core's Async to fill this role, but realworldocaml is fuzzy on
> this topic, apparently preferring to dwell on cooperative multitasking (which
> is fine but not what I'm looking for), and I couldn't find any other
> documentation that was clearer.
> 
> Thanks
> Yotam

-- 
Roberto Di Cosmo
 
------------------------------------------------------------------
Professeur               En delegation a l'INRIA
PPS                      E-mail: roberto@dicosmo.org
Universite Paris Diderot WWW  : http://www.dicosmo.org
Case 7014                Tel  : ++33-(0)1-57 27 92 20
5, Rue Thomas Mann       
F-75205 Paris Cedex 13   Identica: http://identi.ca/rdicosmo
FRANCE.                  Twitter: http://twitter.com/rdicosmo
------------------------------------------------------------------
Attachments:
MIME accepted, Word deprecated
      http://www.gnu.org/philosophy/no-word-attachments.html
------------------------------------------------------------------
Office location:
 
Bureau 3020 (3rd floor)
Batiment Sophie Germain
Avenue de France
Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
-----------------------------------------------------------------
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3                        

Re: [Caml-list] Concurrent/parallel programming

[Yotam Barnoy]

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

Thank you for the very detailed answer, Roberto, and thanks for the
reference to the excellent list discussion.

The machine learning example I gave was not a typical one -- I was using it
for illustration, and honestly I wasn't sure what kind of feedback I'd get.
I'd love to go back and figure out what was wrong with my implementation,
but I currently don't have the time. Nevertheless, I'm glad to see that
many people on this list use Parmap successfully. My assumption at the time
was that perhaps the code was creating and destructing sub-processes
continuously, since the slowdown I experienced was by several orders of
magnitude, but I'm just not sure.

Regarding a place to share ideas, it seems like it would be very useful to
have an official ocaml wiki. Haskell has this and it's a huge help. In
fact, I would say haskell development would be greatly hampered without it.
There's so much information that's relevant to more than one library ie.
doesn't fit in any particular library's documentation. It wouldn't be too
hard to set up a wikimedia instance on ocaml.org, would it? Alternatively
it should be pretty easy to set up something on wikia. This wiki would also
be a great place to describe the conceptual implementation of the compiler,
which is again what haskell has.

In terms of my personal use cases, I'm much more likely to want to be able
to share a lot of state between cores than anything else. Out of everything
that's been mentioned so far (including the discussion you linked), the
best fit for me seems to be either netmulticore or perhaps ocaml's mpi
bindings, given the testament to mpi's speed I saw in the aforementioned
discussion. Netmulticore seems like a marvelous piece of work, but I'm
bothered by how unsafe it is -- one of ocaml's great assets is its safety.
I wish there was a way for the type system or the runtime in general to
make a shared heap work better, but I guess we're stuck with what we have
for now. Anyway, I'm really excited to see what Leo White can come up with
for making a truly multicore runtime a reality.

-Yotam


On Wed, Jan 8, 2014 at 3:29 PM, Roberto Di Cosmo <roberto@dicosmo.org>wrote:

> Dear Yotam,
>     there are regularly discussions on how to perform computations
> involving
> parallelism on this list; a relatively recent and detailed one is
>
>     https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00043.html
>
> And yes, one might be puzzled because there are so many different
> approaches,
> but this is unavoidable, because there are so many different needs which
> are not
> easily covered by a single approach.  If one wants to distribute a
> computation
> that has very little data exchange compared to the local computation on
> each
> node, the best approach is quite different to the one needed when large
> data
> sets need to be shared or exchanged among the workers. And if you can do
> all on
> a single machine, you can obtain significant speedup on a multicore
> machines by
> exploiting OS level mechanisms that are not available if you need a
> cluster. Not
> to mention the fact that in many cases one is looking for concurrency, and
> not
> parallelism: even if at first sight they may look similar, deep down they
> really
> are not.
>
> Since you mention machine learning, it's quite probable that you want to
> perform
> several iterations of relatively inexpensive computations on very large
> arrays
> of integers or floats: if this is the case, Parmap (and not ParMap, that
> lends
> to confusion with a different project in the Haskell world) was specially
> designed to provide a highly efficient solution, and avoid boxing/unboxing
> overhead of float arrays, *if* you use it properly (in particular, see the
> notes
> at the end of the README file, or look at
> http://www.dicosmo.org/code/parmap/
> and the research article pointed from there, where a precise discussion of
> the
> steps involved in performing parallel computation on float arrays is
> given).
> Actually, feedback from happy users, and synthetic benchmarks indicate that
> Parmap should provide one of the best possible performances for this use
> case on
> a multicore machine, short of resorting to using libraries like ancient,
> that
> requires carefulness to avoid core dumps, or external libraries that
> already
> have taken care of parallelism for you (like LaPack, etc.).
>
> But if one performs a map over an array of floats *without* using
> the special functions for floats, then all sort of boxing/unboxing and
> copying will take place, and the "parallel" version might very well be
> even slower than the sequential one, *if* the computation on each float
> is fast.
>
> Finally, if the float computations are the bottleneck, then a very
> interesting
> project to keep an eye on is SPOC, that may significantly outperform
> everything
> else on earth: taking advantage of the GPUs in your machine, it can perform
> float computations on large arrays in a fraction of the time that your CPU,
> even multicore, requires... but of course you need to learn to program a
> GPU
> kernel for that. Learn more about this here http://www.algo-prog.info/spoc
>
> The bottonline is, parallelism is easier than concurrency, but when
> one looks for speed, every detail counts, and getting a real speedup
> does not come for free.
>
> We would really need a single place where to share ideas, tips and serious
> analysis of the various available approaches: multicore machines and GPUs
> are a
> reality, and this issue is bound to come up again and again.
>
> --
> Roberto
>
>
>
> On Tue, Jan 07, 2014 at 02:54:33PM -0500, Yotam Barnoy wrote:
> > Hi List
> >
> > So far, I've been programming in ocaml using only sequential programs.
> In my
> > last project, which was an implementation of a large machine learning
> > algorithm, I tried to speed up computation using a little bit of
> parallelism
> > with ParMap, and it was a complete failure. It's possible that more time
> would
> > have yielded better results, but I just didn't have the time to invest
> in it
> > given how bad the initial results were.
> >
> > My question is, what are the options right now as far as parallelism is
> > concerned? I'm not talking about cooperative multitasking, but about
> really
> > taking advantage of multiple cores. I'm well aware of the runtime lock
> and I'm
> > ok with message passing between processes or a shared area in memory,
> but I'd
> > rather have something more high level than starting up several processes,
> > creating a named pipe or a socket, and trying to pass messages through
> that.
> > Also, I assume that using a shared area in memory involves some C code?
> Am I
> > wrong about that?
> >
> > I was expecting Core's Async to fill this role, but realworldocaml is
> fuzzy on
> > this topic, apparently preferring to dwell on cooperative multitasking
> (which
> > is fine but not what I'm looking for), and I couldn't find any other
> > documentation that was clearer.
> >
> > Thanks
> > Yotam
>
> --
> Roberto Di Cosmo
>
> ------------------------------------------------------------------
> Professeur               En delegation a l'INRIA
> PPS                      E-mail: roberto@dicosmo.org
> Universite Paris Diderot WWW  : http://www.dicosmo.org
> Case 7014                Tel  : ++33-(0)1-57 27 92 20
> 5, Rue Thomas Mann
> F-75205 Paris Cedex 13   Identica: http://identi.ca/rdicosmo
> FRANCE.                  Twitter: http://twitter.com/rdicosmo
> ------------------------------------------------------------------
> Attachments:
> MIME accepted, Word deprecated
>       http://www.gnu.org/philosophy/no-word-attachments.html
> ------------------------------------------------------------------
> Office location:
>
> Bureau 3020 (3rd floor)
> Batiment Sophie Germain
> Avenue de France
> Metro Bibliotheque Francois Mitterrand, ligne 14/RER C
> -----------------------------------------------------------------
> GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
>

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

Re: [Caml-list] Concurrent/parallel programming

[Anil Madhavapeddy]

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

On 8 Jan 2014, at 22:13, Yotam Barnoy <yotambarnoy@gmail.com> wrote:

> Regarding a place to share ideas, it seems like it would be very useful to have an official ocaml wiki. Haskell has this and it's a huge help. In fact, I would say haskell development would be greatly hampered without it. There's so much information that's relevant to more than one library ie. doesn't fit in any particular library's documentation. It wouldn't be too hard to set up a wikimedia instance on ocaml.org, would it? Alternatively it should be pretty easy to set up something on wikia. This wiki would also be a great place to describe the conceptual implementation of the compiler, which is again what haskell has.

We do have a fledgling service for "domain-specific" conversations, in the form of lists.ocaml.org.  In fact, we set up a "wg-parallel" mailing list last year, but never announced it for various reasons.  This seems like a good time to advertise its existence:

http://lists.ocaml.org/pipermail/wg-parallel/

(note that if anyone else would like an archived list on lists.ocaml.org for a project or community group, then please do drop a line to infrastructure@lists.ocaml.org to request it)

Regarding other services on ocaml.org, we (the "infrastructure team") are happy to set them up, but please bear in mind that they all come with a maintenance burden.  Dealing with security issues, backups, software updates, outages all take up time, and I confess a preference for sipping martinis and hacking on code instead of sysadmin work. Jeremy and Leo got tired of waiting for me to set up the wiki too, and started:
https://github.com/ocamllabs/compiler-hacking/wiki

If you follow the links through there, there is a 'compiler internals' page that would be good to contribute to, and you (or anyone else) is extremely welcome to add more information on topics such as parallel programming libraries there.  I think we could have a decent stab at a wiki.ocaml.org by backing it against a GitHub repository, and not have to do any special hosting for it at all (the OPAM web pages work in a similar fashion at the moment).  But for now though, I'd recommend focussing on the problem at hand (parallel programming) and getting some information down somewhere, and less on the lack of a central wiki.

-anil

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

Re: [Caml-list] [ocaml-infra] Concurrent/parallel programming

[Ashish Agarwal]

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

Regarding the need for a wiki, why not create a new Parallel Programming
page under tutorials [1]. A "tutorial" can be as simple as listing the
libraries available and a brief description about the high level goal of
each.

Note ocaml.org is now almost entirely written in Markdown. A new page can
be written quite easily, see for example The Basics tutorial [2].

[1] http://ocaml.org/learn/tutorials/
[2]
https://github.com/ocaml/ocaml.org/blob/master/site/learn/tutorials/basics.md




On Wed, Jan 8, 2014 at 5:38 PM, Anil Madhavapeddy <anil@recoil.org> wrote:

> On 8 Jan 2014, at 22:13, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
>
> Regarding a place to share ideas, it seems like it would be very useful to
> have an official ocaml wiki. Haskell has this and it's a huge help. In
> fact, I would say haskell development would be greatly hampered without it.
> There's so much information that's relevant to more than one library ie.
> doesn't fit in any particular library's documentation. It wouldn't be too
> hard to set up a wikimedia instance on ocaml.org, would it? Alternatively
> it should be pretty easy to set up something on wikia. This wiki would also
> be a great place to describe the conceptual implementation of the compiler,
> which is again what haskell has.
>
>
> We do have a fledgling service for "domain-specific" conversations, in the
> form of lists.ocaml.org.  In fact, we set up a "wg-parallel" mailing list
> last year, but never announced it for various reasons.  This seems like a
> good time to advertise its existence:
>
> http://lists.ocaml.org/pipermail/wg-parallel/
>
> (note that if anyone else would like an archived list on lists.ocaml.orgfor a project or community group, then please do drop a line to
> infrastructure@lists.ocaml.org to request it)
>
> Regarding other services on ocaml.org, we (the "infrastructure team") are
> happy to set them up, but please bear in mind that they all come with a
> maintenance burden.  Dealing with security issues, backups, software
> updates, outages all take up time, and I confess a preference for sipping
> martinis and hacking on code instead of sysadmin work. Jeremy and Leo got
> tired of waiting for me to set up the wiki too, and started:
> https://github.com/ocamllabs/compiler-hacking/wiki
>
> If you follow the links through there, there is a 'compiler internals'
> page that would be good to contribute to, and you (or anyone else) is
> extremely welcome to add more information on topics such as parallel
> programming libraries there.  I think we could have a decent stab at a
> wiki.ocaml.org by backing it against a GitHub repository, and not have to
> do any special hosting for it at all (the OPAM web pages work in a similar
> fashion at the moment).  But for now though, I'd recommend focussing on the
> problem at hand (parallel programming) and getting some information down
> somewhere, and less on the lack of a central wiki.
>
> -anil
>
> _______________________________________________
> Infrastructure mailing list
> Infrastructure@lists.ocaml.org
> http://lists.ocaml.org/listinfo/infrastructure
>
>

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

Re: [Caml-list] [ocaml-infra] Concurrent/parallel programming

[Yotam Barnoy]

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

Wow, I wasn't aware of any of this!

That tutorials page is really incredible... just so much material (and in
different languages too!). And I'm really happy to see those wiki pages as
well. So I guess now there are... too many places to put material? I think
there has to be one centralized location for a thorough, wiki-like
repository.

The tutorials page looks excellent, although I have a feeling people just
aren't going to want to fork, edit, and then submit a push request. The
thing about wikis is that contributing takes minimal effort. Is it possible
to allow anyone with a github account to contribute to parts of the site
(as if it were a wiki?) Also, in a wiki, if you want to create a hierarchy
(ie. split off into sub-pages) at any point, you can easily do so. Is this
doable in the tutorial page? For example, I think it makes more sense to
have a page other than 'tutorials' as the topic for discussions such as
compiler internals and parallelism.

Regarding the existing wikis, how hard would it be to centralize
everything? I'm not so fond of the fact that there is one wiki for compiler
hacking, and one for ocaml internals. Wikis generally include everything on
a wide topic. So to me it would make more sense to have an 'ocaml' wiki,
with sub-categories for compiler hacking, internals, parallelism etc.

Any other opinions?

-Yotam


On Wed, Jan 8, 2014 at 5:57 PM, Ashish Agarwal <agarwal1975@gmail.com>wrote:

> Regarding the need for a wiki, why not create a new Parallel Programming
> page under tutorials [1]. A "tutorial" can be as simple as listing the
> libraries available and a brief description about the high level goal of
> each.
>
> Note ocaml.org is now almost entirely written in Markdown. A new page can
> be written quite easily, see for example The Basics tutorial [2].
>
> [1] http://ocaml.org/learn/tutorials/
> [2]
> https://github.com/ocaml/ocaml.org/blob/master/site/learn/tutorials/basics.md
>
>
>
>
> On Wed, Jan 8, 2014 at 5:38 PM, Anil Madhavapeddy <anil@recoil.org> wrote:
>
>> On 8 Jan 2014, at 22:13, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
>>
>> Regarding a place to share ideas, it seems like it would be very useful
>> to have an official ocaml wiki. Haskell has this and it's a huge help. In
>> fact, I would say haskell development would be greatly hampered without it.
>> There's so much information that's relevant to more than one library ie.
>> doesn't fit in any particular library's documentation. It wouldn't be too
>> hard to set up a wikimedia instance on ocaml.org, would it?
>> Alternatively it should be pretty easy to set up something on wikia. This
>> wiki would also be a great place to describe the conceptual implementation
>> of the compiler, which is again what haskell has.
>>
>>
>> We do have a fledgling service for "domain-specific" conversations, in
>> the form of lists.ocaml.org.  In fact, we set up a "wg-parallel" mailing
>> list last year, but never announced it for various reasons.  This seems
>> like a good time to advertise its existence:
>>
>> http://lists.ocaml.org/pipermail/wg-parallel/
>>
>> (note that if anyone else would like an archived list on lists.ocaml.orgfor a project or community group, then please do drop a line to
>> infrastructure@lists.ocaml.org to request it)
>>
>> Regarding other services on ocaml.org, we (the "infrastructure team")
>> are happy to set them up, but please bear in mind that they all come with a
>> maintenance burden.  Dealing with security issues, backups, software
>> updates, outages all take up time, and I confess a preference for sipping
>> martinis and hacking on code instead of sysadmin work. Jeremy and Leo got
>> tired of waiting for me to set up the wiki too, and started:
>> https://github.com/ocamllabs/compiler-hacking/wiki
>>
>> If you follow the links through there, there is a 'compiler internals'
>> page that would be good to contribute to, and you (or anyone else) is
>> extremely welcome to add more information on topics such as parallel
>> programming libraries there.  I think we could have a decent stab at a
>> wiki.ocaml.org by backing it against a GitHub repository, and not have
>> to do any special hosting for it at all (the OPAM web pages work in a
>> similar fashion at the moment).  But for now though, I'd recommend
>> focussing on the problem at hand (parallel programming) and getting some
>> information down somewhere, and less on the lack of a central wiki.
>>
>> -anil
>>
>> _______________________________________________
>> Infrastructure mailing list
>> Infrastructure@lists.ocaml.org
>> http://lists.ocaml.org/listinfo/infrastructure
>>
>>
>

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