3 ms·

Keep in mind that WebAssembly is not a silver bullet for performance, and carefully crafted JS application (written in engine-friendly way) will perform roughly

Keep in mind that WebAssembly is not a silver bullet for performance, and carefully crafted JS application (written in engine-friendly way) will perform roughly the same or even better than its WA equivalent. I've rewritten chunk of my math-intensive app in AssemblyScript half a year ago - it took me about a month to fight through all the compiler bugs, I used every optimization possible (used floats everywhere, disabled array boundary checks, disabled GC for 70% of classes) and still end up with a binary that is 30% slower than the original JS code. It was mostly AssemblyScript's GC, which was extremely slow (and probably still is), and with GC completely disabled (which is an unfair advantage for WA) performance was almost the same.

maxgraey 6y ago
That's pretty interesting. Could you share you project? There are benchmark which compare JavaScript and AssemblyScript: https://github.com/nischayv/as-benchmarks https://github.com/nischayv/as-benchmarks https://github.com/nischayv/as-benchmarks/issues/3#issuecomment-623159721 https://github.com/nischayv/as-benchmarks/issues/3#issuecomm...
- v_pragma 6y ago
  Unfortunately, no, it's a commercial closed-source project. I profiled both JS and WA versions, the hottest methods took basically the same amount of time in both versions, except that WA build additionally spend ~25% of all time in __retain or something like that.
  - maxgraey 6y ago
    Do you intensive use small objects like Vec3, Quaternion and etc? AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now. All this significantly reduce ARC / memory pressure. But my assumption it could be also wrong measurement. Most of people uses benchmark.js which also measure js <-> wasm interop overhead which usually main bottleneck.
    - v_pragma 6y ago
      > AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now. Yes, I do use a lot of small objects. That's an interesting information, I'll keep an eye on multi-value proposal, thank you! > Most of people uses benchmark.js which also measure js <-> wasm interop overhead which usually main bottleneck. Nope, I loaded all the data into WA module upon initialization and don't perform any additional synchronization between WA and JS afterwards (which is also kind of unfair advantage for WA).
- deleted 6y ago
  [deleted]
- benjamin-lee 6y ago
  I'm not the OP but I can confirm in my own project, we found about a 10x performance gap between AssemblyScript and TypeScript. In essence, we're working on a rewrite of DNAVisualization.org[1][2], a serverless web tool for the interactive inspection of raw DNA sequences. We hoped that WASM would give us a performance boost but have been generally disappointed with both the performance and the amount of complexity involved in getting the tooling to work. We did do a benchmark[3] and, unless we made an error (likely, given that all of us are new to WASM), found that JS was much faster for our simple algorithms. WASM had the approximate performance of our original pure Python implementation[4], so not great. [1]: https://dnavisualization.org https://dnavisualization.org [2]: https://academic.oup.com/nar/article/47/W1/W20/5512090 https://academic.oup.com/nar/article/47/W1/W20/5512090 [3]: https://github.com/Lab41/dnaviz/tree/benchmarks/benchmarks/a.. https://github.com/Lab41/dnaviz/tree/benchmarks/benchmarks/a.... [4]: https://github.com/Lab41/squiggle https://github.com/Lab41/squiggle
  - maxgraey 6y ago
    I made PR which suggest some changes and fixes: https://github.com/Lab41/dnaviz/pull/21 https://github.com/Lab41/dnaviz/pull/21
    - maxgraey 6y ago
      As you can see AssemblyScript approx 4x-4.5x times faster now
brabel 6y ago
You can't judge the performance of WASM solely based on experiments you made using AssemblyScript (a TypeScript subset that compiles directly to WASM). As WASM is meant to be a low level compiler target, a proper comparison would be with binaries produced by the Rust or C compilers that don't rely on a specific GC implementation.
- v_pragma 6y ago
  GC aside, I've inspected assembly code (.wast files) for top 10 hottest methods in my code, and it was pretty much perfect, Rust and C will probably end up with something similar. However, there was no performance improvements whatsoever, those methods performed similarly to their JS equivalents. UPD: modern JS engines are extremely capable of optimizing stuff and they can probably come up with machine code similar to what Rust or C will produce given that you keep your code predictable and optimization-friendly.

maxgraey 6y ago

That's pretty interesting. Could you share you project? There are benchmark which compare JavaScript and AssemblyScript: https://github.com/nischayv/as-benchmarks https://github.com/nischayv/as-benchmarks https://github.com/nischayv/as-benchmarks/issues/3#issuecomment-623159721 https://github.com/nischayv/as-benchmarks/issues/3#issuecomm...

v_pragma 6y ago
Unfortunately, no, it's a commercial closed-source project. I profiled both JS and WA versions, the hottest methods took basically the same amount of time in both versions, except that WA build additionally spend ~25% of all time in __retain or something like that.
- maxgraey 6y ago
  Do you intensive use small objects like Vec3, Quaternion and etc? AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now. All this significantly reduce ARC / memory pressure. But my assumption it could be also wrong measurement. Most of people uses benchmark.js which also measure js <-> wasm interop overhead which usually main bottleneck.
  - v_pragma 6y ago
    > AS hasn't scalar replacement optimization pass yet which JavaScript definitely has. Also it will be much better after implementing tuple / records which depends on multi-value proposal for now. Yes, I do use a lot of small objects. That's an interesting information, I'll keep an eye on multi-value proposal, thank you! > Most of people uses benchmark.js which also measure js <-> wasm interop overhead which usually main bottleneck. Nope, I loaded all the data into WA module upon initialization and don't perform any additional synchronization between WA and JS afterwards (which is also kind of unfair advantage for WA).
deleted 6y ago
[deleted]
benjamin-lee 6y ago
I'm not the OP but I can confirm in my own project, we found about a 10x performance gap between AssemblyScript and TypeScript. In essence, we're working on a rewrite of DNAVisualization.org[1][2], a serverless web tool for the interactive inspection of raw DNA sequences. We hoped that WASM would give us a performance boost but have been generally disappointed with both the performance and the amount of complexity involved in getting the tooling to work. We did do a benchmark[3] and, unless we made an error (likely, given that all of us are new to WASM), found that JS was much faster for our simple algorithms. WASM had the approximate performance of our original pure Python implementation[4], so not great. [1]: https://dnavisualization.org https://dnavisualization.org [2]: https://academic.oup.com/nar/article/47/W1/W20/5512090 https://academic.oup.com/nar/article/47/W1/W20/5512090 [3]: https://github.com/Lab41/dnaviz/tree/benchmarks/benchmarks/a.. https://github.com/Lab41/dnaviz/tree/benchmarks/benchmarks/a.... [4]: https://github.com/Lab41/squiggle https://github.com/Lab41/squiggle
- maxgraey 6y ago
  I made PR which suggest some changes and fixes: https://github.com/Lab41/dnaviz/pull/21 https://github.com/Lab41/dnaviz/pull/21
  - maxgraey 6y ago
    As you can see AssemblyScript approx 4x-4.5x times faster now

brabel 6y ago

You can't judge the performance of WASM solely based on experiments you made using AssemblyScript (a TypeScript subset that compiles directly to WASM). As WASM is meant to be a low level compiler target, a proper comparison would be with binaries produced by the Rust or C compilers that don't rely on a specific GC implementation.

v_pragma 6y ago
GC aside, I've inspected assembly code (.wast files) for top 10 hottest methods in my code, and it was pretty much perfect, Rust and C will probably end up with something similar. However, there was no performance improvements whatsoever, those methods performed similarly to their JS equivalents. UPD: modern JS engines are extremely capable of optimizing stuff and they can probably come up with machine code similar to what Rust or C will produce given that you keep your code predictable and optimization-friendly.