WebAssembly consensus and end of Browser Preview

Re:WebAssembly consensus and end of Browser Preview by zfedoran on Tuesday February 28, 2017 @07:28PM (#13759750)

I'd love to know what the current advantages are over running asm.js? I understand that it will definitely be faster eventually, but if I have a project that uses asm.js today, would it make sense to run it with WebAssembly instead? (ignoring the fact that not all browsers support it)

One potential issue:

"If you have lots of back-and-forth between WebAssembly and JS (as you do with smaller tasks), then this overhead is noticeable."

As far as I'm aware, asm.js code does not have an issue with this, as it is just js code. Is this correct?

(edit: I should have mentioned that I'm primarily interested from an electron.js point of view at the moment, where Firefox asm.js optimizations are unavailable)

[ Parent | on HN ]

Re:WebAssembly consensus and end of Browser Preview by klodolph on Tuesday February 28, 2017 @07:54PM (#13759916)

First question in the FAQ https://github.com/WebAssembly/design/blob/master/FAQ.md

Memory allocation is particularly painful in asm.js, for example.

[ Parent | on HN ]

Re:WebAssembly consensus and end of Browser Preview by zfedoran on Tuesday February 28, 2017 @08:08PM (#13760018)

Thank you for that link, exactly what I was looking for.

[ Parent | on HN ]

Re:WebAssembly consensus and end of Browser Preview by TazeTSchnitzel on Tuesday February 28, 2017 @07:42PM (#13759836)

> As far as I'm aware, asm.js code does not have an issue with this, as it is just js code. Is this correct?

It's not, because asm.js is treated specially in some cases. For instance, in Firefox asm.js calls to JS have to go through an FFI, IIRC.

[ Parent | on HN ]

Re:WebAssembly consensus and end of Browser Preview by geofft on Tuesday February 28, 2017 @07:51PM (#13759894)

asm.js code is "just" JS code in the sense that it is a subset of JS: a non-asm.js-aware JS implementation can treat it the same way as normal JS, and it will execute correctly. But in implementations where it's fast, asm.js is usually handled separately.

It looks like Mozilla's asm.js implementation used to have the exact same problem: https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/#c... I'm not familiar enough with asm.js to know if that's still a problem.

[ Parent | on HN ]

Re:WebAssembly consensus and end of Browser Preview by abecedarius on Tuesday February 28, 2017 @08:07PM (#13760005)

Re your last question: when I wrote http://wry.me/hacking/Turing-Drawings I found that "each call into an asm.js function takes about 2 msec (at this writing)" (on Firefox). That was back in the week of asm.js's release, and I'd bet the situation's better now. But it was the same kind of issue.

[ Parent | on HN ]

Re:WebAssembly consensus and end of Browser Preview by mbebenita on Wednesday March 01, 2017 @05:31AM (#13762727)

Emscripten should produce an asm.js fallback if wasm support is missing. The biggest wins in the short term will be smaller code size, and faster first startup time.

[ Parent | on HN ]