With the convergence between the multicore and standard runtime across OCaml 4.10.0 to 4.13.0 [ 6 ], the development of OCaml multicore has reached a point where further integration into OCaml’s main branch requires fully committing to a switch to OCaml multicore. The OCaml team has decided that the …

How does flambda 2 fit in this plan? I greatly appreciate all the updates regarding multicore and it would be great to know about the status of flambda 2 and when it looks to get merged to the trunk…How impacted is it, if at all, by the upcoming glaciation? When does warming begin for it? :wink:

Flambda 2 is in the situation that Multicore was in a few years back: it’s being developed on the side, and it’s not ready for serious discussion about upstreaming yet. You can track our progress here: [image] GitHub - ocaml-flambda/flambda-backend: The Flambda backend project for OCaml …

And, I should add: Jane Street’s intent to upstream our work is not the same as upstream’s intent to accept it. None of what I’ve said is an announcement on behalf of the core OCaml team, nor am I in any position to make such an announcement!

[image] octachron: x86-64 Is that reasonable? Especially as ARM64 is a major platform now for macOS. At work we’re using OCaml Multicore to offloading some heavy data which cannot be just serialized and not having support for ARM64 is by far the biggest developer problem that we end up having…

[image] EduardoRFS: Is that reasonable, especially as ARM64 is a major platform now for macOS. A minimum viable product is just that – the minimum needed to get going, and the set of [x86_64] is smaller than the set of [x86_64|aarch64]. Having said that, several developers have expressed a de…

Great news :slightly_smiling_face: What decision has been made about the read-barrier (yes or not) for mutable record fields ?

Your response makes sense. However, adding x86-64 and aarch64 simultaneously may ensure that the specific implementation strategy (and performance numbers you get) are not the artifact of special techniques or tricks available only on the intel platform but generalize on all mainstream hardware plat…

[image] octachron: While OCaml 5 is stabilising, we plan to extend the support period for OCaml 4.14 by publishing minor bugfix releases whenever needed. In particular, OCaml 4.14 will be supported until all tier-1 architectures and operating systems are available in OCaml 5, and OCaml 5 sequent…

How does upstream plan to prevent a Python 2/3 Perl5/6 situation with that? I don’t think this situation is comparable with Python 2/3. This is somewhat similar to the Scala 2.x/Scala 3 debate that is going on on the internet – people are seeing shades of the Python 2/3 debacle in that too. If f…

What decision has been made about the read-barrier (yes or not) for mutable record fields ? Multicore now uses a parallel minor collector rather than the older concurrent minor collector. One of the main reasons for this change is that it doesn’t need a read barrier and so preserves the C API. T…

The road to OCaml 5.0

Ecosystem

octachron October 15, 2021, 4:43pm 19

No, the aim is to keep 5.0 small and focused on the multicore runtime.

We might remove some deprecated API, in particular in the internal runtime API, but that’s all the planned changes.

Topic		Replies	Views
Multicore OCaml: Dec 2020 / Jan 2021 Community multicore , multicore-monthly	6	3658	February 8, 2021
Multicore OCaml: January 2022 and post-merge activity Community multicore , multicore-monthly	7	3876	February 14, 2022
OCaml 5.0.0 is out! Ecosystem	7	35897	January 10, 2023
Multicore OCaml: March 2021 Community multicore , multicore-monthly	9	5958	April 20, 2021
Multicore OCaml: October 2021 Community multicore , multicore-monthly	0	9003	November 16, 2021

The road to OCaml 5.0

Related topics