[HN Gopher] Adapting the OCaml Ecosystem for Multicore OCaml
       ___________________________________________________________________
        
       Adapting the OCaml Ecosystem for Multicore OCaml
        
       Author : rbjorklin
       Score  : 106 points
       Date   : 2021-08-31 20:26 UTC (13 hours ago)
        
 (HTM) web link (watch.ocaml.org)
 (TXT) w3m dump (watch.ocaml.org)
        
       | Zababa wrote:
       | A nice detail: this video is hosted on the new OCaml website
       | (https://v3.ocaml.org/en), which includes its own peertube
       | instance.
        
       | niralnetworks wrote:
       | Control your fleet and the staff in real-time with the best fleet
       | management solutions from Trakiga, managing School Bus, Cabs and
       | trucks https://www.trakiga.com/fleet-management/
        
       | dwohnitmok wrote:
       | What's the OCaml community's perception on when multicore will
       | fully land in trunk?
        
         | yawaramin wrote:
         | A few myears. Maybe a few yonths.
        
           | [deleted]
        
         | rbjorklin wrote:
         | My understanding is that 4.14 is scheduled for Q1 2022 and 5.0
         | with multicore _might_ be released roughly in parallel.
        
           | amelius wrote:
           | Are there any benchmarks? Comparisons to other multicore
           | runtimes, like GoLang's?
        
             | sadiq wrote:
             | Our paper from ICFP last year has extensive benchmarks
             | against stock OCaml: https://arxiv.org/abs/2004.11663
             | 
             | In short there should be very little performance difference
             | against stock.
             | 
             | As KC has linked in a sibling comment there's a project
             | going to explore using effects to write high performance IO
             | libraries and that has some early benchmarks.
        
             | Zababa wrote:
             | 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
        
             | kcsrk wrote:
             | We don't compare against Go pervasively. Benchmarking
             | across languages is hard generally, but here is a result on
             | a specific benchmark comparing several versions of OCaml
             | benchmarks against Go and Rust on a Http server benchmark:
             | https://github.com/ocaml-multicore/retro-httpaf-
             | bench/pull/1....
             | 
             | If there are suggestions to make the Go and Rust versions,
             | please feel free to tell us how in the issue tracker.
        
             | yawaramin wrote:
             | Yes, check out https://watch.ocaml.org/videos/watch/playlis
             | t/7a4ad26a-b8c5-... for some interesting comparisons.
        
           | yawaramin wrote:
           | Heh.
        
       | dmitriid wrote:
       | > 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 with
       | these concerns as an afterthought.
        
         | rkangel wrote:
         | > 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 was
         | designed for concurrency on a single core, but when SMP
         | processers appeared all it needed was a VM change that was
         | completely transparent to the programs above it and suddenly
         | all Erlang programs were extremely parallel!
        
       ___________________________________________________________________
       (page generated 2021-09-01 10:01 UTC)