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

What makes WebAssembly fast?

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 238 posts

Re: What makes WebAssembly fast?

#91

Post by hakanito »

lacampbell wrote: post #20

I really hope web assembly takes off and becomes a thing wide implemented in all the major browsers. The web is such a fantastic application platform (despite its frequent misuse...), and removing the javascript performance tax will be huge.

While Javascript has its flaws, it's been refined over many years and finally there are pretty decent ways of building UI's, using React, Vue etc. Wouldn't we have to start all over again if people begin to write UI code in languages not built or configured for interacting with the DOM?

Re: What makes WebAssembly fast?

#92

Post by TazeTSchnitzel »

reitzensteinm wrote: post #83
TazeTSchnitzel wrote: post #65

Earlier quoted context omitted.

> A big part of the advantage is more consistent adoption by browsers. […] Firefox/SpiderMonkey and Edge/Chakra have AOT compilation for asm.js, but notably Chrome/V8 doesn't Not quite. SpiderMonkey has AOT compilation, whereas Chakra and V8 throw it at the JIT, though Chakra's compiler is specially optimised for asm.js AIUI. Thing is, specific support for asm.js is unnecessary, a sufficiently good JIT is good enough…

V8 hasn't implemented asm.js AOT because the authors claim not to need to; but if you compare the performance of a Unity3D WebGL export vs FireFox the gap is very wide.

Well, each has its tradeoffs. JIT has low startup time, whereas Firefox will spend quite a while compiling before anything actually happens.

Re: What makes WebAssembly fast?

#93

Post by wybiral »

rocky1138 wrote: post #90

On one hand, I'm excited about performance improvements. On the other, I lament the fact that this will kill one of the best parts of the web: the fact that the source is sent to the end user instead of a binary. It now makes the code and how it works opaque, thus killing the spirit of innovation and learning.

Agreed. But I've felt that way about minified JS for a long time too. I'm not sure there's a way around it.

Re: What makes WebAssembly fast?

#94

Post by reitzensteinm »

TazeTSchnitzel wrote: post #92
reitzensteinm wrote: post #83

Earlier quoted context omitted.

V8 hasn't implemented asm.js AOT because the authors claim not to need to; but if you compare the performance of a Unity3D WebGL export vs FireFox the gap is very wide.

Well, each has its tradeoffs. JIT has low startup time, whereas Firefox will spend quite a while compiling before anything actually happens.

For the content I'm describing, FF has vastly superior startup/cold execution performance, and mildly better long term.

Re: What makes WebAssembly fast?

#95

Post by ktRolster »

skybrian wrote: post #89
Svenskunganka wrote: post #34

> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases. I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly…

JavaScript is strong competition both on the front end (source ecosystem) and the back end (compiler target). For people who don't want to use JavaScript (they are using a different source ecosystem), compile-to-WebAssembly toolchains will be in direct competition with compile-to-JavaScript toolchains. It's not at all clear which ones will win. It may be different for each language. For C++ and Rust I'd expect WebAss…

Garbage collection is coming to WebAssembly.

Re: What makes WebAssembly fast?

#96

Post by ktRolster »

q3r3qr3q wrote: post #79
ClassyJacket wrote: post #73

>At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. I support anything that improves performance and efficiency. But the best of both worlds is always great. I'm wondering if it would be possible to implement referenc…

> And are there disadvantages to reference counting that make it a bad idea? I thought it had a performance cost.

Not much of one. The amount of time it takes to allocate the memory and free it is the dominant factor.

Re: What makes WebAssembly fast?

#97

Post by ktRolster »

hellofunk wrote: post #42
pmontra wrote: post #28

> At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least until WebAssembly gets garbage collection. I might be wrong but I don't see many peopl…

There are a lot of developers -- a huge amount, actually -- who believe memory management is too important to leave to an automated GC algorithm. That, and the memory requirements of a particular application might require something different than a GC provides.

If your algorithm is such that everything can be placed on the stack then GC gets you nothing.

Re: What makes WebAssembly fast?

#98

Post by comex »

ktRolster wrote: post #96
q3r3qr3q wrote: post #79

Earlier quoted context omitted.

> And are there disadvantages to reference counting that make it a bad idea? I thought it had a performance cost.

Not much of one. The amount of time it takes to allocate the memory and free it is the dominant factor.

Maybe in the non-atomic case. Atomic refcounts force synchronization between CPUs when different threads access the same data, even if they only read it; that can have a quite significant cost.

Re: What makes WebAssembly fast?

#99

Post by brianwawok »

acqq wrote: post #80
barrkel wrote: post #67

Earlier quoted context omitted.

> I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code. Think about that: it they would find something like that, exactly the same technique could be used to speed any native code, including Linux kernel and anything native you imagine. That's exactly what profile-guided optimization does. It's not a new invention, it's workin…

> it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is. A developer could do some kind of PGO before he produces the final binary, I can imagine that. But then it's still just a static binary. And I personally can't imagine PGO being done in the user's browser and not being slower than the alternative of not doing it, just like I've never heard of some OS whi…

Java does PGO on every server running Java in the world.

Even some swing apps benefit once you get it started up..

That said, I'm not sure the full JVM is coming to browsers anytime soon.

Re: What makes WebAssembly fast?

#100

Post by skybrian »

ktRolster wrote: post #95
skybrian wrote: post #89

Earlier quoted context omitted.

JavaScript is strong competition both on the front end (source ecosystem) and the back end (compiler target). For people who don't want to use JavaScript (they are using a different source ecosystem), compile-to-WebAssembly toolchains will be in direct competition with compile-to-JavaScript toolchains. It's not at all clear which ones will win. It may be different for each language. For C++ and Rust I'd expect WebAss…

Garbage collection is coming to WebAssembly.

Sure, eventually, and I assume some day there will be decent debuggers. But if your toolchain outputs JavaScript, you already have these things today.
Post reply on HN