Bonjour
Nous avons de très bonnes présentations aujourd'hui au SFP12. Une était particulièrement intéressante pour tout le groupe alors je vous en envoie les points principaux. La présentation se nommait "Optimizing JS code for V8". Je vous donne tout d'un bloc même si vous connaissez possiblement ce qu'il a dit.
- l'optimisateur se nomme *crankshaft* - seules les fonctions '*hot*' sont optimisées, c.-à-d. des fcts ayant été exécutées un nombre minimum de fois. - il suggère de lancer chrome avec l'option *--user-data-dir=<empty dir>*si on veut avoir une VM clean pour faire des tests. - on peut passer les options suivantes à d8 pour avoir une trace de ce que le compilateur fait de notre code: - *--trace-<flag>*, où flag dans {opt, bailout, inlining, deopt, hydrogen} - *opt*: trace les fcts optimisées - *bailout*: trace les fcts pour lesquelles l'optimisation a été enlevée - *inlining*: trace des fonctions inlinées. Une fct de trop grande taille ("incluant" les commentaires) peut ne pas être inilinée. L'heuristique n'est pas parfaitement au point - *deopt*: trace des fcts pour lesquelles crankshaft enlève les optimisations quand un pattern d'appel change (pour f(a), 'a' a tjrs été un 'int' mais on passe une string). Le processus de deoptimization est coûteux et le code résultant est plus lent. Crankshaft peut optimiser pour une combinaison de types ('a' est int ou str). Crankshaft essaie d'optimiser 5 fois puis démissionne et compile une fonction générique (lente). On peut ajouter le flag *--print-comment* pour avoir plus d'information. - si on compile d8 avec *dissassembler=on*, on peut faire un dump du code asm (scons disassembler=on d8. Utiliser le flag "--print-code"pour avoir le dump. - *hydrogen*: peut être utilisé avec *c1visualizer* pour une représentation graphique du CFG du programme avec capacité d'inspection très cool. Il faut utiliser *--no-sandbox*. Crée le fichier hydrogen.cfg que c1visualizer peut lire. - V8 ne sait pas optimiser le code dans un try/catch - 'arguments' n'est pas optimisé - il vaut toujours mieux utiliser des fonctions monomorphiques (où le type des variables est stable). Vaut mieux dupliquer une fonction et être certain qu'une variable sera tjrs du même type.
J'espère que ce sera utile, et que je n'ai pas fait d'erreur de transcription... Eric
Afficher les réponses par date
Bonjour Eric,
Merci pour l'info, c'est très intéressant. Est-ce qu'il y a un papier là-dessus, ou simplement une présentation? Mais surtout, comment s'est passée ta présentation? As-tu eu des questions intéressantes?
Bruno
On 2012-09-09, at 4:37 PM, Eric Thivierge thiveri@gmail.com wrote:
Bonjour
Nous avons de très bonnes présentations aujourd'hui au SFP12. Une était particulièrement intéressante pour tout le groupe alors je vous en envoie les points principaux. La présentation se nommait "Optimizing JS code for V8". Je vous donne tout d'un bloc même si vous connaissez possiblement ce qu'il a dit. • l'optimisateur se nomme crankshaft • seules les fonctions 'hot' sont optimisées, c.-à-d. des fcts ayant été exécutées un nombre minimum de fois. • il suggère de lancer chrome avec l'option --user-data-dir=<empty dir> si on veut avoir une VM clean pour faire des tests. • on peut passer les options suivantes à d8 pour avoir une trace de ce que le compilateur fait de notre code: • --trace-<flag>, où flag dans {opt, bailout, inlining, deopt, hydrogen} • opt: trace les fcts optimisées • bailout: trace les fcts pour lesquelles l'optimisation a été enlevée • inlining: trace des fonctions inlinées. Une fct de trop grande taille ("incluant" les commentaires) peut ne pas être inilinée. L'heuristique n'est pas parfaitement au point • deopt: trace des fcts pour lesquelles crankshaft enlève les optimisations quand un pattern d'appel change (pour f(a), 'a' a tjrs été un 'int' mais on passe une string). Le processus de deoptimization est coûteux et le code résultant est plus lent. Crankshaft peut optimiser pour une combinaison de types ('a' est int ou str). Crankshaft essaie d'optimiser 5 fois puis démissionne et compile une fonction générique (lente). On peut ajouter le flag --print-comment pour avoir plus d'information. • si on compile d8 avec dissassembler=on, on peut faire un dump du code asm (scons disassembler=on d8. Utiliser le flag "--print-code" pour avoir le dump. • hydrogen: peut être utilisé avec c1visualizer pour une représentation graphique du CFG du programme avec capacité d'inspection très cool. Il faut utiliser --no-sandbox. Crée le fichier hydrogen.cfg que c1visualizer peut lire. • V8 ne sait pas optimiser le code dans un try/catch • 'arguments' n'est pas optimisé • il vaut toujours mieux utiliser des fonctions monomorphiques (où le type des variables est stable). Vaut mieux dupliquer une fonction et être certain qu'une variable sera tjrs du même type. J'espère que ce sera utile, et que je n'ai pas fait d'erreur de transcription... Eric _______________________________________________ Dlteam-list mailing list Dlteam-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/dlteam-list
Je vais demander à Florian pour sa présentation. Je ne crois pas qu'il y ait de papier comme tel.
Pour moi, c'a bien été, au même niveau que mercredi passé. J'ai eu quelques questions de base et une plus intéressante de la part d'Olivier Danvy. Un chapitre/paragraphe de sa thèse de doc portait justement sur le partage des blocs de continuations une fois heapifiés. Il aurait aimé qu'on en parle plus en profondeur. Une slide illustrant ce point aurait été très intéressante.
@+ Eric
2012/9/10 Bruno Dufour dufour@iro.umontreal.ca
Bonjour Eric,
Merci pour l'info, c'est très intéressant. Est-ce qu'il y a un papier là-dessus, ou simplement une présentation? Mais surtout, comment s'est passée ta présentation? As-tu eu des questions intéressantes?
Bruno
On 2012-09-09, at 4:37 PM, Eric Thivierge thiveri@gmail.com wrote:
Bonjour
Nous avons de très bonnes présentations aujourd'hui au SFP12. Une était
particulièrement intéressante pour tout le groupe alors je vous en envoie les points principaux. La présentation se nommait "Optimizing JS code for V8". Je vous donne tout d'un bloc même si vous connaissez possiblement ce qu'il a dit.
• l'optimisateur se nomme crankshaft • seules les fonctions 'hot' sont optimisées, c.-à-d. des fctsayant été exécutées un nombre minimum de fois.
• il suggère de lancer chrome avec l'option --user-data-dir=<emptydir> si on veut avoir une VM clean pour faire des tests.
• on peut passer les options suivantes à d8 pour avoir une tracede ce que le compilateur fait de notre code:
• --trace-<flag>, où flag dans {opt, bailout, inlining,deopt, hydrogen}
• opt: trace les fcts optimisées • bailout: trace les fcts pour lesquelles l'optimisation aété enlevée
• inlining: trace des fonctions inlinées. Une fct de tropgrande taille ("incluant" les commentaires) peut ne pas être inilinée. L'heuristique n'est pas parfaitement au point
• deopt: trace des fcts pour lesquelles crankshaft enlèveles optimisations quand un pattern d'appel change (pour f(a), 'a' a tjrs été un 'int' mais on passe une string). Le processus de deoptimization est coûteux et le code résultant est plus lent. Crankshaft peut optimiser pour une combinaison de types ('a' est int ou str). Crankshaft essaie d'optimiser 5 fois puis démissionne et compile une fonction générique (lente). On peut ajouter le flag --print-comment pour avoir plus d'information.
• si on compile d8 avec dissassembler=on, on peut faire undump du code asm (scons disassembler=on d8. Utiliser le flag "--print-code" pour avoir le dump.
• hydrogen: peut être utilisé avec c1visualizer pour unereprésentation graphique du CFG du programme avec capacité d'inspection très cool. Il faut utiliser --no-sandbox. Crée le fichier hydrogen.cfg que c1visualizer peut lire.
• V8 ne sait pas optimiser le code dans un try/catch • 'arguments' n'est pas optimisé • il vaut toujours mieux utiliser des fonctions monomorphiques (oùle type des variables est stable). Vaut mieux dupliquer une fonction et être certain qu'une variable sera tjrs du même type.
J'espère que ce sera utile, et que je n'ai pas fait d'erreur de
transcription...
Eric _______________________________________________ Dlteam-list mailing list Dlteam-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/dlteam-list
Dlteam-list mailing list Dlteam-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/dlteam-list
On 2012-09-10, at 11:20 AM, Eric Thivierge thiveri@gmail.com wrote:
Je vais demander à Florian pour sa présentation. Je ne crois pas qu'il y ait de papier comme tel.
En effet ça serait intéressant.
Pour moi, c'a bien été, au même niveau que mercredi passé. J'ai eu quelques questions de base et une plus intéressante de la part d'Olivier Danvy. Un chapitre/paragraphe de sa thèse de doc portait justement sur le partage des blocs de continuations une fois heapifiés. Il aurait aimé qu'on en parle plus en profondeur. Une slide illustrant ce point aurait été très intéressante.
En effet. On peut toujours l'ajouter, pour les prochaines fois qu'on donne la présentation.
Marc
-
Bruno Dufour -
Eric Thivierge -
Marc Feeley