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.
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.
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.
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.
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?
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
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.
> 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.
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.
17 comments
[ 5.2 ms ] story [ 52.5 ms ] thread[1] https://docs.microsoft.com/en-us/dotnet/api/system.threading...
The goal is to remove this lock in a way that is safe and allows programs to continue being fast.
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.
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
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.
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.
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.