3 ms·

It seems like it would be easier to make a WebAssembly front end rather than MIR. Just compile rust to WASM and use GCC compile to unusual instruction sets. The

It seems like it would be easier to make a WebAssembly front end rather than MIR. Just compile rust to WASM and use GCC compile to unusual instruction sets. There might be a small performance hit, but the WASM frontend could be likely be upstreamed into GCC. Why was MIR chosen instead of WASM?

pornel 7y ago
WASM is designed for a particular sandbox environment, which currently is 32-bit-only. AFAIK WASM has its own calling conventions and sections, so recompilation back to something that works with platform-specific C would involve difficult guesswork or glue code. MIR is Rust's accurate low-level representation with much more type information, and it's aware of native target's specification, so it can be optimized better, and has better interoperability with native code.
- 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...

pornel 7y ago

WASM is designed for a particular sandbox environment, which currently is 32-bit-only. AFAIK WASM has its own calling conventions and sections, so recompilation back to something that works with platform-specific C would involve difficult guesswork or glue code. MIR is Rust's accurate low-level representation with much more type information, and it's aware of native target's specification, so it can be optimized better, and has better interoperability with native code.

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...