Michel Scott - déjà 34 ans en tant que professeur d'informatique à l'Université de Rochester et à son université natale du Wisconsin – Madison, il a été doyen pendant cinq ans. Il effectue des recherches et enseigne aux étudiants la programmation parallèle et distribuée et la conception de langages.

Le monde connaît Michael grâce au manuel "Pragmatique du langage de programmation", quid du travail "Algorithmes de synchronisation évolutive sur multiprocesseurs à mémoire partagée" a reçu le prix Dijkstra comme l'un des plus célèbres dans le domaine de l'informatique distribuée. Vous le connaissez peut-être aussi comme l'auteur de cet algorithme. Michael-Scott.

Avec Doug Lee, il a développé les algorithmes non bloquants et les files d'attente synchrones qui alimentent les bibliothèques Java. Mise en œuvre "structures de données doubles" dans JavaSE 6, les performances ont été améliorées de 10 fois ThreadPoolExecutor.

Table des matières:

• Début de carrière, Université de Rochester. Projet Charlotte, langage Lynx ;
• Interface cohérente évolutive IEEE, verrouillage MCS ;
• Survie dans un monde en constante évolution ;
• Les étudiants deviennent-ils plus bêtes ? Tendances mondiales, internationalisation ;
• Travail efficace avec les étudiants;
• Comment suivre la préparation de nouveaux cours et livres ;
• Liens entre les entreprises et le monde universitaire ;
• Mise en œuvre pratique des idées. MCS, MS, CLH, JSR 166, en collaboration avec Doug Lee et plus ;
• Mémoire transactionnelle ;
• Nouvelles architectures. La victoire de la mémoire transactionnelle est proche ;
• Mémoire non volatile, Optane DIMM, appareils ultra-rapides ;
• La prochaine grande tendance. Structures de données doubles. Hydre.

L'entretien est mené par :

Vitali Aksenov — actuellement postdoctorant à l'IST Autriche et membre du Département de technologies informatiques de l'Université ITMO. Effectue des recherches dans le domaine de la théorie et de la pratique des structures de données compétitives. Avant de travailler à l'IST, il a obtenu son doctorat à l'Université Paris Diderot et à l'Université ITMO sous la direction du professeur Peter Kuznetsov.

Alexeï Fedorov - Producteur chez JUG Ru Group, une société russe qui organise des conférences pour les développeurs. Alexey a participé à la préparation de plus de 50 conférences, et son CV comprend tout, du poste d'ingénieur de développement chez Oracle (JCK, Java Platform Group) au poste de développeur chez Odnoklassniki.

Vladimir Sitnikov - Ingénieur chez Netcracker. Dix ans de travail sur les performances et l'évolutivité de NetCracker OS, logiciel utilisé par les opérateurs télécoms pour automatiser les processus de gestion des réseaux et des équipements réseaux. Intéressé par les problèmes de performances de Java et Oracle Database. Auteur de plus d'une douzaine d'améliorations de performances dans le pilote officiel PostgreSQL JDBC.

Début de carrière, Université de Rochester. Projet Charlotte, langage Lynx.

Alexey: Pour commencer, je voulais vous dire qu'en Russie, nous aimons tous beaucoup l'informatique, la science des données et les algorithmes. C'est carrément obscène. Nous avons tout lu livre Cormen, Leiserson et Rivest. Par conséquent, la prochaine conférence, l’école et cette interview elle-même devraient être très populaires. Nous avons reçu de nombreuses questions pour cette interview de la part d'étudiants, de programmeurs et de membres de la communauté, nous sommes donc très reconnaissants pour cette opportunité. L’informatique reçoit-elle le même amour aux États-Unis ?

Michael: Notre domaine est si diversifié, il a tellement de directions et il affecte la société de tellement de manières différentes qu'il m'est difficile de vous donner une réponse définitive. Mais le fait est qu’elle a entraîné d’énormes changements dans les affaires, l’industrie, l’art et la société en général au cours des 30 dernières années.

Vitali: Commençons par quelque chose de lointain. Dans de nombreuses universités, il existe une sorte de spécialisation dans un domaine particulier. Pour l'Université Carnegie Mellon, il s'agit de calcul parallèle, pour le MIT, de cryptographie, de robots et de multithreading. Existe-t-il une telle spécialisation à l'Université de Rochester ?

Michael: Pour être honnête, je dirais que la CMU et le MIT se spécialisent dans tous les domaines. Notre département a toujours accordé la plus grande attention à l’intelligence artificielle. La moitié des personnes qui travaillent pour nous sont impliquées dans l'IA ou l'interaction homme-machine - cette part est plus élevée que dans d'autres départements, et cela a toujours été le cas. Mais quand j’étais à l’université, je n’avais aucun cours en IA et je n’ai jamais travaillé dans ce domaine. Mon département se spécialise donc dans un problème avec lequel je n'ai rien à voir. La consolation est que le deuxième problème le plus important pour notre département est la programmation parallèle et multithread, c'est-à-dire ma spécialisation.

Vitali: Vous avez commencé à travailler en informatique alors que le domaine de la programmation multithread commençait tout juste à émerger. La liste de vos publications montre que vos premiers travaux traitaient d'un éventail de problématiques assez large : gestion de la mémoire dans les systèmes multithread, systèmes de fichiers distribués, systèmes d'exploitation. Pourquoi une telle polyvalence ? Avez-vous essayé de trouver votre place dans la communauté des chercheurs ?

Michael: En tant qu'étudiant, j'ai participé à Projet Charlotte à l'Université du Wisconsin, où l'un des premiers systèmes d'exploitation distribués a été développé. Là, j'ai travaillé avec Rafael Finkel (Raphaël Finkel) et Marvin Salomon (Marvin Salomon). Ma thèse était consacrée au développement d'un langage pour les logiciels système pour les systèmes distribués - maintenant tout le monde l'a oublié, et Dieu merci. J'ai créé le langage de programmation Lynx, destiné à faciliter la création de serveurs pour un système d'exploitation distribué faiblement couplé. Comme à cette époque j'étais principalement impliqué dans les systèmes d'exploitation, je pensais que ma carrière serait principalement liée à eux. Mais Rochester était une très petite université et, de ce fait, les différents groupes interagissaient très étroitement les uns avec les autres. Il n'y avait pas une douzaine d'autres spécialistes des systèmes d'exploitation avec qui parler, donc tous mes contacts étaient avec des personnes qui travaillaient dans des domaines complètement différents. J’ai vraiment apprécié, être polyvalent est un gros avantage pour moi. Si nous parlons spécifiquement de structures de données multithread et d'algorithmes de synchronisation, j'ai commencé à travailler dessus complètement par hasard.

Interface cohérente évolutive IEEE, verrouillage MCS.

Vitali: Pouvez-vous m'en dire un peu plus ?

Michael: C'est une histoire drôle que je ne me lasse pas de raconter à tout le monde. C'est arrivé lors d'une conférence ASPLOS à Boston, c'était à la fin des années 80 ou au début des années 90. John Mellor-Crummey (John Mellor-Crummey), diplômé de notre faculté. Je le connaissais, mais nous n'avions jamais mené de recherches communes auparavant. Marie Vernon (Marie Vernon) du Wisconsin a parlé d'un système multiprocesseur qu'ils développaient dans le Wisconsin : Wisconsin Multicube. Ce Multicube avait un mécanisme de synchronisation au niveau matériel appelé Q sur Sync Bit, et plus tard il a été renommé Q sur Lock Bit parce que cela ressemblait à du fromage Colby, ce qui était un jeu de mots. Si vous êtes intéressé par les mécanismes multithreading, vous savez probablement que Colby est finalement devenu le moteur de synchronisation de la norme IEEE Scalable Coherent Interface. Il s'agissait d'un mécanisme de verrouillage qui créait des pointeurs d'un cache à un autre au niveau matériel afin que chaque détenteur de verrou sache à qui appartenait le tour. Lorsque John et moi avons entendu parler de cela, nous nous sommes regardés et nous nous sommes dit : pourquoi faire cela au niveau matériel ? La même chose ne peut-elle pas être obtenue en utilisant la comparaison et l'échange ? Nous avons pris un des cahiers qui traînaient dans la classe et avons griffonné dessus Blocage MCS, tandis que Mary poursuivait son rapport. Par la suite, nous l'avons mis en œuvre, expérimenté, l'idée s'est avérée fructueuse et nous avons publié l'article. À cette époque, ce sujet me paraissait juste une distraction amusante, après quoi j'envisageais de revenir aux systèmes d'exploitation. Mais ensuite un autre problème dans le même sens est apparu, et finalement la synchronisation, le multithreading et les structures de données sont devenus ma spécialité. Comme vous pouvez le constater, tout cela est arrivé par accident.

Vitali: Je connais le blocage MCS depuis longtemps, mais jusqu'à présent je ne savais pas que c'était votre travail, et je ne comprenais pas que c'était un acronyme pour vos noms de famille.

Comment survivre dans un monde en constante évolution ?

Alexey: J'ai une question sur un sujet connexe. Il y a 30 ou 40 ans, il y avait plus de liberté dans les différentes spécialités. Si vous souhaitez débuter une carrière dans le multithreading ou les systèmes distribués, vous êtes les bienvenus, si vous souhaitez vous lancer dans les systèmes d'exploitation, pas de problème. Dans chaque domaine, il y avait de nombreuses questions ouvertes et peu d'experts. Des spécialisations étroites sont désormais apparues : il n'existe pas seulement des experts sur les systèmes d'exploitation en général, il existe des spécialistes sur des systèmes individuels. C'est la même chose avec les systèmes multithreading et distribués. Mais le problème est que nos vies ne sont pas interminables : chacun ne peut consacrer que quelques décennies à la recherche. Comment survivre dans ce nouveau monde ?

Michael: Nous ne sommes pas spéciaux à cet égard, la même chose s'est produite autrefois dans d'autres domaines. J'ai eu la chance de commencer à travailler dans l'informatique alors que le domaine en était à ses années « adolescentes ». Certaines bases avaient déjà été posées, mais tout était encore très immature. Cette opportunité ne se présente pas souvent. L'électrotechnique existe depuis très longtemps, la physique encore plus longtemps et les mathématiques presque depuis la nuit des temps. Mais cela ne veut pas dire que plus personne ne fait de découvertes intéressantes en mathématiques. Il reste encore de nombreux problèmes en suspens, mais dans le même temps, il reste encore beaucoup à apprendre. Vous avez raison de constater qu’il existe aujourd’hui beaucoup plus de spécialisations qu’avant, mais cela signifie simplement que nous nous trouvons dans la même situation que la plupart des autres domaines de l’activité humaine.

Alexey: Je m'intéresse ici à l'aspect plus pratique de la question. J'ai une formation en mathématiques et pendant mes études, j'ai souvent assisté à des conférences et travaillé sur divers sujets scientifiques. J'ai découvert que personne dans l'auditoire ne comprenait mes rapports, et de la même manière, les rapports des autres n'étaient compréhensibles que par eux-mêmes. Ce n'est pas le cas pour les sujets de haut niveau, mais dès que vous commencez à approfondir quelque chose, le public ne peut plus vous suivre. Comment gérez-vous cela?

Michael: Pas toujours réussi. J'ai récemment préparé un rapport dans lequel j'entrais trop profondément dans les détails techniques. Au fur et à mesure que l'exposé avançait, il est devenu évident que la plupart des auditeurs ne me comprenaient pas, j'ai donc dû m'adapter à la situation à la volée. Les diapositives ne pouvaient pas être modifiées, donc cela ne s'est pas très bien passé - donc, d'une manière générale, j'essaie de ne pas utiliser de diapositives. Dans l’ensemble, mon conseil est de considérer votre public. Vous devez savoir à qui vous parlez, quel est leur niveau de connaissances et ce qu'ils ont besoin d'entendre pour apprécier votre travail.

Vitali: Pourriez-vous nous donner une idée du sujet de cette conférence ?

Michael: Pour être honnête, je préférerais ne pas m'étendre sur ce sujet afin de laisser les personnes en question anonymes. Le fait est que nous pénétrons souvent trop profondément dans les subtilités du problème sur lequel nous travaillons, il devient donc difficile pour nous d'expliquer au début de l'exposé pourquoi le problème est intéressant et important et comment il est lié aux questions que le le public le sait déjà. D’après mes observations, ce sont les étudiants qui ont le plus de mal à acquérir cette compétence. Et c’était aussi le point faible de mon récent rapport. Un rapport correctement structuré doit, dès le début, prendre contact avec le public, lui expliquer quel est exactement le problème et comment il se rapporte aux sujets déjà connus. Le degré de technicité de cette introduction dépend du public. S'il est complètement hétéroclite, le rapport peut alors comporter plusieurs étapes. L'introduction doit être accessible à tous, et à la fin, l'article ne pourra peut-être pas vous suivre, mais des personnes relativement familiarisées avec votre domaine seront en mesure de le comprendre.

Les étudiants deviennent-ils plus bêtes ? Tendances mondiales, internationalisation.

Alexey: Vous observez les étudiants depuis plusieurs décennies. Les étudiants deviennent-ils plus stupides ou plus intelligents de décennie en décennie ou d’année en année ? En Russie, les professeurs se plaignent constamment du fait que les étudiants deviennent chaque année plus stupides, et on ne sait vraiment pas quoi faire à ce sujet.

Michael: Vous pouvez vraiment entendre beaucoup de négativité de la part de nous, les personnes âgées. Inconsciemment, nous avons tendance à attendre des étudiants qu’ils absorbent les 30 années d’expérience que nous possédons déjà. Si j’ai une compréhension plus profonde qu’en 1985, pourquoi les étudiants ne l’ont-ils pas ? Probablement parce qu’ils ont 20 ans, qu’en pensez-vous ? Je pense que les changements les plus importants au cours des dernières décennies concernent la composition démographique : nous avons désormais beaucoup plus d’étudiants internationaux, à l’exception des Canadiens. Avant, il y avait beaucoup de Canadiens parce que nous sommes très proches de la frontière canadienne et que les étudiants de là-bas peuvent rentrer chez eux le week-end. Mais il existe désormais de nombreuses bonnes universités au Canada et les Canadiens préfèrent étudier ici ; beaucoup moins d'entre eux viennent aux États-Unis.

Alexey: Pensez-vous qu'il s'agit d'une tendance locale ou mondiale ?

Michael: Je ne me souviens plus exactement de qui, mais quelqu'un a dit que le monde était plat. Notre domaine est devenu beaucoup plus international. Conférences ACM Auparavant, ils se déroulaient exclusivement aux États-Unis, puis ils ont décidé de les organiser une fois tous les 4 ans dans d'autres pays, et maintenant ils ont lieu partout dans le monde. Ces changements ont affecté encore plus IEEE, car elle a toujours été une organisation plus internationale que l’ACM. Et il y a des chaires de programmes en Chine, en Inde, en Russie, en Allemagne et dans de nombreux autres pays, car il se passe actuellement beaucoup de choses partout.

Alexey: Mais, probablement, il y a des aspects négatifs à une telle internationalisation ?

Michael: Je dirais que tous les aspects négatifs ne concernent pas la technologie, mais la politique. Autrefois, le principal problème résidait dans le fait que les États-Unis volaient les personnes les plus intelligentes et les plus talentueuses du monde entier. Et maintenant, le principal problème réside dans les jeux politiques entre les différents pays autour des visas et de l’immigration.

Alexey: Autrement dit, les barrières et des choses comme ça. Il est clair.

Vladimir: Personnellement, je m'intéresse à l'approche que vous adoptez lorsque vous enseignez une nouvelle matière aux étudiants. Il existe différentes options : vous pouvez essayer tout d’abord de les inciter à essayer quelque chose de nouveau, ou vous pouvez accorder plus d’attention aux détails du fonctionnement d’une certaine technologie. Que préfères-tu?

Travail efficace avec les étudiants

Alexey: Et comment trouver ce foutu équilibre entre le premier et le second ?

Michael: Le problème c’est que les cours ne se déroulent pas toujours comme je le souhaiterais. Je donne généralement aux étudiants du matériel de lecture à l'avance afin qu'ils l'approfondissent, le comprennent au mieux de leurs capacités et formulent des questions sur les parties qu'ils ne pouvaient pas comprendre. Ensuite, en classe, vous pourrez vous concentrer sur les moments les plus difficiles et les explorer ensemble. C’est ainsi que j’aime le plus donner des cours. Mais étant donné la charge qui pèse désormais sur les étudiants, je ne suis pas toujours en mesure de m'assurer qu'ils se préparent à l'avance. En conséquence, vous devez consacrer beaucoup plus de temps que vous ne le souhaiteriez à la narration générale du matériel. Malgré cela, j'essaie de garder nos cours interactifs. Sinon, il est plus facile d’enregistrer une fois une vidéo que les élèves pourront ensuite regarder chez eux. Le but des cours en direct est l’interaction humaine. En cours, je préfère utiliser de la craie et un tableau plutôt que des diapositives, sauf dans certains cas où un schéma est trop complexe à représenter au tableau. Grâce à cela, je n'ai pas besoin de m'en tenir à un plan de cours rigide. Puisqu'il n'y a pas d'ordre strict dans lequel je donne le matériel, cela me permet de l'adapter au public en fonction des questions que je reçois. De manière générale, j'essaie de rendre les cours aussi interactifs que possible, afin que le matériel que je présente dépende des questions qui me sont posées.

Vladimir: C'est bien. D’après mon expérience, il est assez difficile d’amener les auditeurs à poser des questions. Même si vous demandez à l'avance de poser des questions, aussi stupides ou intelligentes soient-elles, ils restent silencieux. Comment gérez-vous cela?

Michael: Vous rirez, mais si vous restez silencieux assez longtemps, tôt ou tard, tout le monde se sentira mal à l'aise et quelqu'un posera une question. Ou vous pouvez poser une simple question technique avec une réponse par oui ou par non pour déterminer si les gens comprennent ce qui vient d'être dit. Par exemple, y a-t-il une course aux données dans l’exemple ci-dessus ? Qui le pense ? Qui ne le pense pas ? Qui ne comprend rien du tout car au total seulement la moitié des mains se sont levées ?

Vitali: Et si vous avez mal répondu, vous êtes expulsé de la classe :)

Michael: Si vous n’avez répondu à rien, alors vous devriez poser une question. J'ai besoin de comprendre exactement ce que l'élève doit savoir pour répondre à la question que je viens de poser. J'ai besoin qu'ils m'aident à les aider. Je suis prêt à m'adapter à eux pour qu'ils comprennent le problème. Mais si je ne sais pas ce qui se passe dans leur tête, je ne peux pas le faire. Et si on ne laisse pas assez longtemps la paix aux étudiants, parfois ils finissent par poser les bonnes questions, c’est-à-dire celles qui me permettent de voir exactement ce qui se passe dans la tête des étudiants. 

Alexey: Ces questions vous amènent-elles parfois à des idées auxquelles vous n’aviez pas pensé auparavant ? Sont-ils inattendus ? Permettent-ils d’envisager un problème sous un nouveau jour ?

Michael: Il y a des questions qui ouvrent une nouvelle façon de présenter le matériel. Il y a souvent des questions qui mènent à des problèmes intéressants dont je n'avais pas prévu de parler. Les étudiants me disent souvent que j’ai tendance à sortir du sujet lorsque cela se produit. Et, selon eux, c’est très souvent la partie la plus intéressante de la leçon. Très rarement, à quelques reprises seulement, les étudiants posaient des questions qui incitaient à une nouvelle direction de recherche et débouchaient sur un article. Cela se produit beaucoup plus souvent dans les conversations avec les étudiants que pendant les cours, mais cela se produit parfois pendant les cours. 

Alexey: Les étudiants vous ont donc posé des questions à partir desquelles il a ensuite été possible de publier un article ?

Michael: Oui 

Vitali: À quelle fréquence avez-vous ces conversations avec les étudiants ? Quand souhaitent-ils en savoir plus que ce qui a été abordé pendant la leçon ?

Michael: Avec mes étudiants diplômés - tout le temps. J'en ai environ 5 ou 6 et nous discutons tout le temps de quelque chose avec eux. Et les conversations de ce genre avec des étudiants qui assistent simplement à mes cours ne sont pas très courantes. Même si j'aurais aimé que cela arrive plus souvent. Je soupçonne qu'ils ont simplement peur de venir à la faculté pendant les heures de bureau. Chaque semestre, certains étudiants parviennent à surmonter cette barrière psychologique, et il est toujours très intéressant de discuter avec eux après les cours. Il est vrai que si tous les étudiants étaient aussi courageux, je n’aurais tout simplement pas assez de temps. Alors peut-être que tout fonctionne comme il se doit. 

Vitali: Comment parvenez-vous à trouver du temps pour communiquer avec les étudiants ? Autant que je sache, aux États-Unis, les enseignants ont beaucoup de travail – demander des bourses, etc. 

Michael: Honnêtement, travailler avec des étudiants est l'aspect de mon travail que j'apprécie le plus. J'ai donc assez de motivation pour cela. La plupart du temps que je passe dans mon bureau est consacré à des réunions de toutes sortes. C'est l'été maintenant, donc mon emploi du temps est moins chargé, mais pendant l'année scolaire, tous les jours de 9h à 17h, j'ai tout emballé. Travaux de recherche, critiques, subventions - pour tout cela, il n'y a que les soirs et les week-ends. 

Comment suivre la préparation de nouveaux cours et livres.

Alexey: Continuez-vous actuellement à enseigner des cours que vous enseignez depuis longtemps ? Quelque chose comme une introduction à l'informatique.

Michael: La première chose qui me vient à l’esprit ici est un cours de langages de programmation. 

Alexey: Dans quelle mesure la version actuelle de ce cours est-elle différente de ce qu'elle était il y a 10, 20, 30 ans ? Ce qui est peut-être plus intéressant ici, ce ne sont pas les détails d'un cours particulier, mais les tendances générales.

Michael: Mon cours sur les langages de programmation était quelque peu inhabituel au moment où je l'ai créé. J'ai commencé à le lire à la fin des années 1980, en remplacement de mon collègue Doug Baldwin (Doug Baldwin). Le sujet du cours n'était que indirectement lié à ma spécialité, mais lorsqu'il est parti, j'étais le meilleur candidat pour enseigner le cours. Je n’aimais aucun des manuels qui existaient à l’époque, alors j’ai fini par écrire moi-même le manuel de ce cours. (NDLR : on parle du livre "Pragmatique du langage de programmation") Il est désormais utilisé dans plus de 200 universités à travers le monde. Mon approche est inhabituelle dans la mesure où elle mélange délibérément les problèmes de conception et d'implémentation du langage, et accorde une grande attention à l'interaction entre ces aspects dans tous les domaines possibles. L'approche de base est restée inchangée, tout comme de nombreux concepts de base : abstractions, espaces de noms, modularité, types. Mais l’ensemble des langages avec lesquels ces concepts sont démontrés a complètement changé. Lors de la création du cours, il y avait de nombreux exemples en Pascal, mais aujourd'hui beaucoup de mes étudiants n'ont même pas entendu parler de ce langage. Mais ils connaissent Swift, Go, Rust, je dois donc parler des langages utilisés aujourd'hui. De plus, les étudiants maîtrisent désormais bien les langages de script, mais lorsque j'ai commencé à enseigner ce cours, il s'agissait uniquement de langages compilés. Nous avons maintenant besoin de beaucoup de matériel sur Python, Ruby et même Perl, car c'est ainsi que le code est écrit de nos jours, et il se passe beaucoup de choses intéressantes dans ces langages, y compris dans le domaine de la conception de langages. 

Vitali: Alors ma prochaine question sera liée à la précédente. Comment suivre le rythme dans ce domaine ? Je soupçonne que mettre à jour un cours comme celui-ci nécessite beaucoup de travail - vous devez comprendre de nouvelles langues, comprendre les idées principales. Comment est-ce que tu fais ça?

Michael: Je ne peux pas me vanter de réussir toujours à 100 %. Mais la plupart du temps, je fais ce que tout le monde fait : lire sur Internet. Si je veux comprendre Rust, je le recherche sur Google, je vais sur la page Mozilla et je lis le manuel qui y est publié. Cela fait partie des choses qui se produisent dans le développement commercial. Si nous parlons de science, vous devez alors suivre les rapports des principales conférences. 

Lien entre les entreprises et le monde universitaire

Vitali: Parlons du lien entre les entreprises et la recherche scientifique. Dans votre liste de travaux, j'ai trouvé plusieurs articles sur la cohérence du cache. Je comprends que les algorithmes de cohérence du cache étaient instables au moment de leur publication ? Ou pas assez répandu. Dans quelle mesure vos idées étaient-elles courantes dans la pratique ?

Michael: Je ne sais pas exactement de quelles publications vous parlez. J'ai fait pas mal de travail avec mes étudiants Bill Bolosky (Guillaume Bolosky) et Léonidas Kontotanassis (Léonidas Kontothanassis) au début des années 1990 sur la gestion mémoire des machines Neumann. À cette époque, les entreprises ne comprenaient pas encore comment créer correctement un système multiprocesseur : vaut-il la peine de créer un support pour l'accès à la mémoire distante au niveau matériel, vaut-il la peine de distribuer la mémoire, est-il possible de charger le cache depuis mémoire distante, ou est-il nécessaire de déplacer des pages dans le système du bloc opératoire ? Bill et Leonidas ont tous deux travaillé dans ce domaine et exploré des approches sans chargement de cache à distance. Cela n'était pas directement lié à la cohérence du cache, mais il s'agissait toujours d'un travail sur la gestion de la mémoire NUMA, et par la suite, les approches modernes du placement des pages dans les systèmes d'exploitation modernes en ont découlé. Dans l'ensemble, Bill et Leonidas ont réalisé un travail important, même s'il n'est pas le plus influent dans ce domaine : de nombreuses autres personnes travaillaient sur le même sujet à l'époque. Plus tard, j'ai travaillé sur un sujet lié à la cohérence du cache dans le contexte de la mémoire transactionnelle matérielle. Le groupe avec lequel j'ai travaillé sur ce problème a fini par recevoir plusieurs brevets. Il y a des idées assez intéressantes derrière tout cela, mais je ne pense pas qu'elles finiront par être mises en pratique. D’une manière ou d’une autre, il m’est difficile de juger de leur rentabilité. 

Alexey: À cet égard, une question plus personnelle : dans quelle mesure est-il important pour vous que vos idées soient mises en pratique ? Ou tu n'y penses pas ?

Michael: J'aime poser cette question lors d'entretiens avec d'autres personnes, candidats ou candidats souhaitant rejoindre la faculté. Je ne pense pas qu'il y ait de réponse correcte à cette question. Les gens qui font des choses sympas peuvent avoir des motivations très différentes. Je suis attiré par les problèmes parce que je les trouve personnellement intéressants, et non en raison de leurs avantages pratiques. Mais d'un autre côté, quand quelque chose d'intéressant trouve encore une application, j'aime vraiment ça. Ce n'est donc pas facile ici. Mais au début de mon travail, je ne suis toujours pas motivé par l’idée d’une​​utilisation finale dans le monde, mais par l’harmonie de l’idée et le désir de l’explorer et de voir ce qui en résulte. Si au final cela donne des résultats pratiques, tant mieux. 

Alexey: Grâce à votre éducation et à votre expérience, vous êtes mieux à même que la plupart des gens de juger de la valeur des idées des autres. Vous pouvez les comparer et déterminer lequel fonctionne le mieux avec lequel. Je suis sûr que vous avez une opinion sur les éléments actuellement utilisés dans la pratique par de grands fabricants comme Intel. De votre point de vue, dans quelle mesure la voie suivie par ces entreprises est-elle correcte ?

Michael: La pratique tourne toujours autour de ce qui peut être un succès commercial, c'est-à-dire créer du profit, et il vaut mieux interroger quelqu'un d'autre à ce sujet. Mon travail donne principalement lieu à des publications, et dans le domaine des systèmes d'exploitation ils sont évalués sur la base d'indicateurs de performance : vitesse, consommation d'énergie, taille du code. Mais il m'a toujours semblé que ces résultats empiriques n'étaient ajoutés aux articles que pour qu'ils puissent être publiés, et que les véritables motivations du travail des gens étaient esthétiques. Les chercheurs évaluent les solutions d’un point de vue artistique, ils se soucient de l’élégance des idées et tentent de créer quelque chose de meilleur que les approches existantes. Les chercheurs sont motivés par des motivations personnelles, subjectives et esthétiques. Mais vous ne pouvez pas écrire à ce sujet dans l’article lui-même ; ces choses ne sont pas des arguments pour le comité de programme. Heureusement, les solutions élégantes sont souvent rapides et bon marché. Une douzaine de mes collègues et moi avons discuté de ce sujet il y a environ 15 ans et avons fini par écrire un article à ce sujet. Je pense que tu peux encore le trouver maintenant, ça s'appelle "Comment évaluer la recherche sur les systèmes" ou quelque chose comme ça, il compte plus d'une douzaine d'auteurs. C'est le seul article dont je suis l'auteur avec Sacha Fedorova, donc si vous recherchez son nom dans ma liste de publications, vous trouverez ce dont vous avez besoin. Il parle de l'évaluation de la recherche sur les systèmes et de l'importance de l'élégance. 

Alexey: Il y a donc une différence entre le niveau de ce qui est considéré comme bon en science et en affaires. La science évalue les performances, la consommation d'énergie, le TDP, la facilité de mise en œuvre et bien plus encore. Avez-vous la possibilité de mener ce type de recherche à l’université ? Avez-vous un laboratoire avec différentes machines et différentes architectures dans lequel vous pourriez mener des expériences ?

Michael: Oui, notre département dispose de nombreuses machines différentes et intéressantes. Le plus souvent ils sont petits, nous avons un petit cluster et de nombreux systèmes multiprocesseurs avec différents accélérateurs. De plus, le campus dispose d'un immense centre informatique qui dessert des scientifiques de plusieurs dizaines de disciplines différentes. Il compte environ un millier de nœuds et vingt mille cœurs, tous sous Linux. Si le besoin s’en fait sentir, vous pouvez toujours acheter des AWS. Nous n’avons donc aucune restriction significative concernant le matériel. 

Alexey: Comment c'était il y a trente ans ? Y a-t-il eu des problèmes à ce moment-là ?

Michael: C'était un peu différent à l'époque. Du milieu à la fin des années 1980, on considérait que la science manquait de ressources informatiques. Pour remédier à cette situation, la National Science Foundation (Fondation nationale de la science) a créé un programme de recherche expérimentale coordonnée (Cooperative Experimental Research, CER). La mission du programme était de fournir une infrastructure informatique aux départements d'informatique, et il a apporté des changements importants. Avec l'argent qu'elle a fourni, nous, à l'Université de Rochester, avons acheté un BBN Butterfly de 1984 nœuds en 128, c'était un an avant mon arrivée là-bas. À cette époque, il s’agissait du plus grand système multiprocesseur à mémoire partagée au monde. Il disposait de 128 processeurs, chacun sur une carte mère distincte, et occupait quatre racks. Chaque processeur disposait d'un mégaoctet de mémoire, 128 mégaoctets de RAM était une quantité inimaginable à l'époque. Sur cette machine, nous avons implémenté le verrouillage MCS pour la première fois. 

Alexey: Donc, si je vous comprends bien, alors pour le moment le problème avec le matériel est résolu ? 

Michael: En général, oui. Il y a quelques mises en garde : premièrement, si vous faites de l'architecture informatique au niveau des puces, c'est difficile à faire dans un environnement universitaire car il existe de bien meilleurs outils pour le faire en entreprise. Si vous avez besoin d’un objet inférieur à 10 nanomètres, vous devrez le commander auprès de quelqu’un d’autre. Dans ce domaine, il est beaucoup plus facile d'être chercheur chez Intel. Si vous travaillez sur les communications optiques sur puces ou sur la mémoire solide, vous trouverez dans les entreprises des technologies qui ne sont pas encore scientifiques, il faut donc créer des alliances. Par exemple, Stephen Swanson (Steven Swanson) créé un tel partenariat pour les nouvelles technologies de mémoire. Ce formulaire ne fonctionne pas toujours, mais dans certains cas, il peut s'avérer très efficace. De plus, en science, le développement des systèmes informatiques les plus puissants est plus difficile. Les plus grands projets de supercalculateurs actuellement menés aux États-Unis, au Japon et en Chine sont tous axés sur les affaires. 

Mise en œuvre pratique des idées. MCS, MS, CLH, JSR 166, en collaboration avec Doug Lee et plus encore.

Vitali: Vous avez déjà parlé de la façon dont vous avez commencé à travailler sur les algorithmes de synchronisation. Vous avez deux articles très célèbres sur Blocage MCS и File d'attente Michael-Scott (MS), qui, dans un sens, ont été implémentés en Java. (NDLR : toutes les publications sont consultables lien). Là, ce blocage a été mis en œuvre avec quelques modifications et il s'est avéré Serrure CLH, et la file d'attente a été implémentée comme prévu. Mais de nombreuses années se sont écoulées entre la publication de vos articles et leur application pratique. 

Alexey: Cela semble environ 10 ans dans le cas de la file d'attente.

Michael: Avant que ces fonctionnalités n'apparaissent dans la bibliothèque standard Java ?

Vitali: Oui. Qu'avez-vous fait pour que cela se produise ? Ou n'ont-ils rien fait ?

Michael: Je peux vous raconter comment MS Queue est entré dans Java 5. Quelques années avant sa sortie, j'ai travaillé avec le groupe de Mark Moyers chez Sun Microsystems dans leur laboratoire près de Boston. Il a organisé un atelier pour des personnes qu'il connaissait et qui travaillaient sur des problèmes intéressants en multithreading, car il souhaitait trouver des sujets qu'il pourrait vendre à leur entreprise. C'est là que j'ai rencontré Doug Lea pour la première fois. Doug, moi et environ 25 autres personnes de Sun discutions ensemble de la présentation de Doug sur RSC 166, qui devint plus tard java.util.concurrent. En cours de route, Doug a déclaré qu'il aimerait utiliser la file d'attente MS, mais pour cela, il avait besoin d'un compteur pour le nombre d'éléments dans la file d'attente de l'interface. Autrement dit, cela aurait dû être fait par une méthode distincte, atomique, précise et rapide. J'ai suggéré simplement d'ajouter des numéros de série aux nœuds, en prenant le numéro du premier nœud et du dernier et en soustrayant l'un de l'autre. Doug s'est gratté la tête, a dit « pourquoi pas » et a fini par faire exactement cela. Nous avons discuté de la mise en œuvre de cette approche dans la bibliothèque, mais Doug a fait la majeure partie du travail lui-même. En conséquence, il a réussi à établir un excellent support multithreading en Java. 

Alexey: Donc, si je comprends bien, la méthode .size() aurait dû faire partie de l'interface de file d'attente standard, et elle aurait dû avoir une complexité algorithmique de O(1) ?

Michael: Oui, et en plus de cela, un compteur séparé est requis.

Alexey: Parce que si vous appelez la méthode .size() en Java, le résultat devrait être disponible immédiatement et non basé sur la taille réelle de la collection. Je vois Merci.

Michael: Quelques années plus tard, je travaillais sur des structures de données doubles avec mon élève Bill Scherer - en fait, c'est de cela dont je vais parler reportage sur Hydra. Doug est venu nous voir et nous a dit qu'il pouvait les utiliser dans Java Executor Framework. Avec Bill, ils ont créé deux implémentations, les files d'attente dites justes et injustes. Je les ai conseillés sur ce projet, même si je n'ai pas participé à l'écriture du code proprement dit. En conséquence, la vitesse des exécuteurs testamentaires a considérablement augmenté. 

Vladimir: Avez-vous rencontré des implémentations incorrectes de vos algorithmes ou des demandes d'ajout de nouvelles fonctionnalités ? En général, la pratique devrait coïncider avec la théorie, mais elles diffèrent bien souvent. Supposons que vous ayez écrit un algorithme et que sur papier, cela fonctionne, mais que les personnes impliquées dans la mise en œuvre commencent à vous demander plus de fonctionnalités ou une sorte de peaufinage de l'algorithme. Avez-vous déjà vécu de telles situations ?

Michael: Le seul exemple dans lequel quelqu'un est venu me voir et m'a demandé « comment le mettre en œuvre » était la question de Doug, dont j'ai déjà parlé. Mais il y a eu quelques cas où des changements intéressants ont été apportés pour répondre à des besoins pratiques. Par exemple, l'équipe K42 d'IBM a converti le verrou MCS et en a fait une interface standard, de sorte qu'il n'était pas nécessaire de transmettre le nœud de file d'attente aux routines d'acquisition et de libération. Grâce à cette interface standard, une idée qui était belle en théorie a commencé à fonctionner dans la pratique. Il est surprenant qu’ils n’aient jamais publié d’article à ce sujet et, bien qu’ils aient obtenu un brevet, ils l’ont ensuite abandonné. L’idée était merveilleuse et j’essaie d’en parler autant que possible. 

Il y a eu d’autres cas où des personnes ont amélioré les algorithmes que j’ai publiés. Par exemple, la file d'attente MS dispose d'un mécanisme d'installation en deux étapes, ce qui signifie qu'il y avait deux CAS sur le chemin critique de la file d'attente. Sur les voitures plus anciennes, les CAS étaient assez chers. Intel et d'autres fabricants les ont assez bien optimisés récemment, mais il était une fois des instructions à 30 cycles, il n'était donc pas souhaitable d'en avoir plus d'une sur le chemin critique. En conséquence, une file d’attente différente a été développée, similaire à la file d’attente MS, mais qui ne comportait qu’une seule opération atomique sur le chemin critique. Ceci a été obtenu grâce au fait que pendant une certaine période de temps, l'opération pouvait prendre un temps O(n), plutôt qu'un temps O(1). C'était peu probable, mais possible. Cela est dû au fait qu'à certains moments, l'algorithme a parcouru la file d'attente du début jusqu'à la position actuelle dans cette file d'attente. En général, l’algorithme s’est avéré très efficace. Pour autant que je sache, cette méthode n’est pas très utilisée, en partie parce que les opérations atomiques nécessitent beaucoup moins de ressources qu’auparavant. Mais l'idée était géniale. J'aime aussi beaucoup le travail de Dave Dice d'Oracle. Tout ce qu'il fait est très pratique et il utilise le fer très intelligemment. Il a participé à la plupart des algorithmes de synchronisation et des structures de données multithread prenant en charge NUMA. 

Vladimir: Lorsque vous écrivez des algorithmes ou enseignez à des étudiants, le résultat de votre travail n'est pas immédiatement visible. La communauté a besoin de temps pour se familiariser, par exemple, avec un nouvel article. Le nouvel algorithme ne trouve pas immédiatement d'application. 

Michael: Il est loin d’être immédiatement clair si l’article sera significatif ou non. Je pense qu'il serait intéressant de faire une étude des articles qui ont été primés lors de conférences. Autrement dit, regardez les articles que les membres des comités de programme considéraient à un moment donné comme les meilleurs. Vous devez essayer de calculer, en fonction du nombre de liens et de l'impact sur les entreprises, l'influence réelle de ces articles dans 10, 20, 25 ans. Je doute qu'il y ait une forte corrélation entre les deux. Il ne sera pas nul, mais il sera très probablement beaucoup plus faible que nous le souhaiterions. De nombreuses idées restent longtemps inexploitées avant de se généraliser. Par exemple, prenons la mémoire transactionnelle. Plus de 10 ans se sont écoulés entre la publication de l’article original et le moment où les gens ont commencé à construire des machines avec celui-ci. Et avant l'apparition de ce souvenir dans les produits commerciaux - et tous les 20. Pendant très longtemps, personne n'a prêté attention à l'article, puis le nombre de liens vers celui-ci a fortement augmenté. Il serait difficile de le prévoir à l’avance. D’un autre côté, les idées trouvent parfois une mise en œuvre immédiate. Il y a quelques années, j'ai écrit un article avec Joe Izraelevitz pour DISC qui proposait une nouvelle définition formelle de la validité des structures de données persistantes qui pourraient être utilisées après une panne de l'ordinateur qui les exécute. J'ai aimé l'article dès le début, mais il s'est avéré beaucoup plus populaire que prévu. Il a été utilisé par plusieurs groupes différents et est finalement devenu la définition standard des structures de persistance. Ce qui, bien sûr, est sympa.

Vladimir: Existe-t-il des techniques que vous utilisez pour l'évaluation ? Essayez-vous même d’évaluer vos articles et vos étudiants ? Quant à savoir si la personne à qui vous avez enseigné va dans la bonne direction.

Michael: Comme tout le monde, je fais plus attention à ce que je fais en ce moment. Encore une fois, comme tout le monde, je consulte occasionnellement Google Scholar pour voir si mes articles antérieurs sont cités, mais c'est plutôt par curiosité. La plupart du temps, je suis absorbé par ce que font mes élèves actuellement. Lorsqu’il s’agit d’évaluer le travail actuel, il s’agit en partie de considérations esthétiques, de ce qui est élégant et de ce qui ne l’est pas. Et au quotidien, les questions ouvertes jouent un rôle important. Par exemple, un étudiant vient me voir avec un graphique de certains résultats, et nous essayons de comprendre d'où vient un comportement étrange du graphique. En général, dans notre travail, nous essayons constamment de comprendre des choses que nous ne comprenons pas encore. 

Mémoire transactionnelle

Vitali: Peut-être pourrions-nous parler un peu de mémoire transactionnelle ?

Michael: Je pense que cela vaut la peine d'en parler au moins un peu car j'y ai mis beaucoup d'efforts. C’est un sujet sur lequel j’ai plus de publications que tout autre. Mais en même temps, curieusement, j’ai toujours été très sceptique quant à la mémoire transactionnelle. À mon avis, article de Herlihy et Moss (M. Herlihy, J. E. B. Moss) a été publié en avance sur son temps. Au début des années 1990, ils ont suggéré que la mémoire transactionnelle pourrait aider les programmeurs talentueux à travailler sur des structures de données multithread, afin que ces structures puissent ensuite être utilisées comme bibliothèques par des programmeurs ordinaires. Autrement dit, cela aiderait Doug Lee à réaliser son JSR 166. Mais la mémoire transactionnelle n'était pas destinée à faciliter la programmation multithread. Mais c’est exactement ainsi qu’elle a commencé à être perçue au début des années 2000, lorsqu’elle s’est généralisée. Il a été présenté comme un moyen de résoudre le problème de la programmation parallèle. Cette approche m’a toujours semblé désespérée. La mémoire transactionnelle ne pourrait que faciliter l’écriture de structures de données parallèles. C’est, me semble-t-il, ce qu’elle a réalisé. 

À propos de la difficulté d'écrire du code multithread

Alexey: Très intéressant. Il semble y avoir une certaine barrière entre les programmeurs réguliers et ceux qui peuvent écrire du code multithread. L'année dernière, j'ai parlé à plusieurs reprises avec des personnes qui mettaient en œuvre un cadre algorithmique. Par exemple, avec Martin Thomson, ainsi qu'avec des programmeurs travaillant sur des bibliothèques multithread. (NDLR : Martin Thompson est un développeur très connu, a-t-il écrit Disruptor и Aeron. Et il a aussi rapport à notre conférence Joker 2015, enregistrement vidéo disponible sur YouTube. Il est le même ouvert cette conférence enregistrement du discours d'ouverture aussi disponible). Le principal défi, disent-ils, est de rendre les algorithmes à la fois rapides et faciles à utiliser. Autrement dit, ils essaient de surmonter cet obstacle et d'attirer autant de personnes que possible dans cette région. Qu'en pensez-vous?

Michael: C'est le problème principal du multithreading : comment atteindre des performances élevées sans augmenter la complexité du système. 

Alexey: Parce que lorsqu'ils tentent d'éviter la complexité, l'algorithme devient moins universel.

Michael: La clé ici réside dans des abstractions correctement conçues. Il me semble que c'est généralement l'essentiel dans le domaine des systèmes informatiques. Butler Lampson aime utiliser ce terme et il nous appelle « marchands d’abstractions ». Les technologies simples n’existent pas aujourd’hui. Les processeurs que nous utilisons comportent 10 milliards de transistors : la simplicité est hors de question. En même temps, l'ISA est beaucoup plus simple que le processeur, puisque nous avons travaillé très longtemps pour lui fournir des performances élevées et une interface relativement simple. Mais tout ne se passe pas bien pour elle non plus. Le même problème se pose avec les accélérateurs qui apparaissent désormais sur le marché. Des questions se posent : comment créer la bonne interface pour le GPU, un mécanisme de cryptage, de compression, un mécanisme de transcodage, un mécanisme d'algèbre linéaire ou même un FPGA plus flexible. Comment créer une interface qui rend l’outil facile à utiliser et cache la complexité ? Il ne s’en débarrassera pas, mais plutôt le cachera à un simple programmeur. 

Alexey: Si je comprends bien, nous avons encore un obstacle à la compréhension des abstractions. Prenons le modèle de la mémoire : à notre stade de développement de la science et de la technologie, c'est l'une des principales abstractions. Grâce à lui, tous les programmeurs sont divisés en deux groupes : la plus grande partie sont ceux qui ne le comprennent pas, et la plus petite partie sont ceux qui comprennent, ou pensent comprendre. 

Michael: C'est une bonne question : est-ce que l'un d'entre nous comprend vraiment le modèle de mémoire ?

Vitali: Surtout en C++.

Michael: Parlez à Hans Boehm un jour. C'est l'une des personnes les plus intelligentes que je connaisse, un grand expert en modèles de mémoire. Il vous dira tout de suite qu’il y a beaucoup de choses qu’il ne comprend pas. Mais si nous revenons à la question des abstractions, alors, à mon avis, l'idée la plus importante dans le domaine des modèles de mémoire au cours des 30 dernières années a été exprimée dans la thèse de Sarita Adve. (NDLR : une liste complète des publications est disponible lien).

Alexey: Ma question est : cette barrière vient-elle de la nature même du concept ? 

Michael: Non. Sarita est arrivée à la conclusion qu'avec la bonne approche, vous pouvez réussir à masquer toute la complexité, obtenir des performances élevées et donner au programmeur une API simple. Et si vous suivez cette API, vous pouvez obtenir une cohérence cohérente. Je pense que c'est le bon modèle. Écrivez du code sans courses de données et obtenez une cohérence séquentielle. Bien sûr, afin de réduire les risques de course, des outils spéciaux sont nécessaires, mais c'est une autre affaire. 

Vladimir: Y a-t-il eu des moments dans votre carrière où un problème qui semblait résolu s'est soudainement transformé en catastrophe, ou il s'est avéré que ce problème était insoluble ? Par exemple, en théorie, vous pouvez factoriser n’importe quel nombre ou déterminer si un nombre est premier. Mais en pratique, cela peut s'avérer difficile à réaliser ; avec le matériel actuel, il est difficile de prendre en compte les chiffres. Est-ce qu'il vous est arrivé quelque chose de similaire ?

Michael: Je ne me souviens pas immédiatement de quelque chose comme ça. Il y a eu des moments où il m'a semblé qu'il n'y avait plus rien à faire dans une certaine zone, mais ensuite quelque chose de nouveau et d'intéressant s'est produit là-bas. Par exemple, je pensais que le domaine des files d'attente illimitées avait déjà atteint sa maturité. Après plusieurs améliorations apportées à la file d’attente MNS, il ne se passait plus grand-chose. Et puis Morrison (Adam Morrison) et Afek (Yehuda Afek) ont inventé File d'attente LCRQ. Il est devenu clair qu'une file d'attente multithread illimitée était possible, où la plupart du temps il n'y avait qu'une instruction de récupération et d'incrémentation sur le chemin critique. Et cela a permis d'obtenir des performances d'un ordre de grandeur supérieures. Ce n'est pas que nous ne sachions pas que la récupération et l'incrémentation sont une chose très utile. Eric Freudenthal a écrit à ce sujet dans son travail sur l'Ultracomputer avec Allan Gottlieb à la fin des années 1980, mais il s'agissait de files d'attente limitées. Morrison et Afek ont ​​pu utiliser la récupération et l'incrémentation sur une file d'attente illimitée.

Nouvelles architectures. La victoire de la mémoire transactionnelle est-elle proche ?

Vladimir: Êtes-vous à la recherche de nouvelles solutions architecturales qui pourraient être utiles aux algorithmes ? 

Michael: Bien sûr, il y a beaucoup de choses que j’aimerais voir mises en œuvre. 

Vladimir: Quel genre, par exemple ?

Michael: Tout d'abord, quelques extensions simples de notre mémoire transactionnelle au niveau matériel dans les processeurs Intel et IBM. En particulier, j'aimerais que le chargement et le stockage non transactionnels qui viennent de se produire soient immédiatement disponibles dans les transactions. Ils conduisent immédiatement à des boucles dans la séquence qui se produit avant, elles peuvent donc être difficiles. Mais si vous conservez des couches d'abstraction, vous pouvez faire beaucoup de choses très intéressantes en dehors de la transaction pendant qu'elle se produit. Je ne sais pas à quel point cela serait difficile à mettre en œuvre, mais ce serait très utile. 

Une autre chose utile est de charger le cache depuis la mémoire distante. Je pense que tôt ou tard, cela sera fait. Cette technologie permettra la création de systèmes à mémoire désagrégée. Il serait possible de conserver, disons, 100 téraoctets de mémoire non volatile dans un rack, et le système d'exploitation lui-même déciderait dynamiquement quelles sections de cette mémoire doivent correspondre à l'espace d'adressage physique des processeurs. Cela serait extrêmement utile pour le cloud computing, car cela permettrait de fournir de grandes quantités de mémoire aux tâches qui en ont besoin. Je pense que quelqu'un le fera.

Vitali: Pour finir de parler de mémoire transactionnelle, j'ai encore une question sur ce sujet. La mémoire transactionnelle remplacera-t-elle à terme les structures de données multithread standards ?

Michael: Non. Les transactions sont un mécanisme spéculatif. Au niveau de la programmation, ce sont des verrous atomiques, mais à l’intérieur, ce sont des spéculations. De telles prévisions fonctionnent si la plupart des suppositions sont correctes. Par conséquent, la mémoire transactionnelle fonctionne bien lorsque les threads interagissent à peine les uns avec les autres et il vous suffit de vous assurer qu'il n'y a pas d'interactions. Mais si un message démarre entre les threads, les transactions sont de peu d'utilité. Laissez-moi vous expliquer, nous parlons du cas où les transactions concernent l'ensemble de l'opération atomique. Ils peuvent toujours être utilisés avec succès comme composants de structures de données multithread. Par exemple, si vous avez besoin d'un CAS de trois mots et que vous devez multithreader trois petites choses au milieu d'un algorithme véritablement multithread qui fonctionne avec vingt threads en même temps. En général, les transactions peuvent être utiles, mais elles n’élimineront pas la nécessité de concevoir correctement des structures de données multithread. 

Mémoire non volatile, Optane DIMM, appareils ultra-rapides.

Vitali: La dernière chose dont je voudrais parler est le sujet de vos recherches actuelles : la mémoire non volatile. Que peut-on espérer dans ce domaine dans un avenir proche ? Peut-être connaissez-vous des implémentations efficaces qui existent déjà ? 

Michael: Je ne suis pas un expert en hardware, je sais seulement ce que je lis dans l'actualité et ce que me disent mes collègues. Tout le monde a déjà entendu dire qu'Intel vend DIMM Optane, qui ont environ 3 fois la latence de lecture et 10 fois la latence d'écriture que la RAM dynamique. Ils seront bientôt disponibles dans des versions très grands volumes. C'est drôle de penser que vous pourriez avoir un ordinateur portable avec plusieurs téraoctets de RAM adressable par octets. Il est probable que dans 10 ans nous déciderons d'utiliser cette nouvelle technologie, puisque nous utilisons de la DRAM - il suffit d'augmenter le volume. Mais grâce à l’indépendance énergétique, de toutes nouvelles opportunités s’ouvrent à nous. Nous pouvons modifier fondamentalement la pile de stockage afin qu'il n'y ait pas de séparation entre la mémoire de travail adressable par octets et la mémoire persistante structurée en blocs. Ainsi, nous n'aurons pas besoin de sérialiser tout ce qui doit être transféré d'un programme exécuté à un autre dans des fichiers structurés en blocs. Nous pouvons en déduire de nombreux principes importants qui affectent les systèmes d'exploitation, les environnements d'exécution et les magasins de données distribués. Ce domaine est très intéressant à travailler. Personnellement, il m’est difficile de prédire à quoi tout cela va conduire, mais les problèmes ici sont extrêmement amusants. Il peut y avoir des changements révolutionnaires ici, et ils découlent très naturellement des travaux sur le multithreading, puisque la reprise après incident est un processus "multithreading" à côté du fonctionnement normal du système. 

Le deuxième sujet principal sur lequel je travaille actuellement est la gestion des appareils ultra-rapides et l'accès sécurisé aux appareils depuis l'espace utilisateur avec un contrôle de politique systémique. Ces dernières années, il y a eu une tendance à déplacer l'accès à l'appareil vers l'espace utilisateur. Cela est dû au fait que la pile du noyau TCP-IP ne peut pas fonctionner au-dessus d'une interface réseau qui a besoin d'un nouveau paquet toutes les 5 microsecondes ; elle ne peut tout simplement pas suivre le rythme. Par conséquent, les fabricants offrent un accès direct aux appareils. Mais cela signifie que le système d'exploitation perd le contrôle du processus et ne peut pas fournir un accès approprié à l'appareil pour les applications concurrentes. Notre équipe de recherche estime que cette lacune peut être évitée. Nous aurons un article à ce sujet chez USENIX ATC ce mois-ci. Cela est lié au travail sur la persistance, car la mémoire persistante adressable par octets de longue durée est, par essence, un périphérique doté d'E/S ultra-rapides auquel il faut accéder dans l'espace utilisateur. Cette recherche rend possible de nouvelles approches des micro-noyaux, des exokernels et d'autres tentatives traditionnelles pour déplacer en toute sécurité les fonctionnalités du noyau du système d'exploitation vers l'espace utilisateur. 

Vladimir: La mémoire adressable par octets est excellente, mais il existe une limitation physique : la vitesse de la lumière. Cela signifie qu'il y aura inévitablement un retard lors de l'interaction avec l'appareil. 

Michael: Absolument raison.

Vladimir: Y aura-t-il suffisamment de capacité pour faire face aux nouvelles charges ?

Michael: C'est une excellente question, mais il me sera difficile d'y répondre. L'idée du traitement en mémoire existe depuis pas mal de temps, elle est très intéressante, mais aussi très complexe. Je n'ai pas travaillé dans ce domaine, mais ce serait formidable si des découvertes y étaient faites. Je crains de n'avoir rien d'autre à ajouter. 

Vladimir: Il y a encore un problème. De nouvelles quantités de RAM nettement plus importantes seront impossibles à intégrer dans le processeur. Par conséquent, en raison de limitations physiques, cette RAM doit être isolée. 

Michael: Tout dépend du nombre de défauts dans la fabrication des circuits intégrés. S'il était possible de créer des tranches semi-conductrices entièrement exemptes de défauts, il serait alors possible d'en faire un microcircuit entier. Mais maintenant, nous ne savons pas comment fabriquer des microcircuits plus grands que des timbres-poste. 

Vladimir: Mais nous parlons toujours de tailles énormes, de centimètres. Cela a inévitablement un impact sur la latence. 

Michael: Oui. Vous ne pouvez rien faire contre la vitesse de la lumière. 

Vladimir: Malheureusement. 

La prochaine grande tendance. Structures de données doubles. Hydre.

Vitali: D'après ce que je comprends, vous détectez très rapidement les nouvelles tendances. Vous avez été l’un des premiers à travailler en mémoire transactionnelle et l’un des premiers à travailler en mémoire non volatile. Selon vous, quelle sera la prochaine grande tendance ? Ou peut-être est-ce un secret ?

Michael: Pour être honnête, je ne sais pas. J'espère que je pourrai remarquer quand quelque chose de nouveau arrive. Je n'ai pas eu la chance d'inventer un nouveau domaine par moi-même, mais j'ai eu un peu de chance et j'ai pu commencer à travailler assez tôt dans de nouveaux domaines créés par d'autres. J'espère que je pourrai le faire à l'avenir.

Alexey: La dernière question de cette interview portera sur vos performances à Hydra et vos activités à l'école. Si je comprends bien, le rapport à l'école portera sur les algorithmes sans blocage et lors de la conférence sur les doubles structures de données. Pourriez-vous dire quelques mots sur ces rapports ?

Michael: Nous avons en partie déjà abordé ces sujets avec vous dans cette interview. Il s'agit du travail que j'ai effectué avec mon élève Bill Scherer. Il a écrit une thèse à ce sujet, et Doug Lee y a également contribué, et il est finalement devenu partie intégrante des files d'attente synchrones multithread de la bibliothèque Java. Supposons que la structure des données soit lue et écrite sans blocage, c'est-à-dire que chaque opération comporte un nombre limité d'instructions sur le chemin critique. Si vous tentez de supprimer des données d'un conteneur vide, ou tentez de supprimer certaines données qui ne se trouvent pas dans ce conteneur, vous êtes immédiatement informé que cela n'est pas possible. Mais ce comportement peut ne pas être acceptable si le thread a réellement besoin de ces données. Ensuite, la première chose qui vient à l’esprit est de créer une boucle qui demandera constamment si les données nécessaires sont apparues. Mais il y a ensuite des interférences pour tous les autres. De plus, avec cette approche, vous pouvez attendre 10 minutes, puis un autre thread viendra et il recevra accidentellement les données nécessaires en premier. Les structures de données doubles n'ont toujours pas de verrous, mais elles permettent aux threads d'attendre correctement. Le terme « double » signifie que la structure contient soit des données, soit des demandes de données, appelons-les des anti-données. Ainsi, si vous essayez de récupérer quelque chose dans un conteneur vide, une requête sera placée dans le conteneur à la place. Le fil de discussion peut désormais attendre une demande sans déranger personne d'autre. De plus, la structure de données attribue des priorités aux demandes afin qu'une fois reçues, elles les transmettent à la bonne personne. Le résultat est un mécanisme non verrouillable qui présente toujours une spécification formelle et de bonnes performances dans la pratique. 

Alexey: Quelles sont vos attentes par rapport à cette structure de données ? Cela améliorera-t-il les performances dans tous les cas courants, ou est-il mieux adapté à certaines situations ? 

Michael: C'est utile si, d'une part, vous avez besoin d'un conteneur sans verrouillage et, d'autre part, vous devez attendre dans une situation où vous devez récupérer des données du conteneur qui ne s'y trouvent pas. Au meilleur de ma connaissance, notre framework offre un comportement optimal lorsque ces deux conditions sont remplies. Par conséquent, dans ces cas, je recommande de l’utiliser. Le principal avantage des structures de données sans verrouillage est qu’elles évitent les problèmes de performances. Et l'attente est très importante dans de nombreux algorithmes si les données sont transférées d'un thread à un autre.

Vitali: Laissez-moi clarifier : parlerez-vous de la même chose à l'école et à la conférence ?

Michael: À l'école je parlerai en général sur les structures de données multithread, avec les principes de base décrits au début de la leçon. Je suppose que le public sait ce que sont les threads et est familier avec les verrous. Sur la base de ces connaissances de base, je parlerai des structures de données sans verrouillage. Je vais donner un aperçu des problèmes les plus importants dans ce domaine, en abordant des sujets tels que la gestion de la mémoire. Je ne pense pas qu'il y aura quelque chose de plus compliqué que la file d'attente MS.

Alexey: Envisagez-vous d'enseigner les structures de données doubles à la fin de votre cours à l'école ?

Michael: Je vais les mentionner, mais je n’y consacrerai pas beaucoup de temps. Le rapport Hydra leur sera dédié. Il couvrira le projet qui a finalement été transformé en Java, ainsi que la collaboration avec Joe Israelevich pour créer une double variante de la file d'attente LCRQ et la création d'une conception quasi universelle pour les structures de données doubles.

Alexey: Le cours à l'école peut donc être recommandé aux débutants, et le cours sur les doubles structures de données sur Hydra - aux personnes qui ont déjà une certaine expérience ?

Michael: Corrigez-moi si je me trompe, mais le public d'Hydra sera très diversifié, comprenant de nombreux experts Java et, en général, des personnes qui ne sont pas spécifiquement impliquées dans la programmation multithread. 

Vitali: Oui c'est vrai.

Alexey: Du moins nous l’espérons.

Michael: Dans ce cas, je serai confronté au même problème avec lequel nous avons commencé cet entretien : comment faire un reportage à la fois suffisamment riche en détails techniques et accessible à tous les auditeurs.

Vitali: Allez-vous faire un rapport de la même manière que vous faites des conférences ? C'est-à-dire parler au public et s'adapter à la situation ?

Michael: J'ai peur que cela ne se passe pas ainsi, car le rapport comportera des diapositives. Les diapositives sont importantes lorsque les auditeurs parlent initialement des langues différentes. Beaucoup de gens auront du mal à me comprendre en anglais, surtout si je parle trop vite. J'ai choisi ces sujets parce que Peter Kuznetsov m'a demandé de parler des structures de données sans verrouillage à l'école SPTDC ; puis j'avais besoin d'un rapport pour une conférence d'un groupe d'utilisateurs Java, et je voulais choisir quelque chose qui intéresserait spécifiquement les programmeurs Java. Le moyen le plus simple était de parler de ces éléments de la bibliothèque Java auxquels j'avais participé d'une manière ou d'une autre. 

Alexey: Nous supposons que le public d'Hydra connaît déjà quelque chose sur la programmation sans verrouillage et a peut-être une certaine expérience dans ce domaine. Mais ce n’est qu’une hypothèse : la situation deviendra plus claire lors de la conférence elle-même. Quoi qu'il en soit, merci pour votre temps. Je suis sûr que l'interview sera très intéressante pour nos lecteurs. Merci beaucoup!

Vitali: Merci 

Michael: Je serai heureux de vous rencontrer à Saint-Pétersbourg. 

Alexey: Nous aussi, nous avons une belle ville. Avez-vous déjà été ici?

Michael: Non, je ne suis jamais allé en Russie du tout. Mais Saint-Pétersbourg a toujours été sur la liste des endroits où je ne suis pas encore allé, mais où je veux vraiment aller, donc j'étais très content de l'invitation. 

Alexey: D'ailleurs, nous aurons un programme d'excursions pour les intervenants. Merci beaucoup pour l'interview et bonne journée !

Vous pouvez poursuivre votre conversation avec Michael lors de la conférence Hydra 2019, qui se tiendra les 11 et 12 juillet 2019 à Saint-Pétersbourg. Il viendra avec un rapport "Doubles structures de données". Les billets peuvent être achetés sur le site officiel.

Source: habr.com