29 ms·

Fun fact: Wasm can be be significantly slower than vanilla Javascript https://betterprogramming.pub/how-fast-is-webassembly-versus-javascript-bc0eca058a54 https

Fun fact: Wasm can be be significantly slower than vanilla Javascript https://betterprogramming.pub/how-fast-is-webassembly-versus-javascript-bc0eca058a54 https://betterprogramming.pub/how-fast-is-webassembly-versus...

maxgraey 4y ago
The article is relatively old. But I have the most complaints about the performance measurements. The WebAssembly should be tested in a way that eliminates the interop time, which is very expensive. That's why sorting and simple multiplication will always be slower if tested outside WebAssembly. Sorting in AssemblyScript is actually faster than in Rust or JavaScript: https://twitter.com/MaxGraey/status/1414867216676368384 https://twitter.com/MaxGraey/status/1414867216676368384
enos_feedler 4y ago
This might be a fact, but it certainly isn’t fun or interesting. Anybody who is framing WebAssembly into some sort of competition with javascript is completely missing the point of it’s existence. The major problem with WebAssembly right now is the major point of it’s existence is mirky. It will take time and effort from everyone using it for figure out it’s true calling, but I am hopeful and optimistic this gets discovered. In the meantime it doesn’t help to pit it against javascript.
- smegsicle 4y ago
  what should it be compared against if not javascript?
  - zamadatix 4y ago
    Any general purpose VM is fine, including the VMs behind JavaScript, but just double check that's actually what's being compared instead of inter JavaScript and VM performance. How many times per second you can call 1-5 line functions from a webpage's execution context is comparing the latter and as the article notes at the end: > definitely don’t go converting all your websites’ JavaScript to WebAssembly! However, that’s not really the aim of WebAssembly. Its aim is to enable richer experiences on the web that require higher performance, for example machine learning, virtual reality, or gaming. WASM functions aren't meant to replace small JS functions on your standard website. It's meant to be a general purpose VM you can target large amounts of non-webpage code to.
  - enos_feedler 4y ago
    Its a new thing not trying to supplant anything else.
- EGreg 4y ago
  If you can use emscripten to compile all stuff to Javascript, then what’s the point of WASM? Smaller instruction set? It’s a serious question. All the JS has the same properties, it seems, as WebAssembly. The runtime implementers can reason about it better?
  - RodgerTheGreat 4y ago
    In a nutshell, WASM is slightly more efficient than Empscripten + Asm.js because it has a binary format and circumvents the need to parse a blob of JS. That's about it, really. Whereas Asm.js had (has?) perfect backwards-compatibility with unsupported browsers and JS interpreters, WASM requires users to remain on the bleeding edge of new browser features as it continues to evolve, and introduces a whole host of fantastic new bottlenecks as the designers puzzle over how to interface WASM modules with the rest of the facilities JS can already access. The whole thing is a hilarious boondoggle- an insane amount of effort and complexity for mild bandwidth and page-load time savings- made all the more hilarious for the fact that a remarkable number of people seem unaware that Asm.js ever existed in the first place.
  - jsheard 4y ago
    https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... WASM has continued to evolve past what's possible in JS/asmjs since that article as well, with things like SIMD support
    - davidmurdoch 4y ago
      So it is about performance over JavaScript.
      - zamadatix 4y ago
        Performance against JavaScript for specific use cases (i.e. being a general purpose VM for traditional application code) is a factor. Performance against JavaScript in general (e.g. calling the same simple function in a loop) is not a factor. E.g. if you had only done rendering on a CPU and someone came by and said "we can do all sorts of stuff we couldn't do before with this GPU check it out!" it'd be easy to say "I could do all that on a CPU" and you could even show the exact same benchmarks presented here and then say "see, the CPU even runs the single threaded factorial function many more times per second than this new GPU". Everything you said would be absolutely correct in the most literal form yet it'd still be completely missing the point of why the GPU was made and how to assess if it fits that purpose better. Then someone shows you the GPU doing rendering it was designed to do well better than the CPU and the reply is "So it is about the GPU being faster than the CPU?". Yes. No. It depends what context you're asking from. Traditional use cases no, what it was designed to do well yes. The original article which talked about WASM being slower itself specifically notes this relation of purpose, functionality, and performance it's just tucked away in the conclusion: > definitely don’t go converting all your websites’ JavaScript to WebAssembly! However, that’s not really the aim of WebAssembly. Its aim is to enable richer experiences on the web that require higher performance, for example machine learning, virtual reality, or gaming.
- torginus 4y ago
  Aren't they though? Is it not possible, that in the future web pages will be scripted in literally every programming language, from python to rust, and javascript will be just one of many ways to write a webapp?
- thrashh 4y ago
  It’s not like we haven’t been down a similar path Java introduced a language and library… but the real innovation was that it introduced a cross platform VM that was supported by some organization WebAssembly is now doing the same thing… but just the cross-platform VM part Now you can run Python and JS on the JVM these days but these are not de-facto implementations and so their adoption is pretty low. I wonder if the same issue will apply to these alternate WASM implementations of existing languages.
comonoid 4y ago
I don't see WASM is slower than vanilla JavaScript. I see that calling WASM from JavaScript has certain overhead.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
vbezhenar 4y ago
IMO the main selling point of WASM is its predictable performance. It's not a secret that you can write JS which will be JIT-ed into an extremely efficient machine code. But it's a "secret" - how to write that JS. You would need seriously advanced hackers who can study V8 assembly output and correlate it with used JS features. And do it all the time, when someone changes that code. Or may be even unrelated code changes will change the way V8 compiles that particular code snippet. JS compilation is black magic. On the other hand, writing C is boring and solved problem. Compiling C to wasm works. It's predictably fast. You can use it for performance-critical code and it'll probably work without any adventures to V8 internals.
- no_wizard 4y ago
  I agree with this. One string use case I’ve seen is number crunching. Doing complex math via WASM is fast and predictable and supports a wider variety of float / integer types. Another use case I’ve toyed with is date time. Specifically trying to figure out if something like the rust Chronos crate is a better fit for crunching and calculating dates than something like date-fns or Luxon. Not sure about this one yet.
  - zamadatix 4y ago
    With Temporal on the horizon I wouldn't bother. Even if Temporal doesn't do what you want wrapper libraries that do will be very lightweight in the crunching regard https://tc39.es/proposal-temporal/docs/cookbook.html#arithmetic https://tc39.es/proposal-temporal/docs/cookbook.html#arithme...
    - no_wizard 4y ago
      This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers have asm.js / WASM support, and it goes back much farther than Temporal. Therefore with Temporal we have to consider the following: 1. Browser support - its not there yet. you'd have to polyfill. A production level polyfill is 16 KB, and is still very nasacent, and, on top of that, requires support also for BigInt[0]. The polyfill that tc39 put out is decidedly marked as non-production ready[1]. 2. Polyfilling - as mentioned above, we have to deal with polyfilling the API, and that isn't a clear and easy story yet. WASM support goes back farther than this. 3. Size - its entirely possible to get WASM builds under 16 KB, and the support is better, espcially for operations on strings and numbers (dates fit this category well). The only complication I haven't quite solved yet is: A) Can I validate that a WASM build will be under 16 KB. This is crucial. I'd even accept it at 20 KB because of wider browser support[2] B) Can I fall back to asm.js if needed (there is a slim range of browsers that support ASM.js but not WASM, mostly pre-chromium Edge[3] C) Is it performant compared to something like Luxon or date-fns? WASM excels at string / numerical operations so my sneaking suspicion is yes, at least in terms of the WASM operations. The complexity will be serializing the operations to a JS Date instance, Luxon & the Intl API might be most useful here [0]: https://github.com/fullcalendar/temporal/blob/main/packages/temporal-polyfill/README.md https://github.com/fullcalendar/temporal/blob/main/packages/... [1]: https://github.com/tc39/proposal-temporal#polyfills https://github.com/tc39/proposal-temporal#polyfills [2]: https://caniuse.com/wasm https://caniuse.com/wasm [3]: https://caniuse.com/asmjs https://caniuse.com/asmjs
cornstalks 4y ago
I’m gonna rephrase some of a previous comment[1] I made when someone else posted benchmarks like that: That is comparing WASM+JavaScript vs pure JavaScript. Unsurprisingly there’s some interop overhead. Those benchmarks are not relevant if you’re not using JavaScript (e.g. WASI stuff) or you’re doing the bulk of your calculations in WASM and not rapidly jumping back and forth between WASM and JavaScript. [1]: https://news.ycombinator.com/item?id=30157954 https://news.ycombinator.com/item?id=30157954
torginus 4y ago
I think that article needs some work - for one, it admittedly didn't account for the startup time WASM needs to compile the bytecode. Second, I'm not familiar with AssemblyScript - but I wouldn't be surprised if its performance wasn't up to something like C++, and some of the benchmarks test stuff like the builtin sort which depends massively on the quality of the standard library.
nikki93 4y ago
The main benefits are being able to use the same codebase for native and web builds and also not needing to use a GC and being able to do memory management yourself. The latter stuff really makes a positive difference for Wasm in eg. graphics / games. Can be less pronounced if the app mainly does DOM manipulation potentially due to the API boundary.
svantana 4y ago
Not refuting the results, but that has got to be the worst, laziest benchmarking I've seen in a long time.
flohofwoe 4y ago
The first benchmark isn't measuring the performance of WASM, but the calling overhead from JS to WASM (which is pretty small, but it's still an optimization barrier for the JS engine). The second benchmark isn't measuring the performance of Javascript, but the performance of the Javascript sort() call (which most likely is implemented as native code). In general, WASM should be both in the same ballpark as portable natively compiled code (e.g. not using SIMD), as well as Javascript which has been written for performance (which also means that well written - but non-idiomatic - Javascript can be in the same ballpark as portable native code). The main advantage of WASM versus JS isn't mainly performance, but predictable performance (because the GC is taken out of the picture, and the linear memory model), and that WASM is a better compilation target than JS.

maxgraey 4y ago

The article is relatively old. But I have the most complaints about the performance measurements. The WebAssembly should be tested in a way that eliminates the interop time, which is very expensive. That's why sorting and simple multiplication will always be slower if tested outside WebAssembly. Sorting in AssemblyScript is actually faster than in Rust or JavaScript: https://twitter.com/MaxGraey/status/1414867216676368384 https://twitter.com/MaxGraey/status/1414867216676368384

enos_feedler 4y ago

This might be a fact, but it certainly isn’t fun or interesting. Anybody who is framing WebAssembly into some sort of competition with javascript is completely missing the point of it’s existence. The major problem with WebAssembly right now is the major point of it’s existence is mirky. It will take time and effort from everyone using it for figure out it’s true calling, but I am hopeful and optimistic this gets discovered. In the meantime it doesn’t help to pit it against javascript.

smegsicle 4y ago
what should it be compared against if not javascript?
- zamadatix 4y ago
  Any general purpose VM is fine, including the VMs behind JavaScript, but just double check that's actually what's being compared instead of inter JavaScript and VM performance. How many times per second you can call 1-5 line functions from a webpage's execution context is comparing the latter and as the article notes at the end: > definitely don’t go converting all your websites’ JavaScript to WebAssembly! However, that’s not really the aim of WebAssembly. Its aim is to enable richer experiences on the web that require higher performance, for example machine learning, virtual reality, or gaming. WASM functions aren't meant to replace small JS functions on your standard website. It's meant to be a general purpose VM you can target large amounts of non-webpage code to.
- enos_feedler 4y ago
  Its a new thing not trying to supplant anything else.
EGreg 4y ago
If you can use emscripten to compile all stuff to Javascript, then what’s the point of WASM? Smaller instruction set? It’s a serious question. All the JS has the same properties, it seems, as WebAssembly. The runtime implementers can reason about it better?
- RodgerTheGreat 4y ago
  In a nutshell, WASM is slightly more efficient than Empscripten + Asm.js because it has a binary format and circumvents the need to parse a blob of JS. That's about it, really. Whereas Asm.js had (has?) perfect backwards-compatibility with unsupported browsers and JS interpreters, WASM requires users to remain on the bleeding edge of new browser features as it continues to evolve, and introduces a whole host of fantastic new bottlenecks as the designers puzzle over how to interface WASM modules with the rest of the facilities JS can already access. The whole thing is a hilarious boondoggle- an insane amount of effort and complexity for mild bandwidth and page-load time savings- made all the more hilarious for the fact that a remarkable number of people seem unaware that Asm.js ever existed in the first place.
- jsheard 4y ago
  https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... WASM has continued to evolve past what's possible in JS/asmjs since that article as well, with things like SIMD support
  - davidmurdoch 4y ago
    So it is about performance over JavaScript.
    - zamadatix 4y ago
      Performance against JavaScript for specific use cases (i.e. being a general purpose VM for traditional application code) is a factor. Performance against JavaScript in general (e.g. calling the same simple function in a loop) is not a factor. E.g. if you had only done rendering on a CPU and someone came by and said "we can do all sorts of stuff we couldn't do before with this GPU check it out!" it'd be easy to say "I could do all that on a CPU" and you could even show the exact same benchmarks presented here and then say "see, the CPU even runs the single threaded factorial function many more times per second than this new GPU". Everything you said would be absolutely correct in the most literal form yet it'd still be completely missing the point of why the GPU was made and how to assess if it fits that purpose better. Then someone shows you the GPU doing rendering it was designed to do well better than the CPU and the reply is "So it is about the GPU being faster than the CPU?". Yes. No. It depends what context you're asking from. Traditional use cases no, what it was designed to do well yes. The original article which talked about WASM being slower itself specifically notes this relation of purpose, functionality, and performance it's just tucked away in the conclusion: > definitely don’t go converting all your websites’ JavaScript to WebAssembly! However, that’s not really the aim of WebAssembly. Its aim is to enable richer experiences on the web that require higher performance, for example machine learning, virtual reality, or gaming.
torginus 4y ago
Aren't they though? Is it not possible, that in the future web pages will be scripted in literally every programming language, from python to rust, and javascript will be just one of many ways to write a webapp?
thrashh 4y ago
It’s not like we haven’t been down a similar path Java introduced a language and library… but the real innovation was that it introduced a cross platform VM that was supported by some organization WebAssembly is now doing the same thing… but just the cross-platform VM part Now you can run Python and JS on the JVM these days but these are not de-facto implementations and so their adoption is pretty low. I wonder if the same issue will apply to these alternate WASM implementations of existing languages.

comonoid 4y ago

I don't see WASM is slower than vanilla JavaScript. I see that calling WASM from JavaScript has certain overhead.

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]

vbezhenar 4y ago

IMO the main selling point of WASM is its predictable performance. It's not a secret that you can write JS which will be JIT-ed into an extremely efficient machine code. But it's a "secret" - how to write that JS. You would need seriously advanced hackers who can study V8 assembly output and correlate it with used JS features. And do it all the time, when someone changes that code. Or may be even unrelated code changes will change the way V8 compiles that particular code snippet. JS compilation is black magic. On the other hand, writing C is boring and solved problem. Compiling C to wasm works. It's predictably fast. You can use it for performance-critical code and it'll probably work without any adventures to V8 internals.

no_wizard 4y ago
I agree with this. One string use case I’ve seen is number crunching. Doing complex math via WASM is fast and predictable and supports a wider variety of float / integer types. Another use case I’ve toyed with is date time. Specifically trying to figure out if something like the rust Chronos crate is a better fit for crunching and calculating dates than something like date-fns or Luxon. Not sure about this one yet.
- zamadatix 4y ago
  With Temporal on the horizon I wouldn't bother. Even if Temporal doesn't do what you want wrapper libraries that do will be very lightweight in the crunching regard https://tc39.es/proposal-temporal/docs/cookbook.html#arithmetic https://tc39.es/proposal-temporal/docs/cookbook.html#arithme...
  - no_wizard 4y ago
    This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers have asm.js / WASM support, and it goes back much farther than Temporal. Therefore with Temporal we have to consider the following: 1. Browser support - its not there yet. you'd have to polyfill. A production level polyfill is 16 KB, and is still very nasacent, and, on top of that, requires support also for BigInt[0]. The polyfill that tc39 put out is decidedly marked as non-production ready[1]. 2. Polyfilling - as mentioned above, we have to deal with polyfilling the API, and that isn't a clear and easy story yet. WASM support goes back farther than this. 3. Size - its entirely possible to get WASM builds under 16 KB, and the support is better, espcially for operations on strings and numbers (dates fit this category well). The only complication I haven't quite solved yet is: A) Can I validate that a WASM build will be under 16 KB. This is crucial. I'd even accept it at 20 KB because of wider browser support[2] B) Can I fall back to asm.js if needed (there is a slim range of browsers that support ASM.js but not WASM, mostly pre-chromium Edge[3] C) Is it performant compared to something like Luxon or date-fns? WASM excels at string / numerical operations so my sneaking suspicion is yes, at least in terms of the WASM operations. The complexity will be serializing the operations to a JS Date instance, Luxon & the Intl API might be most useful here [0]: https://github.com/fullcalendar/temporal/blob/main/packages/temporal-polyfill/README.md https://github.com/fullcalendar/temporal/blob/main/packages/... [1]: https://github.com/tc39/proposal-temporal#polyfills https://github.com/tc39/proposal-temporal#polyfills [2]: https://caniuse.com/wasm https://caniuse.com/wasm [3]: https://caniuse.com/asmjs https://caniuse.com/asmjs

cornstalks 4y ago

I’m gonna rephrase some of a previous comment[1] I made when someone else posted benchmarks like that: That is comparing WASM+JavaScript vs pure JavaScript. Unsurprisingly there’s some interop overhead. Those benchmarks are not relevant if you’re not using JavaScript (e.g. WASI stuff) or you’re doing the bulk of your calculations in WASM and not rapidly jumping back and forth between WASM and JavaScript. [1]: https://news.ycombinator.com/item?id=30157954 https://news.ycombinator.com/item?id=30157954

torginus 4y ago

I think that article needs some work - for one, it admittedly didn't account for the startup time WASM needs to compile the bytecode. Second, I'm not familiar with AssemblyScript - but I wouldn't be surprised if its performance wasn't up to something like C++, and some of the benchmarks test stuff like the builtin sort which depends massively on the quality of the standard library.

nikki93 4y ago

The main benefits are being able to use the same codebase for native and web builds and also not needing to use a GC and being able to do memory management yourself. The latter stuff really makes a positive difference for Wasm in eg. graphics / games. Can be less pronounced if the app mainly does DOM manipulation potentially due to the API boundary.

svantana 4y ago

Not refuting the results, but that has got to be the worst, laziest benchmarking I've seen in a long time.

flohofwoe 4y ago

The first benchmark isn't measuring the performance of WASM, but the calling overhead from JS to WASM (which is pretty small, but it's still an optimization barrier for the JS engine). The second benchmark isn't measuring the performance of Javascript, but the performance of the Javascript sort() call (which most likely is implemented as native code). In general, WASM should be both in the same ballpark as portable natively compiled code (e.g. not using SIMD), as well as Javascript which has been written for performance (which also means that well written - but non-idiomatic - Javascript can be in the same ballpark as portable native code). The main advantage of WASM versus JS isn't mainly performance, but predictable performance (because the GC is taken out of the picture, and the linear memory model), and that WASM is a better compilation target than JS.