Bonjour à tous et désolée pour le délai depuis le dernier message, j'ai été pas mal occupée.

Pour commencer: c'est confirmé, je vais présenter à DConf 2013, en mai. Je vais donner un invited talk, un expérience report sur l'implantation de Higgs en D. Le slot dure 60 minutes, ce qui sera amplement suffisant pour parler de Higgs et de ma recherche. Bruno et Marc suggèrent que j'en profite pour faire une courte visite chez Mozilla.

Samedi dernier, j'ai eu l'opportunité de rencontrer Alex Gaynor, qui fait partie de l'équipe PyPy. Il semblait intéressé par le monitoring des types, c'est quelque chose qu'ils ne font pas. Alex semble croire que PyPy a réglé le problème de l'explosion des traces. Semblerait qu'ils ont un mécanisme de cache des traces, un peu comme dans Dynamo. Ce mécanisme jette le code qui n'a pas été récemment utilisé si l'utilisation mémoire est trop grande. J'en ai profité pour lui demander si quelqu'un avait implanté JS sur PyPy. Il dit qu'il y a déja eu un effort pour le faire, mais ce projet est malheureusement mort, et le code n'est plus à date.

Dimanche, je suis allée au Computer History Museum avec Pierre Phaneuf de Google Montréal. J'ai trouvée l'exhibition très complete et impressionante. Ils avaient une réplique du moteur différentiel de Charles Babbage, dont ils démontraient le fonctionnement, en l'activant avec une grosse manivelle. Ça faisait un bruit mécanique très satisfaisant. Ah oui, ils avaient aussi une LISP Machine dans un coin sombre, et la Connection Machine! ;)

Hier, j'ai visité Apple. J'ai présenté Higgs (http://imgur.com/Z6CHEKY) devant les équipes du static analyzer (Clang) et l'équipe JavaScriptCore (WebKit). J'ai eu une réception intéressante. Beaucoup de questions, un peu de scepticisme (je m'y attendait). Un des types de JSC semblait littéralement en colère que j'ose défier certaines de leurs suppositions techniques, par exemple avec mon système de type tagging, il avait le visage tout rouge (type A personality?). Les membres de l'audience ce sont mis à argumenter entre eux à savoir quel impact ça aurait sur la performance.

Je n'ai malheureusement pas pu discuter beaucoup avec les gens d'Apple. Ils étaient pressés et je n'avais pas le droit d'aller voir leurs bureaux. Étienne disait la vérité quand il parlait de leur obsession avec la sécurité. Il y avait des ID scanners partout, ça me prenait un "guest badge". L'édifice était très peu décoré, et très générique. Pas de snacks gratuits non plus. Ça ne semble pas un endroit aussi plaisant que Mozilla. Marc et Bruno seront content de savoir qu'ils ne m'ont pas fait d'offre d'emploi. Mon contact labas (Ted Kremenek) semble tout à fait respecter que je veuille finir mon doctorat.

Quelques faits techniques intéressants que j'ai appris récemment:

- JSC ont un système de read-barrier. C'est-à-dire des tests à la lecture de propriétés qui servent à réduire la taille des ensembles de types possibles. Ceci est un peu comme une version plus faible (ou une implémentation partielle) du type inference de Mozilla.

- JSC semblent du boxing traditionnel avec des tag bits

- Les devs d'IonMonkey parlaient aujourd'hui au lunch du fait que le NaN boxing leur coute une pénalité importante quand ils doivent déboxer des pointeurs. Ils parlent d'éventuellement changer de tag bit scheme.

- Le moteur JS d'Opera (pas open source) utilise soit disant un système de tags similaire aux miens, avec un type stack séparé. Leur performance est compétitive, selon les devs d'IonMonkey.

J'ai entrepris une recherche litéraire un peu plus en profondeur pour essayer de trouver du travail relié à ce que je veux faire avec la compilation de trace. J'ai trouvé un article sur l'extension de trace (style loop unrolling) qui parle aussi de "straightening" de code. Ils présentaient une heuristique à savoir quand étendre le code en fonction de pourcentage estimé de complétion de l'exécution des traces (e.g.: est-ce qu'on va se rendre jusqu'à la fin de la trace avec plus de 97% de certitude?). Il y a des gains à avoir en terme de cache d'instruction, de branch prediction et d'instruction scheduling.

Je commence à croire qu'il y a vraiment quelque chose de nouveau et d'intéressant à faire avec ça. Un compilateur de langage dynamique peut probablement gagner pas mal en accumulant des suppositions sur les types au fur et à mesure qu'une trace progresse. Les heuristiques à choisir pour construire les segments de code ne sont pas évidents. Il faut balancer l'expansion du code avec la performance du code généré. Générer plus de code là ou ça en vaut la peine, sans causer énormément de i-cache misses.

Je crois que l'idéal serait une heuristique d'expansion de code basée sur la fréquence d'exécution. Ce qui s'exécute le plus devrait recevoir davantage d'expansion. J'ai quelques idées à savoir comment faire ça. Je crois qu'on pourrait peut-être faire en sorte que l'interprète maintienne un petit buffer circulaire de l'historique des blocs récemment exécutés. De cette façon il y a moyen d'estimer les probabilités d'exécution de traces spécifiques avant leur génération (e.g.: quelle est la fréquence relative de ABC vs ABD? Notre historique peut nous le dire).

J'ai mis du temps à faire du travail "low-key" dans le code de Higgs aussi. Je règle les bugs qui empêchent certaine benchmarks de rouler sur mon système. Je dois en avoir éliminé une dizaine. Presque tout SunSpider et la moitié de V8 fonctionnement maintenant. Les benchmarks V8 valident la correctitude de leurs résultats, ce qui est très utile.

- Maxime