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

WebAssembly’s post-MVP future

hacks.mozilla.org

Post reply on HN
Print view View original

51–60 of 207 posts

Re: WebAssembly’s post-MVP future

#51

Post by flohofwoe »

fabian2k wrote: post #16

Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript? My experience is that modern JS engines are already pretty good at optimizing that kind of code, so I'm wondering if there are still significant speedups to be had by using WASM, given that it's still pretty new and didn't have much time to get optimized further yet.

Depends if you measure against asm.js or handwritten Javascript, and on which browser.

For my emulator stuff (mostly bit twiddling on integers: https://floooh.github.io/tiny8bit/), I saw a very slight improvement of WASM vs asm.js on browsers that have special handling for asm.js (in the meantime I have dropped asm.js, and only compile to WASM, since all browsers support it).

On iOS Safari (which I guess doesn't have special asm.js handling) WASM is a whopping 3x..5x faster than running the same code compiled to asm.js.

The question now is how much slower 'idiomatic, handwritten Javascript' is on iOS Safari versus the same code written in C compiled to asm.js, but I think another 3x..5x slower is realistic.

Re: WebAssembly’s post-MVP future

#52

Post by amelius »

zimbatm wrote: post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Why not implement the GCs themselves using low-level WASM code? That would enable a language-agnostic approach (though it would prohibit collecting garbage over multiple cooperating languages at the same time, which is a less urgent problem imho).

Re: WebAssembly’s post-MVP future

#53

Post by noblethrasher »

zimbatm wrote: post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

At one time people thought that you couldn't possibly have a high performance runtime that supported both object-oriented and functional patterns vis-à-vis garbage collection, yet the CLR managed to pull it off with some clever use of ML (pun intended)[1].

[1] https://youtu.be/ZTbyKsw7uIU?t=684

Re: WebAssembly’s post-MVP future

#54

Post by AnIdiotOnTheNet »

skybrian wrote: post #12

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

> Developers need laptops to run their development environment in.

I hear a lot of developers going on and on about laptops these days but I can't figure out why. Is working out of a coffee shop the norm now or something?

Re: WebAssembly’s post-MVP future

#55

Post by Rusky »

zimbatm wrote: post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

I believe the GC integration is far more important for Javascript (or other host language) interoperability than for WASM-targeting languages. Many of them will probably be able to take advantage of it, but anything more special-purpose should still be possible to implement in a custom language runtime.

Re: WebAssembly’s post-MVP future

#56

Post by tyingq »

zimbatm wrote: post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

The CLR in .Net seems to support a very broad spectrum of languages, including functional, statically typed, dynamically typed, etc.

Re: WebAssembly’s post-MVP future

#57

Post by bolb »

marcosdumay wrote: post #34
goatlover wrote: post #19

Earlier quoted context omitted.

Wasm isn't really for pretty apps you can quickly make in Vue. It's more for those heavy duty apps, games or libraries that most people run natively because of performance and because they're written in languages like C++, Rust, or even Fortran (scientific computing libraries). Also, JS isn't the best tool for all programs, and programmers would like more of a choice when it comes to things that are more than just yo…

> Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?

There are programmers who haven’t worked with anything but the HTML+JS+CSS ecosystem, especially on the front-end. Lots of sunk costs there.

Presenting WASM as a threat will lead to it facing stiff resistance from entrenched interests (amazing that people in their 20s and 30s are entrenched interests, but that’s modern front-end development).

A more gradual, evolutionary, low-hype approach seems prudent, as the platform matures and until/if someone makes the “killer app”.

Re: WebAssembly’s post-MVP future

#58

Post by colordrops »

zimbatm wrote: post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Is GC that wide of a problem that tunable parameters could not be provided to support different use cases?

Re: WebAssembly’s post-MVP future

#59

Post by goatlover »

bolb wrote: post #57
marcosdumay wrote: post #34

Earlier quoted context omitted.

> Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?

There are programmers who haven’t worked with anything but the HTML+JS+CSS ecosystem, especially on the front-end. Lots of sunk costs there. Presenting WASM as a threat will lead to it facing stiff resistance from entrenched interests (amazing that people in their 20s and 30s are entrenched interests, but that’s modern front-end development). A more gradual, evolutionary, low-hype approach seems prudent, as the platf…

Yeah, look at what happened to Dart in the browser, which is a shame.

Re: WebAssembly’s post-MVP future

#60

Post by lj3 »

cm2187 wrote: post #28
kodablah wrote: post #25

Earlier quoted context omitted.

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)? 0 - https://github.co…

I’d assume you would get a performance (and therefore battery) benefit by not maintaining a js layer, though a js layer is a perfectly acceptable temporary solution.

Careful. Javascript was a perfectly acceptable temporary solution too. Temporary solutions have a way of becoming permanent.
Post reply on HN