6 ms·

Multicore OCaml: March 2020 update

124 points by sadiq 7y ago

sadiq 7y ago
I've been hacking on the OCaml multicore GC recently and am happy to answer questions anyone has.
- anuragsoni 7y ago
  It's been really nice to see these updates from the multicore team. I'm looking forward to the systhread support using the Domain/Atomic modules. Being able to build recent versions of dune is something i'm looking forward to. That'll make it really easy to try (and hopefully contribute/port examples and benchmarks) to the multicore project.
- vijaybritto 7y ago
  When is it expected to be released?
  - sadiq 7y ago
    (Speaking personally and not for OCaml Labs who are driving most of the multicore work at the moment) You can use multicore right now: https://github.com/ocaml-multicore/ocaml-multicore https://github.com/ocaml-multicore/ocaml-multicore though it's currently at an older version of OCaml, 4.06.1. There's work currently going on to rebase on to OCaml trunk, show-stopping bugs aside there should be a more up to date version of multicore in the next couple of months - then the focus will be on upstreaming. Hard to give a reasonable timeframe for release because that's going to depend a lot on how things get upstream.
- pdimitar 7y ago
  As asked before: In what form will Multicore OCaml support the, you know, multicore stuff? Will it be native OS threads? CSP? Actors? Something else?
  - kcsrk 7y ago
    (I work on Multicore OCaml) Multicore OCaml separates the notion of concurrency (overlapped execution) and parallelism (simultaneous execution). You can have one without the other but also have both. The main principle that we're going for is that the compiler should expose just enough support for concurrency and parallelism such that interesting features can live outside the compiler as libraries. This permits the library evolution not to be tied with the language evolution but also permits diversity of libraries beyond what the language developers can aim to achieve. That said, we will build and maintain a few core libraries for concurrency and parallelism. For concurrency, Multicore OCaml exposes effect handlers [1,2,3] which allows you to build generators, async/await, coroutines, etc as library functions (as opposed to primitives natively supported by the compiler). For example, have a look at aeio [4] which permits the construction of scalable asynchronous I/O in direct-style (no callbacks). aeio is also discussed in [1]. We also plan to extend Lwt to support parallelism. For parallelism, the compiler exposes Domains, which are a wrapper over OS-threads [5]. Domains expose a low-level API that is not suitable for end user consumption. On top of domains, we support channels with bounded buffers [6] (similar to channels in Go, Mvars in GHC Haskell) as well as software transactional memory (STM) that supports shared memory and message passing concurrency and which can take advantage of hardware transactional memory [7]. [1] Concurrent System Programming with Effect Handlers: http://kcsrk.info/papers/system_effects_feb_18.pdf http://kcsrk.info/papers/system_effects_feb_18.pdf [2] CUFP effects tutorial: https://github.com/ocamllabs/ocaml-effects-tutorial https://github.com/ocamllabs/ocaml-effects-tutorial [3] Effects Examples: https://github.com/kayceesrk/effects-examples https://github.com/kayceesrk/effects-examples [4] Aeio: Asynchronous Effect-based IO https://github.com/kayceesrk/ocaml-aeio https://github.com/kayceesrk/ocaml-aeio [5] Domains: https://github.com/ocaml-multicore/ocaml-multicore/blob/parallel_minor_gc/stdlib/domain.mli https://github.com/ocaml-multicore/ocaml-multicore/blob/para... [6] domainslib: https://github.com/ocaml-multicore/domainslib https://github.com/ocaml-multicore/domainslib [7] Reagents: https://github.com/ocaml-multicore/reagents https://github.com/ocaml-multicore/reagents
    - pdimitar 7y ago
      Thank you for the extremely informative answer! It was very helpful. Another question, if you allow me: Will you provide preemptive scheduling primitives? Or will they be possible through the more low-level interface you described? IMO preemptive scheduling is something that's very necessary nowadays, especially with the explosion of CPU core count.
thegreatpeter 7y ago
I'm very excited about this because it means ReasonML will be able to take advantage of multi cores for server apps :)
- rienbdj 7y ago
  I don't understand the Reason hype when F# / Fable already offers this
  - cies 7y ago
    As an outsider. F# seems not to get the full blessing. ReasonML is a big thing at Facebook. F# kind of keeps you on the Microsoft stack. Reason has both OCaml based native and JS based interpreted. Reason integrates very well with JS-land. React bindings are maintained by FB itself. Bit-by-bit transitions from JS to Reason are feasible. Fable, I had to take a look again, but it seems a lot more mature then I remember it was a few years back.
    - pjmlp 7y ago
      To be honest, ReasonML doesn't seem to have not even half of the community than F# has, nor the IDE tooling for that matter.
      - bananabreakfast 7y ago
        Reason is new. F# is not
        pjmlp 7y ago
        It thought it was supposed to be a big thing.
        yawaramin 7y ago
        I don't know why someone would think that, Reason is actually pretty niche ;-) Of course, I would love to see it go mainstream, but realistically speaking that will need to happen slowly.
dang 7y ago
https://news.ycombinator.com/item?id=22443428 https://news.ycombinator.com/item?id=22443428

124 points by sadiq 7y ago

sadiq 7y ago

I've been hacking on the OCaml multicore GC recently and am happy to answer questions anyone has.

anuragsoni 7y ago
It's been really nice to see these updates from the multicore team. I'm looking forward to the systhread support using the Domain/Atomic modules. Being able to build recent versions of dune is something i'm looking forward to. That'll make it really easy to try (and hopefully contribute/port examples and benchmarks) to the multicore project.
vijaybritto 7y ago
When is it expected to be released?
- sadiq 7y ago
  (Speaking personally and not for OCaml Labs who are driving most of the multicore work at the moment) You can use multicore right now: https://github.com/ocaml-multicore/ocaml-multicore https://github.com/ocaml-multicore/ocaml-multicore though it's currently at an older version of OCaml, 4.06.1. There's work currently going on to rebase on to OCaml trunk, show-stopping bugs aside there should be a more up to date version of multicore in the next couple of months - then the focus will be on upstreaming. Hard to give a reasonable timeframe for release because that's going to depend a lot on how things get upstream.
pdimitar 7y ago
As asked before: In what form will Multicore OCaml support the, you know, multicore stuff? Will it be native OS threads? CSP? Actors? Something else?
- kcsrk 7y ago
  (I work on Multicore OCaml) Multicore OCaml separates the notion of concurrency (overlapped execution) and parallelism (simultaneous execution). You can have one without the other but also have both. The main principle that we're going for is that the compiler should expose just enough support for concurrency and parallelism such that interesting features can live outside the compiler as libraries. This permits the library evolution not to be tied with the language evolution but also permits diversity of libraries beyond what the language developers can aim to achieve. That said, we will build and maintain a few core libraries for concurrency and parallelism. For concurrency, Multicore OCaml exposes effect handlers [1,2,3] which allows you to build generators, async/await, coroutines, etc as library functions (as opposed to primitives natively supported by the compiler). For example, have a look at aeio [4] which permits the construction of scalable asynchronous I/O in direct-style (no callbacks). aeio is also discussed in [1]. We also plan to extend Lwt to support parallelism. For parallelism, the compiler exposes Domains, which are a wrapper over OS-threads [5]. Domains expose a low-level API that is not suitable for end user consumption. On top of domains, we support channels with bounded buffers [6] (similar to channels in Go, Mvars in GHC Haskell) as well as software transactional memory (STM) that supports shared memory and message passing concurrency and which can take advantage of hardware transactional memory [7]. [1] Concurrent System Programming with Effect Handlers: http://kcsrk.info/papers/system_effects_feb_18.pdf http://kcsrk.info/papers/system_effects_feb_18.pdf [2] CUFP effects tutorial: https://github.com/ocamllabs/ocaml-effects-tutorial https://github.com/ocamllabs/ocaml-effects-tutorial [3] Effects Examples: https://github.com/kayceesrk/effects-examples https://github.com/kayceesrk/effects-examples [4] Aeio: Asynchronous Effect-based IO https://github.com/kayceesrk/ocaml-aeio https://github.com/kayceesrk/ocaml-aeio [5] Domains: https://github.com/ocaml-multicore/ocaml-multicore/blob/parallel_minor_gc/stdlib/domain.mli https://github.com/ocaml-multicore/ocaml-multicore/blob/para... [6] domainslib: https://github.com/ocaml-multicore/domainslib https://github.com/ocaml-multicore/domainslib [7] Reagents: https://github.com/ocaml-multicore/reagents https://github.com/ocaml-multicore/reagents
  - pdimitar 7y ago
    Thank you for the extremely informative answer! It was very helpful. Another question, if you allow me: Will you provide preemptive scheduling primitives? Or will they be possible through the more low-level interface you described? IMO preemptive scheduling is something that's very necessary nowadays, especially with the explosion of CPU core count.

thegreatpeter 7y ago

I'm very excited about this because it means ReasonML will be able to take advantage of multi cores for server apps :)

rienbdj 7y ago
I don't understand the Reason hype when F# / Fable already offers this
- cies 7y ago
  As an outsider. F# seems not to get the full blessing. ReasonML is a big thing at Facebook. F# kind of keeps you on the Microsoft stack. Reason has both OCaml based native and JS based interpreted. Reason integrates very well with JS-land. React bindings are maintained by FB itself. Bit-by-bit transitions from JS to Reason are feasible. Fable, I had to take a look again, but it seems a lot more mature then I remember it was a few years back.
  - pjmlp 7y ago
    To be honest, ReasonML doesn't seem to have not even half of the community than F# has, nor the IDE tooling for that matter.
    - bananabreakfast 7y ago
      Reason is new. F# is not
      - pjmlp 7y ago
        It thought it was supposed to be a big thing.
        yawaramin 7y ago
        I don't know why someone would think that, Reason is actually pretty niche ;-) Of course, I would love to see it go mainstream, but realistically speaking that will need to happen slowly.

dang 7y ago

https://news.ycombinator.com/item?id=22443428 https://news.ycombinator.com/item?id=22443428