Multicore OCaml: October 2020 | Hacker News Reader

Multicore OCaml: October 2020

discuss.ocaml.org

92 pointssadiq9 comments

Lots of talks about `Domains`. So I looked it up [1] and here is what this is about:

> the virtual machine contains a number of domains, each running as a separate system thread in the same address space. Each domain has a relatively small local heap, and a large shared heap is shared between all domains. The local heaps are collected with OCaml’s existing minor collector (modified to use thread-local instead of global state), and long-lived objects are promoted to the shared heap.

> We maintain the invariants that no domain ever follows a pointer to another domain’s local heap, and that immutable fields of objects on the shared heap only point to other objects on the shared heap. Mutable fields of objects on the shared heap may point to objects on a domain’s local heap, and we describe how reads of such fields are handled in Section 4.

> Since local heaps are only ever accessed by a single domain, no synchronisation between threads is required when a domain collects its local heap. This allows us to sustain the high rate of allocation of short-lived objects that many OCaml programs exhibit.

[1] http://166.78.252.20/meetings/ocaml/2014/ocaml2014_1.pdf

Unfortunately some of this information is out of date and refers to Multicore with the concurrent minor collector - a collector we don't plan to upstream.

We plan to upstream the parallel minor collector, which has a shared minor heap across all domains. It maintains compatibility with the existing C API and seems to perform well.

You can find more information on both the concurrent minor collector and the parallel minor collector in the recent ICFP paper: https://dl.acm.org/doi/10.1145/3408995

You can also see KC's talk on the paper here: https://www.youtube.com/watch?v=ASX79I0jm6M&feature=youtu.be...

The TL;DR on Domains is that they're heavyweight threads. You essentially want as many as you have cores.

Our talk (separate to the one above) at the OCaml Workshop also covers a lot of the terminology and how to get started with Multicore today: https://www.youtube.com/watch?v=Z7YZR1q8wzI&list=PLKO_ZowsIO...

I wonder how this will impact the performance of libs like http/af[0] (which is event-based, so it should not make much/any difference, right?).

Also: should we expect OCaml entries to show up higher in TechEmpower style benchmarks in the near future?

[0]: https://github.com/inhabitedtype/httpaf

As you might already be aware OCaml is present on the nightly TechEmpower runs: https://www.techempower.com/benchmarks/#section=test&runid=1... Unfortunately not doing too well.

Did they consider using another VM for OCaml? (Like JVM, CLR, or perhaps even transpile to GoLang)?

There was http://www.ocamljava.org/ around 2015 but there wasn't enough interest to keep the project going.

A fascinating project currently in development is Caramel, a BEAM VM (Erlang) back-end to the OCaml compiler: https://github.com/AbstractMachinesLab/caramel

I heard some random researcher from Microsoft asked about that on the OCaml mailing list in 2001 [1]. I think it led nowhere [2].

[1] http://caml.inria.fr/pub/ml-archives/caml-list/2001/02/57705... [2] https://fsharp.org/

Well i think, eventually it became F#, which is a different language, but this is what I understood from the parts I read from "The Early History of the F# Language, camera ready, HOPL-IV (PDF)" https://fsharp.org/history/

Yes. That suggestion has been brought up often.

Reply on news.ycombinator.com