18 ms·

OCaml Multicore merged upstream

320 points by sadiq 5y ago

sadiq 5y ago
As usual I'm happy to answer any questions I can. (for maybe the second to last time)
- Operyl 5y ago
  Perhaps not the question you expected, but .. > (for maybe the second to last time) How come?
  - sadiq 5y ago
    With the merging to trunk, Multicore doesn't really exist as a separate project. The last major milestone that is likely to have a multicore-dominant discussion thread is probably the 5.0 release.
    - tyre 5y ago
      As someone who has worked so long on the project, how do you feel? Relieved?
      - sadiq 5y ago
        Hah. I only contributed to the project for about half it's life. There's still a lot of work to be done before 5.0 is released, it's just it'll happen through the usual PR and review process rather than a separate one.
- systems 5y ago
  For the not so OCaml savvy, can you recommend a blog post that explain, what programming constructs this adds Maybe a before and after, but one that focus on expressiveness, what you were not able to say/express in OCaml before, that is now* possible not just speed or performance *s/not/now
  - sadiq 5y ago
    Good question! https://github.com/ocaml-multicore/effects-examples https://github.com/ocaml-multicore/effects-examples has links to tutorials and examples for how effects can be used. There's also some slides from KC's talk on effect handlers https://kcsrk.info/slides/handlers_edinburgh.pdf https://kcsrk.info/slides/handlers_edinburgh.pdf and materials from the CUFP 17 tutorial: https://github.com/ocamllabs/ocaml-effects-tutorial https://github.com/ocamllabs/ocaml-effects-tutorial https://gopiandcode.uk/logs/log-bye-bye-monads-algebraic-effects.html https://gopiandcode.uk/logs/log-bye-bye-monads-algebraic-eff... this is also a great introduction
- yodsanklai 5y ago
  What were the main technical challenges? why did it take so many years? did it take research breakthrough, or was it something else (organisational issue / technical debt...)?
  - sadiq 5y ago
    It involved a fair amount of research and there were many technical challenges. Maintaining backwards compatibility in terms of language features and single-threaded performance puts constraints around what you can implement. Also from my personal experience, debugging segfaults in parallel programs that could be caused by GC bugs is a painstaking process. We've written a couple of papers detailing the internals and the trade-offs involved: https://arxiv.org/abs/2004.11663 https://arxiv.org/abs/2004.11663 (for parallelism) and https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 (for effects) Added to that is the complexity of tracking a moving target. Multicore had to be rebased through 12 releases of OCaml, which in itself was a non-trivial amount of work.
- Zababa 5y ago
  What's next after this? There are a lot of different projects ongoing for OCaml (typed effects, modular explicits/implicits, all of the RFCs, flambda and flambda 2, and I'm probably forgetting a lot of them). However, while following the progress of OCaml Multicore was easy thanks to the monthly posts, it's a bit harder to know where the focus will be next. Is there something like a "state of OCaml" that's planned, or a roadmap? Congratulations on the merge, and thank you for all the work that went into it!
  - octachron 5y ago
    Few of those projects are still at the research stage (typed effects, modular implicits, unboxed types), with a handful of people working on them at most. It is hard or even counter-productive to try to fit them on a roadmap. The multicore project is(was?) a bit unusual from the point of view of OCaml development since it is a massive engineering effort with a focused team. Nevertheless, I hope that we continue and extend the "OCaml compiler bimonthly" news to give more information about the ongoing work on the compiler.
    - Zababa 5y ago
      Thank you for the explanation. I hope too you will continue the OCaml compiler bimonthly, it's always an interesting read, and it's nice to be up to date with what's happening.
- maxwell86 5y ago
  Can you recommend a good resource for getting started with OCaml ?
  - av_conk 5y ago
    Real World OCaml (https://dev.realworldocaml.org/ https://dev.realworldocaml.org/) is a great one.
  - gmfawcett 5y ago
    Books, videos, and other good resources are listed here: https://ocaml.org/learn/ https://ocaml.org/learn/ This course text is also great, I don't know if it's listed at ocaml.org/learn or not: https://cs3110.github.io/textbook/ https://cs3110.github.io/textbook/
    - HellsMaddy 5y ago
      +1 for CS 3110 (OCaml Programming: Correct + Efficient + Beautiful), and the video series is similarly excellent: https://www.youtube.com/playlist?list=PLre5AT9JnKShBOPeuiD9b-I4XROIJhkIU https://www.youtube.com/playlist?list=PLre5AT9JnKShBOPeuiD9b...
- Zababa 5y ago
  Maybe a bit of a stupid question, but, will the compiler itself evolve to use multiple cores?
  - sadiq 5y ago
    Not a stupid question. I think adding parallelism to the compiler might be possible, though there are certainly parts that use a lot of mutable state that could prove tricky. Whether it's beneficial or not is unclear though.
gautamcgoel 5y ago
Been reading about this work for years, really cool to see it get merged! I recently came across a neat interview which describes upcoming changes to the OCaml GC and memory management system, which apparently lead to huge performance gains: https://signalsandthreads.com/memory-management/ https://signalsandthreads.com/memory-management/
- gadmm 5y ago
  The "huge performance gains" refers to the prefetching optimisation, which is already in OCaml (the old OCaml 4 branch, not in multicore yet).
nu11ptr 5y ago
Congrats - this is a big hurdle to adoption that is now gone. The engineering that went into this is impressive.
harporoeder 5y ago
Amazing to see this merged. As far as I can tell this work goes all the way back to 2014 (1), and has been a huge effort. 1. https://ocaml.org/meetings/ocaml/2014/ocaml2014_1.pdf https://ocaml.org/meetings/ocaml/2014/ocaml2014_1.pdf
carlsborg 5y ago
Any perf benchmarks?
- infruset 5y ago
  https://github.com/ocaml/ocaml/pull/10831 https://github.com/ocaml/ocaml/pull/10831
- mseri 5y ago
  Yes, have a look at [0] and maybe also the one in [1] [0]: https://github.com/ocaml-bench/sandmark https://github.com/ocaml-bench/sandmark [1]: https://github.com/ocaml-multicore/retro-httpaf-bench/pull/16 https://github.com/ocaml-multicore/retro-httpaf-bench/pull/1...
- sadiq 5y ago
  Along with the graphs from the PR in the sibling comment, there's also the extensive benchmarking from the ICFP2020 paper: https://arxiv.org/pdf/2004.11663.pdf https://arxiv.org/pdf/2004.11663.pdf Work on this is on-going via the sandmark benchmarking suite: https://github.com/ocaml-bench/sandmark https://github.com/ocaml-bench/sandmark In short the expectation should be that single-threaded code performs roughly the same (single digit percentage changes) as on the sequential runtime. Parallel code on multicore can see close to linear speedups on 64 cores, though it depends significantly on your workload. If you're interested in parallelising existing OCaml code, I gave an example-driven OCaml workshop talk in 2020: https://www.youtube.com/watch?v=Z7YZR1q8wzI https://www.youtube.com/watch?v=Z7YZR1q8wzI
xvilka 5y ago
Best news of the day! Is there any roadmap for typed effects?
- octachron 5y ago
  No, typed effects are still in the "research project with open design questions" category. It doesn't really make sense to have roadmaps for such open-ended feature. In other words, I am keen to not reproduce the announcement that "multicore might be in 4.03" from 5 years ago.
the-alt-one 5y ago
It's been a long time since I was hyped about something in programming! Very cool, I really want to try OCaml now.
- nesarkvechnep 5y ago
  I’m hyped about OCaml for some time. I might finally give it a go.
tialaramex 5y ago
Interesting. As I understand it, this lands an approach in which Sequential Consistency is not guaranteed but if you have a data race you get even nicer guarantees than in Java and its authors believe this might be enough that real programmers working on real software can actually debug data races despite loss of sequential consistency. In many popular languages today (e.g. C++) if you have a data race you're completely screwed, (e.g. the program exits successfully, even though it was supposed to loop forever serving TCP requests - good luck figuring out why). In Java they decided OK, that's not acceptable, so data races are constrained to only the data touched by the race and, importantly, that data is still legal it just might be astonishing (e.g. you were adding several small positive integers together from a shared data structure in parallel, but due to a misunderstanding in your design this was actually a data race, and some time later somehow your total is now zero, but you won't crash or whatever) OCaml intends to further constrain the consequences in time, if the total was 114 when you stopped adding, it will still be 114 later, it won't mysteriously become zero (or any other value) thanks to a data race which must have happened before you checked. [I'm sure I have some details wrong, but this is the gist] What remains to be seen is: Is that enough? There was great hope when Java made its rules that they were enough and programmers could understand what was wrong in a Java program with data races, that did not pan out as I understand it. So, it seems to me that it's possible OCaml ends up in the same situation.
- ackfoobar 5y ago
  I believe the less scary race in Java implies a lower performance upper bound. Does the nicer guarantees in multicore OCaml have the same drawback? I.e. even less than Java?
  - avsm 5y ago
    (co-author of the OCaml memory model paper here) The details of the 'LDRF' (local data race freedom) property are described in detail here: https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf The performance numbers are in the paper abstract: "our evaluation demonstrates that it is possible to balance a comprehensible memory model with a reasonable (no overhead on x86, ~0.6% on ARM) sequential performance trade-off in a mainstream programming language". It's a little higher on PowerPC but still very usable, and RISC-V overheads should be roughly comparable to ARM.
saati 5y ago
OCaml was single threaded until this or what is this exactly? There is no description of what the PR does which is pretty bad form.
- Mikeb85 5y ago
  Ish. OCaml didn't have any constructs in the language itself for parallelism. You could fork processes and things and libraries did/do exist to write parallel code in OCaml.
- vrotaru 5y ago
  OCaml had threads. There even a Threads module in standard library. The limitation was that only one thread can run at any given time. P.S There were ways around it, like calling an extern C function which will spawn a new theead and call and pass the control back, but those were almost never used.
- gmfawcett 5y ago
  It was very similar to the Python story: native threads, but there is a global lock on the OCaml runtime. You can fire off a thread and have it stay busy in external code (e.g. in a C library), but only one thread can be running OCaml code at a time. For this reason (and others), forking child processes has been a common alternative on many OCaml projects. See here for an update re: the whole multicore initiative, and links to more information: https://discuss.ocaml.org/t/multicore-ocaml-december-2021-and-the-big-pr/9115 https://discuss.ocaml.org/t/multicore-ocaml-december-2021-an...
  - Blikkentrekker 5y ago
    I would still fork child processes and use i.p.c. probably until there be something similar to channels, and often even then, because signal handling and forking in a multithreaded program is quite a hurdle. Even in Rust, no one really knows at this point what is safe to do in a fork from a multithreaded program or in a signal handler in one. Signal handlers and forks are thus simply “unsafe” in Rust with “care must be taken”, but there is no real explanation either of what care, and Rust does not document or stabilize which of it's functions are async safe, as C does.
exdsq 5y ago
Is anywhere other than Jane Street using OCaml? :)
- anuragsoni 5y ago
  Yes! https://v3.ocaml.org/users https://v3.ocaml.org/users has a list some of industrial users. The list might not be as large as say for languages like Rust, but its more than just Janestreet :) Personally, I've also been lucky enough to have worked for two different employers (not in the finance or compiler space) over the past 2 years where I've mostly used OCaml for writing things that many people might consider "boring", namely lots of web services, database drivers, data processing, etc.
- richeyryan 5y ago
  Facebook, Bloomberg, Citrix, Docker and a handful of others featured on their website[1]. I'm sure there are others that are quietly using it. [1]https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html
codeptualize 5y ago
Congrats on the merge, big achievement! I have been interested in OCaml for a while (mainly because of ReasonML), never really got to it unfortunately, but maybe this is the time.
pjmlp 5y ago
Congratulations on the accomplishment!
mgaunard 5y ago
I'm familiar with the C++11 object model. How does OCaml compare? From a quick skim of papers, it seems it provides sequential consistency when using atomics and acquire/release semantics when not. Sounds like a pretty bad design.
- kcsrk 5y ago
  > it seems it provides sequential consistency when using atomics and acquire/release semantics when not. (author of the said paper here) This is wrong. I suggest reading the paper closely. If not, the morning paper has a good summary [1,2]. [1] https://blog.acolyer.org/2018/08/09/bounding-data-races-in-space-and-time-part-i/ https://blog.acolyer.org/2018/08/09/bounding-data-races-in-s... [2] https://blog.acolyer.org/2018/08/10/bounding-data-races-in-space-and-time-part-ii/ https://blog.acolyer.org/2018/08/10/bounding-data-races-in-s...
  - mgaunard 5y ago
    I would have preferred a straightforward answer instead. It's not obvious to me from those articles how what I said is inaccurate.
eatonphil 5y ago
If you're interested to see a comparison of parallel programming in a number of functional languages check this repo out [0]. It includes multicore OCaml, parallel MLton (but not Poly/ML, which has been around and parallel longer), Haskell, Futhark, F#, Scala, and Rust. Credit to Sam Westrick for turning me on to this [1]. [0] https://github.com/athas/raytracers https://github.com/athas/raytracers [1] https://twitter.com/shwestrick/status/1480587660691480579 https://twitter.com/shwestrick/status/1480587660691480579
- Zababa 5y ago
  One thing that I think is missing is the compilation time. Those can vary widely depending on the languages. Other than that it's a nice repo, thanks for sharing it!
- omniscient_oce 5y ago
  Multicore OCaml seems quite slow compared to the others. I wonder how many low hanging fruit there are in the backend to speed those numbers up a bit.
  - jabl 5y ago
    I wondered the same, but it seems the multicore OCaml implementation of those benchmarks was last touched 2 years ago, and the top level README with the benchmark results was also last updated for the OCaml results around that same time. So maybe just rerunning those tests with the latest version would give better results?
foobarloo2 5y ago
Very interesting.
devmunchies 5y ago
the PR adds effect handlers (`stdlib/effectHandlers.ml`). Does that mean work will begin to start replacing Async+Lwt with a native alternative?
- talex5 5y ago
  Work has already started: https://github.com/ocaml-multicore/eio https://github.com/ocaml-multicore/eio There's also now https://github.com/talex5/lwt_eio https://github.com/talex5/lwt_eio, which allows you to run existing Lwt code alongside code using effects, to aid with porting.
- avsm 5y ago
  work has already begin on a direct-style IO library that internally uses effects. See: - https://github.com/ocaml-multicore/eio#readme https://github.com/ocaml-multicore/eio#readme for more information on the Eio library - https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89 https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5... is a short talk on experiences using effects with some nice motivating examples Note that Eio is more than just a direct replacement for Lwt and Async. We couldn't resist using some of the experiences also gained from the MirageOS (mirage.io) unikernel framework in EIO. This means that the backends are highly optimised to use the best syscalls available in the OS (e.g. io_uring by default in Linux). If you write your applications to use Eio natively, then performance is very high so far. The ergonomics of programming in it also compare favourably to using monadic concurrency.
  - devmunchies 5y ago
    so EIO is a new IO implementation built on top of effect handlers? Will EIO also be part of the stdlib? ie. will the httpaf server library need to import it as an external dependency like it currently does with lwt, or will EIO already be available?
    - rbjorklin 5y ago
      I just lurk the OCaml forums so don't take what I say as gospel but from what I've understood EIO will _not_ be part of stdlib. The OCaml devs go out of their way to not break things in stdlib so from what I've gathered they don't want to include it EIO until there's more real world experience with it and the API has started to settle down. Including it in stdlib might also never happen but that remains to be seen.
dang 5y ago
From three weeks ago: PR to Merge Multicore OCaml - https://news.ycombinator.com/item?id=29638152 https://news.ycombinator.com/item?id=29638152 - Dec 2021 (155 comments) Past related threads: Multicore OCaml: October 2021 - https://news.ycombinator.com/item?id=29238972 https://news.ycombinator.com/item?id=29238972 - Nov 2021 (12 comments) Effective Concurrency with Algebraic Effects in Multicore OCaml - https://news.ycombinator.com/item?id=28838099 https://news.ycombinator.com/item?id=28838099 - Oct 2021 (59 comments) Multicore OCaml: September 2021, effect handlers will be in OCaml 5.0 - https://news.ycombinator.com/item?id=28742033 https://news.ycombinator.com/item?id=28742033 - Oct 2021 (3 comments) Multicore OCaml: September 2021 - Effect handlers will be in OCaml 5.0 - https://news.ycombinator.com/item?id=28719088 https://news.ycombinator.com/item?id=28719088 - Oct 2021 (3 comments) Adapting the OCaml Ecosystem for Multicore OCaml - https://news.ycombinator.com/item?id=28440385 https://news.ycombinator.com/item?id=28440385 - Sept 2021 (1 comment) Adapting the OCaml Ecosystem for Multicore OCaml - https://news.ycombinator.com/item?id=28373155 https://news.ycombinator.com/item?id=28373155 - Aug 2021 (21 comments) Multicore OCaml: July 2021 - https://news.ycombinator.com/item?id=28039219 https://news.ycombinator.com/item?id=28039219 - Aug 2021 (14 comments) Multicore OCaml: May 2021 - https://news.ycombinator.com/item?id=27480678 https://news.ycombinator.com/item?id=27480678 - June 2021 (27 comments) Multicore OCaml: April 2021 - https://news.ycombinator.com/item?id=27140522 https://news.ycombinator.com/item?id=27140522 - May 2021 (89 comments) Multicore OCaml: Feb 2021 with new preprint on Effect Handlers - https://news.ycombinator.com/item?id=26424785 https://news.ycombinator.com/item?id=26424785 - March 2021 (29 comments) Multicore OCaml: October 2020 - https://news.ycombinator.com/item?id=25034538 https://news.ycombinator.com/item?id=25034538 - Nov 2020 (9 comments) Multicore OCaml: September 2020 - https://news.ycombinator.com/item?id=24719124 https://news.ycombinator.com/item?id=24719124 - Oct 2020 (43 comments) Parallel Programming in Multicore OCaml - https://news.ycombinator.com/item?id=23740869 https://news.ycombinator.com/item?id=23740869 - July 2020 (15 comments) Multicore OCaml: May 2020 update - https://news.ycombinator.com/item?id=23380370 https://news.ycombinator.com/item?id=23380370 - June 2020 (17 comments) Multicore OCaml: March 2020 update - https://news.ycombinator.com/item?id=22727975 https://news.ycombinator.com/item?id=22727975 - March 2020 (37 comments) Multicore OCaml: Feb 2020 update - https://news.ycombinator.com/item?id=22443428 https://news.ycombinator.com/item?id=22443428 - Feb 2020 (80 comments) State of Multicore OCaml [pdf] - https://news.ycombinator.com/item?id=17416797 https://news.ycombinator.com/item?id=17416797 - June 2018 (103 comments) OCaml-multicore now at 4.04.2 - https://news.ycombinator.com/item?id=16646181 https://news.ycombinator.com/item?id=16646181 - March 2018 (4 comments) A deep dive into Multicore OCaml garbage collector - https://news.ycombinator.com/item?id=14780159 https://news.ycombinator.com/item?id=14780159 - July 2017 (89 comments) Lock-free programming for the masses - https://news.ycombinator.com/item?id=11907584 https://news.ycombinator.com/item?id=11907584 - June 2016 (29 comments) Lock-free programming for the masses - https://news.ycombinator.com/item?id=11893911 https://news.ycombinator.com/item?id=11893911 - June 2016 (4 comments) OCaml 4.03 will, “if all goes well”, support multicore - https://news.ycombinator.com/item?id=9582980 https://news.ycombinator.com/item?id=9582980 - May 2015 (113 comments) Multicore OCaml - https://news.ycombinator.com/item?id=8003699 https://news.ycombinator.com/item?id=8003699 - July 2014 (1 comment)

320 points by sadiq 5y ago

sadiq 5y ago

As usual I'm happy to answer any questions I can. (for maybe the second to last time)

Operyl 5y ago
Perhaps not the question you expected, but .. > (for maybe the second to last time) How come?
- sadiq 5y ago
  With the merging to trunk, Multicore doesn't really exist as a separate project. The last major milestone that is likely to have a multicore-dominant discussion thread is probably the 5.0 release.
  - tyre 5y ago
    As someone who has worked so long on the project, how do you feel? Relieved?
    - sadiq 5y ago
      Hah. I only contributed to the project for about half it's life. There's still a lot of work to be done before 5.0 is released, it's just it'll happen through the usual PR and review process rather than a separate one.
systems 5y ago
For the not so OCaml savvy, can you recommend a blog post that explain, what programming constructs this adds Maybe a before and after, but one that focus on expressiveness, what you were not able to say/express in OCaml before, that is now* possible not just speed or performance *s/not/now
- sadiq 5y ago
  Good question! https://github.com/ocaml-multicore/effects-examples https://github.com/ocaml-multicore/effects-examples has links to tutorials and examples for how effects can be used. There's also some slides from KC's talk on effect handlers https://kcsrk.info/slides/handlers_edinburgh.pdf https://kcsrk.info/slides/handlers_edinburgh.pdf and materials from the CUFP 17 tutorial: https://github.com/ocamllabs/ocaml-effects-tutorial https://github.com/ocamllabs/ocaml-effects-tutorial https://gopiandcode.uk/logs/log-bye-bye-monads-algebraic-effects.html https://gopiandcode.uk/logs/log-bye-bye-monads-algebraic-eff... this is also a great introduction
yodsanklai 5y ago
What were the main technical challenges? why did it take so many years? did it take research breakthrough, or was it something else (organisational issue / technical debt...)?
- sadiq 5y ago
  It involved a fair amount of research and there were many technical challenges. Maintaining backwards compatibility in terms of language features and single-threaded performance puts constraints around what you can implement. Also from my personal experience, debugging segfaults in parallel programs that could be caused by GC bugs is a painstaking process. We've written a couple of papers detailing the internals and the trade-offs involved: https://arxiv.org/abs/2004.11663 https://arxiv.org/abs/2004.11663 (for parallelism) and https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 (for effects) Added to that is the complexity of tracking a moving target. Multicore had to be rebased through 12 releases of OCaml, which in itself was a non-trivial amount of work.
Zababa 5y ago
What's next after this? There are a lot of different projects ongoing for OCaml (typed effects, modular explicits/implicits, all of the RFCs, flambda and flambda 2, and I'm probably forgetting a lot of them). However, while following the progress of OCaml Multicore was easy thanks to the monthly posts, it's a bit harder to know where the focus will be next. Is there something like a "state of OCaml" that's planned, or a roadmap? Congratulations on the merge, and thank you for all the work that went into it!
- octachron 5y ago
  Few of those projects are still at the research stage (typed effects, modular implicits, unboxed types), with a handful of people working on them at most. It is hard or even counter-productive to try to fit them on a roadmap. The multicore project is(was?) a bit unusual from the point of view of OCaml development since it is a massive engineering effort with a focused team. Nevertheless, I hope that we continue and extend the "OCaml compiler bimonthly" news to give more information about the ongoing work on the compiler.
  - Zababa 5y ago
    Thank you for the explanation. I hope too you will continue the OCaml compiler bimonthly, it's always an interesting read, and it's nice to be up to date with what's happening.
maxwell86 5y ago
Can you recommend a good resource for getting started with OCaml ?
- av_conk 5y ago
  Real World OCaml (https://dev.realworldocaml.org/ https://dev.realworldocaml.org/) is a great one.
- gmfawcett 5y ago
  Books, videos, and other good resources are listed here: https://ocaml.org/learn/ https://ocaml.org/learn/ This course text is also great, I don't know if it's listed at ocaml.org/learn or not: https://cs3110.github.io/textbook/ https://cs3110.github.io/textbook/
  - HellsMaddy 5y ago
    +1 for CS 3110 (OCaml Programming: Correct + Efficient + Beautiful), and the video series is similarly excellent: https://www.youtube.com/playlist?list=PLre5AT9JnKShBOPeuiD9b-I4XROIJhkIU https://www.youtube.com/playlist?list=PLre5AT9JnKShBOPeuiD9b...
Zababa 5y ago
Maybe a bit of a stupid question, but, will the compiler itself evolve to use multiple cores?
- sadiq 5y ago
  Not a stupid question. I think adding parallelism to the compiler might be possible, though there are certainly parts that use a lot of mutable state that could prove tricky. Whether it's beneficial or not is unclear though.

gautamcgoel 5y ago

Been reading about this work for years, really cool to see it get merged! I recently came across a neat interview which describes upcoming changes to the OCaml GC and memory management system, which apparently lead to huge performance gains: https://signalsandthreads.com/memory-management/ https://signalsandthreads.com/memory-management/

gadmm 5y ago
The "huge performance gains" refers to the prefetching optimisation, which is already in OCaml (the old OCaml 4 branch, not in multicore yet).

nu11ptr 5y ago

Congrats - this is a big hurdle to adoption that is now gone. The engineering that went into this is impressive.

harporoeder 5y ago

Amazing to see this merged. As far as I can tell this work goes all the way back to 2014 (1), and has been a huge effort. 1. https://ocaml.org/meetings/ocaml/2014/ocaml2014_1.pdf https://ocaml.org/meetings/ocaml/2014/ocaml2014_1.pdf

carlsborg 5y ago

Any perf benchmarks?

infruset 5y ago
https://github.com/ocaml/ocaml/pull/10831 https://github.com/ocaml/ocaml/pull/10831
mseri 5y ago
Yes, have a look at [0] and maybe also the one in [1] [0]: https://github.com/ocaml-bench/sandmark https://github.com/ocaml-bench/sandmark [1]: https://github.com/ocaml-multicore/retro-httpaf-bench/pull/16 https://github.com/ocaml-multicore/retro-httpaf-bench/pull/1...
sadiq 5y ago
Along with the graphs from the PR in the sibling comment, there's also the extensive benchmarking from the ICFP2020 paper: https://arxiv.org/pdf/2004.11663.pdf https://arxiv.org/pdf/2004.11663.pdf Work on this is on-going via the sandmark benchmarking suite: https://github.com/ocaml-bench/sandmark https://github.com/ocaml-bench/sandmark In short the expectation should be that single-threaded code performs roughly the same (single digit percentage changes) as on the sequential runtime. Parallel code on multicore can see close to linear speedups on 64 cores, though it depends significantly on your workload. If you're interested in parallelising existing OCaml code, I gave an example-driven OCaml workshop talk in 2020: https://www.youtube.com/watch?v=Z7YZR1q8wzI https://www.youtube.com/watch?v=Z7YZR1q8wzI

xvilka 5y ago

Best news of the day! Is there any roadmap for typed effects?

octachron 5y ago
No, typed effects are still in the "research project with open design questions" category. It doesn't really make sense to have roadmaps for such open-ended feature. In other words, I am keen to not reproduce the announcement that "multicore might be in 4.03" from 5 years ago.

the-alt-one 5y ago

It's been a long time since I was hyped about something in programming! Very cool, I really want to try OCaml now.

nesarkvechnep 5y ago
I’m hyped about OCaml for some time. I might finally give it a go.

tialaramex 5y ago

Interesting. As I understand it, this lands an approach in which Sequential Consistency is not guaranteed but if you have a data race you get even nicer guarantees than in Java and its authors believe this might be enough that real programmers working on real software can actually debug data races despite loss of sequential consistency. In many popular languages today (e.g. C++) if you have a data race you're completely screwed, (e.g. the program exits successfully, even though it was supposed to loop forever serving TCP requests - good luck figuring out why). In Java they decided OK, that's not acceptable, so data races are constrained to only the data touched by the race and, importantly, that data is still legal it just might be astonishing (e.g. you were adding several small positive integers together from a shared data structure in parallel, but due to a misunderstanding in your design this was actually a data race, and some time later somehow your total is now zero, but you won't crash or whatever) OCaml intends to further constrain the consequences in time, if the total was 114 when you stopped adding, it will still be 114 later, it won't mysteriously become zero (or any other value) thanks to a data race which must have happened before you checked. [I'm sure I have some details wrong, but this is the gist] What remains to be seen is: Is that enough? There was great hope when Java made its rules that they were enough and programmers could understand what was wrong in a Java program with data races, that did not pan out as I understand it. So, it seems to me that it's possible OCaml ends up in the same situation.

ackfoobar 5y ago
I believe the less scary race in Java implies a lower performance upper bound. Does the nicer guarantees in multicore OCaml have the same drawback? I.e. even less than Java?
- avsm 5y ago
  (co-author of the OCaml memory model paper here) The details of the 'LDRF' (local data race freedom) property are described in detail here: https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf The performance numbers are in the paper abstract: "our evaluation demonstrates that it is possible to balance a comprehensible memory model with a reasonable (no overhead on x86, ~0.6% on ARM) sequential performance trade-off in a mainstream programming language". It's a little higher on PowerPC but still very usable, and RISC-V overheads should be roughly comparable to ARM.

saati 5y ago

OCaml was single threaded until this or what is this exactly? There is no description of what the PR does which is pretty bad form.

Mikeb85 5y ago
Ish. OCaml didn't have any constructs in the language itself for parallelism. You could fork processes and things and libraries did/do exist to write parallel code in OCaml.
vrotaru 5y ago
OCaml had threads. There even a Threads module in standard library. The limitation was that only one thread can run at any given time. P.S There were ways around it, like calling an extern C function which will spawn a new theead and call and pass the control back, but those were almost never used.
gmfawcett 5y ago
It was very similar to the Python story: native threads, but there is a global lock on the OCaml runtime. You can fire off a thread and have it stay busy in external code (e.g. in a C library), but only one thread can be running OCaml code at a time. For this reason (and others), forking child processes has been a common alternative on many OCaml projects. See here for an update re: the whole multicore initiative, and links to more information: https://discuss.ocaml.org/t/multicore-ocaml-december-2021-and-the-big-pr/9115 https://discuss.ocaml.org/t/multicore-ocaml-december-2021-an...
- Blikkentrekker 5y ago
  I would still fork child processes and use i.p.c. probably until there be something similar to channels, and often even then, because signal handling and forking in a multithreaded program is quite a hurdle. Even in Rust, no one really knows at this point what is safe to do in a fork from a multithreaded program or in a signal handler in one. Signal handlers and forks are thus simply “unsafe” in Rust with “care must be taken”, but there is no real explanation either of what care, and Rust does not document or stabilize which of it's functions are async safe, as C does.

exdsq 5y ago

Is anywhere other than Jane Street using OCaml? :)

anuragsoni 5y ago
Yes! https://v3.ocaml.org/users https://v3.ocaml.org/users has a list some of industrial users. The list might not be as large as say for languages like Rust, but its more than just Janestreet :) Personally, I've also been lucky enough to have worked for two different employers (not in the finance or compiler space) over the past 2 years where I've mostly used OCaml for writing things that many people might consider "boring", namely lots of web services, database drivers, data processing, etc.
richeyryan 5y ago
Facebook, Bloomberg, Citrix, Docker and a handful of others featured on their website[1]. I'm sure there are others that are quietly using it. [1]https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html

codeptualize 5y ago

Congrats on the merge, big achievement! I have been interested in OCaml for a while (mainly because of ReasonML), never really got to it unfortunately, but maybe this is the time.

pjmlp 5y ago

Congratulations on the accomplishment!

mgaunard 5y ago

I'm familiar with the C++11 object model. How does OCaml compare? From a quick skim of papers, it seems it provides sequential consistency when using atomics and acquire/release semantics when not. Sounds like a pretty bad design.

kcsrk 5y ago
> it seems it provides sequential consistency when using atomics and acquire/release semantics when not. (author of the said paper here) This is wrong. I suggest reading the paper closely. If not, the morning paper has a good summary [1,2]. [1] https://blog.acolyer.org/2018/08/09/bounding-data-races-in-space-and-time-part-i/ https://blog.acolyer.org/2018/08/09/bounding-data-races-in-s... [2] https://blog.acolyer.org/2018/08/10/bounding-data-races-in-space-and-time-part-ii/ https://blog.acolyer.org/2018/08/10/bounding-data-races-in-s...
- mgaunard 5y ago
  I would have preferred a straightforward answer instead. It's not obvious to me from those articles how what I said is inaccurate.

eatonphil 5y ago

If you're interested to see a comparison of parallel programming in a number of functional languages check this repo out [0]. It includes multicore OCaml, parallel MLton (but not Poly/ML, which has been around and parallel longer), Haskell, Futhark, F#, Scala, and Rust. Credit to Sam Westrick for turning me on to this [1]. [0] https://github.com/athas/raytracers https://github.com/athas/raytracers [1] https://twitter.com/shwestrick/status/1480587660691480579 https://twitter.com/shwestrick/status/1480587660691480579

Zababa 5y ago
One thing that I think is missing is the compilation time. Those can vary widely depending on the languages. Other than that it's a nice repo, thanks for sharing it!
omniscient_oce 5y ago
Multicore OCaml seems quite slow compared to the others. I wonder how many low hanging fruit there are in the backend to speed those numbers up a bit.
- jabl 5y ago
  I wondered the same, but it seems the multicore OCaml implementation of those benchmarks was last touched 2 years ago, and the top level README with the benchmark results was also last updated for the OCaml results around that same time. So maybe just rerunning those tests with the latest version would give better results?

foobarloo2 5y ago

Very interesting.

devmunchies 5y ago

the PR adds effect handlers (`stdlib/effectHandlers.ml`). Does that mean work will begin to start replacing Async+Lwt with a native alternative?

talex5 5y ago
Work has already started: https://github.com/ocaml-multicore/eio https://github.com/ocaml-multicore/eio There's also now https://github.com/talex5/lwt_eio https://github.com/talex5/lwt_eio, which allows you to run existing Lwt code alongside code using effects, to aid with porting.
avsm 5y ago
work has already begin on a direct-style IO library that internally uses effects. See: - https://github.com/ocaml-multicore/eio#readme https://github.com/ocaml-multicore/eio#readme for more information on the Eio library - https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89 https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5... is a short talk on experiences using effects with some nice motivating examples Note that Eio is more than just a direct replacement for Lwt and Async. We couldn't resist using some of the experiences also gained from the MirageOS (mirage.io) unikernel framework in EIO. This means that the backends are highly optimised to use the best syscalls available in the OS (e.g. io_uring by default in Linux). If you write your applications to use Eio natively, then performance is very high so far. The ergonomics of programming in it also compare favourably to using monadic concurrency.
- devmunchies 5y ago
  so EIO is a new IO implementation built on top of effect handlers? Will EIO also be part of the stdlib? ie. will the httpaf server library need to import it as an external dependency like it currently does with lwt, or will EIO already be available?
  - rbjorklin 5y ago
    I just lurk the OCaml forums so don't take what I say as gospel but from what I've understood EIO will _not_ be part of stdlib. The OCaml devs go out of their way to not break things in stdlib so from what I've gathered they don't want to include it EIO until there's more real world experience with it and the API has started to settle down. Including it in stdlib might also never happen but that remains to be seen.

dang 5y ago

From three weeks ago: PR to Merge Multicore OCaml - https://news.ycombinator.com/item?id=29638152 https://news.ycombinator.com/item?id=29638152 - Dec 2021 (155 comments) Past related threads: Multicore OCaml: October 2021 - https://news.ycombinator.com/item?id=29238972 https://news.ycombinator.com/item?id=29238972 - Nov 2021 (12 comments) Effective Concurrency with Algebraic Effects in Multicore OCaml - https://news.ycombinator.com/item?id=28838099 https://news.ycombinator.com/item?id=28838099 - Oct 2021 (59 comments) Multicore OCaml: September 2021, effect handlers will be in OCaml 5.0 - https://news.ycombinator.com/item?id=28742033 https://news.ycombinator.com/item?id=28742033 - Oct 2021 (3 comments) Multicore OCaml: September 2021 - Effect handlers will be in OCaml 5.0 - https://news.ycombinator.com/item?id=28719088 https://news.ycombinator.com/item?id=28719088 - Oct 2021 (3 comments) Adapting the OCaml Ecosystem for Multicore OCaml - https://news.ycombinator.com/item?id=28440385 https://news.ycombinator.com/item?id=28440385 - Sept 2021 (1 comment) Adapting the OCaml Ecosystem for Multicore OCaml - https://news.ycombinator.com/item?id=28373155 https://news.ycombinator.com/item?id=28373155 - Aug 2021 (21 comments) Multicore OCaml: July 2021 - https://news.ycombinator.com/item?id=28039219 https://news.ycombinator.com/item?id=28039219 - Aug 2021 (14 comments) Multicore OCaml: May 2021 - https://news.ycombinator.com/item?id=27480678 https://news.ycombinator.com/item?id=27480678 - June 2021 (27 comments) Multicore OCaml: April 2021 - https://news.ycombinator.com/item?id=27140522 https://news.ycombinator.com/item?id=27140522 - May 2021 (89 comments) Multicore OCaml: Feb 2021 with new preprint on Effect Handlers - https://news.ycombinator.com/item?id=26424785 https://news.ycombinator.com/item?id=26424785 - March 2021 (29 comments) Multicore OCaml: October 2020 - https://news.ycombinator.com/item?id=25034538 https://news.ycombinator.com/item?id=25034538 - Nov 2020 (9 comments) Multicore OCaml: September 2020 - https://news.ycombinator.com/item?id=24719124 https://news.ycombinator.com/item?id=24719124 - Oct 2020 (43 comments) Parallel Programming in Multicore OCaml - https://news.ycombinator.com/item?id=23740869 https://news.ycombinator.com/item?id=23740869 - July 2020 (15 comments) Multicore OCaml: May 2020 update - https://news.ycombinator.com/item?id=23380370 https://news.ycombinator.com/item?id=23380370 - June 2020 (17 comments) Multicore OCaml: March 2020 update - https://news.ycombinator.com/item?id=22727975 https://news.ycombinator.com/item?id=22727975 - March 2020 (37 comments) Multicore OCaml: Feb 2020 update - https://news.ycombinator.com/item?id=22443428 https://news.ycombinator.com/item?id=22443428 - Feb 2020 (80 comments) State of Multicore OCaml [pdf] - https://news.ycombinator.com/item?id=17416797 https://news.ycombinator.com/item?id=17416797 - June 2018 (103 comments) OCaml-multicore now at 4.04.2 - https://news.ycombinator.com/item?id=16646181 https://news.ycombinator.com/item?id=16646181 - March 2018 (4 comments) A deep dive into Multicore OCaml garbage collector - https://news.ycombinator.com/item?id=14780159 https://news.ycombinator.com/item?id=14780159 - July 2017 (89 comments) Lock-free programming for the masses - https://news.ycombinator.com/item?id=11907584 https://news.ycombinator.com/item?id=11907584 - June 2016 (29 comments) Lock-free programming for the masses - https://news.ycombinator.com/item?id=11893911 https://news.ycombinator.com/item?id=11893911 - June 2016 (4 comments) OCaml 4.03 will, “if all goes well”, support multicore - https://news.ycombinator.com/item?id=9582980 https://news.ycombinator.com/item?id=9582980 - May 2015 (113 comments) Multicore OCaml - https://news.ycombinator.com/item?id=8003699 https://news.ycombinator.com/item?id=8003699 - July 2014 (1 comment)