Live data from Hacker News

Adapting the OCaml Ecosystem for Multicore OCaml

watch.ocaml.org

21–24 of 24 posts

Re: Adapting the OCaml Ecosystem for Multicore OCaml

#21
post #4

A nice detail: this video is hosted on the new OCaml website ( https://v3.ocaml.org/en ), which includes its own peertube instance.

Also interesting: the new OCaml website is built with ReScript, the rebranding of ReasonML.

That's right. Here's the forum post presenting the new websites and the choices made: https://discuss.ocaml.org/t/v3-ocaml-org-a-roadmap-for-ocaml....

Re: Adapting the OCaml Ecosystem for Multicore OCaml

#22
post #8
post #7

Earlier quoted context omitted.

Are there any benchmarks? Comparisons to other multicore runtimes, like GoLang's?

I remember seeing a graph where http/af, a http server, was close to Go net/http. I'll try to run https://github.com/ocaml-multicore/retro-httpaf-bench and report back. I also found another graph, but I'm too colorblind to read it properly https://user-images.githubusercontent.com/554131/131155247-f... . Edit: the benchmark fails to build

Top two lines are httpaf_eio and rust_hyper.

Next two lines are httpaf_effects and httpaf_lwt.

Bottom two lines are nethttp_go and cohttp_lwt_unix.

All in order from top to bottom.

Re: Adapting the OCaml Ecosystem for Multicore OCaml

#23
post #22
post #8

Earlier quoted context omitted.

I remember seeing a graph where http/af, a http server, was close to Go net/http. I'll try to run https://github.com/ocaml-multicore/retro-httpaf-bench and report back. I also found another graph, but I'm too colorblind to read it properly https://user-images.githubusercontent.com/554131/131155247-f... . Edit: the benchmark fails to build

Top two lines are httpaf_eio and rust_hyper. Next two lines are httpaf_effects and httpaf_lwt. Bottom two lines are nethttp_go and cohttp_lwt_unix. All in order from top to bottom.

Thank you very much!

Re: Adapting the OCaml Ecosystem for Multicore OCaml

#24
post #15

> Adapting the OCaml Ecosystem for Multicore That's the thing that is missing in discussions around many languages. You can't just add multicore or actors to a language post-factum. Because by the time you get around to doing it everything in your language, from standard lib to third-party packages, has already been written with no concept of multi-anything. And still, time and again, languages are being designed wit…

> And still, time and again, languages are being designed with these concerns as an afterthought. Is that still happening? My impression is that any languages designed since multicore became common have thought very hard about their approach. The problem we have is that a lot of our languages have been around a while. Even Python is 30 years old at this point! Erlang here is the miracle to me. Its programming model w…

Many languages side step the problem. With JS-inspired languages like Dart, you are limited to message passing workers. Many high performance concurrency applications are difficult without shared memory support.
Post reply on HN