4 ms·

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

by sadiq 7y ago

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.
    - kcsrk 7y ago
      I am not sure I understand the suggestion that preemptive scheduling is important with the explosion of CPU core count. You may need preemptive scheduling even on a single core if your application expects some fairness of scheduling guarantees. Am I missing something? We can do preemptive scheduling of user-level threads by registering a timer interrupt with the OS and preempting the currently running user-level thread in favor of another one. This is up to the individual libraries to implement. These issues are discussed in [1] Sec 4.3.
      - pdimitar 7y ago
        No, you're not missing anything -- I was just saying that it would be a shame if people still can't code preemptively scheduled parallel apps when the average home gaming machine is going to have 16 cores soon and that many devs (me included) are looking to buy a 32/64-core workstation. Nothing else. :) Really exciting that preemption is possible. Thanks for your insights!

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

by sadiq 7y ago

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

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.
  - kcsrk 7y ago
    I am not sure I understand the suggestion that preemptive scheduling is important with the explosion of CPU core count. You may need preemptive scheduling even on a single core if your application expects some fairness of scheduling guarantees. Am I missing something? We can do preemptive scheduling of user-level threads by registering a timer interrupt with the OS and preempting the currently running user-level thread in favor of another one. This is up to the individual libraries to implement. These issues are discussed in [1] Sec 4.3.
    - pdimitar 7y ago
      No, you're not missing anything -- I was just saying that it would be a shame if people still can't code preemptively scheduled parallel apps when the average home gaming machine is going to have 16 cores soon and that many devs (me included) are looking to buy a 32/64-core workstation. Nothing else. :) Really exciting that preemption is possible. Thanks for your insights!