Multicore OCaml: July 2021
discuss.ocaml.org
discuss.ocaml.org
What's the reason it's taking so long? Inherent difficulty in changing the language? Lack of resources? Lack of prioritization / urgency / industry support? (it's a rather niche language after all, apart from some prominent users like Jane Street)
There is plenty of Python code written where the authors didn't realise it was going to be CPU-critical or in hotpaths until it was too late. It's a small fraction of these cases where the authors have the fortune/opportunity to subsequently rewrite their code "via celery or the stdlib's multiprocess module" — sharing data in-memory is simply a lot easier than sharing across processes, and avoiding mutation of data structures is easier than writing serialisation code for them.
As an example, consider the straightforward implementation of a heap allocation in the single-core runtime: To allocate a small value (something that OCaml programs tend to do often), you just increment the pointer to the young generation (usually a 2MB buffer). Only when that fails, more complicated operations are triggered. Because it fails seldom and because the compiler can store the pointer in a register all the time, you don't pay very much for many allocations.
If you want to do that for multicore, you have one obvious problem to solve: How do different cores communicate values that live in this young buffer? Do they share the same buffer? Then you'd have to coordinate access, wasting time. Do they copy the values? When? Could we infer shaded values and allocate them specially? Do we need type-system support? Etc., Etc.
Languages that work on the JVM or .NET have it much simpler to answer these kind of questions because the answers have been built-in to the VM itself.
Edit: they're also working on an effect system at the same time, making everything fit into a 25 years old language that's really stable is not trivial.
I can't but admire the people who do this for OCaml