15 ms·

V8 is going to switch to a new compiler architecture after 5.8 branch cut

128 points by ilkkao 10y ago

petercooper 10y ago
And this is how you can try it out now in Chrome Canary: https://v8project.blogspot.com/2017/02/help-us-test-future-of-v8.html https://v8project.blogspot.com/2017/02/help-us-test-future-o...
MikeKusold 10y ago
Can anyone speak to what sort of impact this might have on NodeJS? Will it be difficult for the project to migrate to that version? Is it expected to break packages that rely on C bindings?
- deleted 10y ago
  [deleted]
- randiantech 10y ago
  Based on what the article says, performance would be improved. Since theres no API changes, it would be safe for NodeJS team to try to upgrade to this new version without regression issues.
  - bmeurer 10y ago
    So far the feedback from Node.js users/developers indicates that the --future configuration is a net win. There are some cases where performance degrades, and we are actively working on those. Instructions how to test-drive --future with Node.js can be found here: https://medium.com/@bmeurer/help-us-test-the-future-of-node-js-6079900566f https://medium.com/@bmeurer/help-us-test-the-future-of-node-...
- s3th 10y ago
  This architecture switch will have no impact on the V8 API. We're working closely with the Node.js team to make sure that this is a smooth transition and early results look as though there are significant performance benefits [0]. Disclaimer: I work on the V8 team. [0]: https://twitter.com/bmeurer/status/834677090381348865 https://twitter.com/bmeurer/status/834677090381348865
  - pavs 10y ago
    Probably means I will finally give Atom editor another try. :)
    - ygra 10y ago
      Atom's performance will most likely be more constrained by the algorithms they use than by JS execution speed.
      - sametmax 10y ago
        Since vscode is already pretty fast, you are probably right.
fmap 10y ago
Finally! Congratulations to the V8 team for completing the switch to a sane compilation pipeline. :) Hopefully this will lead to many more simplifications in the future. Does anyone know which optimizations finally catapulted Ignition+Turbofan ahead of FullCodeGen+Crankshaft in terms of performance?
- bmeurer 10y ago
  I'm not sure if you are referring to a particular optimization, but speaking of https://twitter.com/bmeurer/status/834677090381348865 https://twitter.com/bmeurer/status/834677090381348865 and https://twitter.com/bmeurer/status/834668611180625921 https://twitter.com/bmeurer/status/834668611180625921 the "Bazinga!" event in both cases refers to two very specific fixes that addressed deoptimization loops in TurboFan. The more interesting steady increase in performance is due to long-term real-world performance work, especially in the area of data-driven ICs (inline caches) and function context specialization. We will follow up with more details about Ignition and TurboFan, and the whole new code generation architecture soon.
  - fmap 10y ago
    Yes, that's what I had in mind. Another thing I seem to recall is that Turbofan used to be a lot slower than Crankshaft and spend a lot of its time in scheduling and register allocation. Has this changed recently? In any case, I'm looking forward to the more in depth post. :)
- Klathmon 10y ago
  And just to provide some context on the "sane" part. [0] is their current architecture. [1] will be the architecture after this change goes into effect. It's a massive simplification which should allow them to implement new changes to the language much faster, improve memory usage and startup speed, and will allow them to tackle web assembly much easier! [0] http://i.imgur.com/M86wHy2.png http://i.imgur.com/M86wHy2.png [1] http://i.imgur.com/Bmuxtdq.png http://i.imgur.com/Bmuxtdq.png
kethinov 10y ago
I am curious about the possibility of this leading to source code protection in Electron. The Electron team declined to support source code protection, judging it too difficult to implement. [0] NW.js supports the feature but with severe limitations that the Electron team understandably did not want to replicate. [1] Roger Wang of NW.js fame recently tweeted that the NW.js implementation is about to get a whole lot better due to this new compiler landing in V8. [2] Could this new development in V8 put source code protection back on the table for Electron? I posted this question to the official Electron discussion forums too a few days back, but I'd be curious to hear more input on the topic, thus posting it here as well. [3] [0]: https://github.com/electron/electron/issues/3041 https://github.com/electron/electron/issues/3041 [1]: https://github.com/nwjs/nw.js/wiki/protect-javascript-source-code-with-v8-snapshot https://github.com/nwjs/nw.js/wiki/protect-javascript-source... [2]: https://twitter.com/wwr/status/831691865850130432 https://twitter.com/wwr/status/831691865850130432 [3]: https://discuss.atom.io/t/source-code-protection-via-new-v8-compiler/39533 https://discuss.atom.io/t/source-code-protection-via-new-v8-...
- bastawhiz 10y ago
  You'll always be able to decompile electron (and other JS) apps. As the problem becomes more common, better tools will be available and any "protection" will be moot. Source code protection amounts to bad DRM, and I should hope it doesn't need to explained on HN the ways DRM doesn't work.
  - kethinov 10y ago
    My understanding is that the proposals being bandied about to do source code protection involve compiling the JS code into binary, so it's analogous to the protection offered by writing native code rather than mere minification/obfuscation or JIT bytecode stuff. Obviously no compilation process offers 100% protection, but it would be enough for most people's purposes if it occupied a space that was more secure (or more obfuscated) than Java, but less so than, say, C++.
    - penagwin 10y ago
dahart 10y ago
Will performance improve across the board, or is the new architecture targeting common patterns believed to be slow, like heavy use of closures & promises, or getting functional calls like map into the same performance range as a for loop?
- azakai 10y ago
  > Will performance improve across the board Speaking very generally, I've never seen a major architecture change that led to a performance improvement across the board. In particular in JS which has so many corners. There are always going to be some things that improve, some that regress, and some that stay the same. You can see examples of all three here (compare lines with TurboFan+Ignition vs v8): http://arewefastyet.com/#machine=29&view=breakdown&suite=octane http://arewefastyet.com/#machine=29&view=breakdown&suite=oct...
twoodfin 10y ago
I'm a sucker for interpreter designs, and the new Ignition bytecode interpreter looks nice: https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/ https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIP...
nimos 10y ago
I wonder how this will effect performance for games/realtime stuff as that seems like the weak point for JS from the user side, although realistically it's probably more of a GC problem. Seems like most of the test websites are reasonably static - do a bunch of stuff once at startup/do a bunch of stuff on user input so your compilation overhead ends up being fairly large whereas with realtime stuff/games I'd expect it looks more like the octane benchmark....
deleted 10y ago
[deleted]
floatboth 10y ago
Performance, performance, all the talk about performance. What about memory footprint? Apparently Ignition helps a bit, but still… even the baseline memory usage of Node.js and Chromium is bad. Just open a node REPL, its resident set size is 2x the size of a ruby/python REPL, about 10x the size of luajit.

128 points by ilkkao 10y ago

And this is how you can try it out now in Chrome Canary: https://v8project.blogspot.com/2017/02/help-us-test-future-of-v8.html https://v8project.blogspot.com/2017/02/help-us-test-future-o...

MikeKusold 10y ago

Can anyone speak to what sort of impact this might have on NodeJS? Will it be difficult for the project to migrate to that version? Is it expected to break packages that rely on C bindings?

deleted 10y ago
[deleted]
randiantech 10y ago
Based on what the article says, performance would be improved. Since theres no API changes, it would be safe for NodeJS team to try to upgrade to this new version without regression issues.
- bmeurer 10y ago
  So far the feedback from Node.js users/developers indicates that the --future configuration is a net win. There are some cases where performance degrades, and we are actively working on those. Instructions how to test-drive --future with Node.js can be found here: https://medium.com/@bmeurer/help-us-test-the-future-of-node-js-6079900566f https://medium.com/@bmeurer/help-us-test-the-future-of-node-...
s3th 10y ago
This architecture switch will have no impact on the V8 API. We're working closely with the Node.js team to make sure that this is a smooth transition and early results look as though there are significant performance benefits [0]. Disclaimer: I work on the V8 team. [0]: https://twitter.com/bmeurer/status/834677090381348865 https://twitter.com/bmeurer/status/834677090381348865
- pavs 10y ago
  Probably means I will finally give Atom editor another try. :)
  - ygra 10y ago
    Atom's performance will most likely be more constrained by the algorithms they use than by JS execution speed.
    - sametmax 10y ago
      Since vscode is already pretty fast, you are probably right.

fmap 10y ago

Finally! Congratulations to the V8 team for completing the switch to a sane compilation pipeline. :) Hopefully this will lead to many more simplifications in the future. Does anyone know which optimizations finally catapulted Ignition+Turbofan ahead of FullCodeGen+Crankshaft in terms of performance?

bmeurer 10y ago
I'm not sure if you are referring to a particular optimization, but speaking of https://twitter.com/bmeurer/status/834677090381348865 https://twitter.com/bmeurer/status/834677090381348865 and https://twitter.com/bmeurer/status/834668611180625921 https://twitter.com/bmeurer/status/834668611180625921 the "Bazinga!" event in both cases refers to two very specific fixes that addressed deoptimization loops in TurboFan. The more interesting steady increase in performance is due to long-term real-world performance work, especially in the area of data-driven ICs (inline caches) and function context specialization. We will follow up with more details about Ignition and TurboFan, and the whole new code generation architecture soon.
- fmap 10y ago
  Yes, that's what I had in mind. Another thing I seem to recall is that Turbofan used to be a lot slower than Crankshaft and spend a lot of its time in scheduling and register allocation. Has this changed recently? In any case, I'm looking forward to the more in depth post. :)
Klathmon 10y ago
And just to provide some context on the "sane" part. [0] is their current architecture. [1] will be the architecture after this change goes into effect. It's a massive simplification which should allow them to implement new changes to the language much faster, improve memory usage and startup speed, and will allow them to tackle web assembly much easier! [0] http://i.imgur.com/M86wHy2.png http://i.imgur.com/M86wHy2.png [1] http://i.imgur.com/Bmuxtdq.png http://i.imgur.com/Bmuxtdq.png

kethinov 10y ago

I am curious about the possibility of this leading to source code protection in Electron. The Electron team declined to support source code protection, judging it too difficult to implement. [0] NW.js supports the feature but with severe limitations that the Electron team understandably did not want to replicate. [1] Roger Wang of NW.js fame recently tweeted that the NW.js implementation is about to get a whole lot better due to this new compiler landing in V8. [2] Could this new development in V8 put source code protection back on the table for Electron? I posted this question to the official Electron discussion forums too a few days back, but I'd be curious to hear more input on the topic, thus posting it here as well. [3] [0]: https://github.com/electron/electron/issues/3041 https://github.com/electron/electron/issues/3041 [1]: https://github.com/nwjs/nw.js/wiki/protect-javascript-source-code-with-v8-snapshot https://github.com/nwjs/nw.js/wiki/protect-javascript-source... [2]: https://twitter.com/wwr/status/831691865850130432 https://twitter.com/wwr/status/831691865850130432 [3]: https://discuss.atom.io/t/source-code-protection-via-new-v8-compiler/39533 https://discuss.atom.io/t/source-code-protection-via-new-v8-...

bastawhiz 10y ago
You'll always be able to decompile electron (and other JS) apps. As the problem becomes more common, better tools will be available and any "protection" will be moot. Source code protection amounts to bad DRM, and I should hope it doesn't need to explained on HN the ways DRM doesn't work.
- kethinov 10y ago
  My understanding is that the proposals being bandied about to do source code protection involve compiling the JS code into binary, so it's analogous to the protection offered by writing native code rather than mere minification/obfuscation or JIT bytecode stuff. Obviously no compilation process offers 100% protection, but it would be enough for most people's purposes if it occupied a space that was more secure (or more obfuscated) than Java, but less so than, say, C++.
  - penagwin 10y ago

dahart 10y ago

Will performance improve across the board, or is the new architecture targeting common patterns believed to be slow, like heavy use of closures & promises, or getting functional calls like map into the same performance range as a for loop?

azakai 10y ago
> Will performance improve across the board Speaking very generally, I've never seen a major architecture change that led to a performance improvement across the board. In particular in JS which has so many corners. There are always going to be some things that improve, some that regress, and some that stay the same. You can see examples of all three here (compare lines with TurboFan+Ignition vs v8): http://arewefastyet.com/#machine=29&view=breakdown&suite=octane http://arewefastyet.com/#machine=29&view=breakdown&suite=oct...

twoodfin 10y ago

I'm a sucker for interpreter designs, and the new Ignition bytecode interpreter looks nice: https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/ https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIP...

nimos 10y ago

I wonder how this will effect performance for games/realtime stuff as that seems like the weak point for JS from the user side, although realistically it's probably more of a GC problem. Seems like most of the test websites are reasonably static - do a bunch of stuff once at startup/do a bunch of stuff on user input so your compilation overhead ends up being fairly large whereas with realtime stuff/games I'd expect it looks more like the octane benchmark....

deleted 10y ago

[deleted]

floatboth 10y ago

Performance, performance, all the talk about performance. What about memory footprint? Apparently Ignition helps a bit, but still… even the baseline memory usage of Node.js and Chromium is bad. Just open a node REPL, its resident set size is 2x the size of a ruby/python REPL, about 10x the size of luajit.