An update from the ocaml-wasm organization

[jmid]

Summer and ICFP has passed since we announced the ocaml-wasm organization in July. Here we provide an update from the wasocaml and wasm_of_ocaml compiler projects since then.

Introduction

WebAssembly (Wasm) is an attractive compilation target for OCaml, as it holds promises of better web-performance than compiling to JavaScript and furthermore opens up for running OCaml on new platforms. The ocaml-wasm organization is a joint effort between two Wasm-targeting compiler projects for OCaml:

• wasocaml - an FLambda-based backend for OCaml’s native code compiler
• wasm_of_ocaml - a fork of js_of_ocaml that consumes OCaml bytecode and emits Wasm instead of JavaScript

Both compilers depend on the proposed garbage collection (GC) extension to Wasm, which is available behind a flag in development versions of Chrome, Firefox, and Node.js. As a first news item, we are excited to share that the Wasm GC proposal has moved to stage 4. As a consequence Chrome is planning to enable the WasmGC extension in version 119, scheduled to release in November!

wasocaml

• @chambart presented wasocaml at the ML workshop in Seattle in early September in connection with ICFP’23
  • Here’s a video link to the recorded presentation
  • The slides and the workshop paper are available from this page with more details about the compiler
• After having benchmarked wasocaml, it was noticed that V8 exceptions are too slow right now. The OCaml exception compilation strategy has been changed to avoid using the native Wasm ones for now. This will be turned back into proper Wasm exceptions when the engines improve.

wasm_of_ocaml

@vouillon has made solid progress on implementing run-time bindings, which means that
wasm_of_ocaml can now

• compile ocamlc itself into Wasm
• run the Bonsai tests and examples

Early benchmarks results are encouraging: Compiled programs typically run around 10-20% faster compared to the js_of_ocaml equivalent.

A more detailed status:

• Lots of runtime bindings have been implemented
  • for even more parts of the OCaml Stdlib: bigarrays, weak pointers, ephemerons, marshaling/unmarshaling
  • for external packages: base, core, ppx_expect, ppx_inline_test, time_now, incr_dom, alcotest, base_bigstring, core_kernel, string_dict, bigstringaf, js_of_ocaml_patches, ocaml-cstruct, Zarith
• A number of PRs to get Wasm_of_ocaml supported:
  • in dune ocaml/dune#8278
  • in gen_js_api LexiFi/gen_js_api#173
  • in Brr dbuenzli/brr#51 and
  • to improve the js_of_ocaml-wasm_of_ocaml compatibility ocsigen/js_of_ocaml#1492
• It is now possible to include JavaScript runtime files and to use JavaScript primitives from Wasm runtime code, reusing the js_of_ocaml linker.
• Implemented Effect support through CPS transformation for comparison with the current JS promise integration implementation
• Updates contributing to the on-going Wasm GC ecosystem development:
  • Make the legacy parser follow more closely the standard GC text format WebAssembly/binaryen#5889
  • Update stringref text format WebAssembly/binaryen#5891
  • Use the standard syntax for ref.cast, ref.test and array.new_fixed WebAssembly/binaryen#5894
  • Fixed a V8 crash https://chromium-review.googlesource.com/c/v8/v8/+/4660286
    and implemented a workaround in binaryen tools WebAssembly/binaryen#5799
  • Fixed the binaryen linker wasm-merge to support exporting an imported module entry WebAssembly/binaryen#5813

[zapashcanon]

Please note that Wasocaml was also presented at IFL’23. (I could have tell you if you asked before doing the announce )

(Also it’s Flambda not FLambda)

[kayceesrk]

@zapashcanon

I could have tell you if you asked before doing the announce

Hi @zapashcanon, the announcement has been read and approved by one of your PhD advisors @chambart who is working with you closely on the wasocaml project. We would be happy to share a draft of the subsequent announcements with you so that you can incorporate your changes.

[chambart]

Hum yes sorry @zapashcanon I didn’t notice that… Oups

[Yaron_Minsky]

Is there any news on how wasocaml and wasm_of_ocaml compare to each other in performance?

I’m also curious how people think about the 10-20% improvement for wasm_of_ocaml over js_of_ocaml. I’m not sure whether to be disappointed in the former or impressed about the speed of the latter!

y

[jmid]

I don’t know of such a comparison, sorry.

I suspect wasocaml’s Flambda-based optimizations to be a clear win in some cases and wasm_of_ocaml’s whole-program mode to win in other cases.

Note: the 10-20% is a rough average covering a lot of variation of everything from no improvement to speed-ups of up to 50-66% in the best cases.
There has been no effort to optimize the JavaScript interface yet, so performance is likely to improve.

[vouillon]

I get a 30% performance improvement for both ocamlc and the CAMLBOY benchmark. I think @jmid was mostly commenting on the Bonsai benchmarks, where we observe a 40% to 50% performance improvement for some benchmarks but no improvement for others.