Une mauvaise nouvelle: il semblerait qu'un sponsor de DConf demande un slot pour avoir une présentation. Andrei Alexandrescu est donc obligé de retirer son invitation pour le moment (à suivre). Ça continue bien pour les contacts professionnels cependant. Je rencontre quelqu'un presque tous les jours de la semaine, incluant samedi et dimanche prochains.
Ce matin, j'ai eu une rencontre avec Luke Wagner et Michael Bebenita, avec le tracing comme sujet principal. Michael nous a parlé de sa thèse qui impliquait de la compilation de traces pour Java, et de comment il faisait pour résoudre le problème du trace explosion dans son compilateur. Il a fait face à quelques uns des mêmes problèmes que TraceMonkey. Son approche semble en effet éliminer le trace explosion, mais aussi plusieurs des avantages du trace compilation. Il donnait l'impression que dans le contexte d'un langage statique, le tracing n'en vaut pas vraiment la peine, parce que les gains à obtenir sont très petits.
Michael soulève les mêmes doutes que Bruno à savoir si je peut créér avec Higgs un JIT suffisament rapide pour compétitionner avec FF et V8, préfèrerais que j'implante mon système par dessus IonMonkey. Personnellement, je ne crois pas cependant que d'implanter mon tracing JIT par dessus Ion soit vraiment une guarantie de battre les autres sur la performance. Cela risque de contraindre mon design et rendre les refactorings assez difficile si je dois ajuster le tir. Si ma thèse est: "j'ai un design de tracing JIT optimisant qui utilise de l'information de type, spécialise efficacement, et ne produit pas d'explosion de trace", le problème de savoir ce que je vais essayer de publier comme nombres demeure.
J'ai eu comme idée que si on veut vraiment "battre" d'autres JITs sur la performance, il serait probablement assez facile de battre TraceMonkey (le tracing JIT abandonné de Mozilla). Les derniers articles publiés sur TM peignent une image très rose de celui-ci, mais il se trouve que, selon Luke et les autres, TM n'a absolument aucune solution au problème du trace explosion, la performance en terme d'i-cache misses est terrible, et le design comporte beaucoup de faiblesses. Toutes les benchmarks qui ne sont pas des boucles parfaites performent assez mal sur TM, qui, semble-t-il, retombe très souvent en mode interprété.
Il est probablement aussi très possible de battre PyPy sur certains benchmarks. Selon les gens ici, PyPy prend 1-2 minutes à faire son "warmup". Ce serait amusant si on pouvait trouver un compilateur Python->JS et obtenir des meilleur temps qu'eux sur leurs benchmarks traduits à JS. Je n'exclue pas non plus la possibilité de battre IonMonkey sur des benchmarks bien choisis qui s'attaquent spécifiquement à ce qu'Ion optimise mal (programmation fonctionnelle, hauts niveaux d'abstraction... interprète métacirculaire écrit en JS *wink wink*).
Expérience du jour: scores sur benchmarks V8 avec différentes configurations (higher is better):
Options par défaut: 9194 IonMonkey seulement, allocateur de registre linear scan: 7722 IonMonkey seulement, allocateur de registre "stupide": 6100 IonMonkey seulement, sans loop invariant code motion: 7166 IonMonkey seulement, sans inlining: 6695 IonMonkey seulement: sans type inference: 333 JaegerMonkey seulement: 5002 Interprète seulement: 252
Surprenamment, l'inlining fait relativement peu de différence. Moins que le choix d'allocateur de registre, même sur earley-boyer (code Scheme compilé vers JS, plein de petites fonctions) le score est à peine changé. C'est probablement parce qu'Ion fait assez peu d'inlining.
- Maxime
Afficher les réponses par date
On 05-02-2013, at 19:08 , chevalma@iro.umontreal.ca wrote:
Une mauvaise nouvelle: il semblerait qu'un sponsor de DConf demande un slot pour avoir une présentation. Andrei Alexandrescu est donc obligé de retirer son invitation pour le moment (à suivre).
Ok, dommage, tiens nous au courant si la situation change.
Ça continue bien pour les contacts professionnels cependant. Je rencontre quelqu'un presque tous les jours de la semaine, incluant samedi et dimanche prochains.
Wow!
Ce matin, j'ai eu une rencontre avec Luke Wagner et Michael Bebenita, avec le tracing comme sujet principal. Michael nous a parlé de sa thèse qui impliquait de la compilation de traces pour Java, et de comment il faisait pour résoudre le problème du trace explosion dans son compilateur. Il a fait face à quelques uns des mêmes problèmes que TraceMonkey. Son approche semble en effet éliminer le trace explosion, mais aussi plusieurs des avantages du trace compilation. Il donnait l'impression que dans le contexte d'un langage statique, le tracing n'en vaut pas vraiment la peine, parce que les gains à obtenir sont très petits.
Est-ce que ça rejoint ce que tu avais en tête, ou est-ce qu'il reste selon toi une contribution à faire une niveau du tracing?
Michael soulève les mêmes doutes que Bruno à savoir si je peut créér avec Higgs un JIT suffisament rapide pour compétitionner avec FF et V8, préfèrerais que j'implante mon système par dessus IonMonkey. Personnellement, je ne crois pas cependant que d'implanter mon tracing JIT par dessus Ion soit vraiment une guarantie de battre les autres sur la performance. Cela risque de contraindre mon design et rendre les refactorings assez difficile si je dois ajuster le tir.
En effet.
Si ma thèse est: "j'ai un design de tracing JIT optimisant qui utilise de l'information de type, spécialise efficacement, et ne produit pas d'explosion de trace", le problème de savoir ce que je vais essayer de publier comme nombres demeure.
Pour l'instant, voyons ce que ça donne avec Higgs. On pourra mieux cibler les contributions avec un peu de données récoltées.
J'ai eu comme idée que si on veut vraiment "battre" d'autres JITs sur la performance, il serait probablement assez facile de battre TraceMonkey (le tracing JIT abandonné de Mozilla). Les derniers articles publiés sur TM peignent une image très rose de celui-ci, mais il se trouve que, selon Luke et les autres, TM n'a absolument aucune solution au problème du trace explosion, la performance en terme d'i-cache misses est terrible, et le design comporte beaucoup de faiblesses. Toutes les benchmarks qui ne sont pas des boucles parfaites performent assez mal sur TM, qui, semble-t-il, retombe très souvent en mode interprété.
C'est en effet probable que tu puisses atteindre une meilleure performance, mais je ne vois pas trop ce que ça prouve.
Il est probablement aussi très possible de battre PyPy sur certains benchmarks. Selon les gens ici, PyPy prend 1-2 minutes à faire son "warmup". Ce serait amusant si on pouvait trouver un compilateur Python->JS et obtenir des meilleur temps qu'eux sur leurs benchmarks traduits à JS.
1-2 minutes semble assez long en effet pour nous permettre d'avoir une meilleure performance.
Je n'exclue pas non plus la possibilité de battre IonMonkey sur des benchmarks bien choisis qui s'attaquent spécifiquement à ce qu'Ion optimise mal (programmation fonctionnelle, hauts niveaux d'abstraction... interprète métacirculaire écrit en JS *wink wink*).
Je crois, comme toi, que si on comprend bien ce qu'Ion fait, on pourra trouver des benchmarks on ne part pas avec un handicap...
Expérience du jour: scores sur benchmarks V8 avec différentes configurations (higher is better):
Options par défaut: 9194 IonMonkey seulement, allocateur de registre linear scan: 7722 IonMonkey seulement, allocateur de registre "stupide": 6100 IonMonkey seulement, sans loop invariant code motion: 7166 IonMonkey seulement, sans inlining: 6695 IonMonkey seulement: sans type inference: 333 JaegerMonkey seulement: 5002 Interprète seulement: 252
Donc, TI semble critique pour la performance, tel qu'attendu... C'est un bon signe pour toi.
Surprenamment, l'inlining fait relativement peu de différence.
J'avoue que je suis extrêmement surpris par ce résultat.
Moins que le choix d'allocateur de registre, même sur earley-boyer (code Scheme compilé vers JS, plein de petites fonctions) le score est à peine changé. C'est probablement parce qu'Ion fait assez peu d'inlining.
Est-ce qu'on a une façon de vérifier ça avec JIT inspector ?
Bruno
Son approche semble en effet éliminer le trace explosion, mais aussi plusieurs des avantages du trace compilation. Il donnait l'impression que dans le contexte d'un langage statique, le tracing n'en vaut pas vraiment la peine, parce que les gains à obtenir sont très petits.
Est-ce que ça rejoint ce que tu avais en tête, ou est-ce qu'il reste selon toi une contribution à faire une niveau du tracing?
Je crois qu'il reste tout à fait une contribution à faire. Son tracing reste encore basé sur les boucles. Honnêtement, je trouvais son approche peu satisfaisante. Il fait un compromis pour éliminer le trace explosion: il fusionne des morceaux de traces (ceux qui sont partagés entre les traces). Il disait aussi que son tracing JIT tombe souvent hors du mode tracing, quand les boucles ne sont pas idéales.
Je reste persuadée que ça doit être possible de faire grandir une couverture du code jusqu'à ne presque jamais tomber "hors trace". Ça me semble absolument logique. Si on y pense, l'approche la plus naïve serait de se limiter à des fragments d'un basic block de long, et de n'avoir qu'une seule version de chaque. À la limite, chaque basic block est compilé. Ce n'est pas difficile d'imaginer quelque chose d'équivalent mais plus sophistiqué. Je crois aussi que le tracing a beaucoup plus de sens dans le monde dynamique, parce que ça permet de versionner (cloner) le code là ou c'est utile.
Surprenamment, l'inlining fait relativement peu de différence.
J'avoue que je suis extrêmement surpris par ce résultat.
C'est probablement parce qu'Ion fait assez peu d'inlining.
Est-ce qu'on a une façon de vérifier ça avec JIT inspector ?
Je ne crois pas que JIT inspector le fait, mais ils ont probablement un moyen quelconque de le faire. Je vais demander à Luke.
- Maxime
-
Bruno Dufour -
chevalma＠iro.umontreal.ca