# Multicore OCaml: May 2021 **URL:** \ **Category:** Community\ **Tags:** multicore, multicore-monthly\ **Created:** [June 11, 2021, 8:01pm UTC](https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990 "2021-06-11T20:01:47Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![avsm](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/avsm/32/6_2.png) [@avsm](https://discuss.ocaml.org/u/avsm)\ **Post date:** [June 11, 2021, 8:01pm UTC](https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990/1 "2021-06-11T20:01:48Z")
Welcome to the May 2021 [Multicore OCaml](https://github.com/ocaml-multicore/ocaml-multicore) monthly report! This month’s update along with the [previous updates](https://discuss.ocaml.org/tag/multicore-monthly) have been compiled by @avsm, @ctk21, @kayceesrk and @shakthimaan. Firstly, all of our upstream activity on the OCaml compiler is now reported as part of the shiny new [compiler development newsletter #2](https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-2-may-2021/7965) that @gasche has started. This represents a small but important shift – domains-only multicore is firmly locked in on the upstream roadmap for OCaml 5.0 and the whole OCaml compiler team has been helping and contributing to it, with the [GC safe points](https://github.com/ocaml/ocaml/pull/10039) feature being one of the last major multicore-prerequisites (and due to be in OCaml 4.13 soon). This multicore newsletter will now focus on getting our ecosystem ready for domains-only multicore in OCaml 5.0, and on how the (not-yet-official) effect system and multicore IO stack is progressing. It’s a long one this month, so settle in with your favourite beverage and let’s begin 🙂 ## OCaml Multicore: 4.12.0+domains The multicore compiler now supports CTF runtime traces of its garbage collector and there are [tools to display chrome tracing visualisations](https://github.com/ocaml-multicore/eventlog-tools/tree/multicore_wip) of the garbage collector events. A number of performance improvements (see speedup graphs later on) that highlight some ways to make best use of multicore were made to the existing benchmarks in Sandmark. There has also been work on scaling up to 128 cores/domains for task-based parallelism in domainslib using [work stealing deques](https://github.com/ocaml-multicore/domainslib/pull/29), bringing us closer to Cilk-style task-parallel performance. As important as new features are what we have decided _not_ to do. We’ve been working on and evaluating Domain Local Allocation Buffers (DLABs) for some time, with the intention of reducing the cost of minor GCs. We’ve found that the resulting performance didn’t match our expectations (_vs_ the complexity of the change), and so we’ve decided not to proceed with this for OCaml 5.0. You can find the [DLAB summary](https://github.com/ocaml-multicore/ocaml-multicore/wiki/Domain-Local-Allocation-Buffers-Addendum) page summarises our experiences. We’ll come back to this post-OCaml 5.0 when there are fewer moving parts. ## Ecosystem changes to prepare for 5.0.0 domains-only As we are preparing 5.0 branches with the multicore branches over the coming months, we are stepping up preparations to ensure the OCaml ecosystem is ready. ### Making the multicore compilers available by default in opam-repo Over the next few week, we will be merging the multicore 4.12.0+domains and associated packages from their opam remote over in [ocaml-multicore/multicore-opam](https://github.com/ocaml-multicore/multicore-opam) into the mainline opam-repository. This is to make it more convenient to use the variant compilers to start testing your own packages with `Domain`s. As part of this change, there are two new base packages that will be available in opam-repository: - `base-domains`: This package indicates that the current compiler has the `Domain` module. - `base-effects`: This package indicates the current compiler has the experimental effect system. By adding a dependency on these packages, the only valid solutions will be `4.12.0+domains` (until OCaml 5.0 which will have this module) or `4.12.0+effects`. The goal of this is to let community packages more easily release versions of their code using Domains-only parallelism ahead of OCaml 5.0, so that we can start migration and thread-safety early. We do not encourage anyone to take a dependency on base-effects currently, as it is very much a moving target. This opam-repository change isn’t in yet, but I’ll comment on this post when it is merged. ### Adapting the Stdlib for thread-safety One of the first things we have to do before porting third-party libraries is to get the Stdlib ready for thread-safety. This isn’t quite as simple as it might appear at first glance: if we adopt the naïve approach of simply putting a mutex around every bit of global state, our sequential performance will slow down. Therefore we are performing a more fine-grained analysis and fixes, which can be seen [on the multicore stdlib page](https://github.com/ocaml-multicore/ocaml-multicore/wiki/Safety-of-Stdlib-under-Multicore-OCaml). For anyone wishing to contribute: hunt through the Stdlib for global state, and categorise it appropriately, and then create a test case exercising that module with multiple Domains running, and submit a PR to [ocaml-multicore](https://github.com/ocaml-multicore/ocaml-multicore). In general, if you see any build failures or runtime failures now, we’d really appreciate an issue being filed there too. You can see some good examples of such issues [here](https://github.com/ocaml-multicore/ocaml-multicore/issues/574) (for mirage-crypto) and [here](https://github.com/ocaml-multicore/ocaml-multicore/issues/568) (for Coqt). ### Porting third-party libraries to Domains As I mentioned last month, we put a call out for libraries and maintainers who wanted to port their code over. We’re starting with the following libraries and applications this month: - **Lwt** : the famous lightweight-threads library now has a PR to add [Lwt\_domains](https://github.com/ocsigen/lwt/pull/860). This is the first simple(ish) step to using multicore cores with Lwt: it lets you run a pure (non-Lwt) function in another Domain via `detach : ('a -> 'b) -> 'a -> 'b Lwt.t`. - **Mirage-Crypto** : the next library we are adapting is the cryptography library, since it is also low-hanging fruit that should be easy to parallelise (since crypto functions do not have much global state). The port is still ongoing, as there are some minor build failures and also Stdlib functions in Format that aren’t yet thread-safe that are [causing failures](https://github.com/ocaml-multicore/ocaml-multicore/issues/563). - **Tezos-Node** : the bigger application we are applying some of the previous dependencies too is Tezos-Node, which makes use of the dependency chain here via Lwt, mirage-crypto, Irmin, Cohttp and many other libraries. We’ve got this [compiling under 4.12.0+domains](https://gitlab.com/tezos/tezos/-/merge_requests/2671) now and mostly passing the test suite, but will only report significant results once the dependencies and Stdlib are passing. - **Owl** : OCaml’s favourite machine learning library works surprisingly well out-of-the-box with 4.12.0+domains. An experiment for a significant machine-learning codebase written using it saw about a 2-4x speedup before some false-sharing bottlenecks kicked in. This is pretty good going given that we made no changes to the codebase itself, but stay tuned for more improvements over the coming months as we analyse the bottleneck. This is hopefully a signal to all of you to start “having a go” with 4.12.0+domains on your own applications, and particularly with respect to seeing how wrapping it in Domains works out and identifying global state. You can read our handy [tutorial on parallel programming with Multicore OCaml](https://github.com/ocaml-multicore/parallel-programming-in-multicore-ocaml). We are developing some tools to help find global state, but we’re going to all need to work together to identify some of these cases and begin migration. Crucially, we need some diversity in our dependency chains – if you have interesting applications using (e.g.) Async or the vanilla `Thread` module and have some cycles to work with us, please get in touch with me or @kayceesrk . ## 4.12.0+effects The effects-based [eio library](https://github.com/ocaml-multicore/eio) is coming together nicely, and the interface and design rationales are all up-to-date in the README of the repository. The primary IO backend is [ocaml-uring](https://github.com/ocaml-multicore/ocaml-uring), which we are preparing for a separate release to opam-repository now as it also works fine on the sequential runtime for Linux (as long as you have a fairly recent kernel. Otherwise the kernel crashes). We also have a [Grand Central Dispatch effect backend](https://github.com/ocaml-multicore/eio/pull/26) to give us a totally different execution model to exercise our effect handler abstractions. While we won’t publish the performance numbers for the effect-based IO this month, you can get a sense of the sorts of tests we are running by looking at the [retro-httpaf-bench](https://github.com/ocaml-multicore/retro-httpaf-bench) repository, which now has various permutations of effects-based, uring-based and select-based webservers. We’ve submitted a talk to the upcoming OCaml Workshop later this summer, which, if accepted, will give you a deepdive into our effect-based IO. As always, we begin with the Multicore OCaml ongoing and completed tasks. The ecosystem improvements are then listed followed by the updates to the Sandmark benchmarking project. Finally, the upstream OCaml work is mentioned for your reference. For those of you that have read this far and can think of nothing more fun than hacking on multicore programming runtimes, we are hiring in the UK, France and India – please find the job postings at the end! ## Multicore OCaml ### Ongoing - [ocaml-multicore/ocaml-multicore#552](https://github.com/ocaml-multicore/ocaml-multicore/pull/552) Add a force\_instrumented\_runtime option to configure - [ocaml-multicore/ocaml-multicore#553](https://github.com/ocaml-multicore/ocaml-multicore/issues/553) Testsuite failures with flambda enabled - [ocaml-multicore/ocaml-multicore#555](https://github.com/ocaml-multicore/ocaml-multicore/pull/555) runtime: CAML\_TRACE\_VERSION is now set to a Multicore specific value - [ocaml-multicore/ocaml-multicore#558](https://github.com/ocaml-multicore/ocaml-multicore/pull/558) Refactor Domain.{spawn/join} to use no critical sections - [ocaml-multicore/ocaml-multicore#559](https://github.com/ocaml-multicore/ocaml-multicore/pull/559) Improve the Multicore GC Stats ### Completed - [ocaml-multicore/ocaml-multicore#508](https://github.com/ocaml-multicore/ocaml-multicore/pull/508) Domain Local Allocation Buffers - [ocaml-multicore/ocaml-multicore#527](https://github.com/ocaml-multicore/ocaml-multicore/pull/527) Port eventlog to CTF ![OCaml-Multicore-PR-527-Illustration](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/7/7984354f12695102e97bd6a37202ea8da9a6decf.jpeg) - [ocaml-multicore/ocaml-multicore#543](https://github.com/ocaml-multicore/ocaml-multicore/pull/543) Parallel version of weaklifetime test - [ocaml-multicore/ocaml-multicore#546](https://github.com/ocaml-multicore/ocaml-multicore/pull/546) Coverage of domain life-cycle in domain\_dls and ephetest\_par tests - [ocaml-multicore/ocaml-multicore$#550](https://github.com/ocaml-multicore/ocaml-multicore/pull/550) Lazy effects test - [ocaml-multicore/ocaml-multicore#557](https://github.com/ocaml-multicore/ocaml-multicore/pull/557) Remove unused domain functions ## Ecosystem ### Ongoing - [ocaml-multicore/eventlog-tools#2](https://github.com/ocaml-multicore/eventlog-tools/pull/2) Add a pausetimes tool - [domainslib#29](https://github.com/ocaml-multicore/domainslib/pull/29) Task stealing with CL deques - [ocaml-multicore/retro-httpaf-bench#10](https://github.com/ocaml-multicore/retro-httpaf-bench/pull/10) Add Eio benchmark - [ocaml-multicore/eio#26](https://github.com/ocaml-multicore/eio/pull/26) Grand Central Dispatch Backend - [ocsigen/lwt#860](https://github.com/ocsigen/lwt/pull/860) Lwt\_domain: An interfacet to Multicore parallelism ### Completed #### retro-httpaf-bench The `retro-httpaf-bench` repository contains scripts for running HTTP server benchmarks. - [ocaml-multicore/retro-httpaf-bench#6](https://github.com/ocaml-multicore/retro-httpaf-bench/pull/6) Move OCaml to 4.12 - [ocaml-multicore/retro-httpaf-bench#8](https://github.com/ocaml-multicore/retro-httpaf-bench/pull/8) Adds a Rust benchmark using hyper - [ocaml-multicore/retro-httpaf-bench#9](https://github.com/ocaml-multicore/retro-httpaf-bench/pull/9) Release builds for dune, stretch request volumes, rust fixes and remove mimalloc - [ocaml-multicore/retro-httpaf-bench#15](https://github.com/ocaml-multicore/retro-httpaf-bench/pull/5) Make benchmark more realistic #### eio The `eio` library provides an effects-based parallel IO stack for Multicore OCaml. - [ocaml-multicore/eio#18](https://github.com/ocaml-multicore/eio/pull/18) Add fibreslib library - [ocaml-multicore/eio#19](https://github.com/ocaml-multicore/eio/pull/19) Update to latest ocaml-uring - [ocaml-multicore/eio#20](https://github.com/ocaml-multicore/eio/pull/20) Add Fibreslib.Semaphore - [ocaml-multicore/eio#21](https://github.com/ocaml-multicore/eio/pull/21) Add high-level Eio API - [ocaml-multicore/eio#22](https://github.com/ocaml-multicore/eio/pull/22) Add switches for structured concurrency - [ocaml-multicore/eio#23](https://github.com/ocaml-multicore/eio/pull/23) Rename repository to eio - [ocaml-multicore/eio#24](https://github.com/ocaml-multicore/eio/pull/24) Rename lib\_eioio to lib\_eunix - [ocaml-multicore/eio#25](https://github.com/ocaml-multicore/eio/pull/25) Detect deadlocks - [ocaml-multicore/eio#27](https://github.com/ocaml-multicore/eio/pull/27) Convert expect tests to MDX - [ocaml-multicore/eio#28](https://github.com/ocaml-multicore/eio/pull/28) Use splice to copy if possible - [ocaml-multicore/eio#29](https://github.com/ocaml-multicore/eio/pull/29) Improve exception handling in switches - [ocaml-multicore/eio#30](https://github.com/ocaml-multicore/eio/pull/30) Add eio\_main library to select backend automatically - [ocaml-multicore/eio#31](https://github.com/ocaml-multicore/eio/pull/31) Add Eio.Flow API - [ocaml-multicore/eio#32](https://github.com/ocaml-multicore/eio/pull/32) Initial support for networks - [ocaml-multicore/eio#33](https://github.com/ocaml-multicore/eio/pull/33) Add some design rationale notes to the README - [ocaml-multicore/eio#34](https://github.com/ocaml-multicore/eio/pull/34) Add shutdown, allow closing listening sockets, add cstruct\_source - [ocaml-multicore/eio#35](https://github.com/ocaml-multicore/eio/pull/35) Add Switch.on\_release to auto-close FDs #### Sundries - [ocaml-multicore/domainslib#23](https://github.com/ocaml-multicore/domainslib/issues/23) Running tests: moving to `dune runtest` from manual commands in `run_test` target - [ocaml-multicore/domainslib#24](https://github.com/ocaml-multicore/domainslib/pull/24) Move to Mutex & Condition from Domain.Sync.{notify/wait} ![Domainslib-PR-24](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/c/c3525f387ece415069bbac1f76525cf2ca96ef1d.png) - [ocaml-multicore/multicore-opam#53](https://github.com/ocaml-multicore/multicore-opam/pull/53) Add base-domains and base-effects packages - [ocaml-multicore/multicore-opam#54](https://github.com/ocaml-multicore/multicore-opam/pull/54) Shift all multicore packages to unique versions and base-domains dependencies ## Benchmarking ### Ongoing - [ocaml-bench/sandmark#230](https://github.com/ocaml-bench/sandmark/pull/230) Build for 4.13.0+trunk with dune.2.8.1 ### Completed #### Sandmark ##### Performance - [ocaml-bench/sandmark#221](https://github.com/ocaml-bench/sandmark/pull/221) Fix up decompress iterations of work ![PR-221-Time](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/4/49a4b0b3f2e8e7c89e23c91c5f5307cdaa160d5c.png) ![PR-221-Speedup](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/4/49bfcda236b0a900565c73b37867a7d35565b266.png) - [ocaml-bench/sandmark#223](https://github.com/ocaml-bench/sandmark/pull/223) A better floyd warshall ![Sandmark-PR-223-Time](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/4/4a89577052976a094a4813b194aca1ebfb316a73.png) ![Sandmark-PR-223-Speedup](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/b/be902a7ddc891b318c42a0e625b3335fbfeba1d0.png) ![Sandmark-PR-223-Minor-Collections](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/c/cbc5f44ea2b594b7d644a1ced93407e545c0bdb1.png) - [ocaml-bench/sandmark#224](https://github.com/ocaml-bench/sandmark/pull/224) Some improvements for matrix multiplication ![Sandmark-PR-224-Time](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/a/ac194a6ecd26bdb6d9e602378ed4b44eb1f67d8e.png) ![Sandmark-PR-224-Speedup](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/4/4ecdd0c82cd59f50fffd9078cd85b5bbcf740e09.png) - [ocaml-bench/sandmark#225](https://github.com/ocaml-bench/sandmark/pull/225) Better Multicore EA Benchmark ![Sandmark-PR-225-Time](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/6/613a8f51682c02da672d12232bd8b244c65ba6d7.png) ![Sandmark-PR-225-Speedup](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/b/b135d1269f57af9df575ab51ef7c31583713b42c.png) - [ocaml-bench/sandmark#226](https://github.com/ocaml-bench/sandmark/pull/226) Better scaling for mandelbrot6\_multicore ![Sandmark-PR-226-Time](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/3/3ae484f3942252583abc4d44cebc0051adec2b32.png) ![Sandmark-PR-226-Speedup](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/b/b7dbb656928988548ae9668c0d1edfe5186479b2.png) ![Sandmark-PR-226-Minor-Collections](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/2/241f9360e8b3fee78b6f5d95ed40f7dcff24f813.png) - [ocaml-bench/sandmark#227](https://github.com/ocaml-bench/sandmark/pull/227) Improve nbody\_multicore benchmark with high core counts ![Sandmark-PR-227-Time](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/d/d5bb284534e0f32e24c7d8937afa4cac022ef79c.png) ![Sandmark-PR-227-Speedup](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/b/be718f3e5cc676f44c827dfa56bdfa01e376e447.png) - [ocaml-bench/sandmark#229](https://github.com/ocaml-bench/sandmark/pull/229) Improve game\_of\_life benchmarks ![Sandmark-PR-229-Time](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/5/50c1b7e799a4c71ee4585409d1eba575bf0748ed.png) ![Sandmark-PR-229-Speedup](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/e/eb7b75ddaa314fa80908f12758f974223eb70490.png) ##### Sundries - [ocaml-bench/sandmark#215](https://github.com/ocaml-bench/sandmark/pull/215) Remove Gc.promote\_to from treiber\_stack.ml - [ocaml-bench/sandmark#216](https://github.com/ocaml-bench/sandmark/pull/216) Add configs for 4.12.0+stock, 4.12.0+domains, 4.12.0+domains+effects - [ocaml-bench/sandmark#220](https://github.com/ocaml-bench/sandmark/pull/220) Attempt to improve the OCAMLRUNPARAM documentation - [ocaml-bench/sandmark#222](https://github.com/ocaml-bench/sandmark/pull/222) Deprecate 4.06.1 and 4.10.0 and upgrade to 4.12.0 #### current-bench - [ocurrent/current-bench#103](https://github.com/ocurrent/current-bench/issues/103) Ability to set scale on UI to start at 0 - [ocurrent/current-bench#121](https://github.com/ocurrent/current-bench/pull/121) Use string representation for docker cpu setting. ## OCaml ### Ongoing - [ocaml/ocaml#10039](https://github.com/ocaml/ocaml/pull/10039) Safepoints ## Job Advertisements - [Multicore OCaml Runtime Systems Engineer](https://discuss.ocaml.org/t/runtime-systems-engineer-ocaml-labs-uk-tarides-fr-segfault-systems-in-remote/7959) OCaml Labs (UK), Tarides (France) and Segfault Systems (India) - [Benchmark Tooling Engineer](https://tarides.com/jobs/benchmark-tooling-engineer) Tarides Our thanks to all the OCaml users, developers and contributors in the community for their continued support to the project. Stay safe! ## Acronyms - AMD: Advanced Micro Devices - API: Application Programming Interface - CI: Continuous Integration - CPU: Central Processing Unit - CTF: Common Trace Format - DLAB: Domain Local Allocation Buffer - EA: Evolutionary Algorithm - GC: Garbage Collector - GCD: Grand Central Dispatch - HTTP: Hypertext Transfer Protocol - OPAM: OCaml Package Manager - MVP: Minimal Viable Product - PR: Pull Request - TPS: Transactions Per Second - UI: User Interface ---
**Author:** ![gasche](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/gasche/32/4_2.png) [@gasche](https://discuss.ocaml.org/u/gasche)\ **Post date:** [June 12, 2021, 6:33am UTC](https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990/2 "2021-06-12T06:33:51Z")
There is a lot of interesting action here. The work-stealing support in `DomainsLib.Task` is impressive, congratulations @ctk21. It’s also nice that you decided to update the benchmarks to follow evolving best performance practices, as it makes them interesting examples to look at. I haven’t had time to look at [eio](https://github.com/ocaml-multicore/eio) at all, also looks quite interesting! ---
**Author:** ![XVilka](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/xvilka/32/5334_2.png) [@XVilka](https://discuss.ocaml.org/u/XVilka)\ **Post date:** [July 12, 2021, 5:52am UTC](https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990/3 "2021-07-12T05:52:07Z")
Just a small heads up for anyone who is subscribed to the thread - the safepoints PR was finally merged, yay! - [Safepoints (#10039) · ocaml/ocaml@758fc7d · GitHub](https://github.com/ocaml/ocaml/commit/758fc7ddd609fd51ff811db2af5393672b2ef37c) - [Changes entry and comments for Safepoints (#10039) · ocaml/ocaml@1b3ffee · GitHub](https://github.com/ocaml/ocaml/commit/1b3ffee3f195f5feac10c0141f9b1842f7260455) ---
**Author:** ![UnixJunkie](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/unixjunkie/32/638_2.png) [@UnixJunkie](https://discuss.ocaml.org/u/UnixJunkie)\ **Post date:** [July 12, 2021, 8:25am UTC](https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990/4 "2021-07-12T08:25:43Z")
I am interested in maintaining a git branch of parany that would use OCaml multicore instead of forked processes (the current backend): > **[UnixJunkie/parany](https://github.com/UnixJunkie/parany)** > > Parallelize \_anything\_ //. Contribute to UnixJunkie/parany development by creating an account on GitHub. I don’t know when this will happen, but I prefer changing this library rather than porting all my parallel software (I have quite a few) to multicore-OCaml.