- Where: zoom.us
- When: January 10, 5pm-6pm UTC (January 10, 9am-11am Pacific Time)
- Location: link on calendar invite
None required if you've attended before. Fill out the form here to sign up if it's your first time: https://forms.gle/JehrAB4gWbtHjybt9. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Presentation: OCaml on WasmGC (Pierre Chambart and Léo Andrès, 60 min)
- Closure
- Thomas Lively
- Pierre Chambart
- Leo Andres
- Alon Zakai
- Ryan Hunt
- Ilya Rezvov
- Zalim Bashorov
- Francis McCabe
- Slava Kuzmich
- Asumu Takikawa
- Jakob Kummerow
- Manos Koukoutos
- Luke Wagner
- Emanuel Ziegler
- Dmitry Bezhetskov
- Adam Klein
- Deepti Gandluri
- Jean-Christophe Filliatre
- Ioanna Dimitriou
PC presenting slides
PC: There are two OCaml compilers: native and bytecode. We control both completely and we control the GC completely, but making changes is hard. Lots of polymorphism and low-level utilities users use to examine values. Users also depend heavily on the GC. Users expect exceptions to be fast.
PC: Js_of_ocaml compiles the untyped bytecode to JS, which works fine because JS is untyped. But we want to target WasmGC because it will have slightly better performance than compiling the GC to Emscripten, and it has much better interop with external values.
FM: Are you planning to use i31?
PC: Yes, we’re using it everywhere.
TL: How long were the subtyping chains you were seeing?
PC: The size of the largest block. Could reduce it, but it would be difficult. Top level modules are blocks and tend to be quite large. The alternative to using structs is to use arrays of fields, but we statically know all the indices, so using structs is better.
TL: Will it be hundreds or thousands?
PC: Hundreds mostly, but a few libraries will have thousands. For example one library that exports a separate value for each unicode code point. We can do something special for those strange cases.
PC: Must use mutable values because many things can be cyclic.
PC: Have a special representation for float arrays to avoid boxing, but it requires some extra dynamic checks.
FM: What kind of strings are these?
PC: Strings are byte arrays. Some specific libraries additionally validate that the strings are valid unicode.
FM: What about when you want to interop with JS or DOM, etc?
PC: The JS compiler has a lot of problems there because it has to keep both representations. It uses memoization to try to avoid going back and forth a lot.
PC: Have different function types for different arities, they all take Env arguments. Won’t need function subtyping anywhere. Different code paths for currying or when there is the exact right number of arguments. Avoiding partial applications can avoid allocating intermediate closures. The compiler is good at optimizing this.
PC: GADTs, where the output type depends on some input value, is basically impossible without a uniform representation.
TL: To clarify, you are using Wasm exceptions, but just with a single tag covering every OCaml exception?
PC: Yes.
FM: wasocaml is still slower than js_of_ocaml?
PC: Yes, on this simple fibonacci example, but for larger tests and applications we’re already quite faster than js_of_ocaml. Compiling to JS is generally good, but bad cases are very bad (40x slower than native in real examples).
TL: Will this work be upstreamed to OCaml or will it stay separate?
PC: Too early to tell. If it’s very compatible with the entire language, then we might be able to upstream it, but it would take a while.
AK: Do you have examples of users using OCaml on the Web today with the JS or Wasm versions?
PC: There are a few companies using js_of_ocaml. There is some social network stuff and some graphical interfaces. Jane Street uses it a lot. They generate a lot of code that is too much for the JS JIT compiler.
LA (chat): https://jscoq.github.io/scratchpad.html same for Why3 and alt-ergo
FM: Have you looked at using JSPI to help implement effect handlers?
PC: Not sure promises are sufficient. Maybe with CPS as well?
FM: The idea is that the internal code would not be CPS transformed. The promise only appears on the Wasm-JS boundary.
TL: Some other language is using JSPI to implement async things, right?
FM: Right, Dart is using it to implement generators and async functions, although not efficiently.
PC: You need to be in the JS world in order to use it?
FM: Yes, it’s only in V8 right now, but it is standards track.
FM: What kind of applications do you see using OCaml on the Web?
PC: Same as what’s using js_of_ocaml now. The Wasm compiler is a big improvement over js_of_ocaml.
FM: Do you see OCaml being used with Wasm outside the browser?
PC: Yes, I think it already works with Cloudflare. It would also be good to see the OCaml representation become the lingua franca between GC languages. For example calling between OCaml and Java requires a complicated hop through C. Using the OCaml representation would be nicer.
FM: That would require agreement between the OCaml and Java backends on what an object looks like.
PC: Yes, but you could also have a small WebAssembly module to do conversions.
AZ: Do you have any data on code size of the Wasm compared to JS?
PC: I think it’s smaller, but I’m not sure. Will have to look at that.
AZ: Can you run the Wasm reference interpreter in wasocaml?
PC: Probably not because we haven’t implemented all the primitives yet. But in principle there’s no reason we couldn’t.
IR: Have you compared performance to the melange compiler? (A ReasonML to JS compiler)
PC: It’s hard because the language isn’t quite compatible.
RH: Is there public code I could play around with as we develop features in SpiderMonkey?
PC: Things are in flux and hackish, so for now it’s probably best to ask me directly for a wat file.
AT: You mentioned that most of your instructions are casts. Have you seen this to be a bottleneck?
PC: Haven’t compared to a version without casts, so not sure about performance. Most of the casts should be easy for the engine because we cast directly to the exact runtime type. Blocks are an exception, but we might stick with arrays for those.
AT: Are these block casts common?
PC: Yes, very common.
TL: Are there code patterns that Binaryen could optimize but doesn’t?
PC: Unboxing boxed values would be a good candidate. It’s hard because the OCaml compiler already optimizes heavily and knows a lot about the language. Binaryen does a good job of optimizing locals. Sometimes we are going between i32 and i31. Optimizations would have to know about dropping bits being ok.
JK (chat): in V8, we have --experimental-wasm-assume-ref-cast-succeeds, which turns ref.cast into a no-op, so you can measure casting performance overhead for programs where you know that all casts succeed