Wasm_of_ocaml runtime file

[vouillon]

No description provided.

[rgrinberg]

Is there a way to test this PR perhaps?

[OlivierNicole]

With the following diff, one can test by running WASM_OF_OCAML=true dune build @runtest-wasm:

diff --git a/dune-workspace b/dune-workspace
new file mode 100644
index 0000000000..a9b4271989
--- /dev/null
+++ b/dune-workspace
@@ -0,0 +1,9 @@
+(lang dune 3.17)
+
+(env
+ (_
+  (wasm_of_ocaml
+   (enabled_if %{env:WASM_OF_OCAML=false})
+   (runtest_alias runtest-wasm))
+ )
+)
diff --git a/lib_test/dune b/lib_test/dune
index 48789f33a1..789dea0184 100644
--- a/lib_test/dune
+++ b/lib_test/dune
@@ -1,4 +1,5 @@
 (test
  (name test_bigstringaf)
  (libraries alcotest bigstringaf)
- (modules test_bigstringaf s))
+ (modules test_bigstringaf s)
+ (modes exe wasm))

Currently, this fails with

test_bigstringaf.bc.wasm.js: internal error, uncaught exception:
                             Failure("Error: caml_unix_mkdir not implemented")

presumably because upstream alcotest doesn’t support Wasm yet? (Although I see that there is some work from @vouillon in this direction: https://github.com/ocaml-wasm/alcotest/tree/wasm)

[adrien-n]

Hey,

First, thanks a lot for the work. I've built my project as wasm and found the runtime got multiplied by 5 or so in firefox (I can't tell for chrome for the moment).

The hottest spot is memchr but that's also the bigstringaf function I'm using the most. The profile looks like the following:

I'm not very familiar with wasm but the callstack seems much deeper than I had expected. Is it indicative of an issue with the PR? Or maybe me doing something wrong?

If you want to reproduce this, I've hosted the page at https://notk.org/~adrien/traceboot . You'll need to first download an example input file such as https://notk.org/~adrien/traceboot/trace-2.txt (it's 167MB but the server gzip compression should make it 35 times smaller on the wire) . Processing without profiling takes around 15 second on my laptop from a few years ago.

[OlivierNicole]

Thanks for the report and repro case!

@vouillon Maybe something is not behaving as expected with DataViews?

[vouillon]

@adrien-n Could you try this PR: ocsigen/js_of_ocaml#2144.

Bigarrays use a JavaScript ArrayBuffer for their underlying storage. While this isn't the most performant option, it offers better interoperability by providing a reasonably efficient way to manipulate JavaScript typed arrays.

Accessing bigarrays requires calling JavaScript functions. Wasm engines can recognize certain JavaScript functions and generate optimized code for them. For methods, engines have converged on recognizing imports of the form Function.prototype.call.bind(DataView.prototype.getUint8). However, when the engine doesn't optimize these imports, calling them is much slower than calling a simple wrapper like (x, y, z) => x.getUint8(y, z). I'm primarily optimizing for V8, which recognizes DataView primitives and generates inline code for them, something other engines don't yet support.