6 ms·

[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 improve

[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. In the post it is represented by sorting improvements (sorting subsequences rather than the whole array) and by discussions of caching benefits (or lack of them there-off). The second group is represented by a monomorphisation trick: the fact that the performance suffers due to polymorphism is not really a V8 specific issue and it is not even JS specific issue. You can apply this approach across implementations and even languages. Some languages apply it in some form for you under the hood. The last group is represented by argument adaptation stuff. Finally an optimization I did to mappings representation (using typed array instead of an object) is an optimization that spans all three groups. It's about understanding limitations and costs of a GCed system as whole. Now... Why did I choose the title? That's because I think group #3 represents the issue that should and would be mostly fixed over time. While groups 1 and 2 represent universal knowledge that spans across implementations and languages. Obviously it is up to each developer and each team to choose between spending N rigorous hours profiling and reading and thinking about their JavaScript code, or to spend N hours rewriting their stuff in a language X. What I want is: a) that everybody was fully aware that the choice even exists; b) language designers and implementors worked together on making this choice less and less obvious - which means working on language features and tools and reducing the need in group #3 optimizations.

zbentley 9y ago
> Some languages apply it in some form for you under the hood. I suspect some respondents will say, or believe, that this falls under the category of "you have to know the VM/runtime intimately to get good performance". I don't think that's true. If you know the general problems with polymorphic call sites, you can (in JS and many other languages) check to see if the runtime is applying optimizations of this kind by being explicit. If it helps, you can get a free optimization by setting explicit arity/dispatch just because you happened to know about the issues surrounding polymorphic dispatch. That's a case of fundamental knowledge speeding up/improving your progress; not a case of "you need to know the VM guts like the back of your hand to make code fast".
vanderZwan 9y ago
> 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 http://mp.binaervarianz.de/fse2015_slides.pdf [1] https://github.com/chromium/octane/blob/master/splay.js#L390 https://github.com/chromium/octane/blob/master/splay.js#L390
- ridiculous_fish 9y ago
  Yes, this is because the JS spec requires that object keys are iterated in insertion order (with a bizarre exception for arrays).
  - vanderZwan 9y ago
    Ah, I guess that explains it. Although that does not require the engine to have under-the-hood layout respect that, does it? They could just as easily choose to keep the memory layout in the same order. Although I suppose you're already required to have two separate hidden classes to distinguish these two kinds of objects anyway. > with a bizarre exception for arrays Wow, you weren't joking with how bizarre this gets: var a = {}; var b = {}; a.a = 0; a.b = 1; a[0] = 0; a[1] = 1; b.b = 1; b.a = 0; b[1] = 1; b[0] = 0; Object.keys(a); // Array [ "0", "1", "a", "b" ] Object.keys(b); // Array [ "0", "1", "b", "a" ] PS: Thanks for making a great shell :)
TAForObvReasons 9y ago
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 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!

zbentley 9y ago

> Some languages apply it in some form for you under the hood. I suspect some respondents will say, or believe, that this falls under the category of "you have to know the VM/runtime intimately to get good performance". I don't think that's true. If you know the general problems with polymorphic call sites, you can (in JS and many other languages) check to see if the runtime is applying optimizations of this kind by being explicit. If it helps, you can get a free optimization by setting explicit arity/dispatch just because you happened to know about the issues surrounding polymorphic dispatch. That's a case of fundamental knowledge speeding up/improving your progress; not a case of "you need to know the VM guts like the back of your hand to make code fast".

vanderZwan 9y ago

> 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 http://mp.binaervarianz.de/fse2015_slides.pdf [1] https://github.com/chromium/octane/blob/master/splay.js#L390 https://github.com/chromium/octane/blob/master/splay.js#L390

ridiculous_fish 9y ago
Yes, this is because the JS spec requires that object keys are iterated in insertion order (with a bizarre exception for arrays).
- vanderZwan 9y ago
  Ah, I guess that explains it. Although that does not require the engine to have under-the-hood layout respect that, does it? They could just as easily choose to keep the memory layout in the same order. Although I suppose you're already required to have two separate hidden classes to distinguish these two kinds of objects anyway. > with a bizarre exception for arrays Wow, you weren't joking with how bizarre this gets: var a = {}; var b = {}; a.a = 0; a.b = 1; a[0] = 0; a[1] = 1; b.b = 1; b.a = 0; b[1] = 1; b[0] = 0; Object.keys(a); // Array [ "0", "1", "a", "b" ] Object.keys(b); // Array [ "0", "1", "b", "a" ] PS: Thanks for making a great shell :)

TAForObvReasons 9y ago

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