I can't see any numbers comparing the rust implementation and the optimised javascript. Did I miss them in the article?
Maybe you don't need Rust and WASM to speed up your JS
31–40 of 186 posts
Re: Maybe you don't need Rust and WASM to speed up your JS
#32This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language.
At the end of the article, the author wisely chooses to move some objects out of the control of the GC:
We are allocating hundreds of thousands Mapping objects, which puts considerable pressure on GC - in reality we don’t really need those objects to be objects... First of all, I changed Mapping from a normal object into a wrapper that points into a gigantic typed array...
This suggests to me that we are no longer programming the way one usually does in a dynamically typed, garbage collected language -- and thus it might still be the right decision to move to something like Rust (or Swift or Go) where there is considerably more control over allocation.
The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation. There are benefits to having all ones code in the same language; but there are also benefits to switching languages to obtain better ergonomics and safety properties.
Re: Maybe you don't need Rust and WASM to speed up your JS
#33Maybe there should be a tool from linters or VMs to warn against arguments adaptation, monomorphisation. For the rest it is a lot of know how is JS that is for free in with more performance minded languages. At the end with the optimized JS is is 4 times faster, but still 6 times faster in WASM it seems.
It's only necessary in edge cases of super-hot code, avoiding argument adaptation "because performance" is a bad idea.
It's also a v8 specific weakness, it's not hard to imagine a small fix getting rid of the performance penalty.
Re: Maybe you don't need Rust and WASM to speed up your JS
#34I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+ru…
I work on SpiderMonkey JS performance (and got mentioned in the article for fixing a perf bug!) and this is exactly the point I wanted to make. If you're not a VM engineer, it's much harder to write fast JS. Wasm also gives you much more predictable performance across engines, without requiring (often engine-specific) 'hacks' like function cloning.
Re: Maybe you don't need Rust and WASM to speed up your JS
#35I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+ru…
Having micro-optimized and maintained JS code over years and dozens of browser versions, I cannot echo this enough. Tuning JS both the in face of fickleness of VM quirks and data/context is a losing proposition for all but the most speed- and core-functionality-critical code.
The point of rust+wasm benchmarks is that one can write reasonable, maintainable, functionality-focused code (not to mention all the rust-specific benefits) and get good performance out of the box.
Re: Maybe you don't need Rust and WASM to speed up your JS
#36This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language. At the end of the article, the author wisely chooses to move some objects out of the control of the GC: We are allocating hundreds o…
Yeah, this is also where value types are really awesome and you can get the same results from(assuming no strings). Sadly other than C# most of the mainstream GC'd languages don't include them yet as a feature.
Re: Maybe you don't need Rust and WASM to speed up your JS
#37Earlier quoted context omitted.
No offense meant, but that couldn't be more wrong. If you're writing for the server, you can already use whichever language best suits the problem at hand. WASM will eventually allow the same choice in the browser. The extent to which WASM could be used in the Node ecosystem would essentially be an indictment of how badly the Node community has bungled FFI. (node-ffi[0] should absolutely be added to Node core, not be…
No offense taken! I am pretty new to the JS world. "WASM will eventually allow the same choice in the browser." When will that actually be? That's the big question.
Since November WASM is enabled by default in the major browsers now:
Re: Maybe you don't need Rust and WASM to speed up your JS
#38I can't see any numbers comparing the rust implementation and the optimised javascript. Did I miss them in the article?
A comment upthread did the math:
> The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation.
Re: Maybe you don't need Rust and WASM to speed up your JS
#39The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari).
So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever.
This, honestly, is what I hate with modern dev. A few days back there was a discussion on how programming is hard nowadays.
Really, programming is more accessible than ever. What is hard is the "black magic" that's becoming more and more prevalent, most of which is implementation defined, that everyone is expected to know (and really, most don't really know anything. They just repeat rumors they read about online, often years out of date).
Re: Maybe you don't need Rust and WASM to speed up your JS
#40This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language. At the end of the article, the author wisely chooses to move some objects out of the control of the GC: We are allocating hundreds o…
> The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation.
This is not a fair comparison because the author made algorithmic improvements that would also improve the wasm version if applied to the Rust code. Source: https://twitter.com/mraleph/status/965616993310265344