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

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.

Which benchmark did you use?

Did I understand correctly that the native code was compiled without optimization? Meaning “-O0”?

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.

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

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.

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

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.

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.

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.

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

Interesting. Would the differences in binary sizes be prohibitive for use on the internet?

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

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