5 ms·

[2019] Author builds a compiler that _targets_ WebAssembly, not a compiler that _takes in_ WebAssembly. Interesting but I was hoping for the other side, a minim

[2019] Author builds a compiler that _targets_ WebAssembly, not a compiler that _takes in_ WebAssembly. Interesting but I was hoping for the other side, a minimal AOT or JIT wasm --> machine code compiler.

danielvaughn 3y ago
Isn’t one of the main selling points of WASM it’s runtime performance? I’d be surprised if there was interest in a JIT compiler for it.
- disintegore 3y ago
  For 99% of us that's just an implementation detail anyway. Although I remember reading that Firefox can compile wasm faster than normal network transfer rates so maybe AOT makes more sense there.
  - IainIreland 3y ago
    We do streaming baseline compilation as fast as the network can hand us bytes, but we also kick off a more optimized compilation in a background thread. A lot of optimizations can be baked into the generated wasm, but you still need to spend some time doing eg register allocation.
    - kouteiheika 3y ago
      > A lot of optimizations can be baked into the generated wasm, but you still need to spend some time doing eg register allocation. Such a shame WASM is a stack machine. If it wasn't we could have had fast, singlepass compilation with near native performance without any complex optimizing recompilers or multi level JITs. (This is not speculation. I actually wrote a VM which executes code as fast as wasmtime but compiles 160 times faster and guarantees O(n) compilation.)
      - disintegore 3y ago
        Interesting. Would the differences in binary sizes be prohibitive for use on the internet?
        kouteiheika 3y ago
        > Would the differences in binary sizes be prohibitive for use on the internet? No. They are competitive. For one of my benchmarks I get a WASM blob that is 90KB, and for my VM I get 76KB. (Both are stripped of any debug info.)
- flohofwoe 3y ago
  At least in Chrome, WASM is actually jitted and "tiered" on function level. Not sure how relevant this post still is, but AFAIK if anything changed then that the number of tiers has increased rather than decreased: https://v8.dev/docs/wasm-compilation-pipeline https://v8.dev/docs/wasm-compilation-pipeline This may actually introduce visible "warmup-stutter" in rendering applications which is very unfortunate, but AFAIK the tiering was introduced to accommodate massive WASM blobs such as created by Unity which otherwise might take tens of seconds to AOT-compile.
  - tsegratis 3y ago
    Maybe something like signed compilations is an answer -- a trusted source signs and verifies pre-compiled code Then browsers can skip verification+jit etc if they trust the signature
    - AgentME 3y ago
      You could use zero-knowledge proofs to prove that a given native binary was created from a specific compilation process and WASM binary. No privileged trusted authority necessary. Though any pre-compiled binaries would be browser version specific and CPU architecture specific, so it might be too much of a pain for browsers and websites to bother with yet for small gains.
deleted 3y ago
[deleted]
Rochus 3y ago
Here is what you are looking for: https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime
- OmegaMetor 3y ago
  Works very well. I compiled the same c++ code to wasm and native (without optimization), the native version was slower than the wasm one running in this and jit'd, including startup time. Planning on using it for scripting for a game engine I'm slowly working on, instead of being locked into one language.
  - Rochus 3y ago
    Which benchmark did you use?
  - schemescape 3y ago
    Did I understand correctly that the native code was compiled without optimization? Meaning “-O0”?
jedisct1 3y ago
For AOT, the simplest approach, that actually produces the fastest native code, is to naively translate WASM opcodes to C. This is for example what W2C2 does: https://github.com/turbolent/w2c2 https://github.com/turbolent/w2c2

danielvaughn 3y ago

Isn’t one of the main selling points of WASM it’s runtime performance? I’d be surprised if there was interest in a JIT compiler for it.

disintegore 3y ago
For 99% of us that's just an implementation detail anyway. Although I remember reading that Firefox can compile wasm faster than normal network transfer rates so maybe AOT makes more sense there.
- IainIreland 3y ago
  We do streaming baseline compilation as fast as the network can hand us bytes, but we also kick off a more optimized compilation in a background thread. A lot of optimizations can be baked into the generated wasm, but you still need to spend some time doing eg register allocation.
  - kouteiheika 3y ago
    > A lot of optimizations can be baked into the generated wasm, but you still need to spend some time doing eg register allocation. Such a shame WASM is a stack machine. If it wasn't we could have had fast, singlepass compilation with near native performance without any complex optimizing recompilers or multi level JITs. (This is not speculation. I actually wrote a VM which executes code as fast as wasmtime but compiles 160 times faster and guarantees O(n) compilation.)
    - disintegore 3y ago
      Interesting. Would the differences in binary sizes be prohibitive for use on the internet?
      - kouteiheika 3y ago
        > Would the differences in binary sizes be prohibitive for use on the internet? No. They are competitive. For one of my benchmarks I get a WASM blob that is 90KB, and for my VM I get 76KB. (Both are stripped of any debug info.)
flohofwoe 3y ago
At least in Chrome, WASM is actually jitted and "tiered" on function level. Not sure how relevant this post still is, but AFAIK if anything changed then that the number of tiers has increased rather than decreased: https://v8.dev/docs/wasm-compilation-pipeline https://v8.dev/docs/wasm-compilation-pipeline This may actually introduce visible "warmup-stutter" in rendering applications which is very unfortunate, but AFAIK the tiering was introduced to accommodate massive WASM blobs such as created by Unity which otherwise might take tens of seconds to AOT-compile.
- tsegratis 3y ago
  Maybe something like signed compilations is an answer -- a trusted source signs and verifies pre-compiled code Then browsers can skip verification+jit etc if they trust the signature
  - AgentME 3y ago
    You could use zero-knowledge proofs to prove that a given native binary was created from a specific compilation process and WASM binary. No privileged trusted authority necessary. Though any pre-compiled binaries would be browser version specific and CPU architecture specific, so it might be too much of a pain for browsers and websites to bother with yet for small gains.

deleted 3y ago

[deleted]

Rochus 3y ago

Here is what you are looking for: https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime

OmegaMetor 3y ago
Works very well. I compiled the same c++ code to wasm and native (without optimization), the native version was slower than the wasm one running in this and jit'd, including startup time. Planning on using it for scripting for a game engine I'm slowly working on, instead of being locked into one language.
- Rochus 3y ago
  Which benchmark did you use?
- schemescape 3y ago
  Did I understand correctly that the native code was compiled without optimization? Meaning “-O0”?

jedisct1 3y ago

For AOT, the simplest approach, that actually produces the fastest native code, is to naively translate WASM opcodes to C. This is for example what W2C2 does: https://github.com/turbolent/w2c2 https://github.com/turbolent/w2c2