Greetings! I have indeed moved to IIT Madras as an Assistant Professor in Computer Science and Engineering. The demands of the new job meant that I could not contribute more actively to multicore. OTOH, I am building a nice team to hack on multicore at IITM along with the existing team spread across Cambridge and Paris.
Currently, our aim is to get the domains-only multicore (no effect handlers yet) upstreamed. PR#8713 is a step towards that. Our strategy is to carve out self-contained pieces of multicore runtime and upstream it to trunk in such a way that it is independently useful. No one likes to review thousands of lines of highly interconnected PR. However this has meant that there is more to do for the multicore developers to cleanly separate out the features from the multicore runtime to make it self-contained (and hence, more easily reviewable).
Here are some of the things we have been working on, which isn’t quite visible externally:
-
Event tracing: The aim of domains-only multicore is to make your programs go faster. If it doesn’t behave as you would expect, then we would like the developers to have tools to be able to debug it. Multicore has a great tracing framework aimed at performance debugging. There is an in-progress PR aimed at upstreaming this feature: https://github.com/ocaml/ocaml/pull/9082. You can see that this PR has been quite active. This work is being led by @Engil from Tarides, Paris.
-
Synchronized minor GCs: Designing performant GCs is a tricky business. Multicore OCaml uses a scheme where each domain can independently garbage collect its own minor heap without having to synchronize with other domains. While this is highly desirable, the downside is that reading object fields become a GC safe-point (a point where the runtime might potentially have to do a GC). This complicates the C API since every
Fieldaccess now has to be a safe point. Hence, we are exploring an alternative GC design that performs synchronized, parallel, minor GCs. This design should obviate the need to change the C API, but also is expected to have better behavior in programs that share small sized objects between domains frequently. This work is being lead by Tom Kelly and Sadiq Jaffer from OCaml Labs, Cambridge. Some of the open PRs in multicore repo is due to this. -
Mid-sized Benchmarks: In order to evaluate the performance of different GCs, and multicore in general, we’ve been adding new benchmarks to the sandmark benchmarking suite. We’re in the process of enhancing the sandmark suite to support the questions that we might want to ask about the multicore programs. See Sandmark repo for details: https://github.com/ocaml-bench/sandmark. This is led by my student Atul Dhiman at IITM.
-
Better Safepoints: We’re working on addressing issues with timely response to runtime interrupts: https://github.com/ocaml-multicore/ocaml-multicore/issues/187. A PR should be open upstream towards the end of Jan. This is led by Anmol Sahoo at IITM.
There are other developments RWO style chapter on multicore programming, fixing marshaling in trunk to be compatible with multicore, parallel version of Irmin, which are currently in development at IITM, for which I don’t have a link or a PR to show.
On the whole, while the developments may not be concentrated on the multicore repo, there is quite a good momentum building around the multicore ecosystem. I’m eager to see the domains-only multicore across the line in the coming months.