Maurice Herlihy - propriétaire de deux Prix ​​Dijkstra. Le premier concerne les travaux sur "Synchronisation sans attente" (Brown University) et la seconde, plus récente, - "Mémoire transactionnelle : prise en charge architecturale des structures de données sans verrouillage" (Université technologique de Virginie). Le prix Dijkstra est décerné pour un travail dont l'importance et l'influence sont visibles depuis au moins dix ans et Maurice est évidemment l'un des spécialistes les plus célèbres en la matière. Il travaille actuellement comme professeur à l'Université Brown et compte de nombreuses réalisations qui comptent un paragraphe. Il mène actuellement des recherches sur la blockchain dans le contexte de l'informatique distribuée classique.

Auparavant, Maurice était déjà venu en Russie pour le SPTCC (enregistrement vidéo) et a fait une excellente réunion de la communauté des développeurs Java JUG.ru à Saint-Pétersbourg (enregistrement vidéo).

Cet habrapost est une superbe interview de Maurice Herlihy. Il aborde les sujets suivants :

• Interaction entre le monde universitaire et l'industrie ;
• Fondation pour la recherche sur la blockchain ;
• D’où viennent les idées révolutionnaires ? L'influence de la popularité ;
• Doctorat sous la direction de Barbara Liskov ;
• Le monde attend le multicœur ;
• Un nouveau monde apporte de nouveaux problèmes. NVM, NUMA et piratage d'architecture ;
• Compilateurs vs processeurs, RISC vs CISC, mémoire partagée vs transmission de messages ;
• L’art d’écrire du code multithread fragile ;
• Comment apprendre aux étudiants à écrire du code multithread complexe ;
• Nouvelle édition du livre « The Art of Multiprocessor Programming » ;
• Comment la mémoire transactionnelle a été inventée ;   
• Pourquoi cela vaut-il la peine de mener des recherches dans le domaine de l'informatique distribuée ?
• Le développement des algorithmes s’est-il arrêté et comment continuer ?
• Travailler à l’Université Brown ;
• La différence entre la recherche dans une université et au sein d'une entreprise ;
• Hydra et SPTDC.

L'entretien est mené par :

Vitali Aksenov — actuellement, post-doctorant à l'IST Autriche et employé 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.

Interaction entre le monde universitaire et l'industrie

Alexey : Maurice, vous travaillez depuis très longtemps dans un environnement académique et la première question est l'interaction entre les sphères académique et industrielle. Pourriez-vous nous parler de la façon dont les interactions entre eux ont changé récemment ? Que s’est-il passé il y a 20 ou 30 ans et que se passe-t-il aujourd’hui ? 

Maurice : J'ai toujours essayé de travailler en étroite collaboration avec les sociétés commerciales car elles ont des problématiques intéressantes. En règle générale, ils ne sont pas très intéressés ni par la publication de leurs résultats ni par des explications détaillées de leurs problèmes à la communauté mondiale. Ils ne s’intéressent qu’à la résolution de ces problèmes. J'ai travaillé pour de telles entreprises pendant un certain temps. J'ai passé cinq ans à travailler à temps plein dans un laboratoire de recherche chez Digital Equipment Corporation, qui était autrefois une grande entreprise informatique. J'ai travaillé un jour par semaine chez Sun, chez Microsoft, chez Oracle et j'ai travaillé un peu chez Facebook. Maintenant, je vais prendre un congé sabbatique (un professeur d'une université américaine est autorisé à prendre un tel congé d'un an environ une fois tous les six ans) et travailler dans Algorand, il s'agit d'une société de crypto-monnaie basée à Boston. Travailler en étroite collaboration avec des entreprises a toujours été un plaisir car c'est ainsi que l'on apprend des choses nouvelles et intéressantes. Vous pourriez même être la première ou la deuxième personne à publier un article sur un sujet choisi, plutôt que de travailler à l'amélioration progressive des solutions à des problèmes sur lesquels tout le monde travaille déjà.

Alexeï : Pouvez-vous nous dire plus en détail comment cela se passe ?

Maurice : Bien sûr. Vous savez, lorsque je travaillais à Digital Equipment Corporation, moi et Elliot Moss, nous avons inventé la mémoire transactionnelle. Ce fut une période très fructueuse où tout le monde commença à s’intéresser aux technologies de l’information. Le parallélisme, y compris, même si les systèmes multicœurs n'existaient pas encore. Durant les journées Sun et Oracle, j'ai beaucoup travaillé sur des structures de données parallèles. Chez Facebook, j'ai travaillé sur leur projet blockchain, dont je ne peux pas parler, mais j'espère qu'il sera bientôt rendu public. L'année prochaine, chez Algorand, je travaillerai dans un groupe de recherche étudiant les contrats intelligents.

Alexey : La blockchain est devenue un sujet très populaire ces dernières années. Est-ce que cela aidera vos recherches ? Peut-être facilitera-t-il l’obtention de subventions ou l’accès à des ressources auprès des entreprises opérant dans le secteur ?

Maurice : J'ai déjà reçu une petite subvention de la Fondation Ethereum. La popularité de la blockchain est très utile pour inciter les étudiants à travailler dans ce domaine. Ils s'y intéressent beaucoup et sont enthousiastes à l'idée de s'impliquer, mais parfois ils ne réalisent pas que la recherche qui semble passionnante de l'extérieur s'avère être un travail très dur. Cependant, je suis vraiment ravi d’utiliser toute cette mystique autour de la blockchain pour aider à attirer les étudiants. 

Mais ce n'est pas tout. Je fais partie du conseil consultatif de plusieurs startups blockchain. Certains d’entre eux peuvent réussir, d’autres non, mais il est toujours très intéressant de voir leurs idées, de les étudier et de conseiller les gens. La chose la plus excitante, c’est quand on avertit les gens de ne pas faire quelque chose. Beaucoup de choses semblent être une bonne idée au premier abord, mais le sont-elles vraiment ?

Fondation pour la recherche sur la blockchain

Vitaly : Certains pensent que l’avenir réside dans la blockchain et ses algorithmes. Et d’autres disent que c’est juste une autre bulle. Pouvez-vous partager votre opinion à ce sujet ?

Maurice : Une grande partie de ce qui se passe dans le monde de la blockchain est erronée, certaines ne sont que des arnaques, d'autres sont surfaites. Cependant, je pense qu’il existe une base scientifique solide pour ces études. Le fait que le monde de la blockchain regorge de différences idéologiques montre le niveau d’enthousiasme et de dévouement. En revanche, cela n’est pas particulièrement bénéfique pour la recherche scientifique. Or, si vous publiez un article qui parle des défauts d’un algorithme particulier, la réaction qui en résulte n’est pas toujours entièrement scientifique. Souvent, les gens rejettent leurs émotions. Je pense que ce genre d'enthousiasme dans ce domaine peut sembler attrayant à certains, mais en fin de compte, il y a de véritables problèmes scientifiques et techniques qui doivent être résolus. Il y a beaucoup d'informatique ici.

Vitaly : Vous essayez donc de jeter les bases de la recherche sur la blockchain, n'est-ce pas ?

Maurice : J'essaie de poser les bases d'une discipline solide, scientifiquement et mathématiquement solide. Et une partie du problème réside dans le fait qu’il faut parfois contredire certaines positions trop dures d’autres personnes et les ignorer. Parfois, les gens me demandent pourquoi je travaille dans une zone qui n’intéresse que les terroristes et les trafiquants de drogue. Une telle réaction est aussi dénuée de sens que le comportement de vos abonnés qui répètent aveuglément vos paroles. Je pense que la vérité se situe quelque part entre les deux. La blockchain aura un impact profond sur la société et l’économie mondiale. Mais cela n’arrivera probablement pas grâce à la technologie moderne. Les technologies modernes vont se développer et ce que l’on appellera à l’avenir la blockchain deviendra très important. Cela ne ressemble peut-être même pas aux blockchains modernes, c'est une question ouverte.

Si les gens inventent de nouvelles technologies, ils continueront à l’appeler blockchain. Je veux dire, tout comme le Fortran d'aujourd'hui n'a rien à voir avec le langage Fortran des années 1960, mais tout le monde continue de l'appeler Fortran. Idem pour UNIX. Ce qu’on appelle la « blockchain » va encore faire sa révolution. Mais je doute que cette nouvelle blockchain ressemble à ce que tout le monde aime utiliser aujourd’hui.

D’où viennent les idées révolutionnaires ? Impact de la popularité

Alexey : La popularité de la blockchain a-t-elle conduit à de nouveaux résultats d'un point de vue scientifique ? Plus d'interaction, plus d'étudiants, plus d'entreprises sur le territoire. Y a-t-il déjà des résultats de cette popularité croissante ?

Maurice : Je me suis intéressé à cela lorsqu'on m'a remis un flyer officiel d'une entreprise qui venait de récolter pas mal d'argent. Il a écrit sur tâche des généraux byzantins, avec lequel je suis plus que familier. Ce qui était écrit dans le dépliant était clairement techniquement incorrect. Les gens qui ont écrit tout cela n’ont pas vraiment compris le modèle derrière le problème… et pourtant cette entreprise a récolté beaucoup d’argent. Par la suite, l'entreprise a discrètement remplacé ce dépliant par une version beaucoup plus correcte - et je ne dirai pas quel était le nom de cette entreprise. Ils sont toujours là et se portent très bien. Cet incident m’a convaincu que, premièrement, la blockchain est simplement une forme d’informatique distribuée. Deuxièmement, le seuil d’entrée (au moins il y a quatre ans) était assez bas. Les gens travaillant dans ce domaine étaient très énergiques et intelligents, mais ils ne lisaient pas d’articles scientifiques. Ils ont essayé de réinventer des choses connues et se sont trompés. Aujourd'hui, le drame s'est atténué.

Alexey : C'est très intéressant, car il y a quelques années, nous avions une tendance différente. C'est un peu comme le développement front-end, lorsque les développeurs front-end basés sur navigateur ont réinventé des technologies entières qui étaient déjà populaires dans le back-end : systèmes de construction, intégration continue, des choses comme ça. 

Maurice : Je suis d'accord. Mais cela n’est pas surprenant, car les idées véritablement révolutionnaires viennent toujours de l’extérieur de la communauté établie. Il est peu probable que les chercheurs confirmés, notamment les universitaires confirmés, fassent quelque chose de véritablement révolutionnaire. Il est facile de rédiger un article pour la prochaine conférence sur la manière dont vous avez légèrement amélioré les résultats de vos travaux antérieurs. Aller à une conférence, se retrouver entre amis, parler des mêmes choses. Et ceux qui font irruption avec des idées révolutionnaires viennent presque toujours de l’extérieur. Ils ne connaissent pas les règles, ils ne connaissent pas la langue, mais quand même... Si vous êtes au sein d'une communauté établie, je vous conseille de faire attention aux nouveautés, à quelque chose qui ne rentre pas dans l'ensemble. En un sens, on peut tenter de combiner des développements externes, plus fluides, avec des méthodes que nous comprenons déjà. Dans un premier temps, essayez d’établir une base scientifique, puis modifiez-la afin qu’elle puisse être appliquée à de nouvelles idées révolutionnaires. Je pense que la blockchain est idéale pour être une idée nouvelle et disruptive.

Alexeï : Pourquoi pensez-vous que cela arrive ? Parce que les gens « à l’extérieur » n’ont pas de barrières spécifiques inhérentes à la communauté ?

Maurice : Il y a une tendance à se produire ici. Si vous lisez l'histoire des impressionnistes dans la peinture et l'art en général, alors des artistes célèbres ont rejeté l'impressionnisme. Ils ont dit que c'était un peu enfantin. Une génération plus tard, cette forme d’art auparavant rejetée est devenue la norme. Ce que je vois dans mon domaine : les inventeurs de la blockchain n'étaient pas intéressés par le pouvoir, par l'augmentation des publications et de l'indice de citation, ils voulaient juste faire quelque chose de bien. Alors ils se sont assis et ont commencé à le faire. Il leur manquait une certaine profondeur technique, mais c’est réparable. Il est beaucoup plus difficile de proposer de nouvelles idées créatives que de corriger et de renforcer celles qui ne sont pas suffisamment matures. Grâce à ces inventeurs, j'ai désormais de quoi faire !

Alexey : C'est similaire à la différence entre les startups et les projets existants. Nous héritons de nombreuses limitations de pensée, barrières, exigences particulières, etc.

Maurice : Une bonne analogie est celle de l'informatique distribuée. Considérez la blockchain comme s’il s’agissait d’une startup et l’informatique distribuée comme une grande entreprise établie. L'informatique distribuée est en train d'être acquise et fusionnée avec la blockchain.

Thèse sous la direction de Barbara Liskov

Vitaly : Nous avons encore beaucoup de questions ! Nous avons examiné votre parcours et sommes tombés sur un fait intéressant concernant votre doctorat. Oui, c’était il y a longtemps, mais cela semble être un sujet important. Vous avez obtenu votre doctorat sous votre direction Barbara Liskov! Barbara est très connue dans la communauté des langages de programmation, et une personne très connue en général. Il est logique que vos recherches portent sur le domaine des langages de programmation. Comment êtes-vous passé au calcul parallèle ? Pourquoi avez-vous décidé de changer de sujet ?

Maurice : À l'époque, Barbara et son groupe s'intéressaient simplement à l'informatique distribuée, ce qui était une idée très nouvelle. Il y avait aussi ceux qui disaient que l’informatique distribuée était un non-sens et que les ordinateurs communiquant entre eux étaient inutiles. L’un des problèmes abordés dans l’informatique distribuée qui la distingue de l’informatique centralisée est la tolérance aux pannes. Après de nombreuses recherches, nous avons décidé qu'un langage de programmation informatique distribué devait avoir quelque chose comme des transactions atomiques, car on ne peut jamais être sûr qu'un appel à distance réussira. Une fois que vous avez des transactions, le problème de la gestion de la concurrence se pose. Ensuite, il y a eu beaucoup de travail pour obtenir des structures de données transactionnelles hautement parallèles. Puis, après avoir obtenu mon diplôme, je suis allé à Carnegie Mellon et j'ai commencé à chercher un sujet sur lequel travailler. Il m'est venu à l'esprit que l'informatique est passée des ordinateurs individuels aux réseaux d'ordinateurs. Les multiprocesseurs seraient une continuation naturelle du progrès – le mot « multicœur » n'existait pas encore. J'ai pensé : quel est l'équivalent des transactions atomiques pour un système multicœur ? Ce ne sont certainement pas des transactions régulières car elles sont trop volumineuses et lourdes. Et c'est comme ça que j'ai eu l'idée linéarisabilité et c'est ainsi que j'ai imaginé toute la synchronisation sans attente. Il s'agissait d'une tentative de répondre à la question de savoir quel est l'analogue des transactions atomiques pour un système multiprocesseur à mémoire partagée. À première vue, cette œuvre peut paraître complètement différente, mais elle s’inscrit en fait dans la continuité du même thème.

Le monde attend le multicœur

Vitaly : Vous avez mentionné qu'à cette époque il y avait très peu d'ordinateurs multicœurs, n'est-ce pas ?

Maurice : Ils n'étaient tout simplement pas là. Il existait plusieurs multiprocesseurs dits symétriques, qui étaient essentiellement connectés au même bus. Cela n'a pas très bien fonctionné car chaque fois qu'une nouvelle entreprise créait quelque chose de similaire, Intel sortait un seul processeur supérieur au multiprocesseur.

Alexeï : Cela ne veut-il pas dire qu’à cette époque-là, il s’agissait plutôt d’une étude théorique ?

Maurice : Ce n'était pas une étude théorique, mais plutôt une étude spéculative. Il ne s’agissait pas ici de travailler avec de nombreux théorèmes, mais plutôt d’émettre des hypothèses sur une architecture qui n’existait pas à cette époque. C'est à cela que sert la recherche ! Aucune entreprise n’aurait fait une chose pareille ; tout cela venait d’un avenir lointain. En fait, cela a été le cas jusqu'en 2004, lorsque de véritables processeurs multicœurs sont apparus. Étant donné que les processeurs surchauffent, vous pouvez réduire encore plus la taille du processeur, mais vous ne pouvez pas le rendre plus rapide. Pour cette raison, il y a eu une transition vers des architectures multicœurs. Et puis cela signifiait que d’un coup, tous les concepts que nous avions développés dans le passé avaient une utilité.

Alexey : Pourquoi pensez-vous que les processeurs multicœurs ne sont apparus que dans les années XNUMX ? Alors pourquoi est-il si tard ?

Maurice : Cela est dû à des limitations matérielles. Intel, AMD et d'autres sociétés réussissent très bien à augmenter la vitesse du processeur. À un moment donné, les processeurs sont devenus suffisamment petits pour ne plus pouvoir augmenter la vitesse d'horloge car ils commençaient à s'épuiser. Vous pouvez les rendre plus petits, mais pas plus rapides. Ce qui est en leur pouvoir - au lieu d'un très petit processeur, ils peuvent accueillir huit, seize ou trente-deux processeurs dans le même volume du boîtier, là où auparavant un seul pouvait en contenir. Vous disposez désormais du multithreading et d’une communication rapide entre eux car ils partagent des caches. Mais vous ne pouvez pas les forcer à courir plus vite : il existe une limite de vitesse très spécifique. Ils continuent de s’améliorer petit à petit, mais plus tellement maintenant. Les lois de la physique faisaient obstacle aux améliorations.

Un nouveau monde apporte de nouveaux problèmes. NUMA, NVM et piratage d'architecture

Alexey : Cela semble très raisonnable. Avec les nouveaux processeurs multicœurs, de nouveaux problèmes sont apparus. Est-ce que vous et vos collègues vous attendiez à ces problèmes ? Peut-être les avez-vous étudiés à l'avance ? Dans les études théoriques, il n’est souvent pas facile de prédire de telles choses. Lorsque des problèmes surviennent, comment ont-ils répondu à vos attentes et à celles de vos collègues ? Ou étaient-ils complètement nouveaux et vous et vos collègues avez dû passer beaucoup de temps à résoudre les problèmes au fur et à mesure qu'ils apparaissaient ?

Vitaly : J'ajouterai à la question d'Alexeï : avez-vous correctement prédit l'architecture du processeur pendant que vous étudiiez la théorie ?

Maurice : Pas à 100%. Mais je pense que mes collègues et moi avons fait du bon travail en prédisant les multicœurs avec mémoire partagée. Je pense que nous avons correctement prédit les difficultés liées au développement de structures de données parallèles fonctionnant sans verrous. De telles structures de données ont été importantes pour de nombreuses applications, mais pas toutes, mais ce dont vous avez réellement besoin est souvent une structure de données non verrouillable. Lorsque nous les avons inventés, beaucoup ont affirmé que cela n’avait aucun sens et que tout fonctionnait bien avec les serrures. Nous avions très bien prédit qu'il y aurait des solutions toutes faites à de nombreux problèmes de programmation et de structure de données. Il y avait aussi des problèmes plus complexes, comme NUMA – accès inégal à la mémoire. En fait, ils n’ont même pas été envisagés jusqu’à l’invention des processeurs multicœurs, car ils étaient trop spécifiques. La communauté des chercheurs travaillait sur des questions généralement prévisibles. Certains problèmes matériels associés à des architectures spécifiques ont dû attendre en coulisses – en fait, l'apparition de ces architectures. Par exemple, personne n’a vraiment travaillé sur les structures de données spécifiques aux GPU, car les GPU n’existaient pas à l’époque. Même si de nombreux travaux ont été réalisés SIMD, ces algorithmes étaient prêts à être utilisés dès que le matériel approprié était disponible. Mais il est impossible de tout prévoir.

Alexey : Si je comprends bien, NUMA est une sorte de compromis entre le coût, les performances et quelques autres choses. Avez-vous une idée de la raison pour laquelle NUMA est sorti si tard ?

Maurice : Je pense que NUMA existe à cause de problèmes avec le matériel utilisé pour produire la mémoire : plus les composants sont éloignés, plus il est lent d'y accéder. D’un autre côté, la deuxième valeur de cette abstraction est l’uniformité de la mémoire. Ainsi, l’une des caractéristiques du calcul parallèle est que toutes les abstractions sont légèrement brisées. Si l’accès était parfaitement uniforme, toute la mémoire serait équidistante, mais cela est économiquement, et peut-être même physiquement, impossible. Ce conflit surgit donc. Si vous écrivez votre programme comme si la mémoire était uniforme, il sera probablement correct. Dans le sens où cela ne donnera pas de mauvaises réponses. Mais sa performance n’attrapera pas non plus les étoiles du ciel. De même, si vous écrivez verrous tournants Sans comprendre la hiérarchie du cache, le blocage lui-même sera correct, mais vous pouvez oublier les performances. Dans un sens, vous devez écrire des programmes qui reposent sur une abstraction très simple, mais vous devez déjouer les gens qui vous ont donné cette abstraction : vous devez savoir que sous l'abstraction se trouve une certaine hiérarchie de mémoire, qu'il y a un bus entre vous et ce souvenir, et ainsi de suite. Il existe donc un certain conflit entre des abstractions individuellement utiles, ce qui nous amène à des problèmes très concrets et pragmatiques.

Vitaly : Et l'avenir ? Pouvez-vous prédire comment les processeurs évolueront ensuite ? Il existe une idée selon laquelle l’une des réponses est la mémoire transactionnelle. Vous avez probablement autre chose en stock.

Maurice : Il y a quelques défis majeurs à relever. La première est que la mémoire cohérente est une merveilleuse abstraction, mais elle commence à s’effondrer dans des cas particuliers. Ainsi, par exemple, NUMA est un exemple vivant de quelque chose dans lequel vous pouvez continuer à prétendre qu'une mémoire uniforme existe. En fait non, la productivité vous fera pleurer. À un moment donné, les architectes devront abandonner l'idée d'une architecture à mémoire unique : on ne peut pas faire semblant éternellement. Il faudra de nouveaux modèles de programmation suffisamment faciles à utiliser et suffisamment puissants pour rendre le matériel sous-jacent efficace. C'est un compromis très difficile, car si vous montrez aux programmeurs l'architecture réellement utilisée dans le matériel, ils deviendront fous. C'est trop compliqué et pas portable. Si vous présentez une interface trop simple, les performances seront médiocres. Ainsi, de nombreux compromis très difficiles devront être faits pour fournir des modèles de programmation utiles applicables aux processeurs multicœurs de grande taille. Je ne suis pas sûr que quelqu'un d'autre qu'un spécialiste soit capable de programmer sur un ordinateur à 2000 cœurs. Et à moins que vous ne fassiez du calcul ou de la cryptographie très spécialisé ou scientifique ou quelque chose comme ça, on ne sait toujours pas du tout comment le faire correctement. 

Un autre domaine similaire est celui des architectures spécialisées. Les accélérateurs graphiques existent depuis longtemps, mais ils sont devenus un exemple classique de la façon dont vous pouvez prendre un type d’informatique spécialisé et l’exécuter sur une puce dédiée. Cela ajoute ses propres défis : comment communiquer avec un tel appareil, comment le programmer. J'ai récemment travaillé sur des problèmes dans la région proche de l'informatique mémoire. Vous prenez un petit processeur et le collez sur une énorme partie de la mémoire afin que la mémoire fonctionne à la vitesse du cache L1, puis communique avec un périphérique tel que TPU – le processeur est en train de charger de nouvelles tâches dans votre cœur de mémoire. La conception de structures de données et de protocoles de communication pour ce genre de choses est un autre exemple intéressant. Les processeurs et le matériel personnalisés continueront donc de bénéficier d’améliorations pendant un certain temps.

Alexey : Qu'en est-il de la mémoire non volatile (une mémoire non volatile)?

Maurice : Oh, c'est un autre excellent exemple ! NVM va considérablement changer notre façon de voir des choses comme les structures de données. La mémoire non volatile, dans un sens, promet de vraiment accélérer les choses. Mais cela ne facilitera pas la vie car la plupart des processeurs, caches et registres sont encore volatils. Lorsque vous démarrez après un crash, votre état et celui de votre mémoire ne seront pas exactement les mêmes qu'avant le crash. Je suis très reconnaissant envers les personnes travaillant sur NVM - les chercheurs auront beaucoup à faire pendant longtemps pour essayer de comprendre les conditions d'exactitude. Les calculs sont corrects s'ils peuvent survivre à un crash dans lequel le contenu des caches et des registres est perdu, mais la mémoire principale reste intacte.

Compilateurs vs processeurs, RISC vs CISC, mémoire partagée vs transmission de messages

Vladimir : Que pensez-vous du dilemme « compilateurs contre processeurs » du point de vue du jeu d'instructions ? Laissez-moi vous expliquer pour ceux qui ne sont pas au courant : si nous passons par une mémoire asymétrique ou quelque chose de similaire, nous pourrions utiliser un ensemble de commandes très simples et demander au compilateur de générer un code complexe pouvant profiter des nouveaux avantages. Ou nous pouvons aller dans l'autre sens : implémenter des instructions complexes et demander au processeur de réorganiser les instructions et d'effectuer d'autres manipulations avec elles. Qu'est-ce que tu en penses?

Maurice : Je n'ai pas vraiment de réponse à cette question. Ce débat dure depuis quatre décennies. Il fut un temps où entre abrégé un ensemble de commandes et compliqué les guerres civiles étaient menées par un ensemble de commandements. Pendant un certain temps, les gens de RISC ont gagné, mais Intel a ensuite reconstruit ses moteurs de manière à ce qu'un ensemble réduit d'instructions soit utilisé en interne et que l'ensemble complet soit exporté en externe. Il s’agit probablement d’un sujet sur lequel chaque nouvelle génération doit trouver ses propres compromis et prendre ses propres décisions. Il est très difficile de prédire laquelle de ces choses sera la meilleure. Ainsi, toute prédiction que je fais sera vraie pendant un certain temps, puis fausse à nouveau pendant un certain temps, puis à nouveau vraie.

Alexey : Dans quelle mesure est-il courant dans l'industrie que certaines idées gagnent pendant plusieurs décennies et perdent au cours de la suivante ? Existe-t-il d’autres exemples de tels changements périodiques ?

Maurice : En ce qui concerne l'informatique distribuée, il y a des gens qui croient en la memoire partagée et les gens qui croient en messagerie. Initialement, en informatique distribuée, le calcul parallèle signifie la transmission de messages. Puis quelqu’un a découvert qu’il était beaucoup plus facile de programmer avec de la mémoire partagée. Le côté opposé a déclaré que la mémoire partagée est trop compliquée, car elle nécessite des verrous, etc., il vaut donc la peine de passer à des langages où il n'y a que la transmission de messages. Quelqu'un a regardé ce qui en est ressorti et a dit : « wow, cette implémentation de messagerie ressemble beaucoup à de la mémoire partagée, parce que vous créez beaucoup de ces petits modules, ils s'envoient des messages les uns aux autres, et ils tous verrouillage« Créons une meilleure base de données de mémoire partagée ! » Tout cela se répète encore et encore, et il est impossible de dire que l’une des parties a définitivement raison. Un camp dominera toujours, car dès que l’un d’eux gagne presque, les gens inventent encore et encore des moyens d’améliorer l’autre.

L’art d’écrire du code multithread fragile

Alexeï : C'est très intéressant. Par exemple, lorsque nous écrivons du code, quel que soit le langage de programmation, nous devons généralement créer des abstractions telles que des cellules pouvant être lues et écrites. Mais en réalité, à un certain niveau physique, cela peut ressembler à l’envoi d’un message via un bus matériel entre différents ordinateurs et autres appareils. Il s’avère que le travail se déroule simultanément aux deux niveaux d’abstraction.

Maurice : Il est absolument vrai que la mémoire partagée repose sur la transmission de messages – bus, caches, etc. Mais il est difficile d'écrire des programmes en utilisant la transmission de messages, donc le matériel ment délibérément, prétendant que vous disposez d'une sorte de mémoire uniforme. Cela vous permettra d'écrire plus facilement des programmes simples et corrects avant que les performances ne commencent à se détériorer. Ensuite, vous direz : il semble qu’il soit temps de se lier d’amitié avec la cache. Et puis vous commencez à vous soucier de l’emplacement du cache, et c’est à partir de là. Dans un sens, vous piratez l'abstraction : vous savez qu'il ne s'agit pas simplement d'une mémoire plate et uniforme, et vous allez utiliser ces connaissances pour écrire des programmes respectueux du cache. C’est ce que vous devrez faire dans les vrais problèmes. Ce conflit entre l'abstraction douce, simple et agréable qui vous a été donnée et l'implémentation horriblement complexe du matériel sous-jacent est le lieu où chacun fera son propre compromis. J'ai un livre sur les multiprocesseurs et la synchronisation, et à un moment donné j'allais écrire un chapitre sur les structures de données dans java.util.concurrent. Si vous les regardez, des choses comme listes avec omissions Ce sont des œuvres d’art étonnantes. (Note de l'éditeur : ceux qui connaissent le langage Java devraient au moins jeter un œil à l'implémentation ConcurrentSkipListMap, vous pouvez consulter les liens sur API и code source). Mais de mon point de vue, il serait irresponsable de les montrer aux étudiants, car une telle structure de données est un peu comme un type dans un cirque courant sur une corde raide au-dessus d'une fosse aux ours. Si vous modifiez ne serait-ce qu’un petit détail, toute la structure s’effondrera. Ce code est très rapide et élégant simplement parce qu’il est parfaitement écrit, mais le moindre changement entraînera un échec complet. Si je donne ce code en exemple aux élèves, ils diront tout de suite : moi aussi je peux le faire ! Et puis un avion s’écrasera ou un réacteur nucléaire explosera, et je serai coupable de leur avoir donné trop d’informations au mauvais moment.

Alexey : Quand j'étais un peu plus jeune, j'ai essayé plusieurs fois d'étudier le code source de Doug Lee, par exemple, java.util.concurrent, comme il est open source, il est très facile de le trouver et d'essayer de comprendre ce qui s'y passe. Cela ne s’est pas très bien passé : souvent, on ne sait absolument pas pourquoi Doug a décidé de faire quelque chose de cette façon alors que tout le monde le fait différemment. Comment expliquez-vous ces choses à vos élèves ? Existe-t-il une manière particulièrement correcte de décrire des détails spécifiques d'un algorithme hardcore, par exemple ? Comment est-ce que tu fais ça?

Maurice : Les professeurs de dessin ont un cliché dont ils se souviennent en premier : si vous voulez dessiner comme Picasso, vous devez d'abord apprendre à dessiner des images simples et réalistes, et ce n'est que lorsque vous connaissez les règles que vous pouvez commencer à les enfreindre. Si vous commencez par enfreindre les règles tout de suite, vous vous retrouvez dans le pétrin. Tout d’abord, j’enseigne aux étudiants comment écrire du code simple et correct sans se soucier des performances. Ce que je dis, c'est qu'il y a des problèmes de timing complexes qui se cachent ici, alors ne vous inquiétez pas des caches, ne vous inquiétez pas des modèles de mémoire, assurez-vous simplement que tout fonctionne correctement. C’est déjà assez difficile : la programmation moderne n’est pas facile en soi, surtout pour les nouveaux étudiants. Et quand ils ont une intuition sur la façon d'écrire les bons programmes, je dis : regardez ces deux implémentations de spinlock : l'une est très lente, et la seconde n'est pas très non plus, mais meilleure. Cependant, mathématiquement, les deux algorithmes sont identiques. En fait, l’un d’eux utilise la localité du cache. L'un d'eux s'exécute sur des données mises en cache localement et l'autre effectue des opérations de manière répétée sur le bus. Vous ne pouvez pas écrire de code efficace si vous ne comprenez pas de quoi il s’agit et si vous ne savez pas comment briser l’abstraction et examiner la structure sous-jacente. Mais vous ne pourrez pas commencer à le faire tout de suite. Il y a des gens qui commencent tout de suite à faire ça et croient en leur propre génie, généralement ça finit mal parce qu'ils ne comprennent pas les principes. Personne ne dessine comme Picasso ou n'écrit des programmes comme Doug Lee fraîchement sorti de l'université dès sa première semaine. Il faut des années pour atteindre ce niveau de connaissance.

Alexeï : Il s'avère que vous divisez le problème en deux parties : la première est l'exactitude, la seconde est la performance ?

Maurice : Exactement. Et exactement dans cet ordre. Une partie du problème vient du fait que les nouveaux étudiants ne comprennent pas qu’il est difficile d’obtenir l’exactitude. À première vue, ils disent : c'est évidemment correct, il ne reste plus qu'à accélérer. Alors parfois, je leur parle d’un algorithme initialement incorrect comme s’il était correct.

Comment apprendre aux étudiants à écrire du code multithread complexe

Alexey : Juste pour voir s'ils peuvent sentir le piège ?

Maurice : Je préviens toujours à l'avance que parfois je proposerai des algorithmes incorrects. Il ne faut pas tromper les gens. Je suggère qu'ils prennent l'information avec des pincettes. Si je dis quelque chose et que je dis : « écoutez, c'est évidemment correct » - c'est le signal que quelque part ils essaient de vous tromper, et vous devriez commencer à poser des questions. Ensuite, j’essaie d’encourager les élèves à continuer à poser des questions, puis je suggère : « Que se passera-t-il si nous laissons les choses telles qu’elles sont ? » Et ils voient immédiatement l’erreur. Mais convaincre les étudiants qu’ils doivent se soucier de l’exactitude est beaucoup plus difficile qu’il n’y paraît à première vue. Beaucoup de ces étudiants ont acquis une expérience en programmation au lycée, certains ont trouvé un emploi et y ont fait de la programmation, et ils débordent tous de confiance. C'est un peu comme l'armée : il faut d'abord changer leur humeur afin de les convaincre d'aborder patiemment la résolution des problèmes qui se posent. Ou peut-être que c'est comme les moines bouddhistes : ils apprennent d'abord à raisonner sur l'exactitude, et une fois qu'ils comprennent les façons de raisonner sur l'exactitude, ils sont autorisés à passer au niveau suivant et à commencer à se soucier de la performance.

Alexeï : Autrement dit, vous montrez parfois aux étudiants des exemples non fonctionnels, grâce auxquels vous obtenez des commentaires indiquant s'ils comprennent l'essence du problème, s'ils peuvent trouver le mauvais code et le mauvais résultat. Alors, est-ce que les étudiants vous rendent généralement heureux ou triste ?

Maurice : Les étudiants finissent presque toujours par trouver l'erreur. S'ils cherchent trop lentement, je pose des questions suggestives, et ici il est important de comprendre que si vous ne les trompez jamais, ils commenceront à percevoir inconsidérément vos paroles comme la vérité ultime. Ensuite, ils s’ennuieront et commenceront à s’endormir en lisant Facebook sur leur ordinateur portable pendant les cours. Mais lorsque vous leur dites à l'avance qu'ils seront trompés et qu'ils auront l'air stupides s'ils ne sentent pas une tromperie, ils deviennent beaucoup plus vigilants. C'est bien de différentes manières. J’aimerais que les élèves remettent en question non seulement leur compréhension de la question, mais aussi l’autorité de l’enseignant. L’idée est qu’un élève puisse lever la main à tout moment et dire : je pense que ce que vous venez de dire est faux. C'est un outil d'apprentissage important. Je ne veux pas qu’aucun des étudiants s’assoie et réfléchisse en silence : tout cela semble complètement absurde, mais lever la main est trop effrayant, et de toute façon, c’est un professeur, donc tout ce qu’il dit est la vérité. Par conséquent, s’ils sont prévenus à l’avance que tout ce qui est dit n’est pas nécessairement vrai, ils sont incités à accorder plus d’attention au contenu. Je précise clairement que vous pouvez lever la main et poser des questions. Votre question peut paraître stupide ou naïve, mais c’est souvent ainsi que surgissent les meilleures questions.

Alexeï : Très intéressant. Habituellement, les gens ont une sorte de barrière psychologique qui ne leur permet pas de poser une question à un professeur. Surtout s'il y a beaucoup de monde dans la salle et que tout le monde a peur que discuter de votre question stupide prenne tout leur temps. Existe-t-il des astuces pour gérer cela ?

Maurice : Je m'arrête souvent et pose des questions classiques. Si une déclaration serait correcte ou comment ils résoudraient le problème discuté. C’est une action clé, surtout au début d’un cours, lorsque les gens sont gênés de dire la moindre chose. Vous posez une question aux étudiants et ne dites rien de plus. Il y a le silence, tout le monde se tend un peu, la tension monte, puis soudain quelqu'un n'en peut plus, s'effondre et dit la réponse. C’est ainsi que l’on renverse la situation : continuer à se taire devient plus difficile et plus gênant que de répondre ! C'est une astuce pédagogique standard. Tous les enseignants du monde devraient savoir comment procéder.

Alexeï : Nous avons maintenant un excellent titre pour cette interview : « il est plus facile de répondre que de se taire ».

Vitaly : Laissez-moi vous demander à nouveau. Vous travaillez sur des preuves topologiques. Comment vous êtes-vous impliqué là-dedans, car l’informatique distribuée et la topologie sont des choses complètement différentes !

Maurice : Il y a là un lien caché. Quand j'étais étudiant en mathématiques, j'étudiais les mathématiques pures. Je n'avais pas vraiment d'intérêt pour l'informatique jusqu'à la fin de mes études et je me suis retrouvée confrontée au besoin pressant de chercher un emploi. En tant qu'étudiant, j'ai étudié la topologie algébrique. Plusieurs années plus tard, alors que je travaillais sur un problème appelé "Problème d'accord k-Set", j'ai utilisé des graphiques pour modéliser le problème et, comme il semblait à l'époque, j'avais trouvé une solution. Il suffisait de s'asseoir et de faire le tour du décompte. Essayez de trouver une réponse appropriée sur ce graphique. Mais mon algorithme n’a pas fonctionné : il s’est avéré qu’il tournerait en rond pour toujours. Malheureusement, tout cela ne peut pas être expliqué dans le langage formel de la théorie des graphes, celui que connaissent tous les informaticiens. Et puis je me suis souvenu qu'il y a de nombreuses années, en cours de topologie, nous utilisions le concept "complexe simplicial", qui est une généralisation des graphiques à des dimensions supérieures. Puis je me suis demandé : que se passerait-il si on reformulait le problème en termes de complexes simpliciaux ? C’est devenu le moment clé. En utilisant un formalisme plus puissant, le problème devient soudainement beaucoup plus simple. Les gens ont longtemps lutté contre cela, en utilisant des graphiques, mais ils n’ont rien pu faire. Et même maintenant, ils ne le peuvent pas - la bonne réponse s'est avérée n'être pas un algorithme, mais une preuve de l'impossibilité de résoudre le problème. Autrement dit, un tel algorithme n’existe tout simplement pas. Mais toutes les preuves d'impossibilité basés soit sur des complexes simpliciaux, soit sur des choses que les gens prétendaient ne pas considérer comme des complexes simpliciaux. Ce n’est pas parce que vous donnez à quelque chose un nouveau nom qu’il perd son essence.

Vitaly : Il s'avère que vous avez juste eu de la chance ?

Maurice : Outre la chance, c'est aussi préparation. Cela signifie que vous ne devez pas oublier les choses « inutiles » que vous avez apprises plus tôt. Plus vous apprenez de choses inutiles, plus vous pouvez extraire d’idées face à un nouveau problème. Ce type de correspondance de modèles intuitif est important parce que... Faisons-le, c'est une chaîne : au début j'ai découvert que les graphiques ne fonctionnaient pas du tout ou ne fonctionnaient pas du tout, cela m'a rappelé quelque chose des événements de huit il y a des années et mes années d'étudiant, lorsque nous étudiions tous ces complexes simpliciaux. Cela m'a permis de retrouver mon ancien manuel de topologie et de le recharger dans ma tête. Mais sans ces anciennes connaissances, je n’aurais jamais progressé dans la résolution du problème initial.

Nouvelle édition du livre « The Art of Multiprocessor Programming »

Alexey : Vous avez dit quelques mots sur votre livre. Ce n'est probablement pas le pire secret que vous ayez écrit le livre le plus célèbre au monde sur le multithreading, "L'art de la programmation multiprocesseur". Il a déjà environ 11 ans et depuis, il n'est sorti que  réimpression révisée. Y aura-t-il une deuxième édition ?

Maurice : C'est bien que tu aies demandé ! Ce sera très bientôt, dans trois mois environ. Il y a deux autres auteurs, nous avons ajouté beaucoup plus de matériel, amélioré la section sur le parallélisme fork/join, écrit une section sur MapReduce, ajouté beaucoup de nouvelles choses et supprimé les choses inutiles - quelque chose qui était très intéressant au moment de la rédaction la première édition, mais n'est plus là aujourd'hui. Le résultat fut un livre très sérieusement révisé.

Alexeï : Tout a déjà été fait, il ne reste plus qu'à le sortir ?

Maurice : Quelques chapitres nécessitent encore du travail. Notre éditeur (qui, je pense, nous déteste déjà) essaie toujours de faire passer le message selon lequel nous devrions travailler plus vite. Nous sommes très en retard sur le calendrier. Théoriquement, nous aurions pu réaliser ce livre quelques années plus tôt.

Alexey : Y a-t-il une chance d'obtenir une nouvelle version du livre avant Noël ?

Maurice : C'est notre objectif ! Mais j'ai prédit la victoire tellement de fois que plus personne ne me croit. Vous ne devriez probablement pas non plus trop me faire confiance dans cette affaire.

Alexeï : En tout cas, c'est une nouvelle fantastique. J'ai beaucoup aimé la première édition du livre. On pourrait dire que je suis fan.

Maurice : J'espère que la nouvelle édition sera à la hauteur de votre fervent enthousiasme, merci !

Comment la mémoire transactionnelle a été inventée

Vitaly : La question suivante concerne la mémoire transactionnelle. D'après ce que je comprends, vous êtes un pionnier dans ce domaine, vous l'avez inventé à une époque où personne ne pensait à de telles choses. Pourquoi avez-vous décidé de vous lancer dans ce domaine ? Pourquoi les transactions vous semblaient-elles importantes ? Pensiez-vous qu'un jour ils seraient implémentés dans le matériel ?

Maurice : Je connais les transactions depuis mes années de recherche universitaire.

Vitaly : Oui, mais ce sont des transactions différentes !

Maurice : J'ai travaillé avec Elliott Moss sur la collecte des déchets non bloquante. Notre problème était que nous voulions modifier atomiquement quelques mots en mémoire et que les algorithmes deviendraient alors très simples, et au moins certains d'entre eux deviendraient plus efficaces. En utilisant comparer et échanger pour load-link/magasin-conditionnelGrâce à l'architecture parallèle, il est possible de faire quelque chose, mais c'est très inefficace et moche car il faudrait gérer des couches d'indirection. Je veux changer les mots de mémoire et je dois changer car je ne peux changer qu'un seul pointeur, ils doivent donc pointer vers une sorte de structure de type répertoire. Nous avons dit à quel point ce serait génial si nous pouvions changer le matériel pour qu'il puisse effectuer un enregistrement simultané. Elliott semble l'avoir remarqué : si vous regardez les protocoles de cohérence du cache, ils fournissent déjà la plupart des fonctionnalités requises. Dans une transaction optimiste, le protocole de cohérence du cache remarquera qu'il y a un conflit de synchronisation et le cache deviendra invalide. Que se passe-t-il si vous exécutez de manière spéculative une transaction sur votre cache et utilisez les mécanismes du protocole de cohérence pour détecter les conflits ? L'architecture matérielle spéculative était facile à concevoir. Nous avons donc écrit celui-là la toute première publication sur la mémoire transactionnelle. Au même moment, la société pour laquelle je travaillais, Digital Equipment Corporation, créait un nouveau processeur 64 bits appelé Alpha. Je suis donc allé faire une présentation au groupe de développement Alpha sur notre incroyable mémoire transactionnelle et ils ont demandé : combien de revenus supplémentaires notre entreprise obtiendrait-elle si nous ajoutions tout cela directement au processeur ? Et je n'avais absolument aucune réponse à cela, car je suis un technologue, je ne suis pas un spécialiste du marketing. Je n'avais vraiment rien à répondre. Ils n’étaient pas très impressionnés par le fait que je ne sache rien.

Vitaly : Des milliards ! Dites simplement des milliards !

Maurice : Oui, c'est ce que j'aurais dû dire. Maintenant, à l’ère des startups et tout, je sais rédiger un business plan. Que vous pouvez mentir un peu sur l’ampleur de votre profit potentiel. Mais à l’époque, cela semblait naïf, alors j’ai simplement dit : « Je ne sais pas ». Si vous regardez l'historique de la publication sur la mémoire transactionnelle, vous remarquerez qu'au bout d'un an, il y a eu plusieurs références à celle-ci, puis pendant une dizaine d'années, personne n'a cité cet article du tout. Les citations sont apparues vers 2004, lorsque de véritables multicœurs sont apparus. Lorsque les gens ont découvert qu’écrire du code parallèle pouvait rapporter de l’argent, de nouvelles recherches ont commencé. Ravi Rajwar a écrit un article, qui a en quelque sorte introduit le concept de mémoire transactionnelle au grand public. (NDLR : Il existe une deuxième version de cet article, sortie en 2010 et disponible gratuitement en PDF). Tout à coup, les gens ont réalisé exactement comment tout cela pouvait être utilisé, comment les algorithmes traditionnels dotés de verrous pouvaient être accélérés. Un bon exemple de quelque chose qui, dans le passé, semblait n’être qu’un problème académique intéressant. Et oui, si vous m'aviez demandé à ce moment-là si je pensais que tout cela serait important à l'avenir, j'aurais répondu : bien sûr, mais quand exactement, ce n'est pas clair. Peut-être dans 50 ans ? En pratique, cela n’a duré qu’une décennie. C'est très agréable quand on fait quelque chose et qu'après dix ans seulement, les gens le remarquent.

Pourquoi cela vaut-il la peine de mener des recherches dans le domaine de l'informatique distribuée

Vitaly : Si nous parlons de nouvelles recherches, que conseilleriez-vous aux lecteurs : informatique distribuée ou multicœur et pourquoi ? 

Maurice : De nos jours, il est facile d'obtenir un processeur multicœur, mais il est plus difficile de mettre en place un véritable système distribué. J'ai commencé à travailler dessus parce que je voulais faire quelque chose de différent de ma thèse de doctorat. C’est le conseil que je donne toujours aux nouveaux étudiants : n’écrivez pas une suite de votre mémoire, essayez d’aller dans une nouvelle direction. Et aussi, le multithreading est simple. Je peux expérimenter avec mon propre fork fonctionnant sur mon ordinateur portable sans sortir du lit. Mais si je voulais soudainement créer un véritable système distribué, je devrais faire beaucoup de travail, attirer des étudiants, etc. Je suis une personne paresseuse et je préfère travailler sur le multicœur. Expérimenter sur des systèmes multicœurs est également plus facile que de faire des expériences sur des systèmes distribués, car même dans un système distribué stupide, il y a trop de facteurs à contrôler.

Vitaly : Que faites-vous maintenant, en faisant des recherches sur la blockchain ? À quels articles faut-il prêter attention en premier ?

Maurice : Récemment paru très bon article, que j'ai écrit avec mon élève Vikram Saraf, spécialement pour une conférence à Conférence Tokenomcs à Paris il y a trois semaines. Il s'agit d'un article sur les systèmes distribués pratiques, dans lequel nous proposons de rendre Ethereum multithread. Actuellement, les contrats intelligents (code qui s'exécute sur la blockchain) sont exécutés de manière séquentielle. Nous avons écrit un article plus tôt qui parlait d'un moyen d'utiliser les transactions spéculatives pour accélérer le processus. Nous avons pris beaucoup d'idées de la mémoire transactionnelle logicielle et avons dit que si vous intégrez ces idées à la machine virtuelle Etherium, tout fonctionnera plus rapidement. Mais pour cela, il faut qu’il n’y ait pas de conflits de données dans les contrats. Et puis nous avons supposé que dans la vraie vie, de tels conflits n’existaient pas. Mais nous n'avions aucun moyen de le savoir. Ensuite, nous avons réalisé que nous avions près d’une décennie d’historique de contrats réels entre nos mains. Nous avons donc abandonné la blockchain Ethereum et nous sommes demandé : que se passerait-il si ces enregistrements historiques étaient exécutés en parallèle ? Nous avons constaté une augmentation significative de la vitesse. Au début d'Ethereum, la vitesse a beaucoup augmenté, mais aujourd'hui, tout est un peu plus compliqué, car il y a moins de contrats et la probabilité de conflits sur les données nécessitant une sérialisation est devenue plus élevée. Mais tout cela est un travail expérimental avec des données historiques réelles. L’avantage de la blockchain est qu’elle se souvient de tout pour toujours, ce qui nous permet de remonter le temps et d’étudier ce qui se serait passé si nous avions utilisé différents algorithmes pour exécuter le code. Dans quelle mesure les gens du passé auraient-ils apprécié notre nouvelle idée ? Une telle recherche est beaucoup plus facile et agréable à faire, car il existe une chose qui surveille tout et enregistre tout. Cela ressemble déjà plus à de la sociologie qu’au développement d’algorithmes.

Le développement des algorithmes s’est-il arrêté et comment continuer ?

Vitaly : C'est l'heure de la dernière question théorique ! Avez-vous l’impression que les progrès dans les structures de données compétitives diminuent chaque année ? Pensez-vous que nous avons atteint un plateau dans notre compréhension des structures de données ou y aura-t-il des améliorations majeures ? Peut-être existe-t-il des idées astucieuses qui peuvent tout changer complètement ?

Maurice : Nous avons peut-être atteint un plateau dans les structures de données pour les architectures traditionnelles. Mais les structures de données pour les nouvelles architectures restent un domaine très prometteur. Si vous souhaitez créer des structures de données pour, par exemple, des accélérateurs matériels, les structures de données d'un GPU sont très différentes de celles d'un CPU. Lorsque vous développez des structures de données pour les blockchains, vous devez hacher des éléments de données, puis les placer dans quelque chose comme Arbre Merkle, pour prévenir la contrefaçon. Il y a eu un regain d'activité dans ce domaine ces derniers temps, et beaucoup font du très bon travail. Mais je pense que ce qui va se passer, c’est que de nouvelles architectures et de nouvelles applications mèneront à de nouvelles structures de données. Applications héritées et architecture traditionnelle : il n'y a peut-être plus beaucoup de place pour l'exploration. Mais si vous sortez des sentiers battus et regardez au-delà des limites, vous verrez des choses folles que le grand public ne prend pas au sérieux - c'est là que toutes les choses passionnantes se produisent vraiment.

Vitaly : Donc, pour être un chercheur très célèbre, j'ai dû inventer ma propre architecture :)

Maurice : Vous pouvez « voler » la nouvelle architecture de quelqu'un d'autre – cela semble beaucoup plus simple !

Travailler à l'Université Brown

Vitaly : Pourriez-vous nous en dire plus sur Université BrownOù travaillez-vous? On ne sait pas grand-chose de lui dans le contexte des technologies de l’information. Moins qu'au MIT, par exemple.

Maurice : L'Université Brown est l'une des plus anciennes universités des États-Unis. Je pense que seule Harvard est un peu plus âgée. Brown fait partie de ce qu'on appelle Ivy Ligue, qui est un ensemble de huit universités les plus anciennes. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvanie, Princeton. C'est une sorte d'université ancienne, petite et un peu aristocratique. L'accent principal est mis sur l'enseignement des arts libéraux. Il ne s'agit pas de ressembler au MIT, le MIT est très spécialisé et technique. Brown est un endroit idéal pour étudier la littérature russe ou le grec classique et, bien sûr, l'informatique. Il se concentre sur une éducation globale. La plupart de nos étudiants fréquentent Facebook, Apple, Google. Je pense donc que nos étudiants n'ont aucun problème à trouver un emploi dans l'industrie. Je suis allé travailler chez Brown parce que j'avais auparavant travaillé chez Digital Equipment Corporation à Boston. C’était une entreprise qui a inventé beaucoup de choses intéressantes, mais qui niait l’importance des ordinateurs personnels. Une entreprise au destin difficile, dont les fondateurs étaient autrefois de jeunes révolutionnaires, qui n’ont rien appris et n’ont rien oublié, et sont ainsi passés de révolutionnaires à réactionnaires en une douzaine d’années environ. Ils aimaient plaisanter en disant que la place des ordinateurs personnels se trouvait dans le garage – un garage abandonné, bien sûr. Il est bien évident qu’elles ont été détruites par des entreprises plus flexibles. Lorsqu'il est devenu clair que l'entreprise était en difficulté, j'ai appelé un de mes amis à Brown, à environ une heure de Boston. Je ne voulais pas quitter Boston à cette époque car il n'y avait pas beaucoup de débouchés dans d'autres universités. C’était une époque où il n’y avait pas autant d’emplois en informatique qu’aujourd’hui. Et Brown avait une ouverture, je n'ai pas eu à déménager ma maison, je n'ai pas eu à déménager ma famille et j'aime vraiment vivre à Boston ! C'est comme ça que j'ai décidé d'aller à Brown. J'aime ça. Les étudiants sont formidables, donc je n’ai même jamais essayé d’aller ailleurs. Pendant mon congé sabbatique, j’ai travaillé chez Microsoft pendant un an, je suis allé au Technion à Haïfa pendant un an, et maintenant je serai à Algorand. J'ai de nombreux collègues partout et donc l'emplacement physique de nos salles de classe n'est pas si important. Mais le plus important, ce sont les étudiants, ils sont les meilleurs ici. Je n'ai jamais essayé d'aller ailleurs parce que je suis plutôt heureux ici.

Pourtant, malgré sa renommée aux États-Unis, il est étonnamment inconnu à l'étranger. Comme vous pouvez le constater, je fais désormais tout mon possible pour corriger cet état de fait.

Différence entre la recherche dans une université et au sein d'une entreprise

Vitaly : D'accord, la question suivante concerne l'équipement numérique. Vous étiez là en tant que chercheur. Quelle est la différence entre travailler dans le département R&D d’une grande entreprise et travailler dans une université ? Quels sont les avantages et les inconvénients?

Maurice : J'ai travaillé pendant vingt ans chez Microsoft, en étroite collaboration avec des employés de Sun Microsystems, Oracle, Facebook et maintenant Algorand. Sur la base de tout cela, je tiens à dire qu'il est possible de mener des recherches de premier ordre tant dans les entreprises que dans les universités. La différence importante est que dans une entreprise, vous travaillez avec des collègues. Si j’ai soudain une idée pour un projet qui n’existe pas encore, je dois convaincre mes pairs que c’est une bonne idée. Si je suis à Brown, alors je peux dire à mes étudiants : travaillons sur l'antigravité ! Soit ils partiront pour quelqu'un d'autre, soit ils se lanceront dans un projet. Oui, je devrai trouver des financements, je devrai rédiger une demande de subvention, etc. Dans tous les cas, il y aura toujours beaucoup d’étudiants et vous pourrez prendre des décisions unilatéralement. Mais à l’université, vous ne travaillerez probablement pas avec des personnes de votre niveau. Dans le monde de la recherche industrielle, il faut d’abord convaincre tout le monde que votre projet vaut la peine d’être entrepris. Je ne peux rien commander à personne. Et ces deux façons de travailler sont précieuses, car si vous travaillez sur quelque chose de vraiment fou et que vos collègues sont difficiles à convaincre, il est plus facile de convaincre les étudiants diplômés, surtout si vous les payez. Si vous travaillez sur quelque chose qui nécessite beaucoup d'expérience et une expertise approfondie, alors vous avez besoin de collègues qui peuvent dire « non, il se trouve que je comprends dans ce domaine et que votre idée est mauvaise, ça ne marchera pas ». C’est très utile en termes de perte de temps. De plus, si dans les laboratoires industriels vous passez beaucoup de temps à rédiger des rapports, alors dans une université vous passez ce temps à essayer de trouver de l'argent. Si je veux que les étudiants puissent aller quelque part, je dois trouver l’argent ailleurs. Et plus votre poste à l’université est important, plus vous devez consacrer du temps à collecter de l’argent. Alors maintenant, vous savez pour quoi je travaille : un mendiant professionnel ! Comme un de ces moines qui se promènent avec une assiette d'offrandes. En général, ces deux activités se complètent. C'est pourquoi j'essaie de vivre et de garder les pieds sur terre dans les deux mondes.

Vitaly : Il semble qu'il soit plus difficile de convaincre une entreprise que de convaincre d'autres scientifiques.

Maurice : Plus difficile, et bien plus encore. De plus, selon les domaines, c'est différent : certains mènent des recherches à grande échelle, tandis que d'autres se concentrent sur leur sujet. Si j'allais voir Microsoft ou Facebook et disais : faisons de l'anti-gravité, ils ne l'apprécieraient guère. Mais si je disais exactement la même chose à mes étudiants diplômés, ils se mettraient probablement au travail instantanément, même si maintenant j'aurais des problèmes - après tout, j'ai besoin de trouver de l'argent pour cela. Mais tant que vous souhaitez faire quelque chose qui correspond aux objectifs de l’entreprise, cette entreprise peut être un très bon endroit pour faire de la recherche.

Hydra et SPTDC

Vitaly : Mes questions touchent à leur fin, parlons donc un peu du prochain voyage en Russie.

Maurice : Oui, j'ai hâte de retourner à Saint-Pétersbourg.

Alexey : Je suis honoré de vous avoir parmi nous cette année. C'est votre deuxième séjour à Saint-Pétersbourg, n'est-ce pas ?

Maurice : Déjà le troisième !

Alexeï : Je comprends, mais SPTDC – certainement le deuxième. La dernière fois que l'école a été appelée SPTCC, nous avons maintenant modifié une lettre (C à D, Concurrent to Distributed) pour souligner qu'il existe davantage de domaines liés spécifiquement à l'informatique distribuée cette année. Pouvez-vous dire quelques mots sur vos rapports à l'Ecole et Conférence Hydra?

Maurice : À l'École, je souhaite parler des bases de la blockchain et de ce que l'on peut en faire. Je voudrais montrer que les blockchains sont très similaires à la programmation multithread que nous connaissons, mais avec leurs propres nuances, et ces différences sont importantes à comprendre. Si vous faites une erreur dans une application Web classique, c'est tout simplement ennuyeux. Si vous écrivez du code buggé dans une application financière, quelqu'un volera certainement tout votre argent. Ce sont des niveaux de responsabilité et de conséquences complètement différents. Je parlerai un peu de proof-of-work, de smart contracts, de transactions entre différentes blockchains.

Il y aura d'autres intervenants qui travailleront à côté de moi et qui auront également quelque chose à dire sur la blockchain, et nous avons convenu de nous coordonner afin que nos histoires s'emboîtent bien. Mais pour le rapport d'ingénierie, je veux expliquer à un large public pourquoi vous ne devriez pas croire tout ce que vous entendez sur les blockchains, pourquoi les blockchains sont un domaine formidable, comment elles s'intègrent avec d'autres idées connues et pourquoi nous devrions hardiment regarder au futur.

Alexey : De plus, je tiens à dire que cela ne se déroulera pas sous la forme d'un meetup ou d'un groupe d'utilisateurs, comme c'était le cas il y a deux ans. Nous avons décidé d'organiser une petite conférence près de l'école. La raison en est qu'après avoir communiqué avec Peter Kuznetsov, nous avons réalisé que l'école était limitée à seulement une centaine, voire 120 personnes. Dans le même temps, de nombreux ingénieurs souhaitent communiquer avec vous, assister à des présentations et sont généralement intéressés par le sujet. C'est pour cette raison que nous avons créé une nouvelle conférence appelée Hydra. Au fait, avez-vous une idée du pourquoi d'Hydra ?

Maurice : Parce qu'il y aura sept intervenants ? Et leurs têtes peuvent être coupées, et de nouveaux orateurs grandiront à leur place ?

Alexey : Excellente idée pour développer de nouveaux locuteurs. Mais en fait, il y a une histoire ici. Rappelez-vous la légende d'Ulysse, où il devait naviguer entre Scylla et Charybde? Hydra est quelque chose comme Charybde. L'histoire est qu'une fois, j'ai pris la parole lors d'une conférence et j'ai parlé de multithreading. Il n'y avait que deux pistes lors de cette conférence. Au début du reportage, j'ai dit au public présent dans la salle qu'ils avaient désormais le choix entre Scylla et Charybde. Mon animal spirituel est Charybde car Charybde a plusieurs têtes et mon thème est multithread. C'est ainsi qu'apparaissent les noms des conférences.

De toute façon, nous sommes à court de questions et de temps. Alors merci les amis pour cette excellente interview et rendez-vous à l'école SPTDC et à Hydra 2019 !

Vous pourrez poursuivre votre conversation avec Maurice lors de la conférence Hydra 2019, qui se tiendra les 11 et 12 juillet 2019 à Saint-Pétersbourg. Il viendra avec un rapport "Les blockchains et l'avenir de l'informatique distribuée". Les billets peuvent être achetés sur le site officiel.

Source: habr.com