Same code, rust & wasm-bindgen version is 2x slower than c++ & emscripten
dtysky opened this issue · 3 comments
Describe the Bug
I have ported gl-matrix to wasm by using rust and wasm-bindgen, and do some tests for three versions: js, rust-wasm and cpp-wasm.
After many reliable tests for 'matrix4-multiply', I finally find that the c++ version(emscripten o3) is 2x faster than rust version(wasm-bindgen release mode, binaryen.js o2).
Then I begin to find the reason and finally makes some guesses about wast files:
As these code shown, in cpp version, wasm access the memory in a linear, continuous and increased way, but in rust version, wasm access memory randomly.
I think it's the main reason that rust version is so slow.
Expected Behavior
Optimize complier to make wasm code is as fast as c++ version.
Is my guess right? Are we having any idea to solve it?
Thanks.
Thanks for the report! I'm personally no expert in profiling wasm generated by different compilers much less profiling the internals of a wasm function in barious engines. Regardless though this definitely looks like an issue for the LLVM WebAssembly backend rather than the wasm-bindgen repository since we're pretty far separated from generating this code.
Mind opening a bug at https://bugs.llvm.org/ to raise the issue there since this seems like it's an issue with the WebAssembly LLVM backend?
Are there any ways to know the flow that rust files to warm file by wasm-bindgen? I think also emscripten uses llvm bankend as same as wasm-bindgen, I can't understand this problem and need more details.
I believe with emscripten it depends quite a lot on configuration settings to determine what actually is producing the wasm file. One option is the LLVM backend, but the other option is the normal asm.js route plus a asm-to-wasm conversion pass. I don't believe the LLVM backend is on by default.
For Rust and this case here it's simply LLVM. We feed LLVM IR and it spits out wasm.