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