Pour continuer où le compte-rendu #1 s'arrêtait, c'est-à-dire samedi après-midi, Antony m'a invité à venir souper avec lui, Steve Blackburn et d'autres participants de RESoLVE. Il m'a conseillé fortement de publier à OOPSLA le plus tôt possible et de profiter du fait que mon projet est actuellement "sexy".

Avant d'aller souper nous avons pris une bière à l'hôtel. Parmis les conversations les plus intéressantes que j'ai eues, celle avec Anil Madhavapeddy était remarquable. Ce dernier était à la fois très dynamique, avec un débit tellement rapide que je devais le faire répéter de temps à autre et un enthousiasme particulièrement communicatif. Anecdote qui ne sera savoureuse que pour ceux qui ont lu le compte-rendu de POPL (pas juste comme somnifère ;-)), Anil est le superviseur de Heidi, la rousse de Cambridge, qui apparaît dans une des photos que je vous ai envoyée (dans le compte-rendu de POPL). Leur projet est particulièrement excitant, ils travaillent sur un OS micro-kernel en OCAML qui tourne sur l'infrastructure d'Amazon. L'objectif est de permettre d'établir des canaux de communication sécurisés personnels pour plusieurs /devices/ sur des réseaux différents, potentiellement avec firewalls et autres. Je pourrai vous donner plus de détails mercredi après sa présentation.

Le reste du souper était intéressant, bien que comme seul étudiant parmi un groupe de "seniors" du milieu académique et industriel j'ai davantage été observateur que participant. L'objectif avoué d'Antony dans l'invitation était de discuter de leur projet de framework de VM pour langage dynamique. Dans les faits, on en a peu parlé et la conversation a dérivé sur la politique américaine et australienne, les différences culturelles entre les pays, le choix d'un Chair général pour une prochaine conférence, les aléas de l'organisation d'une revue par les pairs d'articles, etc. J'ai également su que la hache a été mis dans le projet Maxine chez Oracle et j'ai eu droit à des anecdotes internes sur la tentative ratée d'Intel de développer une VM haute-performance pour Java pour éviter de laisser une partie critique de la stack informatique dans les mains de son principal concurrent de l'époque, Sun.

Steve a dit essentiellement la même chose qu'Antony sur l'idée de faire une VM haute-performance pour JavaScript (ce qui n'est certainement pas suprenant puisqu'ils travaillent ensembles) c'est-à-dire qu'avec l'effort industriel actuel derrère le langage c'est difficile d'obtenir rapidement des résultats comparablement intéressants. Je ne me rappelle plus ses termes exacts, mais il me semble qu'il ait dit qu'il n'y avait plus rien à faire avec Java non plus à ce niveau, ce qui expliquerait qu'ils sont en train de se tourner vers les langages dynamiques. Il a par la suite argumenté qu'au niveau industriel c'est toujours possible de mettre des ressources démesurées pour optimiser même le pire des langages. Pour supporter son argument, il m'a dit que certains estiment à 1 milliards $ l'argent qui a collectivement été mis sur l'optimisation de Java. Steve a envoyé une demande de financement en Australie la semaine dernière pour leur projet de VM et est en attente de réponse. Atony s'est plaint qu'il était difficile de faire passer des projets "d'infrastructure" à NSF et a même lancé à la "blague" qu'il aurait peut-être mieux fait d'aller en industrie pour faire de l'infrastructure. Il aurait peut-être eu moins de liberté sur le choix de ce qu'il aurait construit mais au moins il aurait pu le faire.

Il y a eu des discussions sur la position des gros joueurs, Oracle, VMWare et de leurs projets en cours, dont je ne me rappelle plus malheureusement. Dans tous les cas, je suis ressorti avec la nette impression que Steve et Antony entretiennent des contacts étroits avec plusieurs personnes en industrie et qu'ils orientent leurs projet de recherches en fonction de ce qui s'y passe. J'ai également eu l'impression que leurs projets étaient solides techniquement mais clairement incrémentaux, ce qui a l'avantage d'être facilement transférable en industrie et plus facile à vendre pour obtenir du financement industriel mais le désavantage d'avoir une demi-vie limitée, ce qui oblige à suivre les tendances industrielles pour éviter de rater la vague ou de tomber en désuétude.

Dimanche, j'ai pris la majeure partie de la journée pour travailler sur Photon, pour faire quelques optimisations et expériences supplémentaires pour l'article et j'ai peu rencontré de gens. J'ai tout de même parlé avec un allemand de l'université de Dresden. Il m'a partagé qu'un de ses collègues qui travaille avec les FPGAs a battu le record du monde pour la résolution du problème des N-Reines, c'est-à-dire qu'ils ont résolu une instance de 26x26 alors que le précédent record était 25x25, en exploitant le circuit de report de retenue qui sert normalement à accélérer les additions matérielles. Il a pas pu m'expliquer comment le problème pouvait être converti de cette façon car ce n'est pas son projet mais j'ai tout de même trouvé l'anecdote intéressante.

Aujourd'hui, j'ai également passé la plus grosse partie de la journée à travailler sur Photon. J'ai été surpris de voir une session entière réservée à l'efficacité énergétique dans les centres de données. En même temps, ça fait du sens étant donné la monté de "l'informatique nuagique".

Pendant le lunch, j'ai parlé avec Chen Ding http://www.cs.rochester.edu/groups/bai/compiler, prof à l'université de Rochester. Après mon pitch de 30s sur Photon, sa réaction fut "It seems like fun!". Il m'a même dit que l'instrumentation dynamique de Ruby pourrait peut être être fait avec une approche similaire. Il m'a ensuite partagé qu'il travaillait sur le Paraléllisme Sécuritaire en Ruby. Il avait un fort accent asiatique (chinois?) et j'ai eu de la difficulté à comprendre le détail de ses explications mais il semble avoir un intérêt marqué pour les optimisations dynamiques exploitant le paraléllisme tout en préservant la sémantique séquentielle du langage original. J'ai tâté l'eau pour voir s'il serait intéressé à appliquer ses idées à JavaScript, il semblait nettement préférer travailler avec Ruby ;-). Il connaissait Laurie de McGill et m'a suggéré de participer à CASCON, histoire de garder contact et d'être avec la gang de compilation ;-).

Dans le reste de la journée, ce qui m'a marqué c'est le développement d'approche probabilistes pour le développement de certaines tâches (par opposition aux méthode déterministes). D'abord, un présentateur a suggéré l'utilisation de compteurs de performances pour obtenir de l'information suffisante pour déterminer la cause de bugs sur du logiciel déployé en production. Puisque l'approche n'est pas garantie d'obtenir des résultats ça a soulevé du scepticisme de la part d'une prof plus agée, de l'université de Virginia je crois. Ensuite, la présentation la plus intéressante fut une présentation invitée de Vikash K. Mansinghka http://web.mit.edu/vkm/www/ dans laquelle il présentait un DSL pour l'apprentissage machine, basé sur des primitives probabilistes plutôt que déterministes (booléennes). Il argumentait avoir obtenu un facteur 100x en nombre de lignes de code et jusqu'à 1000x en vitesse d'exécution avec une implémentation sur FPGA. Le coeur de l'idée c'est qu'apprentissage machine, les fondements mathématiques offrent un parallélisme et un non-déterminisme inhérent qui n'est pas supporté efficacement par nos architectures séquentielles déterministes modernes. Pour exprimer les algorithmes, ils ont développé un langage spécifique au domaine basé sur une variante de scheme sans la mutabilité. Anecdote de métacircularité, à une question de l'auditoire sur les fondaments réellement révolutionnaires de leur approche, Vikash a argumenté que leur langage, Venture, est le premier langage offrant des primitives probabilistes capable d'implémenter son engin d'inférence dans son propre formalisme.

La tendance sous-jacente semble suivre ce que David Ungar argumentait à DLS 2011, c'est à dire qu'il est temps d'abandonner le déterminisme et les garanties de correctitude pour aller chercher la prochaine vague d'amélioration majeure de performance (pour les applications qui s'y prêtent). Ma perception c'est que les méthodes probabilistes vont dans ce sens.

Bon, j'arrête ici, j'ai un rapport à terminer ;).

Erick