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