Michael Scott est âgé de 34 ans en tant que professeur d'informatique à l'Université de Rochester, et a été doyen pendant cinq ans dans son université natale, Wisconsin - Madison. Il est engagé dans la recherche dans le domaine de la programmation parallèle et distribuée et de la conception de langage et enseigne cela aux étudiants.

Le monde connaît Michael du manuel Programming Language Pragmatics , et le travail Algorithms for scalable synchronization on shared-memory multiprocessors a remporté le prix Dijkstra comme l'un des plus célèbres dans le domaine de l'informatique distribuée. Vous pouvez également le connaître comme l'auteur de cet algorithme de Michael-Scott .

Avec Doug Lee, il a développé ces algorithmes non bloquants et ces files d'attente synchrones qui exécutent les bibliothèques Java. L'introduction de «structures de données doubles» dans JavaSE 6 a permis de multiplier par 10 les performances de ThreadPoolExecutor .

Contenu:

• Début de carrière, Université de Rochester. Projet Charlotte, 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;
• La relation entre les entreprises et l'académie;
• Mise en œuvre pratique des idées. MCS, MS, CLH, JSR 166, en collaboration avec Doug Lee et bien plus encore;
• Mémoire transactionnelle;
• Nouvelles architectures. Victoire serrée de la mémoire transactionnelle;
• Mémoire non volatile, DIMM Optane, dispositifs ultrarapides;
• La prochaine grande tendance. Structures de données doubles. Hydra

Entretiens réalisés par:

Vitaly Aksenov est actuellement un post-dock à IST Autriche et un employé du Département de technologie informatique de l'Université ITMO. Engagé dans la recherche sur la théorie et la pratique des structures de données compétitives. Avant de rejoindre IST, il a obtenu un doctorat de l'Université de Paris Didro et de l'Université de l'ITMO sous la direction du professeur Peter Kuznetsov.

Alexey Fedorov est 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 dans son curriculum vitae il y a quelque chose du poste d'ingénieur de développement chez Oracle (JCK, Java Platform Group), et se terminant avec le poste de devrell à Odnoklassniki.

Vladimir Sitnikov est ingénieur chez Netcracker. Depuis dix ans, il travaille sur les performances et l'évolutivité de NetCracker OS, un logiciel utilisé par les opérateurs télécoms pour automatiser les processus de gestion des réseaux et des équipements réseaux. Il s'intéresse aux problèmes de performances Java et Oracle Database. L'auteur de plus d'une douzaine d'améliorations des performances du pilote JDBC PostgreSQL officiel.

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

Alexei : Pour commencer, je voulais vous dire qu'en Russie, nous aimons tous l'informatique, la science des données et les algorithmes. Droit à l'indécence. Nous avons tous lu le livre Cormen, Leiserson and 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 des étudiants, des programmeurs et des membres de la communauté, nous vous sommes donc très reconnaissants de cette opportunité. L'informatique fait-elle le même amour aux États-Unis?

Michael : Notre région est tellement diversifiée, elle a tellement de directions, et elle affecte la société de différentes manières qu'il m'est difficile de vous répondre sans équivoque. Mais le fait est que grâce à elle au cours des 30 dernières années, il y a eu d'énormes changements dans les affaires, l'industrie, l'art et la société dans son ensemble.

Vitaliy : Commençons par quelque chose de distant. Dans de nombreuses universités, il existe quelque chose comme la spécialisation dans un domaine particulier. Pour Carnegie Mellon University, il s'agit de calcul parallèle; pour le MIT, la cryptographie, les robots et le 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 sont spécialisés dans tous les domaines. Dans notre département, la plus grande attention a toujours été portée à l'intelligence artificielle. La moitié des personnes qui travaillent avec nous sont engagées dans l'IA ou l'interaction homme-machine - cette proportion est plus élevée que dans les autres départements, et elle l'a toujours été. Mais quand j'étais à l'université, je n'avais pas de cours d'IA et je n'ai jamais travaillé dans ce domaine. Mon service est donc spécialisé 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.

Vitaliy : Vous avez commencé à étudier l'informatique alors que le domaine de la programmation multi-thread était à ses balbutiements. La liste de vos publications montre que les premiers travaux ont concerné un éventail assez large de problématiques: la gestion de la mémoire dans les systèmes multi-threads, les systèmes de fichiers distribués et les systèmes d'exploitation. Pourquoi une telle polyvalence? Avez-vous essayé de trouver votre place dans le milieu de la recherche?

Michael : En tant qu'étudiant, j'ai participé au projet Charlotte à l'Université du Wisconsin, qui a développé l'un des premiers systèmes d'exploitation distribués. Là, j'ai travaillé avec Raphael Finkel et Marvin Solomon. 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 déjà oublié, et Dieu merci. J'ai créé le langage de programmation Lynx, qui était censé simplifier la création de serveurs pour un système d'exploitation distribué avec une liaison faible. Puisqu'à cette époque j'étais principalement engagé dans les systèmes d'exploitation, je supposais que ma carrière serait principalement liée à eux. Mais l'Université de Rochester était très petite et, pour cette raison, différents groupes communiquaient très étroitement entre eux. Il n'y avait pas une douzaine d'autres spécialistes des systèmes d'exploitation avec qui je pouvais communiquer, donc tous les contacts étaient avec des gens qui travaillaient dans des domaines complètement différents. J'ai vraiment aimé ça, être généraliste est un gros avantage pour moi. En parlant spécifiquement des structures de données multi-thread et des algorithmes de synchronisation, j'ai commencé à les traiter complètement par accident.

Interface cohérente évolutive IEEE, verrouillage MCS.

Vitaliy : Pourriez-vous donner un peu plus de détails à ce sujet?

Michael : C'est une histoire drôle que je ne me lasse pas de raconter à tout le monde. C'est arrivé à la conférence ASPLOS à Boston - c'était à la fin des années 80 ou au début des années 90. John Mellor-Crummey, diplômé de notre faculté, a assisté à la conférence. Je le connaissais, mais avant cela, nous n'avions pas mené de recherches conjointes. Mary Wernon du Wisconsin a fait une présentation sur le système multiprocesseur qu'ils ont développé au Wisconsin: Wisconsin Multicube . Dans ce Multicube, au niveau du fer, il y avait un mécanisme de synchronisation appelé Q sur Sync Bit, et plus tard il a été renommé Q sur Lock Bit, car il pouvait être prononcé comme le nom du fromage Colby, c'est-à-dire que c'était un jeu de mots. Si vous êtes intéressé par les mécanismes multithreads, vous savez probablement que Colby est finalement devenu le mécanisme de synchronisation de la norme IEEE Scalable Coherent Interface. C'était un mécanisme de verrouillage qui créait des pointeurs d'une cache à une autre au niveau du fer, de sorte que chaque détenteur de verrou savait à qui c'était. Lorsque John et moi en avons entendu parler, nous nous sommes regardés et avons dit: pourquoi faire cela au niveau du fer? Ne pouvez-vous pas faire de même avec la comparaison et l'échange? Nous avons pris l'un des cahiers dans le public et y avons jeté un verrou MCS pendant que Mary continuait sa conversation. Plus tard, nous l'avons mis en œuvre, expérimenté, l'idée s'est avérée réussie et nous avons publié un article. Ensuite, pour moi, ce sujet n'a semblé qu'une distraction amusante, après quoi j'ai prévu de revenir aux systèmes d'exploitation. Mais un autre problème est survenu dans la même direction et, finalement, la synchronisation, le multithreading et les structures de données sont devenus ma principale spécialité. Comme vous pouvez le voir, tout cela s'est produit par hasard.

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

Comment survivre dans un monde en constante évolution?

Alexei : J'ai une question sur un sujet connexe. Il y a 30 ou 40 ans, il y avait plus de liberté dans différentes spécialités. Si vous voulez commencer une carrière dans les systèmes multithreads ou distribués - s'il vous plaît, vous voulez faire des systèmes d'exploitation - pas de problème. Dans chaque domaine, il y avait beaucoup de questions ouvertes et peu d'experts. Des spécialisations étroites sont désormais apparues: il n'y a tout simplement pas d'experts sur les systèmes d'exploitation en général, il y a des experts sur les systèmes individuels. Même chose avec les systèmes multithreads et distribués. Mais le problème est que nos vies ne sont pas interminables, chacun ne peut se consacrer à la recherche que quelques décennies. Comment survivre dans ce nouveau monde?

Michael : Nous ne sommes pas spéciaux à cet égard, tout de même arrivé une fois dans d'autres domaines. J'ai eu la chance de commencer à travailler à l'informatique lorsque ce domaine était à l'adolescence. Certaines fondations avaient déjà été posées, mais tout était encore très immature. Une telle opportunité apparaît rarement. Le génie électrique existe depuis très longtemps, la physique - encore plus longtemps, les mathématiques - presque depuis le début des temps. Mais cela ne signifie pas qu'en mathématiques, personne d'autre ne fait de découvertes intéressantes. Il existe encore de nombreux problèmes ouverts, mais en même temps, il faut en apprendre davantage. Vous avez correctement noté que maintenant il y a beaucoup plus de spécialisations qu'auparavant, mais cela signifie seulement que nous sommes dans la même situation que la plupart des autres domaines de l'activité humaine.

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

Michael : Pas toujours réussi. Récemment, j'ai préparé un rapport dans lequel je suis allé trop loin dans les détails techniques. Au fur et à mesure que le rapport progressait, il est devenu clair que la plupart du public ne me comprenait pas, j'ai donc dû m'adapter à la situation lors de mes déplacements. Les diapositives ne pouvaient plus être modifiées, donc cela ne fonctionnait pas très bien - par conséquent, de manière générale, j'essaie de ne pas utiliser les diapositives. En général, mon conseil est le suivant: tenez compte de votre public. Vous devez savoir qui vous contactez, quel niveau de connaissances ils ont et ce qu'ils ont besoin d'entendre afin d'évaluer votre travail.

Vitaliy : Pourriez-vous donner un indice sur le sujet de cette conférence?

Michael : Pour être honnête, je préférerais ne pas parler de ce sujet afin de laisser anonymes les personnes en question. L'essentiel, c'est que nous plongons 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 du rapport pourquoi ce problème est intéressant et important et comment il se rapporte à des questions que les élèves connaissent déjà. Selon mes observations, cette compétence est la plus difficile pour les étudiants. Et c'était le point faible de mon récent rapport. Un rapport bien structuré devrait dès le départ trouver le contact avec le public, lui expliquer exactement quel est le problème et comment il se rapporte à des sujets qu'il connaît déjà. Le degré de technicité de cette partie introductive dépend du public. S'il est complètement tacheté, le rapport peut être en plusieurs étapes. L'entrée doit être accessible à tous, et à la fin, une partie peut ne pas être à temps pour vous, mais les personnes qui connaissent relativement bien votre région seront en mesure de tout comprendre.

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

Alexei : Vous regardez les étudiants depuis plusieurs décennies. Les élèves deviennent-ils plus bêtes ou plus intelligents d'une décennie à l'autre ou d'une année à l'autre? En Russie, les professeurs se plaignent constamment que les étudiants deviennent stupides chaque année, et on ne sait tout simplement pas quoi faire à ce sujet.

Michael : Vous pouvez vraiment entendre beaucoup de négativité de notre part de personnes âgées. Inconsciemment, nous avons tendance à nous attendre à ce que les étudiants maîtrisent toutes les 30 années d'expérience que nous avons déjà. Si j'ai une compréhension plus profonde qu'en 1985, alors pourquoi les étudiants ne l'ont-ils pas? Probablement parce qu'ils ont 20 ans, comment aimez-vous ça? Je pense que les changements les plus importants des dernières décennies concernent la composition démographique: nous avons maintenant beaucoup plus d'étudiants étrangers, à l'exception des Canadiens. Il y avait autrefois beaucoup de Canadiens, car nous sommes très près de la frontière avec le Canada, et les étudiants peuvent rentrer chez eux le week-end. Mais maintenant, au Canada, il existe de nombreuses bonnes universités, et les Canadiens préfèrent étudier à la maison, aux États-Unis, ils ont commencé à voyager beaucoup moins.

Alexei : Pensez-vous que ce soit une tendance locale ou mondiale?

Michael : Je ne me souviens pas exactement de qui, mais quelqu'un a dit que le monde était plat. Notre région est devenue beaucoup plus internationale. Les conférences ACM se tenaient auparavant exclusivement aux États-Unis, puis ils ont décidé de les tenir tous les 4 ans dans d'autres pays, et maintenant elles ont lieu dans le monde entier. Dans une plus large mesure, ces changements ont affecté l' IEEE , car il a toujours été une organisation plus internationale que ACM. Et les directeurs de programme (présidents de programme) viennent de Chine, d'Inde, de Russie, d'Allemagne et de nombreux autres pays, car partout il se passe beaucoup de choses maintenant.

Alexei : Mais il y a probablement des aspects négatifs d'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 était le fait que les États-Unis avaient volé les personnes les plus intelligentes et les plus talentueuses des pays du monde. Et maintenant, le principal problème est les jeux politiques entre les différents pays autour des visas et de l'immigration.

Alexei : Autrement dit, les barrières et autres. Je vois.

Vladimir : Personnellement, je me demande quelle approche vous adoptez lorsque vous enseignez une nouvelle matière aux étudiants. Après tout, il existe différentes options: vous pouvez d'abord essayer de les inciter à essayer quelque chose de nouveau, et vous pouvez accorder plus d'attention aux détails du fonctionnement d'une certaine technologie. Que préférez-vous?

Travail efficace avec les étudiants

Alexei : Et comment trouver le foutu équilibre entre le premier et le deuxième?

Michael : Le problème est que les cours ne se déroulent pas toujours comme je le souhaiterais. Habituellement, je donne à l'avance aux élèves du matériel de lecture afin qu'ils s'y plongent, le comprennent le plus possible et formulent des questions dans les endroits qu'ils ne peuvent pas comprendre. Ensuite, en classe, vous pouvez vous concentrer sur les moments les plus difficiles et les explorer tous ensemble. C'est ainsi que j'aime le plus diriger les cours. Mais compte tenu de la charge qui pèse actuellement sur les étudiants, je n'arrive pas toujours à m'assurer qu'ils sont préparés à l'avance. En conséquence, nous devons consacrer beaucoup plus de temps à la narration générale du matériel que nous le souhaiterions. Malgré cela, j'essaie de garder nos cours interactifs. Sinon, il est plus facile d'enregistrer une vidéo une fois, que les élèves peuvent ensuite regarder à la maison. Le sens des activités vivantes est dans l'interaction humaine. En classe, je préfère ne pas utiliser de diapositives, mais de la craie et un tableau noir, sauf dans certains cas où un schéma est trop compliqué pour être dessiné sur un tableau noir. Grâce à cela, je n'ai pas besoin de suivre un plan de cours strict. Puisqu'il n'y a pas d'ordre strictement défini dans lequel je donne le matériel, cela me permet de m'adapter au public en fonction des questions que je reçois. En général, 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 très cool. D'après mon expérience, il est assez difficile de poser des questions au public. Même si vous demandez à l'avance de poser des questions, qu'elles soient stupides ou intelligentes, elles restent silencieuses. Comment gérez-vous cela?

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

Vitaliy : Et si vous avez répondu incorrectement, vous sortez de la classe :-)

Michael : Si vous n’avez rien répondu, vous devriez poser une question. Je dois comprendre exactement ce que l'élève doit savoir pour répondre à la question que je viens de poser. Ils doivent m'aider à 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 faire ça. Et si vous ne donnez pas la paix aux étudiants pendant longtemps, ils finissent parfois par poser les bonnes questions, c'est-à-dire celles qui m'aident à voir ce qui se passe dans la tête des étudiants.

Alexei : Ces questions soulèvent-elles parfois des idées auxquelles vous n'aviez pas pensé auparavant? Sont-ils inattendus? Est-ce qu'ils nous permettent d'examiner un problème sous un nouveau jour?

Michael : Il y a des questions qui ouvrent une nouvelle façon de présenter du matériel. Il y a souvent des questions qui conduisent à des problèmes intéressants dont je n'avais pas l'intention de parler. Les élèves me disent souvent que j'ai tendance à m'éloigner du sujet de la leçon lorsque cela se produit. Et, selon eux, c'est très souvent la partie la plus intéressante de l'activité. Assez rarement, littéralement plusieurs fois, les étudiants ont posé des questions qui ont trouvé une nouvelle direction dans l'étude et sont devenues un article. Cela se produit beaucoup plus souvent dans les conversations avec les élèves, et non pendant les cours, mais occasionnellement pendant les cours.

Alexei : Autrement dit, les étudiants vous ont posé des questions, sur la base desquelles vous pourriez plus tard publier un article?

Michael : Oui.

Vitaliy : À quelle fréquence avez-vous de telles conversations avec les élèves? , ?

: — . - 5 6 , - . , — . , . , . , . , , . , , , .

: ? , — .

: , — , . . , , . , , 9 17 . , , — .

.

: - , ? - Computer Science.

: , — .

: , 10, 20, 30 ? , , .

: , . 1980-, , ( Doug Baldwin ). , , . , . ( : «Programming Language Pragmatics» ) 200 . , , . , : , , , . , , . , Pascal, . Swift, Go, Rust, , . , , , . Python, Ruby Perl, , , , .

: . ? , — , . ?

: , 100% . , — . Rust, Google, Mozilla . , . , .

: . (cache coherence). , ? . ?

: , . ( William Bolosky ) ( Leonidas Kontothanassis ) 1990- . , : , , , . . , NUMA, page placement . , , — . , (hardware transactional memory). , , . , , . , .

: : , ? ?

: , , . , . , , . , , - . , - - , . . - , , . — .

: . , . , , Intel. , ?

: , , , - . , : , , . , , , . , , , , . , , . , . , . - 15 . , , «How to evaluate systems research» - , . , , , , . , .

: , , . , , TDP, . ? , ?

: , . , . , , . , Linux. , AWS. .

: ? ?

: . - 1980- , . , (National Science Foundation ) (Coordinated Experimental Research, CER). Computer Science, . 1984 128- BBN Butterfly, . . 128 , , . , 128 . MCS.

: , ?

: — . : -, , , . - 10 , - . Intel. , , , . , ( Steven Swanson ) . , . , . , , , .

. MCS, MS, CLH, JSR 166, .

: , . MCS - (MS) , Java. ( : ). CLH , . .

: , 10 .

: Java?

: . , ? ?

: , MS Java 5. (Mark Moyers) Sun Microsystems . , , , . (Doug Lea). , - 25 Sun JSR 166 , java.util.concurrent. , MS, . , , . , . , « », . , . Java.

: , .size() , O(1)?

: , .

: .size() Java, , , . , .

: (dual data structures) (Bill Scherer) — , Hydra . , Java Executor Framework. , (fair and unfair queues). , . executors .

: ? , . , , , , , - . ?

: , « » — , . , . , K42 IBM MCS , acquire release. , , . , , , . , .

, . , MS , , CAS. CAS . Intel , - 30 , . , MS, . , O(n) , O(1). , . - , . , . , , , , . . (Dave Dice) Oracle. , , , . NUMA-aware .

: , . - , , , . .

: , . , , . , . , 10, 20, 25 . , . , , , , . , . , . , , 10 . — 20. , . . , . (Joe Izraelevitz) DISC, , . , , . , . , , .

: - , ? , ? , , , .

: , , . -, , Google Scholar , , . , . , , , — . . , , , . , , .

: , ?

: , , . , , . , , . , (M. Herlihy, JEB Moss) . 1990- , , , . , JSR 166. , . 2000-, . . . . , , .

: . , , . , . , , , . ( : — , Disruptor Aeron . Joker 2015, YouTube . , ). , , . . ?

: : , .

: , .

: — . , . (Butler Lampson), « ». . , , 10 — . ISA , , . . , . — GPU, , , , FPGA. , ? , .

: , . , . : — , , — , , , .

: — - .

: C++.

: - (Hans Boehm). , , . , . , , , 30 . ( : ).

: : ?

: . , , API. API, . , . . , , , , .

: , , , , , ? , , . , . ?

: . , , , - . , , . MNS . (Adam Morrison) (Yehuda Afek) LCRQ . , , fetch-and-increment. . , fetch-and-increment . (Eric Freudenthal) Ultracomputer c (Allan Gottlieb) 1980-, . fetch-and-increment .

. ?

: , ?

: , , , .

: , ?

: — Intel IBM. , - load store . happens-before, . , , , . , , .

— . , . . , , 100 , , . , , . , - .

: , . ?

: . — . , — . , . , , , . , . , , . . , CAS , , . , , .

, Optane DIMM, .

: , — : . ? , - ?

: , , . , Intel Optane DIMM , - 3 10 , RAM. . , RAM. , 10 , DRAM — . . , - . , - , — . , , . . , , . , , , «» .

, — . . - , , 5 , TCP-IP , . . , , . , . USENIX ATC . , , , I/O, . , .

: — , — . , .

: .

: , ?

: , - . , , . , , - . , .

: . , RAM CPU. - RAM .

: . , . .

: , . .

: . .

: .

. Dual data structures. Hydra.

: , . , , . , ? , , ?

: , . , , - . - , , , . , .

: Hydra . , , . ?

: . , . , , Java. , , . , , , , . , . , — , , . . , 10 , - , . - , . «» , , , -. - , . . , , , . , .

: ? , ?

: , , -, , , -, , , . , , . . , . , .

: : , ?

: , . , , , . , . , . , - MS.

: ?

: , . Hydra. , Java, LCRQ, .

: , Hydra — , - ?

: , , Hydra , Java, , .

: , .

: , .

: , : .

: , ? ?

: , , . , . , . , SPTDC; - Java, -, Java. Java, .

: , Hydra - , , - . , . , , . , . Merci beaucoup!

: .

: -.

: , . - ?

: , . - , , , .

: , . , !

Hydra 2019, 11-12 2019 -. «Dual data structures» . .