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

Assembling WebAssembly

webkit.org

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Assembling WebAssembly

#11

Post by TazeTSchnitzel »

saamyjoon wrote: post #10
TazeTSchnitzel wrote: post #7

Earlier quoted context omitted.

> WebAssembly would have to load and start as quickly as JS. Wouldn't it already load faster than JS, because it's much less work to compile and doesn't require guessing types?

It's implementation dependent. Most implementations JIT Wasm up front (I think Chakra is the only engine that interprets). So, JS loads faster because almost all engines interpret first (all?).

Is “interpreting” necessarily faster?

Consider also this is perhaps a false distinction. V8 always produces machine code when running JS IIRC. And that code is JITed doesn't mean the entire module is.

Re: Assembling WebAssembly

#12

Post by jfbastien »

JoshTriplett wrote: post #9
pizlonator wrote: post #4

Earlier quoted context omitted.

We're a long way away from that. Here's what you'd need: - GC types in WebAssembly. That's still an open problem, but that would give you API access. - Ability to load WebAssembly via something like . - WebAssembly would have to load and start as quickly as JS. The last one is probably the hardest in the long run, since wasm is being optimized for the kinds of apps where you want to pay some cost up front so that you…

> - GC types in WebAssembly. That's still an open problem, but that would give you API access. I've seen numerous discussions about integrating WebAssembly with the JavaScript heap. That might not require full GC; ownership semantics might suffice (such that either wasm or JS can own the object at any given time, and within the wasm world it can use wasm memory management). > - Ability to load WebAssembly via somethi…

For reference, the current GC proposal is here: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

I expect it'll be discussed at an upcoming CG meeting. Either the next one or the one after.

Re: Assembling WebAssembly

#13

Post by saamyjoon »

TazeTSchnitzel wrote: post #11
saamyjoon wrote: post #10

Earlier quoted context omitted.

It's implementation dependent. Most implementations JIT Wasm up front (I think Chakra is the only engine that interprets). So, JS loads faster because almost all engines interpret first (all?).

Is “interpreting” necessarily faster? Consider also this is perhaps a false distinction. V8 always produces machine code when running JS IIRC. And that code is JITed doesn't mean the entire module is.

V8 used to do this. Now they have a JS interpreter called Ignition.

Re: Assembling WebAssembly

#14

Post by pizlonator »

JoshTriplett wrote: post #9
pizlonator wrote: post #4

Earlier quoted context omitted.

We're a long way away from that. Here's what you'd need: - GC types in WebAssembly. That's still an open problem, but that would give you API access. - Ability to load WebAssembly via something like . - WebAssembly would have to load and start as quickly as JS. The last one is probably the hardest in the long run, since wasm is being optimized for the kinds of apps where you want to pay some cost up front so that you…

> - GC types in WebAssembly. That's still an open problem, but that would give you API access. I've seen numerous discussions about integrating WebAssembly with the JavaScript heap. That might not require full GC; ownership semantics might suffice (such that either wasm or JS can own the object at any given time, and within the wasm world it can use wasm memory management). > - Ability to load WebAssembly via somethi…

> I've seen numerous discussions about integrating WebAssembly with the JavaScript heap. That might not require full GC; ownership semantics might suffice (such that either wasm or JS can own the object at any given time, and within the wasm world it can use wasm memory management).

Those discussions have not resulted in a proposal.

Ownership semantics are most likely not going to work. The options being considered are:

- WebAssembly has strong or weak handles to JS objects. That's not ownership.

- WebAssembly can allocate GC'd objects. That's not ownership.

- WebAssembly exposes enough stuff so that you can write your own GC. That's ownership, sorta, but doesn't allow wasm to access JS objects. Wasm would simply own objects it allocated in its own heap and would never be able to claim ownership of JS objects or relinquish ownership of its objects to JS. By itself, this means zero GC interop with JS.

Most likely, we'll end up with all three options.

It sounds like you're proposing that WebAssembly can somehow come to own a JS object. That's not practical, since it would imply either eagerly ref-counting all JS objects (that's a 2x slow-down), or it would imply full synchronous GC every time you share any object (totally impractical), or it would imply pretending that WebAssembly can own an object without first proving it (then wasm code could create use-after-free bugs to escape the web sandbox).

> What we have today seems very close to that in practice.

You have to use JS API to load wasm, so we're not close to this at all.

> A combination of a fast bytecode interpreter and compiled code caching could probably manage that. Or a fast, targeted JIT.

So long as WebAssembly is a low-level compiler target, that implies that developers shipping WebAssembly will also be shipping a userland for whatever their source language is. See emscripten for example, which has a large userland (the "emsdk", which includes libc and other things). So long as this is the pattern, WebAssembly will necessarily take longer to load than JS because the same program written in wasm will be bigger than its JS variant.

> Still an improvement, but also see above about ownership semantics.

I don't think your ownership idea will work, see above.

Re: Assembling WebAssembly

#15

Post by pizlonator »

sp332 wrote: post #8
pizlonator wrote: post #4

Earlier quoted context omitted.

We're a long way away from that. Here's what you'd need: - GC types in WebAssembly. That's still an open problem, but that would give you API access. - Ability to load WebAssembly via something like . - WebAssembly would have to load and start as quickly as JS. The last one is probably the hardest in the long run, since wasm is being optimized for the kinds of apps where you want to pay some cost up front so that you…

Large JS applications take so long to parse that they could already be slower on startup. https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...

WebKit has a fast JS parser. I don't think this would be true for us.

Re: Assembling WebAssembly

#16

Post by HugThem »

Man, we are bringing a giant load of complexity into the browser with this. As I understand it, what we get in return is a 2x speed increase. I wonder if its worth it.

Re: Assembling WebAssembly

#17

Post by luke_wagner »

saamyjoon wrote: post #10
TazeTSchnitzel wrote: post #7

Earlier quoted context omitted.

> WebAssembly would have to load and start as quickly as JS. Wouldn't it already load faster than JS, because it's much less work to compile and doesn't require guessing types?

It's implementation dependent. Most implementations JIT Wasm up front (I think Chakra is the only engine that interprets). So, JS loads faster because almost all engines interpret first (all?).

I think the primarily-AOT compilation strategy we see today is a consequence of many of the initial workloads being frame-based animation where AOT avoids animation stutters. But this is likely to evolve over time as wasm workloads evolve. If and when we see wasm showing up in frameworks in contexts where page-load is the primary concern I can see a more lazy JIT strategy being the right thing and then we'd want to specify some sort of developer knob to control this. But given a pure-JIT approach like Chakra is using, wasm should be able to load code byte-for-byte faster than JS.

Re: Assembling WebAssembly

#18

Post by mozumder »

pizlonator wrote: post #6
mcphage wrote: post #5

> Currently, there are two tiers to the engine: the Build Bytecode Quickly (BBQ) tier and the Optimized Machine-code Generator (OMG) tier. I assume the next tier they're going to do will be "WTF"?

WTF stands for Web Template Framework. BBQ and OMG both use it.

Ok now make LOL: LLVM Optimized Language

Re: Assembling WebAssembly

#20

Post by dwg »

HugThem wrote: post #16

Man, we are bringing a giant load of complexity into the browser with this. As I understand it, what we get in return is a 2x speed increase. I wonder if its worth it.

As I understand it, potential performance gains are higher than 2x, and we're still in a pretty early stage. It depends on your application.

Also, as has been mentioned by others, WebAssembly could perhaps evolve to take a greater role, leading to a greater potential impact of performance gains.

Finally, if the complexity does in fact outweigh the benefit, the idea would eventually fade away. So far it looks promising. Time will tell.

Post reply on HN