Maybe you don't need Rust and WASM to speed up your JS • Hacker News Board

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

#101

Post by vanderZwan » Mon, Feb 19, 2018, 10:07 PM UTC

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

> 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 performance:

    var node = new SplayTree.Node(key, value);
    if (key > this.root_.key) {
      node.left = this.root_;
      node.right = this.root_.right;
      ...
    } else {
      node.right = this.root_;
      node.left = this.root_.left;
      ...
    }

Now, I assume that this out-of-order thing was actually done on purpose, to benchmark how the JIT handles code like this. Further evidence for that is that the SplayTree constructor[1] does not feature a left and right key either:

    SplayTree.Node = function(key, value) {
      this.key = key;
      this.value = value;
    };

Still, I wouldn't be surprised if it was common for real-life code to accidentally have objects that should have the same hidden class end up with different ones because of this.

[0] http://mp.binaervarianz.de/fse2015_slides.pdf

[1] https://github.com/chromium/octane/blob/master/splay.js#L390

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

#102

Post by ptx » Mon, Feb 19, 2018, 10:17 PM UTC

seeekr wrote: post #90

ef4 wrote: post #85

The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser. It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get…

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…

But what if I want to target all the engines, including future ones? The compiler could compile separate versions for each engine, I guess, and you could choose which one to load at runtime based on the UserAgent string ... but even then everyone would have to recompile their websites every time a new browser version comes out.

The advantage of WebAssembly is supposed to be (I think) that it's simpler and will give more consistency between browsers, so browser behaviour will be less surprising, and you can thus get away with compiling a single version.

And if you take this approach of compiling JavaScript to a simple and consistent subset of JavaScript that can be optimized similarly in all engines, you'd end up more or less targeting asm.js, the predecessor to WebAssembly. :)

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

#103

Post by ShinTakuya » Mon, Feb 19, 2018, 10:21 PM UTC

gear54rus wrote: post #43

themihai wrote: post #9

I wonder if the performance gain is worth the effort. Surely you can always squeeze more performance from JS like from any other language but what's the point if you spend hours to match the performance you get for "free" from other languages? As far as WASM is concerned I'm more excited about the possibility to run any programming language on the web than the raw performance gains. So far it is still year(s) away fr…

> 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.

Can you elaborate on how JS is more intuitive than, say, Rust? I can give a simple counter example - make a JS object, assign another object as a key, copy it three times into a list (without deepcopy) and modify the object inside. Suddenly you've modified all three objects. Not intuitive at all, and easily missed if you're a less experienced developer. Rust would stop you in your tracks and force you to explicitly say that you want that behaviour.

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

#104

Post by catnaroek » Mon, Feb 19, 2018, 10:25 PM UTC

alangpierce wrote: post #51

wereHamster wrote: post #22

Earlier quoted context omitted.

Any language that doesn't have first-class support for ADTs is a waste of my time. And I say that as someone who's working with TypeScript all day long, and try to push it in my team, even though it sometimes requires verbose code and boilerplate. But I take that over plain JS any day. It took long enough for my coworkers to recognise the benefit of a type system. Can't push them too hard too far too quickly.

When you say ADTs, do you mean algebraic data types or abstract data types? My impression has been that TypeScript is quite good at algebraic data types (i.e. tagged unions). You need to use normal conditionals like if/switch or your own function instead of syntactic support for pattern matching, but IMO the static analysis makes it work out pretty well.

It is good at neither. Union types and sum types are veeery different from each other.

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

#105

Post by z3t4 » Mon, Feb 19, 2018, 10:25 PM UTC

We should be more wary about premature optimizations, like in the article where caching in the original code made it slower! Always measure! Write naive code and measure, the JavaScript engines are very good at optimization, especially V8 and the others are catching up.

However when I do optimize JavaScript code I often get 10-100x performance. Usually by writing better algorithms. Eg no "black magic". So the original code in the article is not that bad, considering he "only" got 4x performance.

Moving to another programming language / WASM for less then 2x performance is not worth it - unless you hate JavaScript.

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

#106

Post by ShinTakuya » Mon, Feb 19, 2018, 10:28 PM UTC

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.

I agree regarding JS not being the easiest or most intuitive language, but I don't see JS going away any time soon and I don't think that's a bad thing. The last 5 years or so have seen JS transform from one of the most frustrating languages to one of the better ones. I think Typescript is where the future of web dev lies. Typescript for your main logic and WASM for optimising the parts that need it.

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

#107

Post by acemarke » Mon, Feb 19, 2018, 10:29 PM UTC

vortico wrote: post #95

This is a broad, naive question, but the number of responses and upvotes on this post suggest to me that many people actually need to speed up their JS. I've never once come across this problem in web app development. The bottleneck is always DOM rendering like layout changes, networking, handling large WebGL vertex buffers for video games, etc. In which use cases is JS performance significant?

In this case, the sourcemaps library isn't normally running as part of user application code. It's primarily used by the browser's DevTools, and server-side build tools like Webpack and Gulp.

The faster sourcemaps can be parsed and manipulated, the faster the DevTools and build tools will execute.

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

#108

Post by ridiculous_fish » Mon, Feb 19, 2018, 10:32 PM UTC

vanderZwan wrote: post #101

mraleph wrote: post #62

Earlier quoted context omitted.

[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.…

> 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).

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

#109

Post by nocman » Mon, Feb 19, 2018, 10:41 PM UTC

robocat wrote: post #77

nocman wrote: post #49

Earlier quoted context omitted.

I guess if you don't include IE11 as one of the "major browsers". I wish that was the case. Yes, I know it is only receiving security updates -- but it will supposedly get those until Windows 10 is no longer supported (if I'm reading things right). Unfortunately, that doesn't stop a bunch of people from using it. It still has a considerable amount more marketshare than Edge does (if netmarketshare.com is to be believ…

40% of desktop users use IE11 for our browser based app. 1% use an older version of IE, and 1% use Edge. Our clients are businesses, mostly in Australia and New Zealand.

Yeah, I know many businesses still have to use IE11 because some web app they use requires IE (often on an intranet, but sometimes still even in the internet). Sad state of affairs.

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

#110

Post by ef4 » Mon, Feb 19, 2018, 10:45 PM UTC

seeekr wrote: post #90

ef4 wrote: post #85

The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser. It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get…

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…

You're basically describing asm.js -- a subset of javascript that is known to be easy for engines to turn directly into native code and execute, that you can use as a compilation target.

The difference between asm.js and WASM is mostly just that WASM is more compact and easier to parse, while asm.js is a more gradually compatible upgrade story.