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

21–30 of 91 posts

Re: Assembling WebAssembly

#21

Post by merb »

pizlonator wrote: post #15
sp332 wrote: post #8

Earlier quoted context omitted.

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.

I'm not sure if that is true. our application takes at least 100ms or more to parse. only parsing. on Safari 10.1.1 on a macbook pro 2013 late. well chrome and firefox is as slow as that. I don't think the same stuff in WebAssembly would take that long (i.e. angular 1 application, if we add angular 4 which we are planning it will prolly take even longer since we need more vendor stuff.)

Re: Assembling WebAssembly

#22

Post by jfbastien »

merb wrote: post #21
pizlonator wrote: post #15

Earlier quoted context omitted.

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

I'm not sure if that is true. our application takes at least 100ms or more to parse. only parsing. on Safari 10.1.1 on a macbook pro 2013 late. well chrome and firefox is as slow as that. I don't think the same stuff in WebAssembly would take that long (i.e. angular 1 application, if we add angular 4 which we are planning it will prolly take even longer since we need more vendor stuff.)

Link to repro?

Re: Assembling WebAssembly

#23

Post by saamyjoon »

luke_wagner wrote: post #17
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?).

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 s…

I agree.

Chakra uses a pure JIT approach? I thought they interpret both in JS and Wasm?

Re: Assembling WebAssembly

#24

Post by [deleted] »

luke_wagner wrote: post #17
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?).

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 s…

[deleted]

Re: Assembling WebAssembly

#25

Post by luke_wagner »

saamyjoon wrote: post #23
luke_wagner wrote: post #17

Earlier quoted context omitted.

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 s…

I agree. Chakra uses a pure JIT approach? I thought they interpret both in JS and Wasm?

Maybe some terminology difference here but what I meant by 'pure JIT' was that, iiuc, Chakra waits until the function is called to even validate it, then warms up in an interpreter and only if the function is hot compiles it in a background thread. I think that's one end of the eager/lazy spectrum that may well be what a category of wasm uses will want.

Re: Assembling WebAssembly

#26

Post by floatboth »

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.

What complexity? It's just a new frontend for the complex tiered interpreter-and-JIT-compiler monstrosities that JS engines have.

A massively simpler frontend than JS itself — it's closer to, well, assembly :) while JS is a dynamic language.

What we get in return is very very close to native execution speed for all the performance-sensitive things you might want to run on a computer — game engines, crypto, compression, codecs, etc. — in a sandboxed and portable way. One executable for everything from the typical Windows/amd64 desktop to your NetBSD/mips toaster, potentially.

Re: Assembling WebAssembly

#27

Post by jfbastien »

floatboth wrote: post #26
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.

What complexity? It's just a new frontend for the complex tiered interpreter-and-JIT-compiler monstrosities that JS engines have. A massively simpler frontend than JS itself — it's closer to, well, assembly :) while JS is a dynamic language. What we get in return is very very close to native execution speed for all the performance-sensitive things you might want to run on a computer — game engines, crypto, compressio…

It's quite a bit more than a frontend, but I agree it isn't as complex as the JS engine itself. For comparison, this is the JSC wasm implementation: https://github.com/WebKit/webkit/tree/master/Source/JavaScri...

Re: Assembling WebAssembly

#28

Post by badminton1 »

I hope wasm becomes the first class citizen and JavaScript becomes just one out of many languages that compiles to it.

JavaScript is not bad at the high level, but at the low level it has been hell for engineers to implement a fast VM. A wasm VM is way easier to implement than a JavaScript VM.

Re: Assembling WebAssembly

#29

Post by [deleted] »

JoshTriplett wrote: post #3

I really look forward to the day when WebAssembly stops being seen as "JavaScript's fast sidekick" and starts being seen as "the language of the web". It won't take that much to expose APIs directly to WebAssembly rather than just to JavaScript.

[deleted]

Re: Assembling WebAssembly

#30

Post by madeofpalk »

pizlonator wrote: post #4
JoshTriplett wrote: post #3

I really look forward to the day when WebAssembly stops being seen as "JavaScript's fast sidekick" and starts being seen as "the language of the web". It won't take that much to expose APIs directly to WebAssembly rather than just to JavaScript.

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…

What would it take to give WebAssembly access to the DOM?
Post reply on HN