Quelles étaient les optimisations (alors) non publiées auxquelles Steve Yegge faisait référence dans "Dynamic Languages ​​Strike Back"?

Question

Je lisais la transcription de la présentation de Steve Yegge Dynamic Languages Strike Back, quand je remarqué ce commentaire quand il commence à discuter des arbres de traces:

Je vais être honnête avec vous, j'ai en fait deux optimisations qui ne pouvaient pas aller dans cette conversation qui sont encore plus cool que cela parce qu'ils n'ont pas encore publié. Et je ne voulais pas laisser le chat sortir du sac avant qu'ils ne publient. Donc, ce n'est en fait que la pointe de l'iceberg.

Quelles sont les optimisations auxquelles il faisait référence?

Mise à jour

Il y a quelques jours, j'ai posé cette question dans un commentaire sur l'article. Cependant, la modération des commentaires est activée (forgoodreasons), elle n'est donc pas encore apparue.

Mise à jour

Il a été quelques semaines depuis que j'ai essayé de joindre l'auteur. Est-ce que quelqu'un d'autre sait une autre façon de le contacter?

Answer 1

Vous pouvez visionner cette vidéo sur youtube sous le canal StanfordUniversity: http://www.youtube.com/watch?v=tz-Bb-D6teE Vous pouvez également y ajouter des commentaires. Peut-être que quelqu'un viendra à votre secours.

Answer 2

Jetez un oeil à ceci: http://blog.stackoverflow.com/2009/04/podcast-50/

EDIT: Difficile de trouver des références cependant, ce document spécifique (confirmé) donne peut-être quelques informations à ce sujet: http://people.mozilla.org/~dmandelin/tracemonkey-pldi-09.pdf et ce blog qui semble lié: http://andreasgal.wordpress.com/2008/08/22/tracing-the-web/

Peut ne pas être lié car il s'agit d'un document de recherche de Microsoft à partir de Mars 2010: http://research.microsoft.com/pubs/121449/techreport2.pdf

pure spéculation de ma part mais il semble (au moins pour moi) qu'il existe deux formes majeures de performance, au niveau du développeur (IDE) et celui au niveau du compilateur auquel s'adresse ce sujet des arbres de trace, d'où le "optomisation continue" lors de l'exécution pour obtenir la trace en ligne pour les points chauds. Cela m'amène ensuite rapidement aux domaines de l'optomisation liés aux multi-cœurs et à l'utilisation de l'arbre de trace à cet égard (environnements multi-cœurs). Des choses intéressantes étant donné la spéculation de vitesse de type non statique actuellement théorique par rapport aux gagnants de vitesse de type statique utilisés dans le courant C et le potentiel de performance à gagner. Je me souviens d'une discussion que j'ai eue avec un ingénieur en matériel il y a des années (1979) où nous avions spéculé que si nous pouvions capturer les trajectoires d'exécution «chaudes», nous pourrions obtenir un gain énorme en performance en le gardant in situ. c'était bien avant le travail chez HP à cet égard (1999?) et malheureusement nous n'avons pas dépassé le stade de la discussion en raison d'autres engagements. (Je divague ici je pense ... :)

OU, était-ce juste lié à la langue GO? difficile à dire à certains égards.