4 ms·

Happy to answer any questions.

by sadiq 5y ago

NanoCoaster 5y ago
I'm sorry if these are dumb questions, I'd be totally fine with some pointers in the right directions if you don't want to waste your time :) I'm under the impression that the implementation is based on algebraic effects. Does that include extending the language in a way that lets users define their own effects & handlers? Also, how's the performance? Last time I looked this stuff up (and played around with Eff), which was quite a while ago, I was told that regular usage of effects may impact performance quite noticeably.
- sadiq 5y ago
  Not dumb questions at all. Multicore adds parallelism via Domains (which are essentially heavyweight threads) and concurrency via Effects and fibers. There's a multicore GC that supports both of those. We plan to upstream things in two parts. First domains-only parallelism and then effects as a follow-up. When the latter lands users will be able to define their own effects and handlers, yes. Performance is pretty good, you can see our PLDI2021 paper for a proper performance evaluation and loads more details: https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250
  - NanoCoaster 5y ago
    Thank you, interesting stuff. Very much looking forward to user-definable effects! I like Ocaml in principal, but haven't yet strayed beyond learning the very basics some time ago. Seeing a usable implementation of algebraic effects in a somewhat popular language...that I gotta see :)
    - sadiq 5y ago
      Worth pointing out you don't just need to stop at seeing it, you can get started playing around with it today: https://github.com/ocaml-multicore/multicore-opam#install-multicore-ocaml https://github.com/ocaml-multicore/multicore-opam#install-mu...
      - NanoCoaster 5y ago
        Cool, thanks for the link. Will definitely play around with it as soon as I find the time. Too many programming languages, too little free time, sadly.
mirekrusin 5y ago
Is it currently possible to play with multicore ocaml on M1?
- mseri 5y ago
  I think not yet: https://github.com/ocaml-multicore/ocaml-multicore/issues/86#issuecomment-822000783 https://github.com/ocaml-multicore/ocaml-multicore/issues/86... Fwiw, OCaml itself can be compiled natively on M1.
  - sadiq 5y ago
    Yes, arm64 support is non-functional but we're planning to get it back in to a working state very soon.
wuschel 5y ago
Hello sadiq, I have some more general questions for you: As understand that currently, the situation is analogous to Python. The GIL allows for process based concurrency, with the well known disadvantage regarding memory consumption. Also, my guess is that OCaml relies library based solutions at the moment? 1) What does the introduction of MultiCore potential mean for Ocaml? Will Ocaml be a much better fit to run a webserver backend? Could you perhaps give a comparison to other programming languages? 2) How will Ocaml stand out with Multicore in the PL world, and what solutions would be it uniquely suited for? 3) What tools are going to be present to deal with bugs introduced by your new runtime e.g. race conditions? 4) If one wants to have a go at Multicore and play around with it, where/how do I start? Many thanks!
- sadiq 5y ago
  Good questions! 1) As I mentioned in https://news.ycombinator.com/item?id=27142502 https://news.ycombinator.com/item?id=27142502 there is support for parallelism and concurrency. Giving an example of where these might be useful in a webservice. The addition of shared-memory parallelism is beneficial where you might have a great deal of shared state that needs to be used to service requests. An in-memory cache is a good example - with a processed-based approach managing read/writes and avoiding significant overhead from marshalling the data is difficult. Concurrency via effects at a minimum can make writing network-based services much more pleasant (and debuggable!). See the examples in https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 where programs can be written in a direct-style similar to blocking IO but using effects are transformed to use asynchronous interfaces. There's work going on in the project at the moment to build fast cross-platform IO implementations that sit atop of uring/gcd/iocp. 3) This is a good question and one we're still working on. I think one of the lead developers KC has a few good ideas about instrumentation we can do to enable detecting races to global state. It's certainly going to be an issue for people porting large codebases. 4) This is the place to start: https://github.com/ocaml-multicore/multicore-opam#install-multicore-ocaml https://github.com/ocaml-multicore/multicore-opam#install-mu... .
  - wuschel 5y ago
    Thank you for the your answer! I will check out the URIs.
intc 5y ago
Could you explain (in simple terms if possible) how the Multicore OCaml achieves a memory model which is much simpler on more efficient than in Java or C (mentioned at https://github.com/ocaml-multicore/ocaml-multicore/wiki https://github.com/ocaml-multicore/ocaml-multicore/wiki)? Didn't see any mentions of critical sections (mutexes) with C++ examples in the documentation ("Bounding Data Races in Space and Time"). I'm not sure I understand the comparisons the writers are presenting.
- jlouis 5y ago
  The key problem is program transformation, and in particular optimizations. Different CPUs/ISAs, and compilers, might want to transform your program to make it run faster. However, in the multi-core setting, data races pose bounds and limits on how much you can trigger those optimizations. The program doesn't generally execute sequentially in a way that can be entirely reasoned about. Instructions might be reordered for the sake of the program to run faster. Programmers can't work with that. So one proposes a memory model. Follow these rules, and our optimizations won't alter the behavior of the program. They kind-of describes what happens "in between" the critical sections of the program, hence the lack of a mutex mention. The paper presents a local property and then shows, formally, that this property is enough to guarantee an efficient memory model. That is, a model in which you can perform optimizations, while programmers can still reason about the programs behavior. The crux of the paper is that the property is local. This is new, because memory models which came before it are global: to reason about correctness, you have to consider the whole program, rather than consider a small (local) subset. OCaml requires more safety than most programming languages, so this is good for the fact that you can now compose local fragments of OCaml programs, without having to worry about a global safety property. The property is also simpler for programmers to reason about. The way you "use" the paper is that you adapt your optimizations to follow the property, and you make sure that the virtual memory model is implemented the same way on different architectures. Finally, the examples: they explore the idea of a local reasoning. In particular, they show why the (existing) global properties fail if you view them under the stronger requirement of local reasoning. It's the setup for the paper, since it means you can't just use the existing models. They need to be adapted if you want a more localized property.
- 5y ago
hajile 5y ago
StandardML implementations have had good multicore support for decades now despite having only a tiny fraction of the users and development time. Meanwhile, Ocaml has been promising support for years. What in Ocaml makes this so much harder to implement?
- rwmj 5y ago
  OCaml (or its immediate predecessor[1]) had a multicore implementation, but it was dropped because of its complexity and effect on single-thread performance. The challenge is to add it back in a way that is maintainable and doesn't negatively affect current users. [1] https://www.researchgate.net/publication/2774662_Concurrent_generational_garbage_collector_for_a_multithreaded_implementation_of_ML https://www.researchgate.net/publication/2774662_Concurrent_...
- sadiq 5y ago
  As the sibling comment mentions, the hard part is actually retrofitting multicore whilst maintaining compatibility _and_ performance. Our paper last year covers most of why this is tricky: https://arxiv.org/abs/2004.11663 https://arxiv.org/abs/2004.11663
4ad 5y ago
Algebraic effects as described in the OCaml papers about effects are dynamically typed. I recently heard in some talk that this idea was abandoned, and the new algebraic effects are in fact statically typed. Do I remember this correctly? If so, where can I read about these new algebraic effects?
- kcsrk 5y ago
  Abandoned is perhaps too strong a term :-). Effect handlers in the language are supported by fibers, lightweight stacklets managed by the runtime. The details of the implementation can be found in the upcoming research paper in PLDI'21 conference [1]. The effect handlers in Multicore OCaml today do not provide effect safety. Programs are not statically guaranteed to handle all the effects they may perform. This is only as bad as exceptions in OCaml and every other mainstream language with exceptions. We are working on developing an effect system, which will ensure effect safety i.e, the compiler ensures that all the effects performed are caught. You also get a nice inferred type that says what effects a particular function may perform; if it performs none, then it is a pure function! This implementation would still use the current fiber support in the runtime. Leo White, one of the developers of Multicore OCaml had given a talk on this new effect system a few years ago [2]. That's the best place today to learn about the new effect handlers. The plan is to first add the fiber runtime support to OCaml without the syntax extensions for effect handlers, and then introduce syntax along with the effect system. [1] https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 [2] https://www.janestreet.com/tech-talks/effective-programming/ https://www.janestreet.com/tech-talks/effective-programming/
agumonkey 5y ago
How much resources are going into multicore compared to other needs / improvements in ocaml (if any) ?
- sadiq 5y ago
  Not sure I have enough of an overview to comment on that in general, unfortunately. The overview Anil gave at the end of last year on the OCaml Platform should give you an idea of the many other strands of work that are going on: https://ocaml.org/platform/ https://ocaml.org/platform/
  - agumonkey 5y ago
    Thanks man, and Best wishes

Happy to answer any questions.

by sadiq 5y ago

Happy to answer any questions.

I'm sorry if these are dumb questions, I'd be totally fine with some pointers in the right directions if you don't want to waste your time :) I'm under the impression that the implementation is based on algebraic effects. Does that include extending the language in a way that lets users define their own effects & handlers? Also, how's the performance? Last time I looked this stuff up (and played around with Eff), which was quite a while ago, I was told that regular usage of effects may impact performance quite noticeably.

sadiq 5y ago
Not dumb questions at all. Multicore adds parallelism via Domains (which are essentially heavyweight threads) and concurrency via Effects and fibers. There's a multicore GC that supports both of those. We plan to upstream things in two parts. First domains-only parallelism and then effects as a follow-up. When the latter lands users will be able to define their own effects and handlers, yes. Performance is pretty good, you can see our PLDI2021 paper for a proper performance evaluation and loads more details: https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250
- NanoCoaster 5y ago
  Thank you, interesting stuff. Very much looking forward to user-definable effects! I like Ocaml in principal, but haven't yet strayed beyond learning the very basics some time ago. Seeing a usable implementation of algebraic effects in a somewhat popular language...that I gotta see :)
  - sadiq 5y ago
    Worth pointing out you don't just need to stop at seeing it, you can get started playing around with it today: https://github.com/ocaml-multicore/multicore-opam#install-multicore-ocaml https://github.com/ocaml-multicore/multicore-opam#install-mu...
    - NanoCoaster 5y ago
      Cool, thanks for the link. Will definitely play around with it as soon as I find the time. Too many programming languages, too little free time, sadly.

mirekrusin 5y ago

Is it currently possible to play with multicore ocaml on M1?

mseri 5y ago
I think not yet: https://github.com/ocaml-multicore/ocaml-multicore/issues/86#issuecomment-822000783 https://github.com/ocaml-multicore/ocaml-multicore/issues/86... Fwiw, OCaml itself can be compiled natively on M1.
- sadiq 5y ago
  Yes, arm64 support is non-functional but we're planning to get it back in to a working state very soon.

wuschel 5y ago

Hello sadiq, I have some more general questions for you: As understand that currently, the situation is analogous to Python. The GIL allows for process based concurrency, with the well known disadvantage regarding memory consumption. Also, my guess is that OCaml relies library based solutions at the moment? 1) What does the introduction of MultiCore potential mean for Ocaml? Will Ocaml be a much better fit to run a webserver backend? Could you perhaps give a comparison to other programming languages? 2) How will Ocaml stand out with Multicore in the PL world, and what solutions would be it uniquely suited for? 3) What tools are going to be present to deal with bugs introduced by your new runtime e.g. race conditions? 4) If one wants to have a go at Multicore and play around with it, where/how do I start? Many thanks!

sadiq 5y ago
Good questions! 1) As I mentioned in https://news.ycombinator.com/item?id=27142502 https://news.ycombinator.com/item?id=27142502 there is support for parallelism and concurrency. Giving an example of where these might be useful in a webservice. The addition of shared-memory parallelism is beneficial where you might have a great deal of shared state that needs to be used to service requests. An in-memory cache is a good example - with a processed-based approach managing read/writes and avoiding significant overhead from marshalling the data is difficult. Concurrency via effects at a minimum can make writing network-based services much more pleasant (and debuggable!). See the examples in https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 where programs can be written in a direct-style similar to blocking IO but using effects are transformed to use asynchronous interfaces. There's work going on in the project at the moment to build fast cross-platform IO implementations that sit atop of uring/gcd/iocp. 3) This is a good question and one we're still working on. I think one of the lead developers KC has a few good ideas about instrumentation we can do to enable detecting races to global state. It's certainly going to be an issue for people porting large codebases. 4) This is the place to start: https://github.com/ocaml-multicore/multicore-opam#install-multicore-ocaml https://github.com/ocaml-multicore/multicore-opam#install-mu... .
- wuschel 5y ago
  Thank you for the your answer! I will check out the URIs.

intc 5y ago

Could you explain (in simple terms if possible) how the Multicore OCaml achieves a memory model which is much simpler on more efficient than in Java or C (mentioned at https://github.com/ocaml-multicore/ocaml-multicore/wiki https://github.com/ocaml-multicore/ocaml-multicore/wiki)? Didn't see any mentions of critical sections (mutexes) with C++ examples in the documentation ("Bounding Data Races in Space and Time"). I'm not sure I understand the comparisons the writers are presenting.

jlouis 5y ago
The key problem is program transformation, and in particular optimizations. Different CPUs/ISAs, and compilers, might want to transform your program to make it run faster. However, in the multi-core setting, data races pose bounds and limits on how much you can trigger those optimizations. The program doesn't generally execute sequentially in a way that can be entirely reasoned about. Instructions might be reordered for the sake of the program to run faster. Programmers can't work with that. So one proposes a memory model. Follow these rules, and our optimizations won't alter the behavior of the program. They kind-of describes what happens "in between" the critical sections of the program, hence the lack of a mutex mention. The paper presents a local property and then shows, formally, that this property is enough to guarantee an efficient memory model. That is, a model in which you can perform optimizations, while programmers can still reason about the programs behavior. The crux of the paper is that the property is local. This is new, because memory models which came before it are global: to reason about correctness, you have to consider the whole program, rather than consider a small (local) subset. OCaml requires more safety than most programming languages, so this is good for the fact that you can now compose local fragments of OCaml programs, without having to worry about a global safety property. The property is also simpler for programmers to reason about. The way you "use" the paper is that you adapt your optimizations to follow the property, and you make sure that the virtual memory model is implemented the same way on different architectures. Finally, the examples: they explore the idea of a local reasoning. In particular, they show why the (existing) global properties fail if you view them under the stronger requirement of local reasoning. It's the setup for the paper, since it means you can't just use the existing models. They need to be adapted if you want a more localized property.
5y ago

hajile 5y ago

StandardML implementations have had good multicore support for decades now despite having only a tiny fraction of the users and development time. Meanwhile, Ocaml has been promising support for years. What in Ocaml makes this so much harder to implement?

rwmj 5y ago
OCaml (or its immediate predecessor[1]) had a multicore implementation, but it was dropped because of its complexity and effect on single-thread performance. The challenge is to add it back in a way that is maintainable and doesn't negatively affect current users. [1] https://www.researchgate.net/publication/2774662_Concurrent_generational_garbage_collector_for_a_multithreaded_implementation_of_ML https://www.researchgate.net/publication/2774662_Concurrent_...
sadiq 5y ago
As the sibling comment mentions, the hard part is actually retrofitting multicore whilst maintaining compatibility _and_ performance. Our paper last year covers most of why this is tricky: https://arxiv.org/abs/2004.11663 https://arxiv.org/abs/2004.11663

4ad 5y ago

Algebraic effects as described in the OCaml papers about effects are dynamically typed. I recently heard in some talk that this idea was abandoned, and the new algebraic effects are in fact statically typed. Do I remember this correctly? If so, where can I read about these new algebraic effects?

kcsrk 5y ago
Abandoned is perhaps too strong a term :-). Effect handlers in the language are supported by fibers, lightweight stacklets managed by the runtime. The details of the implementation can be found in the upcoming research paper in PLDI'21 conference [1]. The effect handlers in Multicore OCaml today do not provide effect safety. Programs are not statically guaranteed to handle all the effects they may perform. This is only as bad as exceptions in OCaml and every other mainstream language with exceptions. We are working on developing an effect system, which will ensure effect safety i.e, the compiler ensures that all the effects performed are caught. You also get a nice inferred type that says what effects a particular function may perform; if it performs none, then it is a pure function! This implementation would still use the current fiber support in the runtime. Leo White, one of the developers of Multicore OCaml had given a talk on this new effect system a few years ago [2]. That's the best place today to learn about the new effect handlers. The plan is to first add the fiber runtime support to OCaml without the syntax extensions for effect handlers, and then introduce syntax along with the effect system. [1] https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 [2] https://www.janestreet.com/tech-talks/effective-programming/ https://www.janestreet.com/tech-talks/effective-programming/

agumonkey 5y ago

How much resources are going into multicore compared to other needs / improvements in ocaml (if any) ?

sadiq 5y ago
Not sure I have enough of an overview to comment on that in general, unfortunately. The overview Anil gave at the end of last year on the OCaml Platform should give you an idea of the many other strands of work that are going on: https://ocaml.org/platform/ https://ocaml.org/platform/
- agumonkey 5y ago
  Thanks man, and Best wishes