11 ms·

Multicore OCaml: October 2020

92 points by sadiq 6y ago

cies 6y ago
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 https://github.com/inhabitedtype/httpaf
- rbjorklin 6y ago
  As you might already be aware OCaml is present on the nightly TechEmpower runs: https://www.techempower.com/benchmarks/#section=test&runid=10218082-6e18-4513-9be4-e721bb8a1596&hw=ph&test=json&l=z8jn5r-v&a=2 https://www.techempower.com/benchmarks/#section=test&runid=1... Unfortunately not doing too well.
BenoitP 6y ago
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 http://166.78.252.20/meetings/ocaml/2014/ocaml2014_1.pdf
- sadiq 6y ago
  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 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&t=6195 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_ZowsIOu5fHjRj0ua7_QWE_L789K_f&index=6&t=0s https://www.youtube.com/watch?v=Z7YZR1q8wzI&list=PLKO_ZowsIO...
amelius 6y ago
Did they consider using another VM for OCaml? (Like JVM, CLR, or perhaps even transpile to GoLang)?
- adultSwim 6y ago
  Yes. That suggestion has been brought up often.
- brmgb 6y ago
  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/5770514eec29b794c2d560fc3282bc14.en.html http://caml.inria.fr/pub/ml-archives/caml-list/2001/02/57705... [2] https://fsharp.org/ https://fsharp.org/
  - systems 6y ago
    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/ https://fsharp.org/history/
- vphantom 6y ago
  There was http://www.ocamljava.org/ 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 https://github.com/AbstractMachinesLab/caramel

92 points by sadiq 6y ago

cies 6y ago

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 https://github.com/inhabitedtype/httpaf

rbjorklin 6y ago
As you might already be aware OCaml is present on the nightly TechEmpower runs: https://www.techempower.com/benchmarks/#section=test&runid=10218082-6e18-4513-9be4-e721bb8a1596&hw=ph&test=json&l=z8jn5r-v&a=2 https://www.techempower.com/benchmarks/#section=test&runid=1... Unfortunately not doing too well.

BenoitP 6y ago

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 http://166.78.252.20/meetings/ocaml/2014/ocaml2014_1.pdf

sadiq 6y ago
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 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&t=6195 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_ZowsIOu5fHjRj0ua7_QWE_L789K_f&index=6&t=0s https://www.youtube.com/watch?v=Z7YZR1q8wzI&list=PLKO_ZowsIO...

amelius 6y ago

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

adultSwim 6y ago
Yes. That suggestion has been brought up often.
brmgb 6y ago
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/5770514eec29b794c2d560fc3282bc14.en.html http://caml.inria.fr/pub/ml-archives/caml-list/2001/02/57705... [2] https://fsharp.org/ https://fsharp.org/
- systems 6y ago
  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/ https://fsharp.org/history/
vphantom 6y ago
There was http://www.ocamljava.org/ 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 https://github.com/AbstractMachinesLab/caramel