6 ms·

Build your own WebAssembly Compiler (2019)

161 points by davikr 3y ago

ReactiveJelly 3y ago
[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
deleted 3y ago
[deleted]
ColinEberhardt 3y ago
Oh wow, really chuffed to see a blog post I wrote 4 years ago back on the front page of HN once again. It was a real rollercoaster, spending ages developing a talk, that I wasn't able to give due to a flight cancellation - then turning it into a blog post that lots of people seemed to like. Hard work pays off in the end :-)
- jwilber 3y ago
  Just letting you know: love the high-quality blogs you guys always write, especially the few on webgl!
Joker_vD 3y ago
(block (loop [loop condition] i32.eqz [nested statements] br_if 1 br 0) ) That's... not really the while loop, is it? That should've been something like this IMO (block (loop [loop condition] i32.eqz br_if 1 [nested statements] br 0) ) Honestly, WASM's "br"/"br_if" semantics is quite wacky: for a block "br"/"br_if" mean "break", and for a loop they mean "continue". I understand that they didn't want to have two separate opcodes which would only make sense in certain contexts but could we at least have gotten two mnemonics for them? Having "break/break_if" for targeting a block and "continue/continue_if" for targeting a loop would reduce some confusion and I don't think there are any difficulties in either assembling or disaseembling that. I've seen only about three toy-ish WASM interpreters and they all translate those unorthodox control flow instructions into something like goto's during the parsing stage. Why did the WASM authors did it this way, I don't know: it's just as well possible to give types to traditional asm-like GOTOs and labels.
- titzer 3y ago
  Structured control flow is more efficient to verify, more compact, and disallows irreducible loops by design. Also note that "br" "br_if" and "br_table" are all just text format mnemonics. You can think of the "br" as "branch" instead of break. We didn't have different instructions for branching depending on the type of the label because it's not necessary, just a waste of opcode space.
  - tomcam 3y ago
    I was hoping we’d have someone more qualified to answer this question, but whatever. Holy shit! https://news.ycombinator.com/user?id=titzer https://news.ycombinator.com/user?id=titzer I love this site
  - tsegratis 3y ago
    Well, more efficient to verify, because it is more restrictive Meaning some control flows are unrepresentable and certainly less compact; since they must be 'interpreted' I think that's probably the best decision for quick webpage loading, but given that WASM is generally used for code heavy webpages -- not quick jquery replacements, I'm not convinced it was the best decision overall -- I love a lot of wasm, I just wish it was a better target for open ended computation; which is something gotos and coroutines are better suited for That said; WASM is a clever trade off; but the trade-off is hidden within compilers (ref Go's wasm for instance)
crabmusket 3y ago
If you're interested in this, there's also https://wasmgroundup.com/ https://wasmgroundup.com/ currently in early access. I've worked through the first couple of chapters and found it pretty well structured and helpful.
- tomhallett 3y ago
  Thanks! I was looking for a wasm book a few weeks ago, and most looked (understandably) out of date. Very helpful! The frontend masters course by Jem Young was really good as well. https://frontendmasters.com/courses/web-assembly/ https://frontendmasters.com/courses/web-assembly/
dang 3y ago
Discussed at the time: Build Your Own WebAssembly Compiler - https://news.ycombinator.com/item?id=21889614 https://news.ycombinator.com/item?id=21889614 - Dec 2019 (19 comments)

161 points by davikr 3y ago

[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

deleted 3y ago

[deleted]

ColinEberhardt 3y ago

Oh wow, really chuffed to see a blog post I wrote 4 years ago back on the front page of HN once again. It was a real rollercoaster, spending ages developing a talk, that I wasn't able to give due to a flight cancellation - then turning it into a blog post that lots of people seemed to like. Hard work pays off in the end :-)

jwilber 3y ago
Just letting you know: love the high-quality blogs you guys always write, especially the few on webgl!

Joker_vD 3y ago

(block (loop [loop condition] i32.eqz [nested statements] br_if 1 br 0) ) That's... not really the while loop, is it? That should've been something like this IMO (block (loop [loop condition] i32.eqz br_if 1 [nested statements] br 0) ) Honestly, WASM's "br"/"br_if" semantics is quite wacky: for a block "br"/"br_if" mean "break", and for a loop they mean "continue". I understand that they didn't want to have two separate opcodes which would only make sense in certain contexts but could we at least have gotten two mnemonics for them? Having "break/break_if" for targeting a block and "continue/continue_if" for targeting a loop would reduce some confusion and I don't think there are any difficulties in either assembling or disaseembling that. I've seen only about three toy-ish WASM interpreters and they all translate those unorthodox control flow instructions into something like goto's during the parsing stage. Why did the WASM authors did it this way, I don't know: it's just as well possible to give types to traditional asm-like GOTOs and labels.

titzer 3y ago
Structured control flow is more efficient to verify, more compact, and disallows irreducible loops by design. Also note that "br" "br_if" and "br_table" are all just text format mnemonics. You can think of the "br" as "branch" instead of break. We didn't have different instructions for branching depending on the type of the label because it's not necessary, just a waste of opcode space.
- tomcam 3y ago
  I was hoping we’d have someone more qualified to answer this question, but whatever. Holy shit! https://news.ycombinator.com/user?id=titzer https://news.ycombinator.com/user?id=titzer I love this site
- tsegratis 3y ago
  Well, more efficient to verify, because it is more restrictive Meaning some control flows are unrepresentable and certainly less compact; since they must be 'interpreted' I think that's probably the best decision for quick webpage loading, but given that WASM is generally used for code heavy webpages -- not quick jquery replacements, I'm not convinced it was the best decision overall -- I love a lot of wasm, I just wish it was a better target for open ended computation; which is something gotos and coroutines are better suited for That said; WASM is a clever trade off; but the trade-off is hidden within compilers (ref Go's wasm for instance)

crabmusket 3y ago

If you're interested in this, there's also https://wasmgroundup.com/ https://wasmgroundup.com/ currently in early access. I've worked through the first couple of chapters and found it pretty well structured and helpful.

tomhallett 3y ago
Thanks! I was looking for a wasm book a few weeks ago, and most looked (understandably) out of date. Very helpful! The frontend masters course by Jem Young was really good as well. https://frontendmasters.com/courses/web-assembly/ https://frontendmasters.com/courses/web-assembly/

dang 3y ago

Discussed at the time: Build Your Own WebAssembly Compiler - https://news.ycombinator.com/item?id=21889614 https://news.ycombinator.com/item?id=21889614 - Dec 2019 (19 comments)