TurboFan: Google's New V8 JavaScript Compiler

[phoronix]

Phoronix: TurboFan: Google's New V8 JavaScript Compiler

Over on the Chromium Blog is a new posting about the work Google is doing on a new JavaScript compiler for V8 in Chrome, codenamed TurboFan...

http://www.phoronix.com/scan.php?page=news_item&px=Google-TurboFan-V8-JavaScript

[talvik]

Michael, isn't it about time some JS benchmarks are added to PTS?

[yoshi314]

This compiler looks like a major step back, tbh judging by graphs on http://arewefastyet.com/

[DanL]

^Are you saying TurboFan doesn't blow you away?

[CrystalGamma]

This compiler looks like a major step back, tbh judging by graphs on http://arewefastyet.com/

Yeah, that's what I thought too ... but maybe the guys at Mozilla (provider of arewefastyet) just don't know how to set it up correctly ...
But honestly, the numbers they have are so abysmal that I originally thought TurboFan was the older compiler in v8.
Then again, those benchmarks are mostly about optimizing tight loops, which do occur if you try to write a video decoder in JS (I heard the daala guys did this) but don't really matter for most web apps.

[cb88]

The tradeoff is longer compilation time to improved long term performance.... the benchmarks used don't run for very long so you see poor performance. If something runs for 10min or an hour.... it probably makes sense to optimize it more. Its the same tradeoff Java makes... slow startup time for improved long term performance.

[deppman]

The tradeoff is longer compilation time to improved long term performance.... the benchmarks used don't run for very long so you see poor performance. If something runs for 10min or an hour.... it probably makes sense to optimize it more. Its the same tradeoff Java makes... slow startup time for improved long term performance.

Agrred. One part of the solution would be to cache previously compiled code so that if signatures match on a requested resource, the compiled code from the cache is used directly instead. Consider, for example, the many thousands of site that use the Google jQuery library 2.12. That library could be compiled and cached once for use by every one of those sites on a given computer.

[name99]

Agrred. One part of the solution would be to cache previously compiled code so that if signatures match on a requested resource, the compiled code from the cache is used directly instead. Consider, for example, the many thousands of site that use the Google jQuery library 2.12. That library could be compiled and cached once for use by every one of those sites on a given computer.

That's not a trivial exercise. The important part of what's being done in JS compilation is not exactly the "compile" parts, it's the materialization of virtual code. That is, statistics are tracked for how pieces of code are used ("is this code constantly handling a string or a float or an integer") and when those statistics look stable, code specific to the relevant case is emitted.
Problem is those statistics may not be persistent from site to site, and may not even be persistent across runs. In addition to a cached code system, you need a system for caching these statistics and maybe some sort of trustworthiness indicator for how often the statistics change, between sites and across runs.