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

81–90 of 238 posts

Re: What makes WebAssembly fast?

#81

Post by Salgat »

deburo wrote: post #64
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…

The lack of GC is a benefit here. Remember, WASM as an MVP is meant to bring C/C++ codebases on the web. There is plenty to be excited about here. This will enable faster [media apps, games, etc]( http://webassembly.org/docs/use-cases/ ) on the web. Wasm is knocking at the door and I can't wait to see what it's bringing with it. Edit: HN really should support a few more formatting options.

It's not a benefit, it's simply a temporary compromise to get it out faster.

Re: What makes WebAssembly fast?

#82

Post by rogersach »

jfoutz wrote: post #76
shadowmint wrote: post #71

Earlier quoted context omitted.

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

Wild guess? Oracle with Java.

Java already compiles to JS via Kotlin.

Re: What makes WebAssembly fast?

#83

Post by reitzensteinm »

TazeTSchnitzel wrote: post #65
johncolanduoni wrote: post #54

Earlier quoted context omitted.

A big part of the advantage is more consistent adoption by browsers. All the major browsers have experimental WebAssembly support already, and Firefox and Chrome are already shipping it (although it's off by default). Firefox/SpiderMonkey and Edge/Chakra have AOT compilation for asm.js, but notably Chrome/V8 doesn't (although they did optimize its performance significantly). Asm.js also still hasn't become a formal s…

> 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.

Re: What makes WebAssembly fast?

#84

Post by pcwalton »

flukus wrote: post #41
dmarcos wrote: post #9

Earlier quoted context omitted.

WebAssembly won't give you unlimited power. You will still have the browser sandboxing and security / privacy policies in place. Accessing to the local file system is for instance constrained in the browser for good reasons. WebAssembly apps will be able to do what Web APIs let any page do.

Not a problem, we can just wait for the inevitable security vulnerabilities.

If it's "not a problem", it should be easy to write a Web page that opens calc.exe. Can you do that? Can anyone on HN do that?

Re: What makes WebAssembly fast?

#85

Post by mintplant »

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…

GC integration is on the roadmap for WebAssembly, as I understand it. At the moment languages can bring their own GC implementations written in WebAssembly, but eventually they should be able to hook into and take advantage of the browser's native GC facilities. I believe this is considered a blocker for exposing a standard DOM API directly to WebAssembly code.

Re: What makes WebAssembly fast?

#86

Post by [deleted] »

deburo wrote: post #64
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…

The lack of GC is a benefit here. Remember, WASM as an MVP is meant to bring C/C++ codebases on the web. There is plenty to be excited about here. This will enable faster [media apps, games, etc]( http://webassembly.org/docs/use-cases/ ) on the web. Wasm is knocking at the door and I can't wait to see what it's bringing with it. Edit: HN really should support a few more formatting options.

[deleted]

Re: What makes WebAssembly fast?

#87

Post by wyldfire »

matthewmacleod wrote: post #48
callahad wrote: post #35

Earlier quoted context omitted.

You don't have to go back to the 80's to develop closer to the metal. Neither Rust nor Swift have garbage collection, but both are thoroughly modern, productive languages. I've also been told that C++14 is reasonably pleasant, but I have no personal experience with which to judge.

Swift is garbage-collected – it might not have a tracing GC, but ARC is essentially compile-time GC – certainly, from the perspective of a developer, ARC is extrordinarily similar to a tracing GC (with some small caveats).

"compile-time GC" sounds like it would apply to C/C++'s automatic storage duration too.

Re: What makes WebAssembly fast?

#89

Post by skybrian »

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 WebAssembly will perform well, since it fits these languages' runtime model better. But for garbage-collected languages, compiling to JavaScript may result in smaller and faster code, since you can reuse JavaScript's runtime instead of downloading it. There may not be any reason for Elm or Dart (for example) to replace a compiler that works well with one that targets WebAssembly. Or if you like Go, I'd at least try out GopherJS before thinking you need a whole new toolchain.

It's not just performance, either. Generating somewhat-readable JavaScript that you can debug using Chrome Devtools when something goes wrong is a pretty nice advantage.

Re: What makes WebAssembly fast?

#90

Post by rocky1138 »

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.
Post reply on HN