[HN Gopher] Build your own WebAssembly Compiler (2019)
___________________________________________________________________
Build your own WebAssembly Compiler (2019)
Author : davikr
Score : 94 points
Date : 2023-12-03 15:11 UTC (7 hours ago)
(HTM) web link (blog.scottlogic.com)
(TXT) w3m dump (blog.scottlogic.com)
| ReactiveJelly wrote:
| [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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.)
| flohofwoe wrote:
| 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.
| tsegratis wrote:
| 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
| Rochus wrote:
| Here is what you are looking for:
| https://github.com/bytecodealliance/wasm-micro-runtime
| OmegaMetor wrote:
| 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 wrote:
| Which benchmark did you use?
| schemescape wrote:
| Did I understand correctly that the native code was
| compiled without optimization? Meaning "-O0"?
| jedisct1 wrote:
| 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
| ColinEberhardt wrote:
| 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 wrote:
| Just letting you know: love the high-quality blogs you guys
| always write, especially the few on webgl!
| Joker_vD wrote:
| (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 wrote:
| 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 wrote:
| I was hoping we'd have someone more qualified to answer this
| question, but whatever. Holy shit!
|
| https://news.ycombinator.com/user?id=titzer
|
| I love this site
| tsegratis wrote:
| 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 wrote:
| If you're interested in this, there's also
| https://wasmgroundup.com/ currently in early access.
|
| I've worked through the first couple of chapters and found it
| pretty well structured and helpful.
___________________________________________________________________
(page generated 2023-12-03 23:00 UTC)