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

1–10 of 45 posts

Re: Optimizing the Ion compiler back end

#3

Post by zyedidia »

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 default-enabled all sorts of extensions that are not yet widely supported by the rest of the ecosystem?

Re: Optimizing the Ion compiler back end

#5

Post by emmanueloga_ »

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 JetStream2 is what you want if you want to benchmark wasm.

How this relates to TFA, no idea ... is not really easy to tell which version of SpiderMonkey is running on the installed Firefox.

--

1: https://browserbench.org/

Re: Optimizing the Ion compiler back end

#6

Post by Dylan16807 »

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.

Re: Optimizing the Ion compiler back end

#7

Post by kevingadd »

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 ecosystem?

Yes

Photoshop in particular is a good example of a bleeding edge wasm app - browsers had to relax restrictions on things like function pointer table size in order for it to work. So I wouldn't expect it to build and run anywhere outside of v8 or spidermonkey.

Re: Optimizing the Ion compiler back end

#9

Post by kevingadd »

icsa wrote: post #4

Moral of the story: First, use an array. If an array doesn't work, try something else.

It's definitely the case that in many scenarios, the right data structure is an array, since you'll have work dominated by gets and sets.

However, the OP has one scenario where the opposite was true - they were using a dense bitset that needed to be obscenely huge because of degenerate code in the wasm module, so swapping to a sparse container was a win.

In the end you just have to profile and understand your data.

Post reply on HN