
Multicore OCaml: May 2020 update - rbjorklin
https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/5898
======
inetsee
For those of us (like me) who have never heard of MultiCore Ocaml before, here
is the github page with a brief overview. [https://github.com/ocaml-
multicore/ocaml-multicore](https://github.com/ocaml-multicore/ocaml-multicore)

------
jeffdavis
Will this always be a compiler extension, or is intended to be an evolution of
the language?

~~~
dan-robertson
It’s not a compiler extension. It’s currently a fork of the compiler and
patches are slowly being upstreamed.

~~~
jeffdavis
Should people write programs differently than before, or just use existing
concurrency constructs and things will execute with better parallelism?

~~~
yawaramin
There will be some new differences. Multicore is bringing in some new
concepts–e.g. domains (an abstraction for system threads). Perhaps down the
road the existing concurrent programming libraries like Lwt will abstract all
that away and preserve their existing interfaces. Remains to be seen.

------
xedrac
Assuming this works without major regressions, this is a fantastic step
forward for OCaml, opening it up to use cases that require parallelism.

~~~
sadiq
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](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.

------
jeffdavis
What is an example of a simple, serial ocaml program and how you would change
it to use parallelism?

~~~
vizzier
This always depends on context if parallelizing anything actually helps with
performance but my most common usage of F# (essentially Ocaml on .net)
parallel features are using the .net parallel library[1]. Easy way to
introduce parallelized loops into your processing if what you're doing is
heavy enough to warrant them. In my particular usage this was used for data
transformations that were heavy enough to warrant the parallelization
overhead.

[1] [https://docs.microsoft.com/en-
us/dotnet/api/system.threading...](https://docs.microsoft.com/en-
us/dotnet/api/system.threading.tasks.parallel.for?view=netcore-3.1)

------
smabie
Now we just need modular implicits and OCaml would be _the_ ideal language for
non-ML projects. Without them, OCaml is a little crusty.

~~~
bjoli
Now, my understanding of ocaml is rather rusty, but shouldn't modular
implicits be pretty straight forward to implement? Do you know of any good
reason why it hasn't been implemented other than inertia? I don't remember
missing them other than for generic arithmetic. What would be your use case?

~~~
smabie
Typeclasses. With typeclasses, we could get a collections api, monads, etc.
Basically everything that Haskell has, except without the academic purity
obsessed bullshit.

Right now, OCaml is very... concrete. You have to call different functions to
find the length of a string, a list, or an array. Modular implicits would get
rid of all that bullshit. We could do more type-level programming, instead of
the "earth-bound" kind of stuff we do now. Here's a 2014 paper on it:
[http://www.lpw25.net/papers/ml2014.pdf](http://www.lpw25.net/papers/ml2014.pdf)

The only problem is that, well, it's from 2014. OCaml moves unbearably slow
compared to any other language (except maybe Python). It seems like there's a
lack of knowledgeable contributors, which is a shame. But maybe if OCaml was
rewritten from scratch using LLVM IR, more progress could be made. But I don't
really know, I'm not an OCaml internals expert.

~~~
brmgb
> Typeclasses

Modular implicits are not typeclasses.

> With typeclasses, we could get a collections api, monads, etc.

OCaml already has that through parameterized modules modules and inclusion.
Modular implicits would not fundamentally change that. It would make calling a
bit less cumbersome (but with local opening, it's already not that bad).

Sadly, implementing modular implicits properly is a tremendous undertaking.

> OCaml moves unbearably slow compared to any other language (except maybe
> Python).

I personally find Ocaml to move quite fast. Actually I think it has never been
that fast. There is a release every six months and the last few releases have
seen significant improvements on every fronts: performance (flambda), the
standard library (notably with regard to collections) and syntax (let+ and
let*).

> But maybe if OCaml was rewritten from scratch using LLVM IR, more progress
> could be made.

One of the most enjoyable part of writting Ocaml is how fast and efficient the
compiler is. I personnaly fail to see what porting it to LLVM IR would bring
(apart from more compilation targets). I mean, no one would complain if
someone did the port but that seems like a lot of work for meagre returns.

~~~
smabie
Of course modular implicits aren't typeclasses, but they would allow
functionality very similar to typeclasses: function polymorphism.

Maybe we have a different idea of cumbersome, but I find that having to
explicitly find the right >>= or >> to be cumbersome, and it feels bad. Having
to implicitly pass modules around or using local open is simply inelegant.

I've found that there's a surprisingly large number of OCaml users who defend
the status quo no matter what. OCaml seems to be perfect for them, even though
everyone else can see its flaws. I've introduced OCaml to quite a few
Haskellers, and _all_ of them have been shocked to learn about the lack of
flexibility OCaml provides. OCaml doesn't get anywhere close to providing the
kind of "type-level" programming that Scala and Haskell do.

Most of the interesting kind of programming you can do in Haskell is simply
not possible with OCaml. While OCaml will never be Haskell and probably
shouldn't, modular implicits would go a long way in helping.

Here's a concrete example: ppx_let. ppx_let is a very nice library and makes
monadic code a lot nicer. It's fantastic, even if you have to find the right
Let_syntax module. I use core, so it's relatively easy to just import the
correct one. The problem is when you're using other libraries. For example,
angstrom (a parser combinator library) doesn't have a Let_syntax module. So I
either have create my own or not use ppx_let with it. Modular implicits could
solve this problem.

Another problem is that very few OCaml users are actually using stdlib bundled
with OCaml. Personally, I think stdlib should be ditched and replaced with
Core_kernel, but this is never going to happen. It's too late to make updates
to the collections library, the biggest industrial user, Jane Street, is never
going to use them.

About the LLVM IR, it's not what LLVM IR would bring exactly. It's that time
and time again, the reason for why so and so is taking so long is that there
aren't enough compiler experts. Not enough performance experts for multicore,
not enough type experts for modular implicits, etc etc. I am ignorant on OCaml
internals, but why are there so few people who can contribute? New masters
students who've never touched the Scala compiler, for example, make pretty
significant changes all the time. I suspect there is something about how the
compiler is written that makes it very hard to understand.

Perhaps if OCaml used LLVM IR, it would simplify things. LLVM can do some
pretty impressive optimizations on IR, has a JIT, includes a number of
backends, etc etc. There's a reason why almost all new languages use it:
because it's easy. Hell, you could create a compiler for a very simple
imperative dynamic language (like Python, say) in a weekend that would have
pretty impressive performance.

Look, I love OCaml. I like that it produces native executables, I like the
practicality, I like the clean syntax, etc. But the language has some _major_
problems: fractured ecosystem, weak type system, strange module system, etc.
OCaml does things differently than other languages, and that's fine. But being
different has a price, and sometimes, it actually has no benefit. I understand
the core language will not change, but I think things modular implicits could
be a game-changer in terms of usability. OCaml wouldn't look so weird anymore.
Maybe it could even be used for scientific computing.

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

------
waynesonfire
wha's the end goal here?

~~~
dan-robertson
Currently the ocaml runtime has a global lock on running ocaml. Like python
you may have multiple OS threads but only one may have this lock at a time.
Non-ocaml code may release this lock while e.g. doing blocking IO.

The goal is to remove this lock in a way that is safe and allows programs to
continue being fast.

