Google booste les performances de son moteur JavaScript V8
Grâce à la « compilation concurrente »
Le 2014-02-18 08:58:50, par Cedric Chevalier, Expert éminent sénior
JavaScript est un omniprésent sur le Web. Les développeurs y ont recours pour dynamiser le contenu des pages web, et améliorer ainsi significativement l’expérience utilisateur.
Chaque navigateur implémente sa propre solution faite maison pour l’interprétation et l’exécution des scripts JavaScript. Safari utilise JavaScriptCore, Microsoft a recours au moteur Chakra, Mozilla développe Rhino et SpiderMonkey, Google quant à lui à mis sur pied V8.
Les développeurs de Google ont opté pour une approche de compilation à la volée (JIT Compiler) pour V8, qui permet de convertir les scripts du langage en code machine natif, afin qu’ils puissent être exécutés plus rapidement.
Cette conversion à un prix : elle augmente le temps de réponse des pages. C’est la raison pour laquelle, la compilation JIT de V8 s’opère en deux étapes. La première s’exécute juste avant l’exécution d’un script. Elle est rapide, mais ne comporte pas de phase d’optimisation du code machine natif.
Par contre, la deuxième étape de compilation s’opère plus lentement sur les scripts qui doivent être exécutés plus d’une fois. C’est la phase d’optimisation.
Si pour la plupart des scénarios cette approche se révèle amplement suffisante, dans certaines situations elle est inefficace. C’est notamment le cas des applications complexes comme les jeux, ou la seconde phase de compilation provoque irréfutablement une augmentation du temps de réponse de la page.
Les développeurs de Google ont planché sur la question, et en sont venus à la conclusion que l’emploi de la compilation concurrente permettrait de résoudre le problème.
En pratique, les deux phases de compilation à la volée s’opèrent en même temps, sauf que l’étape d’optimisation se fait dans un thread concurrent en arrière-plan. L’implémentation de cette solution a permis à V8 d’accroître ses performances de 27% pour le test Mandreel du benchmark Octane 2.0. Il ne reste plus qu’à attendre la prochaine sortie de Chrome pour bénéficier de ce nouvel ajout.
Source: Blog Chromium
Et vous ?
Chaque navigateur implémente sa propre solution faite maison pour l’interprétation et l’exécution des scripts JavaScript. Safari utilise JavaScriptCore, Microsoft a recours au moteur Chakra, Mozilla développe Rhino et SpiderMonkey, Google quant à lui à mis sur pied V8.
Les développeurs de Google ont opté pour une approche de compilation à la volée (JIT Compiler) pour V8, qui permet de convertir les scripts du langage en code machine natif, afin qu’ils puissent être exécutés plus rapidement.
Cette conversion à un prix : elle augmente le temps de réponse des pages. C’est la raison pour laquelle, la compilation JIT de V8 s’opère en deux étapes. La première s’exécute juste avant l’exécution d’un script. Elle est rapide, mais ne comporte pas de phase d’optimisation du code machine natif.
Par contre, la deuxième étape de compilation s’opère plus lentement sur les scripts qui doivent être exécutés plus d’une fois. C’est la phase d’optimisation.
Si pour la plupart des scénarios cette approche se révèle amplement suffisante, dans certaines situations elle est inefficace. C’est notamment le cas des applications complexes comme les jeux, ou la seconde phase de compilation provoque irréfutablement une augmentation du temps de réponse de la page.
Les développeurs de Google ont planché sur la question, et en sont venus à la conclusion que l’emploi de la compilation concurrente permettrait de résoudre le problème.
En pratique, les deux phases de compilation à la volée s’opèrent en même temps, sauf que l’étape d’optimisation se fait dans un thread concurrent en arrière-plan. L’implémentation de cette solution a permis à V8 d’accroître ses performances de 27% pour le test Mandreel du benchmark Octane 2.0. Il ne reste plus qu’à attendre la prochaine sortie de Chrome pour bénéficier de ce nouvel ajout.
Source: Blog Chromium
Et vous ?
-
SaverokExpert éminentBien évidement, il nous manque pas mal de détails pour se faire une idée précise. Mais dit comme ça, le multi thread est une solution évidente quand on a plusieurs processus indépendants...
Mais il est toujours plus simple de l'ouvrir une fois qu'on a la solution...le 18/02/2014 à 14:44 -
LSMetagExpert confirméLa chose que je me demande, c'est pourquoi Mozilla ne fait pas pareil avec Firefox ? Le principe est pourtant simple (j'espère qu'il n'est pas breveté). Les performances JS de Firefox sont à la ramasse par rapport au V8.
En tout cas, la différence est en effet assez nette sur les dernières builds "stables" de Chromium (version 34).le 18/02/2014 à 16:57 -
ZeflingExpert confirméBha, il a des échange des deux côtés, des fois c'est Google qui pique de trucs à Mozilla et d'autres fois c'est l'inverse (principe du libre). Il me semble que V8 est libre (après il y a des histoires de types de licence). Mozilla bosse sur asm.js et d'autres trucs. Puis si on se fie juste aux benchs, difficile de dire qui est vraiment le meilleur.le 18/02/2014 à 23:28
-
LSMetagExpert confirméAprès peut-être que ce n'est pas représentatif.le 19/02/2014 à 18:13