en très gros, parce que j'avoue ne pas avoir tout compris, les améliorations en questions sont issues de recherches assez poussées de grosses têtes en université, et que parait-il, ce genre d'optimisation est l'avenir dans les interpréteurs de langage, les compilateurs en bytecode et cie...
Pour simplifier comment ca marche:
Il faut imaginer comment l'interpreteur fonctionne: une boucle sur le flux de bytecode et a l'interieur un gros switch pour chacune des valeurs possibles.
Pour chaque "case", le code effectue un certain nombre de tests: C'est quoi le type de la variable en entree? est-ce que la valeur est bien definie... ensuite il effectue le traitement approprie puis stocke le resultat en respectant une certaine convention comme ca le code qui est associe au prochain bytecode trouve tout comme il veut, quel qu'il soit. Mine de rien, une simple addition, ca prend du temps avec toute les verifications qui vont avec.
Ici l'idee est de dire: Au lieu d'avoir un case pour chaque bytecode, on pourrait rajouter des cas qui traite 2 bytecode successifs. La combinaison des deux codes permet au compilateur de supprimer des tests redondants, eviter une sequence stockage puis rechargement...
C'est pas nouveau et on trouve dans quelques interpreteurs ce genre de regroupement. Les sequences choisies sont celles qui sont communes a la majorite des applications. En fait, on parle de trace.
En fait, il m'est arrive il y a environ 2 ans de le faire manuellement pour certains code scientifiques (les sequences etant specifiques, peut reutilisables) dans python.
L'idee developee ici est de dire: chaque application a ses propres traces characteristiques. Par exemple une boucle: le corps de la boucle ou une partie peut contenir une sequence de bytecode tres frequement executee. C'est ce que fait l'optimiseur:
- construction des traces;
- dermination des traces les plus frequement utilisee;
- emition et optimisation "JIT" du code interpreteur correspondant a l'execution sequentielle de chacun des "sous-codes" de l'interpreteur.
Donc oui, le concept applique ici n'est pas specifique a javascript, car l'optimiseur s'applique a n'importe quel bytecode. Mais les resultats en terme d'amelioration de performance dependent des optimisations trouvees par le compilateur. Ca depent du code source lui-meme et du compilo.
[^] # Re: en attendant ...
Posté par mdlh . En réponse au journal Firefox: Encore plus vite que vite. Évalué à 4.
Pour simplifier comment ca marche:
Il faut imaginer comment l'interpreteur fonctionne: une boucle sur le flux de bytecode et a l'interieur un gros switch pour chacune des valeurs possibles.
Pour chaque "case", le code effectue un certain nombre de tests: C'est quoi le type de la variable en entree? est-ce que la valeur est bien definie... ensuite il effectue le traitement approprie puis stocke le resultat en respectant une certaine convention comme ca le code qui est associe au prochain bytecode trouve tout comme il veut, quel qu'il soit. Mine de rien, une simple addition, ca prend du temps avec toute les verifications qui vont avec.
Ici l'idee est de dire: Au lieu d'avoir un case pour chaque bytecode, on pourrait rajouter des cas qui traite 2 bytecode successifs. La combinaison des deux codes permet au compilateur de supprimer des tests redondants, eviter une sequence stockage puis rechargement...
C'est pas nouveau et on trouve dans quelques interpreteurs ce genre de regroupement. Les sequences choisies sont celles qui sont communes a la majorite des applications. En fait, on parle de trace.
En fait, il m'est arrive il y a environ 2 ans de le faire manuellement pour certains code scientifiques (les sequences etant specifiques, peut reutilisables) dans python.
L'idee developee ici est de dire: chaque application a ses propres traces characteristiques. Par exemple une boucle: le corps de la boucle ou une partie peut contenir une sequence de bytecode tres frequement executee. C'est ce que fait l'optimiseur:
- construction des traces;
- dermination des traces les plus frequement utilisee;
- emition et optimisation "JIT" du code interpreteur correspondant a l'execution sequentielle de chacun des "sous-codes" de l'interpreteur.
Donc oui, le concept applique ici n'est pas specifique a javascript, car l'optimiseur s'applique a n'importe quel bytecode. Mais les resultats en terme d'amelioration de performance dependent des optimisations trouvees par le compilateur. Ca depent du code source lui-meme et du compilo.