What makes WebAssembly fast? • Hacker News Board

Re: What makes WebAssembly fast?

#61

Post by the_duke » Wed, Mar 01, 2017, 12:08 AM UTC

AgentME wrote: post #50

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…

You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if man…

Direct DOM access including manipulation is planned for WebAssembly.

They wanted to progress on the spec and push it out without that, but it's on the roadmap. (Along with GC integration).

Re: What makes WebAssembly fast?

#62

Post by callahad » Wed, Mar 01, 2017, 12:11 AM UTC

johncolanduoni wrote: post #55

Is WebAssembly's binary format finalized? I wasn't able to find anything about it, but about two weeks ago binaryen pushed a new release[1] whose notes said "update wasm version to 0x01, in prep for release, and since browsers are ready to accept it". From what I had heard the plan was not to do that until the final standard was settled on, but I wasn't able to find any corresponding announcement. [1]: https://github…

Yes. Here's the announcement: https://lists.w3.org/Archives/Public/public-webassembly/2017...

Re: What makes WebAssembly fast?

#63

Post by chatterbeak » Wed, Mar 01, 2017, 12:16 AM UTC

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

Well, if you're going to say that, then C++ with smart-pointers is Garbage Collected, and nobody says that!

Re: What makes WebAssembly fast?

#64

Post by deburo » Wed, Mar 01, 2017, 12:17 AM UTC

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.

Re: What makes WebAssembly fast?

#65

Post by TazeTSchnitzel » Wed, Mar 01, 2017, 12:17 AM UTC

johncolanduoni wrote: post #54

TazeTSchnitzel wrote: post #5

The edge over asm.js is a subset of this. Obviously, asm.js neither has JIT reoptimisation overhead, nor garbage collection to worry about. However, a weird, highly-annotated strict subset of JS is not the ideal representation of what is basically portable assembly language. WebAssembly's big strength over asm.js is it has smaller executables and they can be rapidly decoded and verified in binary IR form, rather than…

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 it doesn't need to. I assume the same would be true of WebAssembly.

> Asm.js also still hasn't become a formal spec

Though it is a spec.

Re: What makes WebAssembly fast?

#66

Post by ncantelmo » Wed, Mar 01, 2017, 12:33 AM UTC

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…

I agree completely, but I would take it a step further:

If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS.

We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. Now that a doorway to replacing it with a general-purpose solution has been cracked, I expect the industry to kick it wide open as soon as possible. Not because JS is bad per se (it has certainly gotten much better), but because a lot of developers would simply prefer to use something else.

Re: What makes WebAssembly fast?

#67

Post by barrkel » Wed, Mar 01, 2017, 12:40 AM UTC

acqq wrote: post #53

Someone wrote: post #30

Earlier quoted context omitted.

I think that is left open to the implementation. _If_ an implementer thinks there is a benefit in doing so, he's free to do so. In fact, that's similar to how a CPU runs "real binaries". Modern CPUs use _some_ runtime information to make code run faster. Examples include branch predictors and the recognition of stride lengths to move data into the cache before the instructions being executed need it. That's only smal…

I think you confuse the tracing during the interpretation of JavaScript with asm.js&WebAsm. Namely asm.js&WebAsm are designed to avoid as much as possible anything deciding in the run-time, except for verifying and generating the machine code, exactly because these "let's see what the code is doing in the run-time" were already implemented and were used for "plain" JavaScript, but had too much overhead, compared to w…

> 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 working technology. And it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is.

Specific example: a common tradeoff made in compilation is between space and speed, and there are some cases - like padding to align a jump target - that can win big speed improvements in inner loops, but are pessimal when used liberally (because code size inflates and doesn't fit in cache). Realigning jump targets is something that can be done to compiled code, in particular compiled code before it has been linked, when all the relocations and fixups are still available. Having information about hot code can make a big difference here.

(BTW: optimizing linkers are surprisingly involved here, particularly for targets that have a bunch of addressing modes, like x86. Some ways of writing in fixups can result in smaller code (e.g. 1 byte offsets rather than 2 byte offsets), but this effect cascades: making code smaller can make what used to be a 2 byte offset possible to fit in 1 byte. Don't underestimate the amount of optimization that your linker does with native code (if you have a smart linker; my experience is from the Delphi compiler source).)

Re: What makes WebAssembly fast?

#68

Post by [deleted] » Wed, Mar 01, 2017, 12:45 AM UTC

nessus42 wrote: post #26

zeveb wrote: post #23

Earlier quoted context omitted.

Well, it's possible that if it hadn't been for Java JavaScript might have had a decent, parens-based syntax. I still wonder what might have been if Eich had been allowed to write the Scheme system he had been hired to do. While I'm not a fan of Scheme by any means, it is approximately 281,757,423,024,353 better than JavaScript. And Scheme's a great little language for implementing other languages. Imagine, we could h…

I'm a HUGE fan of Scheme. And of Lisp, in general. But having seen in the "real world" how so many people are so adverse to Lisp's beautiful syntax, I'm pretty confident that JavaScript would never have caught on if it looked like Lisp rather than like C.

[deleted]

Re: What makes WebAssembly fast?

#69

Post by coldtea » Wed, Mar 01, 2017, 12:49 AM UTC

robotresearcher wrote: post #44

coldtea wrote: post #14

Earlier quoted context omitted.

Yay! Nothing improved for me as a consumer, but total control of the app by Microsoft (it runs on their website and I don't even own my own copy) and slower speed (because of the extra VM and sandbox). Can't wait!

> Nothing improved for me as a consumer Nothing to install, no updates, no license key, not tied to a machine.... ?

>Nothing to install

Modern app stores like the Mac App Store make installing an one click affair. It will take me more clicks to login to their Word website...

Also, "nothing to install" means "nothing to own".

>no updates

There will still be updates, only I won't be controlling them, and I wont be able to stick with an older version.

Besides, it has been ages since updates for apps have been totally painless (e.g. with something like the Mac App Store, or a framework like Sparkle).

>no license key

Yes, but a password. And presumably a subscription, and my access to this "WebAssembly-based Office" lost when I can't fork out the money for a few months.

(Also no piracy option for the developing world anymore).

>not tied to a machine....

I can have that with regular software not running on a browser. I can use Reason e.g. (a native application) on any machine I care to install it with their over-the-internet verification.

Re: What makes WebAssembly fast?

#70

Post by daurnimator » Wed, Mar 01, 2017, 12:51 AM UTC

callahad wrote: post #60

daurnimator wrote: post #49

What's the point if you can't interact with the DOM? Almost all examples of webassembly just render to a canvas. Does this mean instead of a normal "native app" I'm going to start getting C applications compiled with wasm and distributed in electron? What does this possibly gain the end user?

You're unnecessarily constraining your thinking to the present-day Web. WASM fundamentally expands what's feasible in that domain. For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal, or for lower level libraries like OpenCV, libsass, or libarchive which you might want to use in your web application. No one is arguing that WebAssembly will completely replace JavaScript, especia…

> For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal

My point was who wants these to be in the browser? I mean they're cool as demos, but I don't see the use. Is it just people using web browsers as the content delivery platform instead of e.g. Steam?