sadiq

Multicore is almost entirely backwards compatible with stock OCaml.

One issue is C libraries that use so-called naked pointers but these are discouraged anyway and 4.12 ships a detector to find these: https://discuss.ocaml.org/t/ann-a-dynamic-checker-for-detect...

There are also two functions on the Obj module which aren't supported because they're unsafe to do concurrently. These are clearly marked as "not for the casual user" so their use is relatively rare.

With regards to performance, you can find a fairly detailed analysis in our ICFP 20 paper: https://arxiv.org/abs/2004.11663 In short, the impact is 3-4% across those benchmarks.

You can grab the current multicore compiler on https://github.com/ocaml-multicore/ocaml-multicore and give it a spin to see, today.

Was this the paper? https://www.repository.cam.ac.uk/bitstream/handle/1810/28323...

Effects that 'interrupt' a fiber are asynchronous effects. They can be used to implement schedulers and the like. We don't currently support them in Multicore, there's still a few open research questions as to how to reconile them with the effect system.

I'm not aware of large standalone projects that depend solely on it. Multicore is backwards compatible with stock OCaml though and 4.12 ships with some stub Atomics (https://github.com/ocaml/ocaml/blob/4.12/stdlib/atomic.mli) which makes writing programs that can work on both easier.

We also maintain some projects on top of Multicore that are pretty interesting:

* Domainslib - channels and task queue that makes using parallelism via Domains much easier: https://github.com/ocaml-multicore/domainslib

* eioio - very much a work in progress but enables high performance direct-style IO with fibers and effects. Backs on to io_uring on Linux and is designed to also work with IOCP on Windows: https://github.com/ocaml-multicore/eioio

It's pretty close. There have been PRs landing to close the gap with Multicore for a couple of releases now.

You should see an OCaml 5.0 branch (which brings parallelism via Domains) in the next couple of months. The time between that branching and release depends a lot on how the review process for the Multicore patches go though.

As usual, happy to answer any questions.

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

You can also see KC's talk on the paper here: 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_ZowsIO...

Microsoft have been using them in Bing and other projects for a while: https://www.microsoft.com/en-us/research/project/project-cat...

That's the Chrome tracing tool: https://www.chromium.org/developers/how-tos/trace-event-prof...

It uses the event logging infrastructure in multicore which outputs json.

Normal OCaml has integrated this since 4.11: https://ocaml.org/releases/4.11/htmlman/instrumented-runtime... but switches to the Common Tracing Format (CTF) so you'll need an extra step to convert it to a format Chrome tracing can ingest.

Just to add to this good summary, OCaml already has some support for parallelism that would be useful for scientific computation.

Essentially you can already have multi-threaded OCaml programs as long as only one thread is using the OCaml runtime at any point in time. For numerical code where you might be spending the vast majority of your time in external libraries this ends up not being a major problem. It's not a dissimilar story for where Python is.

What Multicore OCaml adds is the ability to run multiple threads of OCaml code at the same time (we call them Domains, to avoid confusing them with existing Threads - which can coexist).

There's an entry on the Multicore wiki that gives some more depth: https://github.com/ocaml-multicore/ocaml-multicore/wiki/Conc...

In terms of the project you can also follow progress in the Multicore Monthlies: https://discuss.ocaml.org/tag/multicore-monthly as well as see the in-progress and merged multicore PRs that are hitting upstream ocaml: https://github.com/ocaml/ocaml/pulls?q=is%3Apr+label%3Amulti...

If you want to know more about how the multicore runtime works the recent ICFP2020 paper has a lot of detail: https://arxiv.org/abs/2004.11663 and KC's presentation is worth a watch: https://www.youtube.com/watch?v=ASX79I0jm6M&feature=youtu.be...

The plans, and implementation effort, are focused on getting ParMinor upstreamed so I suspect ConcMinor will stay at version 4.06.

I think we were all surprised by how well ParMinor performed. There's work on-going to see just how far ParMinor can scale and there's also a few tricks we might be able to do to make it scale even better.

Domain is a unit of parallelism in Multicore OCaml - it's effectively a heavyweight thread. The intention is that you tend to have as many Domains as you have cores you want to use in the computation.

Deferred relates to concurrency rather than parallelism, that you can have multiple overlapping computations. You can have concurrency without parallelism. OCaml has ways you can have parallel computations going on that don't hold the interpreter lock and I think some of the concurrent libraries can utilise this.

Multicore OCaml splits parallelism and concurrency, the former is via Domains and the latter is with Fibers. The paper I linked in my other comment on this thread touches on this a little but kc also has a short write-up of how you can use effects to write a scheduler for multicore's fibers: https://kcsrk.info/ocaml/multicore/2015/05/20/effects-multic...

(Multicore OCaml hacker here - speaking for myself though)

Nice to see people having a look at this. It's an early draft chapter that Sudha, one of the Multicore team, has been working on.

If you have feedback or suggestions I'm sure she'd welcome it on the draft's PR: https://github.com/prismlab/parallel-programming-in-multicor...

If you're new to Multicore OCaml the repo is at https://github.com/ocaml-multicore/ocaml-multicore . It has installation instructions near the bottom (easiest way is via OPAM).

The latest June update of our progress is available at https://discuss.ocaml.org/t/multicore-ocaml-june-2020/6047

For a technical deep dive on how Multicore OCaml works our recent ICFP paper has a lot of detail: https://arxiv.org/abs/2004.11663

We have a preprint up of our paper that details the design of Multicore OCaml along with a range of performance comparisons: https://arxiv.org/abs/2004.11663

In terms of performance it varies. The benchmarks in that paper it ranges from a 20% slowdown to a 20% speedup - most macro benchmarks are <10%. There's also still some more performance work we can do to chip away at that further.

With previous months, happy to answer any questions people might have.

As with previous months, happy to answer any questions people might have.

(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 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.

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

Both current multicore GCs do exactly that to keep allocation cheap but there are different design choices within the constraints we could have gone with.

To avoid frequent synchronisation we could have gone with a (potentially generational) non-moving collector for the minor GC which would still have preserved the C API, probably allowed for very low pauses but would have made allocation more expensive.

Yes, it's very easy to make pause times low if you're willing to make allocation expensive - it's all trade-offs.

In multicore's case it's about keeping low pause times while also keeping allocation cheap _and_ maintaining throughput.

Disclaimer: I don't speak for OCaml or OCaml Labs but I am a contributor to multicore.

It is indeed that it is hard to retrofit parallelism on to an existing language while trying to retain backwards compatibility _and_ performance.

Backwards compatibility is tricky because there's lots of C code using the C API.

Performance is hard because OCaml users are used to well performing code, with low and predictable pause times from the GC (<10ms).

The community is small and it seems like there wasn't appetite for maintaining two distinct runtimes with very different performance characteristics.

The current implementation for multicore GC (https://github.com/ocaml-multicore/ocaml-multicore) is reasonably close to upstream in performance on single threaded code and yet will scale up to multiple threads. It requires a change to the C API though.

There's a modified multicore GC (https://github.com/ctk21/ocaml-multicore/tree/stw_minor_gc) that doesn't require the C API change and we're currently writing up a paper that contrasts the two wit a fairly substantial amount of benchmarking (https://github.com/ocamllabs/sandmark).

Happy to answer any questions.

There's an update to for January: http://discuss.ocaml.org/t/multicore-ocaml-january-2020-upda...

Behind the scenes there's a lot of work happening. Retrofitting parallelism to an existing runtime while maintaining compatibility with existing code and keeping the kind of performance users are used to is difficult.

There will be a lot more information out in the next month or two about how it all works, which should coincide with getting more of it upstream.

I don't speak for OCaml or OCaml Labs but am a contributor to multicore if people have specific questions, I can try to answer them.

That's an interesting paper. For anyone on mobile who wants a PDF: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.11...

4.09 (which has just been released) includes a number of changes that are being introduced soley to ease the merging of multicore.

4.10 will also include a recently merged, large change for multicore support: https://github.com/ocaml/ocaml/pull/8713

The plan is to land multicore in trunk through a series of smaller chunks such as #8713

We do exactly this!

Our startup Opsian (https://www.opsian.com) is a very low overhead continuous profiling service for the JVM.

Our JVM agent sends profiling data from your instances to our cloud environment where it's indexed, aggregated and made available for hotspots/tree/flamegraph reports.

We even have a dedicated report telling you where regressions happen between releases.

(We're actually out at Devoxx 2018 right now doing a talk on why everyone should be doing continuous profiling)

JDK 8u131 and 9 had a few improvements but the changes to 10 increase support.

For example, 8u131 and 9 only supported cpu sets whereas 10 includes support for cpu shares. Available memory detection in 10 applies to the whole of the JVM rather than just the heap on 8u131 and 9.

Something not mentioned amongst the JEPs on the release email is that this release also fixes a bunch of issues related to running the JVM in a container. I wrote about some of these yesterday:

https://www.opsian.com/blog/java-on-docker/

Relevant JEPs:

https://bugs.openjdk.java.net/browse/JDK-8146115

https://bugs.openjdk.java.net/browse/JDK-8179498

https://bugs.openjdk.java.net/browse/JDK-8146115

Are there any performance results for single threaded versus parallel for full GCs? Is the increase linear in the number of cores?

Worth pointing out an approach that Julia took, compiling LLVM to C might also work for Rust:

https://juliacomputing.com/blog/2016/03/10/j2c-announcement....

There's more of us about.