You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Disclaimer: This are my assumptions and I'm not based in any direct information from the team behind V8.
Why I think they made the switch to Ignition + TurboFan
In the old days, when Lars Bak was still the Team Lead on V8's team he mentioned that it was to favor simplicity to use source code as an intermediate representation (minute 38) and directly compile to native code as the first step in the pipeline. At that time it made a lot of sense and was V8's way to execute source code for many years.
I believe that the efforts that started back then with pretty much all JavaScript engines was, and for some it might still be, to compete in terms of performance with the most advanced compilers of all time. And I think for a big part they succeeded: type-specializing JIT compilers were a huge advance on JavaScript performance. For many years the most complex JavaScript engines engaged on a race for writing the best complementing JIT compilers, that's were AWFY appeared and showed that the difference between all of them was a little bit more subtle.
Fast-forward a couple of years mobile devices sums up to a few billions, making some big companies (Google among them) to think in terms of mobile first. That's what Ignition was designed to do, to play an important role in memory-constrained devices (the average mobile device). At the same time, they were re-thinking the ways on how to measure if a JavaScript engine is faster or precisely better. Suddenly it made much more sense to measure how the web is being used, to inspect and decipher how the most popular websites are built, and the premise was if you optimize for that, you would be optimizing for most common use cases.
These last moves are not necessarily a setback for C-like performance code running on a JavaScript engine because of the evolution from ASM.js to WebAssembly. Now all the browsers can share the common goal of optimizing a statically typed language, something that could be fun to watch.
I plan to publish an article explaining Ignition + TurboFan for JavaScript developers in the near future, but until then, I think Seth’s recent presentation explains it quite well.
Disclaimer: This are my assumptions and I'm not based in any direct information from the team behind V8.
Why I think they made the switch to Ignition + TurboFan
In the old days, when Lars Bak was still the Team Lead on V8's team he mentioned that it was to favor simplicity to use source code as an intermediate representation (minute 38) and directly compile to native code as the first step in the pipeline. At that time it made a lot of sense and was V8's way to execute source code for many years.
I believe that the efforts that started back then with pretty much all JavaScript engines was, and for some it might still be, to compete in terms of performance with the most advanced compilers of all time. And I think for a big part they succeeded: type-specializing JIT compilers were a huge advance on JavaScript performance. For many years the most complex JavaScript engines engaged on a race for writing the best complementing JIT compilers, that's were AWFY appeared and showed that the difference between all of them was a little bit more subtle.
Fast-forward a couple of years mobile devices sums up to a few billions, making some big companies (Google among them) to think in terms of mobile first. That's what Ignition was designed to do, to play an important role in memory-constrained devices (the average mobile device). At the same time, they were re-thinking the ways on how to measure if a JavaScript engine is faster or precisely better. Suddenly it made much more sense to measure how the web is being used, to inspect and decipher how the most popular websites are built, and the premise was if you optimize for that, you would be optimizing for most common use cases.
These last moves are not necessarily a setback for C-like performance code running on a JavaScript engine because of the evolution from ASM.js to WebAssembly. Now all the browsers can share the common goal of optimizing a statically typed language, something that could be fun to watch.
Some resources to read:
The text was updated successfully, but these errors were encountered: