Same code, rust & wasm-bindgen version is 2x slower than c++ & emscripten

[dtysky]

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.

source-cpp
source-rust

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:

wast-cpp
wast-rust

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.

[alexcrichton]

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?

[dtysky]

@alexcrichton

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.

[alexcrichton]

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.