6 ms·

What are the main benefits of WebAssembly over asm.js? I understand that asm.js was a subset of JavaScript that allowed the compiler to create faster code. For

by TekMol 9y ago

What are the main benefits of WebAssembly over asm.js? I understand that asm.js was a subset of JavaScript that allowed the compiler to create faster code. For example because it could be sure that variable types do not change during runtime. But what do we gain with WebAssembly? Faster download+compilation times? How much faster?

paulddraper 9y ago
Yes, faster load times. Also, a more sensible target language.
- TekMol 9y ago
  How much faster? I would think gzip should even out most of the difference between a text based and a byte based code.
  - sanxiyn 9y ago
    > I would think gzip should even out most of the difference between a text based and a byte based code. You would be wrong then. Quoting Unity https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-feature-roadmap/ https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-f... "Experimenting with a prototype WebAssembly format on a build of our AngryBots demo, we saw the size of the generated JavaScript code go from 19.0 MB of asm.js code (gzip-compressed to 4.1 MB) down to 6.3 MB of WebAssembly code (gzip-compressed to 3.0 MB). This means that the amount of data the browser needs to process gets reduced by 3.0x, and the compressed download size gets reduced by 1.4x." So WebAssembly is 1.4x smaller, after gzip.
vanderZwan 9y ago
A lot. There's a talk by Alex Danilo from Google IO 17 explaining it in detail. Here, I'll link you directly to the part where he starts explaining the differences on a technical level: https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s Another part is that I suspect it makes maintaining a good JS compiler easier, because all of that asm.js code can be removed. I'm sure the browser vendors are happy about that.
- TekMol 9y ago
  I don't mean the technical differences. I mean the benefit. What will be the gain for the user of a web app?
  - flohofwoe 9y ago
    Compressed download size is indeed only slightly smaller (mostly around 10%), but the parsing is much faster, even noticeable for fairly small demos. (edit: replied to the wrong comment, apologies)
    - TekMol 9y ago
      Is the "parsing" what is displayed as "compile script" in Chromes profiler? That seems to take almost zero time. For example jquery.min.js compiles in 0.1ms here.
      - livingparadox 9y ago
        Libraries like jquery are not the target use case for WASM. Its intent is to make large applications viable on the web, like something you'd normally install on your computer.
  - Arcaten 9y ago
    I'm not 100% sure about any of this (I've only listened to most of the video above), but I think the gist is that WebAssembly provides a compile target for applications, meaning you can pre-compile an application so that your source is downloaded essentially as machine code. Furthermore, that means your compilation can perform as many optimizations that you care for, because it's happening ahead of time (not on the user's machine). Without WebAssembly, browser vendors have to strike a balance between optimizing the JS as much as possible (for increased performance), and running the script as soon as possible (so the user isn't waiting too long for execution to begin). edit: Demo of this in-browser video editor charts a FPS difference between the JS and WebAssembly implementations. https://github.com/shamadee/web-dsp https://github.com/shamadee/web-dsp
flohofwoe 9y ago
Here's a good overview from the emscripten author: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... TL;DR: much faster parsing over asm.js (10x to 20x faster), parsing should also use much less memory, 10%..20% smaller downloads (when comparing the compressed sizes, uncompressed WASM is several times smaller then asm.js), 64-bit integers (these have to be emulated on asm.js),
- TekMol 9y ago
  much faster parsing Isn't parsing super fast already? From my experiments, jquery seems to compile in a staggering 0.1ms.
  - flohofwoe 9y ago
    I get 165ms for my 8-bit homecomputer emulator which is 534KB compressed asm.js (http://floooh.github.io/virtualkc/ http://floooh.github.io/virtualkc/), and it seems the first call into the code takes another 500ms on Chrome (probably for JIT warmup). Bigger apps like UE4 or Unity demos are several times bigger and can take seconds to compile.
  - kibwen 9y ago
    The partial intent of WASM is to write things orders of magnitude larger than jQuery. Whether or not it will ever be practical to ship e.g. a complete Photoshop clone in a browser remains to be seen, but if that's your goal then you do have to start worrying about things like parse time.
    - TekMol 9y ago
      Why would the whole Photoshop be downloaded and compiled? I would expect a web app to only download the parts the I use. If I want to blur an image, I don't need the other gazillion filters for example. And hey, even if photoshop is 1000 times bigger then jquery - that would still compile in one tenth of a second.

by TekMol 9y ago

paulddraper 9y ago

Yes, faster load times. Also, a more sensible target language.

TekMol 9y ago
How much faster? I would think gzip should even out most of the difference between a text based and a byte based code.
- sanxiyn 9y ago
  > I would think gzip should even out most of the difference between a text based and a byte based code. You would be wrong then. Quoting Unity https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-feature-roadmap/ https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-f... "Experimenting with a prototype WebAssembly format on a build of our AngryBots demo, we saw the size of the generated JavaScript code go from 19.0 MB of asm.js code (gzip-compressed to 4.1 MB) down to 6.3 MB of WebAssembly code (gzip-compressed to 3.0 MB). This means that the amount of data the browser needs to process gets reduced by 3.0x, and the compressed download size gets reduced by 1.4x." So WebAssembly is 1.4x smaller, after gzip.

vanderZwan 9y ago

A lot. There's a talk by Alex Danilo from Google IO 17 explaining it in detail. Here, I'll link you directly to the part where he starts explaining the differences on a technical level: https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s Another part is that I suspect it makes maintaining a good JS compiler easier, because all of that asm.js code can be removed. I'm sure the browser vendors are happy about that.

TekMol 9y ago
I don't mean the technical differences. I mean the benefit. What will be the gain for the user of a web app?
- flohofwoe 9y ago
  Compressed download size is indeed only slightly smaller (mostly around 10%), but the parsing is much faster, even noticeable for fairly small demos. (edit: replied to the wrong comment, apologies)
  - TekMol 9y ago
    Is the "parsing" what is displayed as "compile script" in Chromes profiler? That seems to take almost zero time. For example jquery.min.js compiles in 0.1ms here.
    - livingparadox 9y ago
      Libraries like jquery are not the target use case for WASM. Its intent is to make large applications viable on the web, like something you'd normally install on your computer.
- Arcaten 9y ago
  I'm not 100% sure about any of this (I've only listened to most of the video above), but I think the gist is that WebAssembly provides a compile target for applications, meaning you can pre-compile an application so that your source is downloaded essentially as machine code. Furthermore, that means your compilation can perform as many optimizations that you care for, because it's happening ahead of time (not on the user's machine). Without WebAssembly, browser vendors have to strike a balance between optimizing the JS as much as possible (for increased performance), and running the script as soon as possible (so the user isn't waiting too long for execution to begin). edit: Demo of this in-browser video editor charts a FPS difference between the JS and WebAssembly implementations. https://github.com/shamadee/web-dsp https://github.com/shamadee/web-dsp

flohofwoe 9y ago

Here's a good overview from the emscripten author: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... TL;DR: much faster parsing over asm.js (10x to 20x faster), parsing should also use much less memory, 10%..20% smaller downloads (when comparing the compressed sizes, uncompressed WASM is several times smaller then asm.js), 64-bit integers (these have to be emulated on asm.js),

TekMol 9y ago
much faster parsing Isn't parsing super fast already? From my experiments, jquery seems to compile in a staggering 0.1ms.
- flohofwoe 9y ago
  I get 165ms for my 8-bit homecomputer emulator which is 534KB compressed asm.js (http://floooh.github.io/virtualkc/ http://floooh.github.io/virtualkc/), and it seems the first call into the code takes another 500ms on Chrome (probably for JIT warmup). Bigger apps like UE4 or Unity demos are several times bigger and can take seconds to compile.
- kibwen 9y ago
  The partial intent of WASM is to write things orders of magnitude larger than jQuery. Whether or not it will ever be practical to ship e.g. a complete Photoshop clone in a browser remains to be seen, but if that's your goal then you do have to start worrying about things like parse time.
  - TekMol 9y ago
    Why would the whole Photoshop be downloaded and compiled? I would expect a web app to only download the parts the I use. If I want to blur an image, I don't need the other gazillion filters for example. And hey, even if photoshop is 1000 times bigger then jquery - that would still compile in one tenth of a second.