5 ms·

Is WebAssembly faster than JavaScript? Any good benchmarks you can link me to? I found one of Daniel Lemire's [0] from 2018 which seems to suggest it's basical

Is WebAssembly faster than JavaScript? Any good benchmarks you can link me to? I found one of Daniel Lemire's [0] from 2018 which seems to suggest it's basically not much faster. 2018 is long enough away from now though that this post may not be relevant. I don't know. It's odd to me how WebAssembly seemed to be started as a way to get performance improvements by working with cached instructions (and maybe also explicit memory management and integer types) but I don't hear much about performance these days. Maybe I'm not paying attention. Instead I hear more about it as a universal platform or a way you can run C/C++ code in the browser (like tree-sitter and CPython and Ruby, etc.). Or about people using it in edge compute or as the engine for smart contracts. In those ways you could just as well have used the JVM though. [0] https://lemire.me/blog/2018/10/23/is-webassembly-faster-than-javascript/ https://lemire.me/blog/2018/10/23/is-webassembly-faster-than...

joren- 5y ago
I do see some improvements for FFT workloads. The SIMD webassembly version is quite a bit faster. Try it yourself: https://0110.be/posts/pffft.wasm%3A_an_FFT_library_for_the_web https://0110.be/posts/pffft.wasm%3A_an_FFT_library_for_the_w...
GiorgioG 5y ago
I don't care if it's faster, the same or even slightly slower. The sooner I can start working on large applications with a strongly typed language (that isn't just transpiled to JS) - the better.
- eatonphil 5y ago
  My point is that compilation targets are somewhat arbitrary. Non-JavaScript languages have been compiling to JavaScript for a long time. What difference does it make for you as a user of a language that it compiles to webassembly than to JavaScript or any other VM?
  - laszlokorte 5y ago
    JavaScript being garbage-collected, having a rather complex runtime, not having proper integers etc... makes it a rather unfortunate compile target. Yes you can do it and it is done but js idiosyncrasies leak into the source langues pretty easily.
    - eatonphil 5y ago
      That's a good argument but more of a maintainer argument than a user argument. From a user it should be transparent except for performance and FFIs.
      - laszlokorte 5y ago
        Well the user perspective is: suddenly there a compilers for all kind of languages targetting the browser because wasm makes it easier for the maintainers to build them. Sure you could have implemented unsigned integer semantics on top of bool-arrays in javascript years ago but if the result is too slow you have gained because the compiled c++ code does not run fast enough to be usable.
        josephg 5y ago
        Regarding numbers, Javascript supports bigints now - which makes the situation a little bit better. (But maybe a lot more complex). I wish they were somehow better supported by JSON.parse though. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - spiffytech 5y ago
    Compile-to-JS is a leaky abstraction that gets messy when JavaScript's type system and built-ins collide with your language's. Some languages also need specialized tooling for their compile-to-JS stuff, rather than treating it as just another compile target. I usually find it causes more problems than it solves, but I'm hopeful that someday WebAssembly can make compile-for-Web transparent enough that non-JS languages really feel like a great experience in the browser.
- cercatrova 5y ago
  You could use Dart I guess, Flutter is similar to WASM apps like Figma in that they manipulate a canvas, not the DOM directly. I'd assume most WASM apps in the future will look more like that than true DOM manipulation. There are others however, such as Yew written in Rust, or Blazor in C#.
  - mhoad 5y ago
    Interestingly enough Dart is also pretty deep into adding WASM as a compile target to act as an alternative to the current compile to optimised JS approach they do currently in the browser. You are right though they are going to be the first big WASM / Canvas and WebGPU framework as opposed to the generations of JS / DOM. It will be interesting to see where they land with it, I’m quietly hopeful especially once you get AOM sorted in the browser too. I think the real test is going to be when they decide to migrate over the multiple billion dollars of revenue project that Google Ads is from JS based Dart to WASM based Dart. Work going on here but not much to look at now just source and no docs https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm
titzer 5y ago
I think Lemire's measurements are unacceptably lazy. WebAssembly is faster than JavaScript on the right things; there are many measurements showing this. Typically, measurements that show JS on par or beating Wasm either end up falling into microbenchmarking traps (one small, hot loop, something gets deadcode-eliminated), or they end up relying on a particular type of dynamic optimization that Wasm engines don't yet do (inlining, escape analysis). With SIMD and threads, Wasm can absolutely crush JS performance. https://www.infoq.com/articles/webassembly-simd-multithreading-performance-gains/ https://www.infoq.com/articles/webassembly-simd-multithreadi...
- native_samples 5y ago
  Isn't SIMD new in this release of the spec? How can WASM crush JS using SIMD if they only just added support?
  - titzer 5y ago
    It's been implemented in browsers for longer than the spec has been out. In fact, one condition of a proposal being merged into the spec is that two production engines must have implemented it.
- torginus 5y ago
  Why would Wasm engines need to do inlining and dead code elimination? My impression was that Wasm is basically native level-code, save for register allocation, and some arch-specific peephole optimizations. Dead code elimination is the job of the C++ compiler.
  - titzer 5y ago
    Generally, I don't disagree, but not all producers are LLVM. And JS inlining is driven by dynamic heuristics, speculatively inlining likely candidates, whereas statically-compiled C++ code generally doesn't have speculative inlining. So a Wasm call_indirect will not get dynamically optimized into a guarded inline.
josephg 5y ago
The big thing that makes javascript slow (that the optimizer can’t really fix) is complex data structures. For example, if you want to implement an editable string, you have to do so using an array of smaller strings and hope the optimizer can figure it out, or slice() and re-join a single “immutable” string. Either way, your javascript code will be slower than the C/rust equivalent because the language is less expressive. Javascript has the same problem with b-trees, skip lists, ropes, gap buffers, AABB trees, and so on. You can implement all of this stuff in javascript - you just end up with much more memory indirection than you want. And for trees with different internal nodes and leaves, your code will give the optimizer indigestion. In my experience, basically any of these data structures will run about 10-200x slower than their native counterparts. (If both are well optimized). To me this is the big performance advantage wasm has - that we can make high performance data structures. I’m working on a CRDT in Rust. The fastest JS implementation I know of takes about 1 second to replay an editing trace from a user. In rust I can replay the same trace in 0.01 seconds (100x faster), by using a skip list. In wasm I can do it in about 0.03 seconds.
- criticaltinker 5y ago
  Adding to this great comment with my own experience at work where we extensively use signal processing and time series compression algorithms to visualize large amounts of biological signals in the browser. WebAssembly is less than 10%-20% slower than native code in our benchmarks and tests for algorithms like fast wavelet transform and bit packing. WA allows us to aggressively optimize ahead of time when compiling, and be less sensitive to JS engine performance pitfalls around JIT optimization and garbage collection.
  - pistachiopro 5y ago
    Throwing in my data: for physics simulation code, WASM vs native was identical, provided the native code was compiled with automatic SIMD optimizations disabled. On the one hand, that speaks well of the idea of web assembly, on the other, disabling SIMD is highly artificial. It's good to see basic SIMD being made standard, though the 256-bit wide SIMD instructions are still being finalized, and those will be necessary to really have a chance at evening out performance vs. native.
3np 5y ago
This post (discussed on HN recently) goes into some of it and provides some further links. TL;DR: It depends. https://zaplib.com/docs/blog_ts++.html https://zaplib.com/docs/blog_ts++.html
alephnan 5y ago
http://iswebassemblyfastyet.com http://iswebassemblyfastyet.com

joren- 5y ago

I do see some improvements for FFT workloads. The SIMD webassembly version is quite a bit faster. Try it yourself: https://0110.be/posts/pffft.wasm%3A_an_FFT_library_for_the_web https://0110.be/posts/pffft.wasm%3A_an_FFT_library_for_the_w...

GiorgioG 5y ago

I don't care if it's faster, the same or even slightly slower. The sooner I can start working on large applications with a strongly typed language (that isn't just transpiled to JS) - the better.

eatonphil 5y ago
My point is that compilation targets are somewhat arbitrary. Non-JavaScript languages have been compiling to JavaScript for a long time. What difference does it make for you as a user of a language that it compiles to webassembly than to JavaScript or any other VM?
- laszlokorte 5y ago
  JavaScript being garbage-collected, having a rather complex runtime, not having proper integers etc... makes it a rather unfortunate compile target. Yes you can do it and it is done but js idiosyncrasies leak into the source langues pretty easily.
  - eatonphil 5y ago
    That's a good argument but more of a maintainer argument than a user argument. From a user it should be transparent except for performance and FFIs.
    - laszlokorte 5y ago
      Well the user perspective is: suddenly there a compilers for all kind of languages targetting the browser because wasm makes it easier for the maintainers to build them. Sure you could have implemented unsigned integer semantics on top of bool-arrays in javascript years ago but if the result is too slow you have gained because the compiled c++ code does not run fast enough to be usable.
      - josephg 5y ago
        Regarding numbers, Javascript supports bigints now - which makes the situation a little bit better. (But maybe a lot more complex). I wish they were somehow better supported by JSON.parse though. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- spiffytech 5y ago
  Compile-to-JS is a leaky abstraction that gets messy when JavaScript's type system and built-ins collide with your language's. Some languages also need specialized tooling for their compile-to-JS stuff, rather than treating it as just another compile target. I usually find it causes more problems than it solves, but I'm hopeful that someday WebAssembly can make compile-for-Web transparent enough that non-JS languages really feel like a great experience in the browser.
cercatrova 5y ago
You could use Dart I guess, Flutter is similar to WASM apps like Figma in that they manipulate a canvas, not the DOM directly. I'd assume most WASM apps in the future will look more like that than true DOM manipulation. There are others however, such as Yew written in Rust, or Blazor in C#.
- mhoad 5y ago
  Interestingly enough Dart is also pretty deep into adding WASM as a compile target to act as an alternative to the current compile to optimised JS approach they do currently in the browser. You are right though they are going to be the first big WASM / Canvas and WebGPU framework as opposed to the generations of JS / DOM. It will be interesting to see where they land with it, I’m quietly hopeful especially once you get AOM sorted in the browser too. I think the real test is going to be when they decide to migrate over the multiple billion dollars of revenue project that Google Ads is from JS based Dart to WASM based Dart. Work going on here but not much to look at now just source and no docs https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm

titzer 5y ago

I think Lemire's measurements are unacceptably lazy. WebAssembly is faster than JavaScript on the right things; there are many measurements showing this. Typically, measurements that show JS on par or beating Wasm either end up falling into microbenchmarking traps (one small, hot loop, something gets deadcode-eliminated), or they end up relying on a particular type of dynamic optimization that Wasm engines don't yet do (inlining, escape analysis). With SIMD and threads, Wasm can absolutely crush JS performance. https://www.infoq.com/articles/webassembly-simd-multithreading-performance-gains/ https://www.infoq.com/articles/webassembly-simd-multithreadi...

native_samples 5y ago
Isn't SIMD new in this release of the spec? How can WASM crush JS using SIMD if they only just added support?
- titzer 5y ago
  It's been implemented in browsers for longer than the spec has been out. In fact, one condition of a proposal being merged into the spec is that two production engines must have implemented it.
torginus 5y ago
Why would Wasm engines need to do inlining and dead code elimination? My impression was that Wasm is basically native level-code, save for register allocation, and some arch-specific peephole optimizations. Dead code elimination is the job of the C++ compiler.
- titzer 5y ago
  Generally, I don't disagree, but not all producers are LLVM. And JS inlining is driven by dynamic heuristics, speculatively inlining likely candidates, whereas statically-compiled C++ code generally doesn't have speculative inlining. So a Wasm call_indirect will not get dynamically optimized into a guarded inline.

josephg 5y ago

The big thing that makes javascript slow (that the optimizer can’t really fix) is complex data structures. For example, if you want to implement an editable string, you have to do so using an array of smaller strings and hope the optimizer can figure it out, or slice() and re-join a single “immutable” string. Either way, your javascript code will be slower than the C/rust equivalent because the language is less expressive. Javascript has the same problem with b-trees, skip lists, ropes, gap buffers, AABB trees, and so on. You can implement all of this stuff in javascript - you just end up with much more memory indirection than you want. And for trees with different internal nodes and leaves, your code will give the optimizer indigestion. In my experience, basically any of these data structures will run about 10-200x slower than their native counterparts. (If both are well optimized). To me this is the big performance advantage wasm has - that we can make high performance data structures. I’m working on a CRDT in Rust. The fastest JS implementation I know of takes about 1 second to replay an editing trace from a user. In rust I can replay the same trace in 0.01 seconds (100x faster), by using a skip list. In wasm I can do it in about 0.03 seconds.

criticaltinker 5y ago
Adding to this great comment with my own experience at work where we extensively use signal processing and time series compression algorithms to visualize large amounts of biological signals in the browser. WebAssembly is less than 10%-20% slower than native code in our benchmarks and tests for algorithms like fast wavelet transform and bit packing. WA allows us to aggressively optimize ahead of time when compiling, and be less sensitive to JS engine performance pitfalls around JIT optimization and garbage collection.
- pistachiopro 5y ago
  Throwing in my data: for physics simulation code, WASM vs native was identical, provided the native code was compiled with automatic SIMD optimizations disabled. On the one hand, that speaks well of the idea of web assembly, on the other, disabling SIMD is highly artificial. It's good to see basic SIMD being made standard, though the 256-bit wide SIMD instructions are still being finalized, and those will be necessary to really have a chance at evening out performance vs. native.

3np 5y ago

This post (discussed on HN recently) goes into some of it and provides some further links. TL;DR: It depends. https://zaplib.com/docs/blog_ts++.html https://zaplib.com/docs/blog_ts++.html

alephnan 5y ago

http://iswebassemblyfastyet.com http://iswebassemblyfastyet.com