ocaml
ocaml copied to clipboard
ocaml
Soften the 5.0 cautionary README note
Extracted from #13389. 5.3 is essentially at feature parity with 4.14 - my impression is that while there are various performance issues in flight, that we're not particularly less stable (in the segfaults and other random crashes department) than 4.14?
I propose a switch of tone in the cautionary note, therefore - the "TL;DR" which I'm going for is "If you're writing a new project, you should use OCaml 5; if you're maintaining an existing project, you should be evaluating OCaml 5 and reporting performance issues as a matter of priority.".
Your new proposal does not say that there are various performance issues in flight. I think it would be reasonable to say so explicitly, somewhere in your new paragraph. What about something like the following? (Feel free to change.)
Most OCaml programs are as fast or faster with OCaml 5, but we occasionally find some programs whose performance are degraded by the new runtime, and we are working on fixing these performance regressions.
Most OCaml programs are as fast or faster with OCaml 5
FWIW this does not match our experience with OCaml 5 at Jane Street. Most programs are measurably slower with OCaml 5.
Most programs are measurably slower with OCaml 5.
Then please do what @dra27 suggests in this PR, namely report those performance issues with concrete examples and repro cases. Some design decisions in OCaml 5 are known to cause minor slowdowns w.r.t. OCaml 4 (supporting parallelism has inherent performance costs), but other slowdowns may be accidental and fixable, so please help us do so like @dra27 writes.
Most OCaml programs are as fast or faster with OCaml 5, but we occasionally find some programs whose performance are degraded by the new runtime, and we are working on fixing these performance regressions.
We don't really know which programs are faster / as fast / slower with 5 than with 4, so this is too specific. I prefer @dra27's original formulation, "try OCaml 5 and if you find it too slow, let us know".
I would also prefer to go with @dra27's original wording.
There are known performance issues, such as GC pacing, memory model-related performance slowdowns, and slowdowns with Gc.stat.
Since as @kayceesrk commented there are known performance regressions, maybe it would be useful to tag them on GitHub and provide a link in the README pointing to the reported & known regressions?
I have been tagging issues and PRs with performance label to track these regressions. But the label is used not just for regressions from 4 to 5.
No one likes my proposed additions to the changes of @dra27 ! Don't worry, I'll get over it, I propose to go ahead and merge.
Ah, apparently there is a conflict which needs fixing (probably with @dra27's own changes in the other PR).
As discussed at ICFP with @kayceesrk (before I had time to comment on this PR), I think that the possible changes to the FFI for the OCaml-C memory model issues is important for programmers to expect. As the previous message mentioned stability, this can also rightfully concern the stability of APIs.
