What is the state of OCaml's parallelization abilities?
Asked Answered
F

4

41

I'm interested in using OCaml for a project, however I'm not sure about where its parallelization capabilities are anymore. Is there a message passing ability in OCaml? Is OCaml able to efficiently use more than 1 CPU?

Most of what I have read on the subject was written in 2002-2006, and I haven't seen anything more recent.

Thanks!

Froufrou answered 5/7, 2011 at 20:30 Comment(1)
See also this related question on SOMedia
E
23

This 2009 issue of the Caml weekly news ("CWN", a digest of interesting messages from the caml list) shows that:

  • the official party line on threads and Ocaml hasn't changed. A notable quote:

    (...) in general, the whole standard library is not thread-safe. Probably that should be stated in the documentation for the threads library, but there isn't much point in documenting it per standard library module. -- X. Leroy

    (for how Ocaml threads can still be useful, see a remark by the culprit himself in another question on SO)

  • the most frequently adopted paradigm for parallelism is message-passing, and of note is X. Leroy's OcamlMPI, providing bindings for programming in SPMD style against the MPI standard. The same CWN issue I pointed to above provides references to examples, and numerous other related projects.

  • another message-passing solution is JoCaml, pioneering new style of concurrent communications known as join calculus. Note that it is binary-compatible with OCaml compilers.

  • that did not prevent the confection of a runtime whose GC is ok with parallelism, though: see a discussion of OCAML4MC in this other issue of the CWN.

There is also:

  • Netmulticore - multi-processing sharing ocaml values via mapped shared memory.

  • CamlP3l - compiler for Caml parallel programs.

  • OCaml-Java - an OCaml compiler that emits Java bytecode


I haven't followed more recent discussions about Ocaml & parallel programming, though. I'm leaving this CW so that others can update what I mention. It would be great if this question could reach the same level of completeness as the analogous one for Haskell.

Excurrent answered 5/7, 2011 at 20:30 Comment(3)
Where does github.com/ocamllabs/compiler-hacking/wiki/Multicore-OCaml fit into this picture?Fuliginous
Tracking the state of Multicore OCaml and its mainstreaming in this reddit thread reddit.com/r/ocaml/comments/63hgid/tracking_multicore_progressMendelian
While waiting for multicore-ocaml, you can use the ocaml libraries (available in opam): parmap or paranyDerman
M
8

At present, the OCaml runtime does not support running across multiple cores in parallel, so a single OCaml process cannot take advantage of multiple cores. This is unlikely to change directly; the direction the OCaml developers are most interested in taking for increased parallelism seems to be allowing multiple OCaml runtimes to run in parallel in a single process; this will allow for very fast message passing, but will not allow multiple threads to run in parallel in a shared-memory configuration. The major hangup is the garbage collector; some years ago, the team experimented with a concurrent GC, but it introduced unacceptable slowdowns in the single-threaded case.

There are a couple of projects, namely Functory and OCamlnet, which provide multicore-happy parallelism by using multiple processes.

In general, the OCaml community tends to favor message passing approaches, which can be done across process boundaries (like OCamlnet does), over single-process shared-memory multithreading. If your program can be split into multiple processes (many can!), then yes, you can efficiently use multiple CPUs.

Mori answered 5/7, 2011 at 23:3 Comment(4)
Regarding the concurrent GC experiment: Would it be possible to have different GCs that could be "plugged in"? So out-of-the box OCaml would come with the non-concurrent GC (as it does now), with the option of using a concurrent GC if you needed it - Would that scenario be possible?Invigilate
@Invigilate If the different GCs are binary-compatible, it might be possible. It has been discussed; I'm not entirely sure why it hasn't been done, other than that no one has done the work and/or they don't want to maintain multiple runtimes.Mori
@MichaelEkstrand The OC4MC project already cleaned up OCaml's GC interface in order to facilitate the creation of more GCs. The problem is that OCaml's data representation places huge stress on the GC so it would require a lot of work to get comparable performance out of a new GC which puts everyone off trying.Forenamed
Good to know, but what if I need to use OCaml for a shared-memory application? Are there any libraries/modules I can use? The Netmulticore mentioned in community wiki is said to be very new and for sure neither fully optimized nor even bug-free. according to this post: blog.camlcity.org/blog/multicore3.html , but that is over 4 years ago, I wonder if things have changed for the better?Seppala
J
2

Ocaml 5.0 (16 Dec 2022) introduced multicore support which means that OCaml supports parallel execution on OS threads.

See also the documentation for this in the OCaml 5.0 Manual. Using domainslib, there is support for both async/await style parallel tasks and a parallel_for for direct parallel execution - using shared memory parallelism.

As of OCaml 5.1 it still has some limitations, multicore is only supported for architectures: ARM64, x86-64, RISC-V, IBM Z (please edit this answer when this changes), and only up to 128 domains - corresponding to 128 OS threads.

Jemimah answered 27/8, 2023 at 8:38 Comment(0)
R
1

BSMLlib provides a simplified programming interface for data-parallel programming in OCaml. Its execution amounts to BSP-style message passing but it is deterministic and even declarative for a subset of OCaml. The key concept is the 'a par type which corresponds to a vector of values, one per process.

http://traclifo.univ-orleans.fr/BSML/ http://fr.wikipedia.org/wiki/Bulk_Synchronous_Parallel_ML

Gaétan Hains University Paris-Est

Ranchero answered 17/3, 2014 at 13:47 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.