51–60 of 97 posts
1247 px/ms Chrome JS
1681 px/ms Firefox JS
5878 px/ms Chrome WASM
6382 px/ms Firefox WASMThese comparisons are always highly biased by the kind of work being done. V8 is so good at optimizing code, it's usually possible to reach similar performance in JS. See https://surma.dev/things/js-to-asc/ Not that relevant, but it looks pretty terrible on a hi-dpi screen, it's probably not accounting for the pixel density when creating the canvas. Looks much better on a normal screen.
> V8 is so good at optimizing code, it's usually possible to reach similar performance in JS. It often is, but unless your code is purely numerical (in which case V8 is fast by default) you have write very awkward code to make JavaScript fast. On the other hand you can often transliterate JS code 1:1 into Rust and it'll be 10x faster.
mraleph then went through a pretty epic bout of algorithmic improvement and engine-specific optimisations, reaching not quite parity with the rust/wasm version but close (Maybe you don’t need Rust and WASM to speed up JS).
Nick Fitzgerald was then able to relatively easily add the algorithmic improvements to the WASM version for an other 3x gain (~10x total from the original) (Speed Without Wizardry).
These comparisons are always highly biased by the kind of work being done. V8 is so good at optimizing code, it's usually possible to reach similar performance in JS. See https://surma.dev/things/js-to-asc/ Not that relevant, but it looks pretty terrible on a hi-dpi screen, it's probably not accounting for the pixel density when creating the canvas. Looks much better on a normal screen.
IMO we need to start building UI frameworks that are powered by WASM, and then benchmark those as compared to JS equivalent.
The difference in performance is about 3x and it looks like an pretty ideal case for wasm. Seems to match observations from Zaplip portmortem: > Rust is faster than JS in some cases, but those cases are rarer than we expected, and the performance gain is on the order of 2x some of the time, not 10x most of the time. https://zaplib.com/docs/blog_post_mortem.html
Separately, though, on very large applications wasm does have an advantage on startup times: there is no warmup period as the JIT learns the types, no sluggish first frames for the entire application or the first time you click on a feature that hits a new code path. For something like Photoshop or a game engine that can be a very big deal. But, again, this type of application is not the most common, so JS will remain the best option for most things.
Earlier quoted context omitted.
That's kind of an underrated aspect of these comparisons - while you absolutely can work around Javascript's weird performance cliffs and avoid putting pressure on the garbage collector, you have to fight the language at every turn because so many idiomatic JS patterns are inherently slow or flood the GC. You may find idiomatic JS easier to work with than something like Rust, but Rust is much easier to work with than…
The rust code is 3x as long and a lot more complex too. In theory, static typing would correct the biggest performance issues in JS (use monomorphic functions, don't mutate objects, and limit arrays of just one primitive/object type). In practice, TypeScript allows and encourages you to create types that are horrendous for performance. I'd love to see a comparison using AssemblyScript (basically stricter TS for WASM)…
but the core loop in Rust is pretty straightforward. It could have been shortened and optimized further.
Also keep in mind that the larger the project, the harder it gets to keep JS in the performance sweet spot without tipping over any JIT heuristic, using GC, or accidentally causing a perf cliff, while the Rust has pretty stable and deterministic optimizations and keeps its memory management control at any scale.
Earlier quoted context omitted.
> V8 is so good at optimizing code, it's usually possible to reach similar performance in JS. It often is, but unless your code is purely numerical (in which case V8 is fast by default) you have write very awkward code to make JavaScript fast. On the other hand you can often transliterate JS code 1:1 into Rust and it'll be 10x faster.
That is well demonstrated by the sourcemap events from 2018: Mozilla replaced part of the source-map JS library by a straightforward Rust rewrite compiled to WASM, yielding a 5.9x speed improvement (with much less variance to boot) (Oxidising Source Maps with Rust and WebAssembly). mraleph then went through a pretty epic bout of algorithmic improvement and engine-specific optimisations, reaching not quite parity with…
- Oxidising Source Maps with Rust and WebAssembly: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...
- Maybe you don’t need Rust and WASM to speed up JS: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
- Speed Without Wizardry: https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry...
Earlier quoted context omitted.
The fact that it was written in Rust (or any other non-VM lang) is meaningful because programs written in a Language that needs a VM (All the GC'd languages for example) need the vm to be shipped as well. Thus, making the WASM-program larger and slower.
Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.
Larger runtimes not only add bloat to the final WebAssembly, but they also can make interoperating harder because they often require more (i.e. any) bookkeeping when sending stuff back and forth.
also worth mentioning is that this is why people build projects like TinyGo and MicroPython – they love the language, but can't work with the trade-offs that the designers chose
Earlier quoted context omitted.
Maybe Runtime or Runtime System is a better word than VM? Go has _something_ that manages Go routines and GC and so on.
Sure, but Rust can have a runtime, and presumably Rust on WASM does. If you don't have a runtime in Rust you only get core. https://doc.rust-lang.org/core/ This has obvious effects (you don't have an allocator so you can't have String) and more subtle effects (your slices don't have a sort() method! However they do have a sort_unstable() method) but while it's probably a reasonable environment for the firmware inside…