2 ms·
I agree with you that there would be glue code and I don't doubt your right that MIR can be optimized more. But rust in the general case is agnostic about 32 v
by Avi-D-coder 7y ago
I agree with you that there would be glue code and I don't doubt your right that MIR can be optimized more.
But rust in the general case is agnostic about 32 vs 64 bit pointers and explicitly targets WASM.
I'm not familiar with GCC's IR, but unsandboxed AOT WASM compiled thru LLVM IR is astoundingly fast.
> This average benchmark has speed in microseconds and is compiled using GCC -O3 –march=native on WSL. “We usually see 75% native speed with sandboxing and 95% without. The C++ benchmark is actually run twice – we use the second run, after the cache has had time to warm up. Turning on fastmath for both inNative and GCC makes both go faster, but the relative speed stays the same”, the official website reads.
> “The only reason we haven’t already gotten to 99% native speed is because WebAssembly’s 32-bit integer indexes break LLVM’s vectorization due to pointer aliasing”, the WebAssembly researcher mentions. Once fixed-width SIMD instructions are added, native WebAssembly will close the gap entirely, as this vectorization analysis will have happened before the WebAssembly compilation step.
https://hub.packtpub.com/introducing-innative-an-aot-compiler-that-runs-webassembly-using-llvm-outside-the-sandbox-at-95-native-speed/ https://hub.packtpub.com/introducing-innative-an-aot-compile...