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

51–60 of 238 posts

Re: What makes WebAssembly fast?

#51

Post by shakna »

brlewis wrote: post #39
zeveb wrote: post #29

Earlier quoted context omitted.

They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. I imagine that folks would have cottoned on to the advantage pretty quickly. And those that didn't … I guess they could have always become telephone cleaners or something:-)

Pure Scheme would not be sufficient. You need at least DOM-handling libraries. And if those libraries were poorly designed, then people wouldn't cotton onto the advantage quickly. Look at DSSSL.

Just about every modern Lisp has an X-Expression library, and having used Racket's in production, it's a hell of a lot better than the DOM browsers have today.

Re: What makes WebAssembly fast?

#52

Post by randomdata »

zeveb wrote: post #29
nessus42 wrote: post #26

Earlier quoted context omitted.

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.

They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. I imagine that folks would have cottoned on to the advantage pretty quickly. And those that didn't … I guess they could have always become telephone cleaners or something:-)

Browsers worked just fine before the advent of Javascript. Nobody had to use it, but they decided to use it because it was good enough. If some other language was deemed not good enough, there would have been more aversion to using it, and it would have never taken off.

Not to mention that there were other ways to execute code in the browser in those days. We have 'no choice' but Javascript today simply because it's the option that people eventually gravitated towards, forcing the others out of the market.

Re: What makes WebAssembly fast?

#53

Post by acqq »

Someone wrote: post #30
acqq wrote: post #16

Earlier quoted context omitted.

> For example asm.js and WebAssembly have branches don't they? Does the JIT always compile both branches even if one has never been taken in practice? WebAssembly is treated just like other "real binaries" produced for the "real" OS. Whatever survived the static optimizations while producing the binaries is converted, at the end, to the pure machine code, you don't "trace" it in run-time by the user. > even very stat…

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 what asm.js&WebAsm does (or avoids to do), for the kind of uses where asm.js&WebAsm are desired.

For the "plain" JavaScript, there are the run-time decisions.

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

Sure. But that run-time information is internal to the CPU. And the CPU will use it for the native binary code that is the final result of asm.js or WebAsm, just like any other. But that native binary code is "static," it's explicitly not "small traced chunks" the way "plain" JavaScript is handled.

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

If you manage to develop software method that actually improves the execution speed of the native code in run-time, you'd be famous and (if you know how to market it) rich.

Re: What makes WebAssembly fast?

#54

Post by johncolanduoni »

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 spec, while WebAssembly is already very close.

Re: What makes WebAssembly fast?

#55

Post by johncolanduoni »

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.com/WebAssembly/binaryen/releases/tag/version...

Re: What makes WebAssembly fast?

#56

Post by int_19h »

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

Reference-counted GC is trivially implemented on top of WebAssembly memory model.

Re: What makes WebAssembly fast?

#57

Post by Svenskunganka »

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…

Yes of course, but only during the early stages. The post-MVP roadmap for WebAssembly specifies DOM & Web API integration (http://webassembly.org/docs/gc/), so that specific case will too disappear with time.

If you read point 3 on this page (http://webassembly.org/docs/high-level-goals/) you should realize that the need for JavaScript won't be required at that point.

edit: I'd like to clarify that I'm not saying wasm will boom in usage over night, but as time goes on, the rough edges clears up & features like these are added it might become the better choice.

Re: What makes WebAssembly fast?

#58

Post by int_19h »

randomdata wrote: post #52
zeveb wrote: post #29

Earlier quoted context omitted.

They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. I imagine that folks would have cottoned on to the advantage pretty quickly. And those that didn't … I guess they could have always become telephone cleaners or something:-)

Browsers worked just fine before the advent of Javascript. Nobody had to use it, but they decided to use it because it was good enough. If some other language was deemed not good enough, there would have been more aversion to using it, and it would have never taken off. Not to mention that there were other ways to execute code in the browser in those days. We have 'no choice' but Javascript today simply because it's…

They decided to use it because it let you add things like drop-down menus (and falling snowflakes!) to your website, which made it look better than your competitor's website. Syntax was just the hoop to jump through to achieve that, and a very minor one at that. I doubt it would have made any difference.

Re: What makes WebAssembly fast?

#59

Post by int_19h »

khedoros1 wrote: post #46
zeveb wrote: post #29

Earlier quoted context omitted.

They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. I imagine that folks would have cottoned on to the advantage pretty quickly. And those that didn't … I guess they could have always become telephone cleaners or something:-)

> They wouldn't have had a choice, though, just as folks don't have a choice with JavaScript. If people disliked the syntax enough to avoid the language (and the browser that uses it), I imagine that other browsers would've started supporting other languages, and something else would've dominated.

Browsers actually did support other languages back then. Remember VBScript? IIRC there was also an attempt to draft Tcl into that role.

In IE world, things were actually even crazier, because the whole scripting story was extensible (via Active Scripting). So you could use Perl, for example...

Re: What makes WebAssembly fast?

#60

Post by callahad »

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, especially not right out of the gate, but it will be used to optimize hot code paths within JS apps, as well as allowing robust, efficient, native libraries to be used directly on the Web. This is more about the pie getting larger than it is about WebAssembly hypothetically crowding out JavaScript.

Post reply on HN