4 ms·

There are a few OCaml contributors lurking and happy to answer questions if you have them.

by sadiq 4y ago

jon_smark 4y ago
Are the plans for typed algebraic effects solidifying, or are they still nebulous? Concretely, are you willing to take a guess as to when we are expected to see OCaml 6? ;-)
- kcsrk 4y ago
  Rather than a full effect system, we're very likely to have lexically scoped "checked" effects with the help of modal types. I briefly talked about it at the end of my ICFP keynote: https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retrofitting-Concurrency-Lessons-from-the-Engine-Room https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retro... There are other cool stuff that is being worked on, which I am very excited about: https://discuss.ocaml.org/t/jane-street-compiler-development-and-open-source/10806 https://discuss.ocaml.org/t/jane-street-compiler-development.... Hopefully, we will see many of these make it into OCaml 6.
  - jon_smark 4y ago
    Thanks for the reply. I hope that the array and list comprehensions land soon in upstream; it's a useful and hopefully not-too-controversial feature. I'm more ambivalent regarding the local allocations and the unboxed types. I totally understand why they'd be useful when you are trying to squeeze every last drop of performance, but they do require a not-so-trivial complexification of the language.
    - kcsrk 4y ago
      The local types are less invasive than the full support for typed effects. In particular, they are opt-in and associated complexity is pay-as-you-go. In my initial experiments, they seemed pretty nice to program with.
- octachron 4y ago
  The type system for algebraic effects is still in the research and design phase at this point. Right now, I am not even taking a guess of what will be the defining new major features of OCaml 6 (effect system + modular implicits maybe? Maybe not?).
  - jon_smark 4y ago
    Thanks for the reply. I'm hoping that modular macros land soon. I'm very ambivalent about the PPX mechanism, and I hope that modular macros reduces the need of PPX.
pdimitar 4y ago
As an Elixir (which steps on Erlang) and Rust dev I'm curious if you think OCaml 5.0 / Eio will give the Erlang's BEAM VM and Rust's tokio a run for their money in the parallel runtime space. I'm super curious about OCaml, picked it up and left it several times in the last 3 years. Now that multicore is here I'll absolutely be picking it up again and try to use it for parallel scripting and for some of my work. Great job!
- sadiq 4y ago
  We certainly hope so. You may find Thomas Leonard's talk from last year's workshop interesting: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89 https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5... The paper we wrote on retrofitting effect handlers: https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 also has some http benchmarks
tomp 4y ago
How does "bounding races in space and time" impact the generated machine code? Do you have some interesting examples of how it's different from the code C++ or JVM JIT would generate? What's the performance impact? Thanks!
- kcsrk 4y ago
  See examples in the second section and the results in the paper: https://kcsrk.info/papers/pldi18-memory.pdf https://kcsrk.info/papers/pldi18-memory.pdf
  - tomp 4y ago
    Do you mean section 2 of the paper? It only contains C-like pseudo-code, no machine code. The results section of the paper only compare the performance of Multicore OCaml with plain OCaml, not OCaml vs C++ / Java.
    - kcsrk 4y ago
      Right. It is hard in general to compare performance or generated code across languages as they make different trade offs. Table 3 and 5 show compilation of our memory model to X86 and ARMv7. The compilation and the related work section discusses trade offs. To summarise, atomic read and write in OCaml is more expensive than C++ since C++ SC atomics only establish total order between SC operations on not operations that are weaker but related to SC operations by happens before. We need stronger atomics for local data race freedom. Our non atomic are also stronger than non atomics on C++ and Java. That said, The non atomic operations are free on X86 (compiled to plain loads and stores) and involve a lightweight fence before stores on weaker architectures such as ARM, Power and RISC-V. The performance results show that extra fences before stores have a barely noticeable impact on ARM and Power.

There are a few OCaml contributors lurking and happy to answer questions if you have them.

by sadiq 4y ago

There are a few OCaml contributors lurking and happy to answer questions if you have them.

Are the plans for typed algebraic effects solidifying, or are they still nebulous? Concretely, are you willing to take a guess as to when we are expected to see OCaml 6? ;-)

kcsrk 4y ago
Rather than a full effect system, we're very likely to have lexically scoped "checked" effects with the help of modal types. I briefly talked about it at the end of my ICFP keynote: https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retrofitting-Concurrency-Lessons-from-the-Engine-Room https://icfp22.sigplan.org/details/icfp-2022-papers/48/Retro... There are other cool stuff that is being worked on, which I am very excited about: https://discuss.ocaml.org/t/jane-street-compiler-development-and-open-source/10806 https://discuss.ocaml.org/t/jane-street-compiler-development.... Hopefully, we will see many of these make it into OCaml 6.
- jon_smark 4y ago
  Thanks for the reply. I hope that the array and list comprehensions land soon in upstream; it's a useful and hopefully not-too-controversial feature. I'm more ambivalent regarding the local allocations and the unboxed types. I totally understand why they'd be useful when you are trying to squeeze every last drop of performance, but they do require a not-so-trivial complexification of the language.
  - kcsrk 4y ago
    The local types are less invasive than the full support for typed effects. In particular, they are opt-in and associated complexity is pay-as-you-go. In my initial experiments, they seemed pretty nice to program with.
octachron 4y ago
The type system for algebraic effects is still in the research and design phase at this point. Right now, I am not even taking a guess of what will be the defining new major features of OCaml 6 (effect system + modular implicits maybe? Maybe not?).
- jon_smark 4y ago
  Thanks for the reply. I'm hoping that modular macros land soon. I'm very ambivalent about the PPX mechanism, and I hope that modular macros reduces the need of PPX.

pdimitar 4y ago

As an Elixir (which steps on Erlang) and Rust dev I'm curious if you think OCaml 5.0 / Eio will give the Erlang's BEAM VM and Rust's tokio a run for their money in the parallel runtime space. I'm super curious about OCaml, picked it up and left it several times in the last 3 years. Now that multicore is here I'll absolutely be picking it up again and try to use it for parallel scripting and for some of my work. Great job!

sadiq 4y ago
We certainly hope so. You may find Thomas Leonard's talk from last year's workshop interesting: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89 https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5... The paper we wrote on retrofitting effect handlers: https://arxiv.org/abs/2104.00250 https://arxiv.org/abs/2104.00250 also has some http benchmarks

tomp 4y ago

How does "bounding races in space and time" impact the generated machine code? Do you have some interesting examples of how it's different from the code C++ or JVM JIT would generate? What's the performance impact? Thanks!

kcsrk 4y ago
See examples in the second section and the results in the paper: https://kcsrk.info/papers/pldi18-memory.pdf https://kcsrk.info/papers/pldi18-memory.pdf
- tomp 4y ago
  Do you mean section 2 of the paper? It only contains C-like pseudo-code, no machine code. The results section of the paper only compare the performance of Multicore OCaml with plain OCaml, not OCaml vs C++ / Java.
  - kcsrk 4y ago
    Right. It is hard in general to compare performance or generated code across languages as they make different trade offs. Table 3 and 5 show compilation of our memory model to X86 and ARMv7. The compilation and the related work section discusses trade offs. To summarise, atomic read and write in OCaml is more expensive than C++ since C++ SC atomics only establish total order between SC operations on not operations that are weaker but related to SC operations by happens before. We need stronger atomics for local data race freedom. Our non atomic are also stronger than non atomics on C++ and Java. That said, The non atomic operations are free on X86 (compiled to plain loads and stores) and involve a lightweight fence before stores on weaker architectures such as ARM, Power and RISC-V. The performance results show that extra fences before stores have a barely noticeable impact on ARM and Power.