6 ms·

Multicore OCaml: May 2020 update

71 points by rbjorklin 6y ago

sadiq 6y ago
With previous months, happy to answer any questions people might have.
inetsee 6y ago
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 6y ago
What is an example of a simple, serial ocaml program and how you would change it to use parallelism?
- vizzier 6y ago
  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.tasks.parallel.for?view=netcore-3.1 https://docs.microsoft.com/en-us/dotnet/api/system.threading...
jeffdavis 6y ago
Will this always be a compiler extension, or is intended to be an evolution of the language?
- dan-robertson 6y ago
  It’s not a compiler extension. It’s currently a fork of the compiler and patches are slowly being upstreamed.
  - jeffdavis 6y ago
    Should people write programs differently than before, or just use existing concurrency constructs and things will execute with better parallelism?
    - yawaramin 6y ago
      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.
waynesonfire 6y ago
wha's the end goal here?
- dan-robertson 6y ago
  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.
xedrac 6y ago
Assuming this works without major regressions, this is a fantastic step forward for OCaml, opening it up to use cases that require parallelism.
- sadiq 6y ago
  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.
smabie 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      > 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.

71 points by rbjorklin 6y ago

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

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 6y ago

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

vizzier 6y ago
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.tasks.parallel.for?view=netcore-3.1 https://docs.microsoft.com/en-us/dotnet/api/system.threading...

jeffdavis 6y ago

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

dan-robertson 6y ago
It’s not a compiler extension. It’s currently a fork of the compiler and patches are slowly being upstreamed.
- jeffdavis 6y ago
  Should people write programs differently than before, or just use existing concurrency constructs and things will execute with better parallelism?
  - yawaramin 6y ago
    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.

waynesonfire 6y ago

wha's the end goal here?

dan-robertson 6y ago
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.

xedrac 6y ago

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

sadiq 6y ago
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.

smabie 6y ago

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 6y ago
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 6y ago
  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 6y ago
    > 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.