WASM optimizations

[Gaurav Dewan]

Are there methods to optimize these calls out of wasm (change code or use compiler options or add to webassembly)

(1) f64 to int - there is pattern (promote f64, and call 50 - f64 to int outside wasm)  - BINARYEN imprecise option is removed. I see this is the only asm-wasm imports getting called in my application.

https://github.com/kripken/emscripten/issues/4885

I am using default trap mode(not specifying anything).BINARYEN_IMPRECISE is not present in new toolchain versions.

(2) emscriptenmemcpy_big with 32768 bytes - is it some performance technique or necessary evil ?

(3) clock_get_time - perhaps there is no wasm instructions for this.

Chrome devtools profiler does not seem to profile inside wasm for performance(it just shows it as a monolithic blackbox) - only calls out to js are shown. Same with JS profiler tabs (although debugger is able to disassemble wasm). 

Has FF nightly started WASM debugging and profiling now ?

I remember seeing a snapshot of profiler with fast trampoline (calls from wasm to asm.js are shown) somewhere.

(4) Shadow stack - If application is taking address of local variable, wasm size can increase due to shadowing. Does it mean that even if I take address of a local variable in just one function, the application will always maintain the shadow stack ? Or does it increase proportionally with such instances ?

How can I spot such pattern in my application ?

Thanks

[Alon Zakai]

1. The "imprecise" flag was replaced by the "trap mode" flag. if you left it as "allow" (the default) then there should be no ffi calls to imports for f64 to int etc. Perhaps you are hitting a bug, do you have a testcase showing the issue?

2. memcpy_big uses tricks in JS for fast memcopying of large amounts of bytes. It's not necessary, just an optimization (you can remove it from src/library.js if you don't want it).

3. Yes, wasm has no way to interact with the outside, except for calls to imports. So getting the time must be done by JS on the outside.

I see individual wasm functions in Firefox nightly profiling. (Make sure to use latest emscripten incoming when building for profiling, as the wasm spec changed.)

4. If you take the address of a local variable, we store it on the C stack, in linear memory. But that shouldn't increase the wasm binary size, except that it takes a few more instructions to handle the stack and to read and write such a local. Usually this is negligible.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gaurav Dewan]

I see f64 to int callback to js is fixed in latest emscripten.
But unfortunately we are using emscripten 1.37.3 and unable to upgrade because of huge performance loss due to inlining strategy even after llvm lto.
Any way we can port that fix to older version by cherry picking?

[Alon Zakai]

I don't think it would be easy to cherry-pick that, as there are other changes in asm2wasm all the time. It's possible, though. But I'd recommend focusing on investigating the inlining performance loss on your project, that should be figured out and fixed as using an older version will become less good over time. Also it is possible that if it's an LLVM upstream issue, that it'll be fixed next time we update LLVM (which might be soon).