Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimizing the Ion compiler back end

spidermonkey.dev

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Optimizing the Ion compiler back end

#11

Post by aseipp »

zyedidia wrote: post #3

Is there any AOT WebAssembly compiler that can compile Wasm used by websites? I tried locally compiling the Photoshop Wasm module mentioned in the article but the compilers I tried (Wasmtime, wasm2c, WAMR) all complained about some unsupported Wasm extension/proposal being required (exceptions seems like the blocker on wasmtime, and the others gave cryptic error messages). Is it really the case that browsers have def…

No, I think most of the AOT compilers in practice are a bit behind V8 and/or Spidermonkey for newer features. Realistically, most development driving new WASM features is motivated by website-ish use cases. Exception handling in particular is still not standardized so I guess it's expected that the browser engines would be the one to have the most evolving support (and the ability to test it thoroughly) because people want that platform as their inevitable target anyway.

Re: Optimizing the Ion compiler back end

#12

Post by KwanEsq »

emmanueloga_ wrote: post #5
cjblomqvist wrote: post #2

If anyone have a comparison with V8 that would be great!

Not sure what kind of comparison you mean, but you can compare desktop browsers with [1]. I just ran it on my mac M2 Max and got: (F)irefox 131.0.3 (E)dge 129.0, V8 12.9.17.8 (S)afari 18.0 (20619.1.26.31.6) Speedometer 3.0 (F) 25.9 (E) 22.3 (S) 30.9 JetStream2 (F) 251.787 (E) 350.74 (S) 360.568 Safari seems slightly faster in all benchmarks. I did not run motionmark because it takes forever :-/. The page says JetStre…

Spidermonkey just follows Firefox version numbering, so far as I know, and the linked bugs in the article seem to have landed in a mix of the 132 and 133 milestones, so you'll have to wait a couple of release cycles for the full effect.

Re: Optimizing the Ion compiler back end

#15

Post by [deleted] »

zyedidia wrote: post #3

Is there any AOT WebAssembly compiler that can compile Wasm used by websites? I tried locally compiling the Photoshop Wasm module mentioned in the article but the compilers I tried (Wasmtime, wasm2c, WAMR) all complained about some unsupported Wasm extension/proposal being required (exceptions seems like the blocker on wasmtime, and the others gave cryptic error messages). Is it really the case that browsers have def…

[deleted]

Re: Optimizing the Ion compiler back end

#16

Post by zyedidia »

Dylan16807 wrote: post #6
zyedidia wrote: post #3

Is there any AOT WebAssembly compiler that can compile Wasm used by websites? I tried locally compiling the Photoshop Wasm module mentioned in the article but the compilers I tried (Wasmtime, wasm2c, WAMR) all complained about some unsupported Wasm extension/proposal being required (exceptions seems like the blocker on wasmtime, and the others gave cryptic error messages). Is it really the case that browsers have def…

> Is it really the case that browsers have default-enabled all sorts of extensions that are not yet widely supported by the rest of the ecosystem? I don't know the answer, but it would be hard to blame them for following normal browser development practices on the standard they created for the purpose of being in browsers.

Fair enough. I think it would be unfortunate if the WebAssembly language in browsers were a significantly different language than WebAssembly outside of browsers (just referring to language itself, not the overall runtime system). I don't think that has quite happened, and the outer ecosystem can probably catch up, but it worries me.

Re: Optimizing the Ion compiler back end

#17

Post by titzer »

zyedidia wrote: post #16
Dylan16807 wrote: post #6

Earlier quoted context omitted.

> Is it really the case that browsers have default-enabled all sorts of extensions that are not yet widely supported by the rest of the ecosystem? I don't know the answer, but it would be hard to blame them for following normal browser development practices on the standard they created for the purpose of being in browsers.

Fair enough. I think it would be unfortunate if the WebAssembly language in browsers were a significantly different language than WebAssembly outside of browsers (just referring to language itself, not the overall runtime system). I don't think that has quite happened, and the outer ecosystem can probably catch up, but it worries me.

Non-browser environments are a little behind on the Wasm standard, but not by much. E.g. wasmtime has now landed support for Wasm GC. AFAIK they implement all phase 4 proposals. Wizard implements all the Phase 4 proposals as well. The Wasm 3.0 spec will be out soon, which will be a big milestone to motivate Wasm engines outside the Web to catch up.

Re: Optimizing the Ion compiler back end

#18

Post by zyedidia »

kevingadd wrote: post #7
zyedidia wrote: post #3

Is there any AOT WebAssembly compiler that can compile Wasm used by websites? I tried locally compiling the Photoshop Wasm module mentioned in the article but the compilers I tried (Wasmtime, wasm2c, WAMR) all complained about some unsupported Wasm extension/proposal being required (exceptions seems like the blocker on wasmtime, and the others gave cryptic error messages). Is it really the case that browsers have def…

> Is there any AOT WebAssembly compiler that can compile Wasm used by websites? This doesn't really make sense, given that the wasm used by websites is going to import a bunch of JS functions as dependencies. You're not going to have those available in any native environment. > Is it really the case that browsers have default-enabled all sorts of extensions that are not yet widely supported by the rest of the ecosyst…

I think one of the interesting aspects of WebAssembly compared to JavaScript is that it can be efficiently AOT-compiled. I've been interested in investigating AOT compilation for a browser (perhaps there is a distant/alternative future where web browsing does not require a JIT), but maybe Wasm AOT compilers aren't really there yet.

Re: Optimizing the Ion compiler back end

#19

Post by koala_man »

> extremely large functions > quadratic behavior

*High five*

I fixed several of these during my time as a compiler engineer too.

It's true what they say, quadratic is the worst possible time complexity. Fast enough to work on all your test cases, slow enough to explode in prod.

Re: Optimizing the Ion compiler back end

#20

Post by rpearl »

Wow, that dominator tree algorithm I wrote as an intern (https://bugzilla.mozilla.org/show_bug.cgi?id=666426) seems to have lasted 13 years! At the time we assumed that graphs would be small enough to not warrant the constant factor against Lengauer-Tarjan. ...And of course, browser-based apps have gotten much bigger since then.

Semi-NCA hadn't even been published yet and seems like the clear choice nowadays, so I'm glad to see it in place! Great work!

Post reply on HN