1. 19
  1.  

  2. 3

    Multicore in OCaml sure seems like a big effort. Does anyone have insight into how much of that effort stems from trying to work a feature like this into an old and mature codebase, versus the way that they have chosen to do it? From looking at the roadmap in this post it seems like a lot of former: plenty of code (both internals, and in libraries) has been written with assumptions that are no longer valid in a multicore world, and this needs to be addressed carefully, and incrementally.

    1. 9

      Much of the effort springs from a desire to end up with the language we really want for the next few decades. OCaml has had a really good execution model for single-core performance since its inception over 20 years ago (fast exceptions, pretty good GC, cheap FFI, very decent representation for symbolic processing).

      With multicore, we have a rare opportunity: unlike many other languages which must maintain full backwards compatibility, we can evolve the OCaml language to make it more suitable for multicore parallelism. As we’ve gone through the GC design process, several language edge cases (for example, finalisers or ephemerons) have had their performance expectations altered or simpler alternatives proposed and integrated into OCaml. Another big realisation we had during development was that the OCaml memory model could be dramatically safer in the presence of data races than C++ or Java’s, with a minimal performance hit for single core performance (details in the paper).

      All of this has taken time (and we are deeply grateful to Jane Street funding this effort across over five years!). On the other hand, it is getting us really excited about having not “just an OCaml with parallelism bolted on”, but one whose parallel programming model and runtime captures the essence of the single core ML that we know and love – safety by default, predictability by inspecting code, well-defined semantics, and a lightweight execution model. And in the background, of course, is the requirement to minimally affect the existing single-core users of OCaml, who are myriad and growing in their codebases.

      Thus, we decided to take a measured approach to the design, publishing papers when appropriate for an aspect of it, benchmarking very precisely, and incrementally upstreaming patches that the existing userbase can test while not affecting their current use of the language. It’s been a lot of work, but also continues to a lot of fun!

      1. 2

        Avoiding the “just an OCaml with parallelism bolted on” trap sounds compelling. You can already right now bolt parallelism onto any old PL by splitting your programs across multiple processes. So to be really valuable, the implementation wants to be much more attractive than that.

        👍

        1. 1

          Thanks for the detailed reply!

          1. 1

            Great answer! If I could pry a touch further: How much of this is tied up with effects?

            1. 1

              Leo White at Jane Street is (in parallel to our work, pun intended) leading the efforts to design the effect system. We’ll most likely expose a low-level set of primitives from our multicore patches, which the typed effect system can subsequently integrate into the frontend language. Leo’s work is best summarised in this talk.