2 ms·

README> Turbolizer is a HTML-based tool that visualizes optimized code along the various phases of Turbofan's optimization pipeline, allowing easy navigation be

README> Turbolizer is a HTML-based tool that visualizes optimized code along the various phases of Turbofan's optimization pipeline, allowing easy navigation between source code, Turbofan IR graphs, scheduled IR nodes and generated assembly code. https://github.com/v8/v8/tree/master/tools/turbolizer https://github.com/v8/v8/tree/master/tools/turbolizer is like IRHydra, but for Turbofan. svn export https://github.com/v8/v8/trunk/tools/turbolizer turbolizer cd turbolizer python -m SimpleHTTPServer 8000 chromium-browser http://0.0.0.0:8000/ chromium-browser --no-sandbox --js-flags="--allow-natives-syntax --code-comments --trace-turbo" testfile.html mkdir out cd out node --allow-natives-syntax --code-comments --trace-turbo ../testfile.js cat testfile.js function add(a,b) { return a + b; } add(23, 44); add(2, 88); %OptimizeFunctionOnNextCall(add); add(2, 7); ls out ... turbo-add-0.json ...

mraleph 9y ago
> is like IRHydra It does 'IR' part of the IRHydra, but it does not give you another important feature - ability to see how your function evolved over time and figure out reasons for it. Loading files one by one in search for the right version is pretty cumbersome. I was always hoping that V8 will eventually get proper Dev Tools integration for compiler / runtime internals - and I think things have finally started happening in that area.
- mncharity 9y ago
  > cumbersome Yes, turbolizer currently lacks some of IRHydra/2's mature featurefulness. No pretty "you're deopt is here". I've no idea whether Google would welcome contributions or not. > I was always hoping that V8 will eventually get proper Dev Tools integration for compiler / runtime internals Wistful sigh.
mncharity 9y ago
The current usefulness of turbolizer seems... mixed. Turbofan generated code is highly variable. Changes in argument types and optimization order can result in very different code being emitted. It's not like "all these cases were well optimized, but this one case wasn't, so let's fix/avoid that one". Instead, it's "well, that's a diverse mess of results, hmm...". Perhaps that will change. One project objective is apparently optimization with fewer performance cliffs. But another objective is a compiler which better serves low-end mobile devices - thus raising the bar for what optimizations are worth spending time on. There's a tension between those two. Also, CPU branch prediction makes interpreting the resulting assembly more interesting. Turbofan output has a lot of deopt guards. Tests that the assumptions used when writing the optimized code are still true. But say one bit of javascript optimizes to code with more guards than another. Do they matter? Maybe not, if the guards end up off mainline and hit cache. So turbolizer seems helpful if you have a some red-hot performance chokepoint. But at present, perhaps less so for providing more general guidance.

mraleph 9y ago

> is like IRHydra It does 'IR' part of the IRHydra, but it does not give you another important feature - ability to see how your function evolved over time and figure out reasons for it. Loading files one by one in search for the right version is pretty cumbersome. I was always hoping that V8 will eventually get proper Dev Tools integration for compiler / runtime internals - and I think things have finally started happening in that area.

mncharity 9y ago
> cumbersome Yes, turbolizer currently lacks some of IRHydra/2's mature featurefulness. No pretty "you're deopt is here". I've no idea whether Google would welcome contributions or not. > I was always hoping that V8 will eventually get proper Dev Tools integration for compiler / runtime internals Wistful sigh.

mncharity 9y ago

The current usefulness of turbolizer seems... mixed. Turbofan generated code is highly variable. Changes in argument types and optimization order can result in very different code being emitted. It's not like "all these cases were well optimized, but this one case wasn't, so let's fix/avoid that one". Instead, it's "well, that's a diverse mess of results, hmm...". Perhaps that will change. One project objective is apparently optimization with fewer performance cliffs. But another objective is a compiler which better serves low-end mobile devices - thus raising the bar for what optimizations are worth spending time on. There's a tension between those two. Also, CPU branch prediction makes interpreting the resulting assembly more interesting. Turbofan output has a lot of deopt guards. Tests that the assumptions used when writing the optimized code are still true. But say one bit of javascript optimizes to code with more guards than another. Do they matter? Maybe not, if the guards end up off mainline and hit cache. So turbolizer seems helpful if you have a some red-hot performance chokepoint. But at present, perhaps less so for providing more general guidance.