Wasm runtime: make resuming continuations more efficient

[vouillon]

This was done in #1765 for the JavaScript runtime.
See corresponding OCaml PR ocaml/ocaml#12735

fix #1779

[hhugo]

@OlivierNicole, Would you be able to review this PR ?

[hhugo]

I used the deep_state benchmarks and show the following improvement

compile the bench with:

WASM_OF_OCAML=true dune build  compiler/tests-jsoo/lib-effects/deep_state.bc.wasm.js --profile with-effects

before:

$ time node _build/default/compiler/tests-jsoo/lib-effects/deep_state.bc.wasm.js 128 500_000
Running deepstate: depth=128 ops=500000

real	0m6,003s
user	0m5,980s
sys	0m0,033s

after:

$ time node _build/default/compiler/tests-jsoo/lib-effects/deep_state.bc.wasm.js 128 500_000
Running deepstate: depth=128 ops=500000

real	0m2,359s
user	0m2,342s
sys	0m0,025s

stack switching is however very slow

$ time node --experimental-wasm-stack-switching _build/default/compiler/tests-jsoo/lib-effects/deep_state.bc.wasm.js 128 500_000
Running deepstate: depth=128 ops=500000

real	1m11,467s
user	1m11,388s
sys	0m0,122s

[vouillon]

stack switching is however very slow

Yes, that's expected. It goes through the JavaScript event loop for each stack switch.

[hhugo]

stack switching is however very slow

Yes, that's expected. It goes through the JavaScript event loop for each stack switch.

Should the doc/readme say something about this ?

[vouillon]

Should the doc/readme say something about this ?

We have this at the moment:

js_of_ocaml/manual/wasm_overview.wiki

Line 56 in 55c6228

The CPS transformation is not the default since the generated code is slower, larger and less readable. On the other hand, the JSPI extension is not yet enabled by default in Web browsers, and performing effects is slower when using this extension.

[hhugo]

I didn't review the wat diff but the CI is happy. @vouillon, I'll let you decide whether to merge now or wait for more review

[OlivierNicole]

@OlivierNicole, Would you be able to review this PR ?

I am swamped for now, but maybe I can start on Friday.

[OlivierNicole]

From a high level point of view, I’m not sure to understand why this change affects %perform and %reperform, while ocaml/ocaml#12735 only affected %resume. There was also code shared between perform and reperform (in line with the native and bytecode backends) that this PR seems to remove, and I’m not sure to understand why.

[OlivierNicole]

I’m happy to review this PR but I reiterate that to do that I would need a high-level description of the change, otherwise I don’t have enough context, and figuring it out by myself is going to take forever. Visibly ocaml/ocaml#12735 is not the whole story.

[vouillon]

You can have a look at #1765 and #1891.

We have some changes to make in perform/reperform since we were storing the fibers in reversed order in the continuation. They were already stored in the right order in the OCaml runtime. Also, we need to store the tail of the stack in the continuation.

Separating perform and reperform also allows some simplifications regarding unhandled effects: for perform, we can just raise the exception right away, and for reperform, we can resume the continuation with an exception. One no longer needs to put a default handler at the top of the current stack.

[OlivierNicole]

Thanks, this looks good to me.

Do we have an effects benchmark to assess the impact of this PR?

[vouillon]

Do we have an effects benchmark to assess the impact of this PR?

@hhugo did some measurements.

[OlivierNicole]

Oh, sorry, I had scanned through this message but for some reason thought it was on the other PR (the Javascript runtime one).