Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe you don't need Rust and WASM to speed up your JS

mrale.ph

Post reply on HN
Print view View original

141–150 of 186 posts

Re: Maybe you don't need Rust and WASM to speed up your JS

#141

Post by vvanders »

zbentley wrote: post #74
aschampion wrote: post #35

Earlier quoted context omitted.

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-speci…

Writing an O(N^2) algorithm that processes lots of data in wasm is not going to speed it up more than writing an O(log N) algorithm in pure JS; the knowledge of how to identify problems like that will serve you better in many more cases than the selection of a "fast" runtime.

Not totally true, some algos while large O(n) are incredible cache friendly.

Radix sort for instance comes to mind.

Re: Maybe you don't need Rust and WASM to speed up your JS

#142

Post by qarioz »

kjksf wrote: post #96
bcoates wrote: post #33

Earlier quoted context omitted.

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.

Given that this contrasts a JavaScript implementation with Rust implementation compiled to WASM: my 5 minute investigation shows that Rust doesn't have optional arguments at all. So in Rust you would be forced to write it the way you consider to be "bad idea". Many people think that default function arguments are a bad idea and languages like Rust or C or Go or Java don't even have them.

you get creative, passing map, passing Option. it's very trivial to do.

Re: Maybe you don't need Rust and WASM to speed up your JS

#143

Post by TAForObvReasons »

mraleph wrote: post #62
anp wrote: post #25

I 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…

[Thank you for reading the post! I am glad you enjoyed it] All optimizations in the post can mostly be divided into three large groups: 1) algorithmic improvements; 2) workarounds for implementation independent, but potentially language dependent issues; 3) workarounds for V8 specific issues; You need to think about algorithms no matter which language you write in, so we don't need to talk much about the first group.…

Ultimately, much of the enthusiasm over WASM, like ASM.JS, is rooted in the idea that it's extremely difficult to improve JS engine performance. ASM.JS used certain conventions to essentially create a "language within JS", while WASM is a new language altogether. The goal was the same in both cases: construct a language that is easier to optimize and make the end users conform.

The key takeaway of your commentary on asm.js five years ago (http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html) is the same as the key takeaway from this post: we haven't reached the end of JS engine performance improvements, and if we apply the same rigor to JS development that we apply to C++ or C or Rust or some other language the results are definitely surprising!

Re: Maybe you don't need Rust and WASM to speed up your JS

#144

Post by b0rsuk »

kbenson wrote: post #89
b0rsuk wrote: post #83

Earlier quoted context omitted.

I'm afraid it's easier to get started as a Javascript developer than a Rust developer. What if it's easier to learn JS optimization quirks than to become an average Rust developer ?

It's a cost/benefit type of situation. Learning to optimize JavaScript might cost less, but the benefit is fairly narrow, and may lesson over time (or you may need to pay more in attention and time to keep up with JavaScript VM changes). Rust (or C++) to WASM costs more (if you don't already know the language), but the benefit should stay static and useful over time, and there are many other benefits as well (such as…

I agree with this, but I think most people don't, until it's demonstrated Rust kicks ass. Javascript is all the age right now. People might think "I'll get a Javascript job now, and I will learn to optimize later. Javascript is highly optimized anyway." Then it's just inertia. They already know Javascript. Besides, Javascript may have a reputation for being messy, but not for being a hard language to pick up. Yes it does have an unusual OO style, and supports functional programming, but you don't have to start with high level topics just to write any code with it.

As far as I know Rust has just two major success stories right now: Firefox 57 (Servo) ripgrep (even included in Microsoft Visual Studio)

Re: Maybe you don't need Rust and WASM to speed up your JS

#145

Post by adrianN »

fenomas wrote: post #133
seeekr wrote: post #90

Earlier quoted context omitted.

It seems to me there is no reason we shouldn't be able to create an "optimizing babel" that could be doing performance optimizations based on the target JS engine and version, as a build step. I don't think we need to go to a completely different source language and a compilation to WASM in order to get permission to create such an optimization tool. Such a tool would give you the benefits you're praising about the W…

JS engines already do insane levels of optimization, and they do it while watching the code execute so they understand the code better than any preprocessing tool can hope to. What could a tool like you're describing do that the engines don't do themselves?

I assume that JITs don't do very expensive optimizations because they have to do a trade off between execution speed and compilation time. JITs are also fairly blind on the first execution of a piece of code. Static optimizations are not made obsolete by the existence of JITs.

Re: Maybe you don't need Rust and WASM to speed up your JS

#146

Post by kbenson »

b0rsuk wrote: post #144
kbenson wrote: post #89

Earlier quoted context omitted.

It's a cost/benefit type of situation. Learning to optimize JavaScript might cost less, but the benefit is fairly narrow, and may lesson over time (or you may need to pay more in attention and time to keep up with JavaScript VM changes). Rust (or C++) to WASM costs more (if you don't already know the language), but the benefit should stay static and useful over time, and there are many other benefits as well (such as…

I agree with this, but I think most people don't, until it's demonstrated Rust kicks ass. Javascript is all the age right now. People might think "I'll get a Javascript job now, and I will learn to optimize later. Javascript is highly optimized anyway." Then it's just inertia. They already know Javascript. Besides, Javascript may have a reputation for being messy, but not for being a hard language to pick up. Yes it…

Sure, and that's why I was careful to couch the argument as just some other language that includes C and C++ as options (and truthfully includes others, but few have quite the same compatibility story). At this point if you don't know C++ or Rust, which one will give you the most benefit from learning it is a very open question. I think Rust has advantages over C++ in correctness and safety, but C++ currently offers better paths for understanding and utilizing existing code or getting a job using it (whether that was an initial goal or not). Five years down the line the differences may not be so cut and dry though. C++ will almost definitely still have those advantages, but the gap have have closed somewhat. Or maybe not? It's all up in the air.

Re: Maybe you don't need Rust and WASM to speed up your JS

#147

Post by swsieber »

b0rsuk wrote: post #144
kbenson wrote: post #89

Earlier quoted context omitted.

It's a cost/benefit type of situation. Learning to optimize JavaScript might cost less, but the benefit is fairly narrow, and may lesson over time (or you may need to pay more in attention and time to keep up with JavaScript VM changes). Rust (or C++) to WASM costs more (if you don't already know the language), but the benefit should stay static and useful over time, and there are many other benefits as well (such as…

I agree with this, but I think most people don't, until it's demonstrated Rust kicks ass. Javascript is all the age right now. People might think "I'll get a Javascript job now, and I will learn to optimize later. Javascript is highly optimized anyway." Then it's just inertia. They already know Javascript. Besides, Javascript may have a reputation for being messy, but not for being a hard language to pick up. Yes it…

Does drop box writing a fs in Rust count as a major success story?

Re: Maybe you don't need Rust and WASM to speed up your JS

#148

Post by deathanatos »

ridiculous_fish wrote: post #108
vanderZwan wrote: post #101

Earlier quoted context omitted.

> monomorphisation trick Here's a crazy thing I recently learned: apparently monomorphism isn't just "object with identical keys", apparently (at least in Chrome), the order in which you declare those keys matters . According to this presentation from 2015[0], adjusting the following lines in the Octane/Splaytree benchmark so that node.left and node.right are always assigned in the same order resulted in 15% better p…

Yes, this is because the JS spec requires that object keys are iterated in insertion order (with a bizarre exception for arrays).

TIL. For those like me for which this is new, this was apparently a change in the ES 2015 / ES 6 version of the standard.

See: https://stackoverflow.com/questions/5525795/does-javascript-...

The order is only sometimes guaranteed, of course, because JavaScript. (But critically, for this discussion, it is important that it is sometimes guaranteed, because it forces that information to be stored by the VM.)

Re: Maybe you don't need Rust and WASM to speed up your JS

#149

Post by FridgeSeal »

thefounder wrote: post #61
gear54rus wrote: post #43

Earlier quoted context omitted.

> hours to match the performance you get for "free" from other languages? In a sense, you pay those hours that you saved up by using an easier, more intuitive language like JS. Or you can choose not to and still have pretty good performance and blazing fast dev cycles.

I believe there are other languages easier and more intuitive than JS. The lack of DOM and GC support in WASM is the only reason JS is still ruling the web. As far as the performance is concerned I believe profilling the internals of the VM(as the author does) is not a good fix on the long term.

That and the fact that it's the only language blessed to have it's interpreter in the browser.

If we could have been able to challenge it by allowing another language in there I would like to think we wouldn't be facing a lot of the issues we do now.

Re: Maybe you don't need Rust and WASM to speed up your JS

#150

Post by b0rsuk »

swsieber wrote: post #147
b0rsuk wrote: post #144

Earlier quoted context omitted.

I agree with this, but I think most people don't, until it's demonstrated Rust kicks ass. Javascript is all the age right now. People might think "I'll get a Javascript job now, and I will learn to optimize later. Javascript is highly optimized anyway." Then it's just inertia. They already know Javascript. Besides, Javascript may have a reputation for being messy, but not for being a hard language to pick up. Yes it…

Does drop box writing a fs in Rust count as a major success story?

It doesn't count as a major success story I knew about when I was typing that comment.
Post reply on HN