„Es ist einfacher zu antworten als zu schweigen“ – ein großartiges Interview mit dem Vater des Transaktionsgedächtnisses, Maurice Herlihy

Maurice Herlihy - Besitzer von zwei Dijkstra-Preise. Der erste dient der Bearbeitung „Wartefreie Synchronisierung“ (Brown University) und die zweite, neuere, - „Transaktionaler Speicher: Architekturunterstützung für sperrenfreie Datenstrukturen“ (Virginia Tech University). Der Dijkstra-Preis wird für Arbeiten verliehen, deren Bedeutung und Einfluss seit mindestens zehn Jahren sichtbar ist, und Maurice ist offensichtlich einer der bekanntesten Spezialisten auf diesem Gebiet. Derzeit arbeitet er als Professor an der Brown University und hat zahlreiche Erfolge vorzuweisen, die einen Absatz lang sind. Derzeit erforscht er Blockchain im Kontext des klassischen Distributed Computing.

Zuvor war Maurice bereits für SPTCC nach Russland gekommen (Videoaufnahme) und veranstaltete ein hervorragendes Treffen der JUG.ru-Java-Entwickler-Community in St. Petersburg (Videoaufnahme).

Dieser Habrapost ist ein großartiges Interview mit Maurice Herlihy. Es werden folgende Themen besprochen:

  • Interaktion zwischen Wissenschaft und Industrie;
  • Stiftung für Blockchain-Forschung;
  • Woher kommen bahnbrechende Ideen? Der Einfluss der Popularität;
  • Promotion unter der Leitung von Barbara Liskov;
  • Die Welt wartet auf Multicore;
  • Eine neue Welt bringt neue Probleme mit sich. NVM-, NUMA- und Architektur-Hacking;
  • Compiler vs. Prozessoren, RISC vs. CISC, Shared Memory vs. Message Passing;
  • Die Kunst, fragilen Multithread-Code zu schreiben;
  • Wie man Schülern beibringt, komplexen Multithread-Code zu schreiben;
  • Neuauflage des Buches „The Art of Multiprocessor Programming“;
  • Wie das Transaktionsgedächtnis erfunden wurde;   
  • Warum es sich lohnt, im Bereich Distributed Computing zu forschen;
  • Hat die Entwicklung von Algorithmen aufgehört und wie geht es weiter?
  • Arbeit an der Brown University;
  • Der Unterschied zwischen Forschung an einer Universität und innerhalb eines Unternehmens;
  • Hydra und SPTDC.

Das Interview wird geführt von:

Vitaly Aksenov — derzeit Postdoc am IST Austria und Mitarbeiter des Department of Computer Technologies an der ITMO University. Führt Forschungen auf dem Gebiet der Theorie und Praxis wettbewerbsfähiger Datenstrukturen durch. Bevor er am IST arbeitete, promovierte er an der Universität Paris Diderot und der ITMO-Universität unter der Leitung von Professor Peter Kuznetsov.

Alexey Fedorov - Produzent bei JUG Ru Group, einem russischen Unternehmen, das Konferenzen für Entwickler organisiert. Alexey war an der Vorbereitung von mehr als 50 Konferenzen beteiligt und sein Lebenslauf umfasst alles von der Position eines Entwicklungsingenieurs bei Oracle (JCK, Java Platform Group) bis zur Position eines Entwicklers bei Odnoklassniki.

Wladimir Sitnikow - Ingenieur bei Netcracker. Zehn Jahre Arbeit an der Leistung und Skalierbarkeit von NetCracker OS, einer Software, die von Telekommunikationsbetreibern zur Automatisierung von Netzwerk- und Netzwerkgeräteverwaltungsprozessen verwendet wird. Interessiert an Leistungsproblemen bei Java- und Oracle-Datenbanken. Autor von mehr als einem Dutzend Leistungsverbesserungen im offiziellen PostgreSQL-JDBC-Treiber.

Interaktion zwischen Wissenschaft und Industrie

Alexey: Maurice, Sie haben sehr lange in einem akademischen Umfeld gearbeitet und die erste Frage ist die Interaktion zwischen der akademischen und der industriellen Sphäre. Könnten Sie darüber sprechen, wie sich die Interaktionen zwischen ihnen in letzter Zeit verändert haben? Was ist vor 20-30 Jahren passiert und was passiert jetzt? 

Maurice: Ich habe immer versucht, eng mit kommerziellen Unternehmen zusammenzuarbeiten, weil sie interessante Probleme haben. Sie haben in der Regel kein großes Interesse daran, ihre Ergebnisse zu veröffentlichen oder der Weltgemeinschaft ihre Probleme ausführlich zu erklären. Sie sind nur daran interessiert, diese Probleme zu lösen. Ich habe einige Zeit für solche Unternehmen gearbeitet. Ich habe fünf Jahre lang Vollzeit in einem Forschungslabor bei Digital Equipment Corporation gearbeitet, einem ehemaligen großen Computerunternehmen. Ich habe einen Tag in der Woche bei Sun, bei Microsoft, bei Oracle gearbeitet und ein wenig bei Facebook gearbeitet. Jetzt werde ich in einen Forschungsurlaub gehen (ein Professor an einer amerikanischen Universität darf etwa alle sechs Jahre einen solchen Urlaub für ein Jahr nehmen) und dort arbeiten Algorand, das ist ein Kryptowährungsunternehmen in Boston. Die enge Zusammenarbeit mit Unternehmen war schon immer eine Freude, denn so lernt man Neues und Interessantes kennen. Möglicherweise sind Sie sogar die erste oder zweite Person, die einen Artikel zu einem ausgewählten Thema veröffentlicht, anstatt an der schrittweisen Verbesserung von Lösungen für Probleme zu arbeiten, an denen alle anderen bereits arbeiten.

Alexey: Können Sie uns genauer erzählen, wie das passiert?

Maurice: Natürlich. Wissen Sie, als ich bei der Digital Equipment Corporation arbeitete, haben ich und Elliot Moss das Transaktionsgedächtnis erfunden. Es war eine sehr fruchtbare Zeit, in der sich jeder für die Informationstechnologie zu interessieren begann. Parallelität inklusive, obwohl es Multicore-Systeme noch nicht gab. Während der Sun- und Oracle-Zeit habe ich viel an parallelen Datenstrukturen gearbeitet. Bei Facebook habe ich an ihrem Blockchain-Projekt gearbeitet, über das ich nicht sprechen kann, aber ich hoffe, dass es bald an die Öffentlichkeit geht. Nächstes Jahr werde ich bei Algorand in einer Forschungsgruppe arbeiten, die sich mit intelligenten Verträgen befasst.

Alexey: Blockchain ist in den letzten Jahren zu einem sehr beliebten Thema geworden. Wird dies Ihrer Forschung helfen? Vielleicht wird es dadurch einfacher, Zuschüsse zu erhalten oder Zugang zu Ressourcen von Unternehmen zu erhalten, die in der Branche tätig sind?

Maurice: Ich habe bereits einen kleinen Zuschuss von der Ethereum Foundation erhalten. Die Popularität der Blockchain ist sehr hilfreich, um Studierende für die Arbeit in diesem Bereich zu inspirieren. Sie interessieren sich sehr dafür und freuen sich darauf, sich zu engagieren, aber manchmal ist ihnen nicht bewusst, dass die Forschung, die nach außen hin spannend klingt, sich als wirklich harte Arbeit herausstellt. Ich freue mich jedoch sehr, all diese Mystik rund um die Blockchain zu nutzen, um dabei zu helfen, Studenten anzulocken. 

Aber das ist noch nicht alles. Ich bin im Beirat mehrerer Blockchain-Startups. Einige von ihnen mögen Erfolg haben, andere vielleicht nicht, aber es ist immer sehr interessant, ihre Ideen zu sehen, sie zu studieren und Menschen zu beraten. Das Aufregendste ist, wenn man die Leute davor warnt, etwas zu tun. Viele Dinge scheinen zunächst eine gute Idee zu sein, aber sind sie es wirklich?

Stiftung für Blockchain-Forschung

Vitaly: Manche Leute denken, dass die Zukunft in der Blockchain und ihren Algorithmen liegt. Und andere sagen, es sei nur eine weitere Blase. Können Sie uns Ihre Meinung zu diesem Thema mitteilen?

Maurice: Vieles, was in der Blockchain-Welt vor sich geht, ist falsch, manches ist nur Betrug, vieles wird überbewertet. Ich denke jedoch, dass es für diese Studien eine solide wissenschaftliche Grundlage gibt. Die Tatsache, dass die Blockchain-Welt voller ideologischer Unterschiede ist, zeigt das Ausmaß der Begeisterung und des Engagements. Andererseits ist dies für die wissenschaftliche Forschung nicht besonders vorteilhaft. Wenn Sie nun einen Artikel veröffentlichen, der über die Mängel eines bestimmten Algorithmus spricht, ist die daraus resultierende Reaktion nicht immer vollständig wissenschaftlich. Oft werfen Menschen ihre Gefühle raus. Ich denke, dass diese Art von Aufregung in diesem Bereich für manche attraktiv erscheinen mag, aber letztendlich gibt es echte wissenschaftliche und technische Probleme, die angegangen werden müssen. Hier gibt es viel Informatik.

Vitaly: Sie versuchen also, den Grundstein für die Blockchain-Forschung zu legen, oder?

Maurice: Ich versuche, den Grundstein für eine solide, wissenschaftlich und mathematisch fundierte Disziplin zu legen. Und ein Teil des Problems besteht darin, dass man manchmal den übermäßig harten Positionen anderer Menschen widersprechen und sie ignorieren muss. Manchmal fragen mich die Leute, warum ich in einem Bereich arbeite, der nur für Terroristen und Drogenhändler von Interesse ist. Eine solche Reaktion ist ebenso bedeutungslos wie das Verhalten von Followern, die Ihre Worte blind wiederholen. Ich denke, die Wahrheit liegt irgendwo in der Mitte. Blockchain wird tiefgreifende Auswirkungen auf die Gesellschaft und die Weltwirtschaft haben. Aber das wird dank moderner Technologie wahrscheinlich nicht passieren. Moderne Technologien werden sich weiterentwickeln und die sogenannte Blockchain wird in Zukunft sehr wichtig werden. Es sieht vielleicht nicht einmal nach modernen Blockchains aus, das ist eine offene Frage.

Wenn Menschen neue Technologien erfinden, werden sie sie weiterhin Blockchain nennen. Ich meine, genau wie das heutige Fortran nichts mit der Fortran-Sprache aus den 1960er Jahren zu tun hat, aber jeder nennt es weiterhin Fortran. Das Gleiche gilt für UNIX. Was „Blockchain“ genannt wird, wird noch seine Revolution erleben. Aber ich bezweifle, dass diese neue Blockchain auch nur annähernd das sein wird, was heute jeder gerne nutzt.

Woher kommen bahnbrechende Ideen? Einfluss der Popularität

Alexey: Hat die Popularität der Blockchain aus wissenschaftlicher Sicht zu neuen Ergebnissen geführt? Mehr Interaktion, mehr Studenten, mehr Unternehmen in der Region. Gibt es bereits Ergebnisse aus dieser Popularitätssteigerung?

Maurice: Ich wurde dafür interessiert, als mir jemand einen offiziellen Flyer für ein Unternehmen überreichte, das gerade eine Menge Geld gesammelt hatte. Es wurde darüber geschrieben Aufgabe der byzantinischen Generäle, mit dem ich mehr als vertraut bin. Was in der Broschüre stand, war eindeutig technisch falsch. Die Leute, die das alles geschrieben haben, haben das Modell hinter dem Problem nicht wirklich verstanden ... und dennoch hat dieses Unternehmen eine Menge Geld gesammelt. Anschließend ersetzte das Unternehmen diese Broschüre stillschweigend durch eine viel korrektere Version – und ich werde nicht sagen, wie der Name dieses Unternehmens lautete. Sie sind immer noch da und es geht ihnen sehr gut. Dieser Vorfall hat mich überzeugt, dass Blockchain erstens einfach eine Form des verteilten Rechnens ist. Zweitens war die Eintrittsschwelle (zumindest damals, vor vier Jahren) recht niedrig. Die auf diesem Gebiet tätigen Menschen waren sehr energisch und intelligent, lasen jedoch keine wissenschaftlichen Arbeiten. Sie haben versucht, Bekanntes neu zu erfinden und haben es falsch gemacht. Heute hat das Drama nachgelassen.

Alexey: Das ist sehr interessant, denn vor ein paar Jahren hatten wir einen anderen Trend. Es ist ein bisschen wie bei der Front-End-Entwicklung, als browserbasierte Front-End-Entwickler ganze Technologien neu erfanden, die im Back-End bereits beliebt waren: Build-Systeme, kontinuierliche Integration und solche Dinge. 

Maurice: Ich stimme zu. Dies ist jedoch nicht überraschend, da wirklich bahnbrechende Ideen immer von außerhalb der etablierten Gemeinschaft kommen. Es ist unwahrscheinlich, dass etablierte Forscher, insbesondere etablierte Akademiker, etwas wirklich Bahnbrechendes leisten werden. Es ist einfach, für die nächste Konferenz einen Aufsatz darüber zu schreiben, wie Sie die Ergebnisse Ihrer bisherigen Arbeit leicht verbessert haben. Gehen Sie zu einer Konferenz, treffen Sie sich mit Freunden und reden Sie über die gleichen Dinge. Und die Leute, die mit bahnbrechenden Ideen hereinplatzen, kommen fast immer von außen. Sie kennen die Regeln nicht, sie kennen die Sprache nicht, aber trotzdem... Wenn Sie sich in einer etablierten Gemeinschaft befinden, rate ich Ihnen, auf Neues zu achten, auf etwas, das nicht ins Gesamtbild passt. In gewisser Weise kann versucht werden, externe, fließendere Entwicklungen mit Methoden zu kombinieren, die wir bereits verstehen. Versuchen Sie als ersten Schritt, eine wissenschaftliche Grundlage zu schaffen und diese dann so zu ändern, dass sie auf neue bahnbrechende Ideen angewendet werden kann. Ich denke, dass Blockchain großartig ist, weil es eine frische, disruptive Idee ist.

Alexey: Warum passiert das Ihrer Meinung nach? Weil Menschen „draußen“ keine spezifischen Barrieren in der Gemeinschaft haben?

Maurice: Hier gibt es ein Muster. Wenn Sie die Geschichte der Impressionisten in der Malerei und Kunst im Allgemeinen lesen, dann lehnten berühmte Künstler einst den Impressionismus ab. Sie sagten, es sei irgendwie kindisch. Eine Generation später wurde diese zuvor abgelehnte Kunstform zum Standard. Was ich in meinem Bereich sehe: Den Erfindern der Blockchain ging es nicht um Macht, sondern um mehr Veröffentlichungen und Zitierzahlen, sie wollten einfach nur etwas Gutes tun. Und so setzten sie sich hin und begannen damit. Es fehlte ihnen eine gewisse technische Tiefe, aber das lässt sich beheben. Es ist viel schwieriger, neue kreative Ideen zu entwickeln, als unzureichend ausgereifte zu korrigieren und zu stärken. Dank dieser Erfinder habe ich jetzt etwas zu tun!

Alexey: Das ähnelt dem Unterschied zwischen Startups und Legacy-Projekten. Wir erben viele Denkbeschränkungen, Barrieren, besondere Anforderungen usw.

Maurice: Eine gute Analogie ist das verteilte Rechnen. Stellen Sie sich Blockchain als ein Startup und Distributed Computing als ein großes, etabliertes Unternehmen vor. Distributed Computing wird derzeit übernommen und mit der Blockchain verschmolzen.

Promotion unter der Leitung von Barbara Liskov

Vitaly: Wir haben noch viele Fragen! Wir haben uns mit Ihrem Hintergrund befasst und sind auf eine interessante Tatsache zu Ihrer Promotion gestoßen. Ja, das ist schon lange her, aber es scheint ein wichtiges Thema zu sein. Sie haben Ihren Doktortitel unter der Anleitung Ihrer eigenen Person erhalten Barbara Liskov! Barbara ist in der Programmiersprachen-Community sehr bekannt und allgemein eine sehr bekannte Person. Es ist logisch, dass Ihre Forschung im Bereich der Programmiersprachen lag. Wie sind Sie auf Parallelrechnen umgestiegen? Warum haben Sie sich entschieden, das Thema zu wechseln?

Maurice: Damals befassten sich Barbara und ihre Gruppe gerade mit verteiltem Rechnen, was eine sehr neue Idee war. Es gab auch diejenigen, die sagten, verteiltes Rechnen sei Unsinn und Computer, die miteinander kommunizieren, seien sinnlos. Eines der Probleme, mit denen sich das verteilte Computing befasst und das es vom zentralisierten Computing unterscheidet, ist die Fehlertoleranz. Nach langer Recherche kamen wir zu dem Schluss, dass eine Programmiersprache für verteiltes Rechnen so etwas wie atomare Transaktionen benötigen muss, da man nie sicher sein kann, dass ein Remote-Aufruf erfolgreich sein wird. Sobald Sie Transaktionen haben, entsteht das Problem der Parallelitätsverwaltung. Dann wurde viel daran gearbeitet, hochparallele Transaktionsdatenstrukturen zu erhalten. Dann, als ich meinen Abschluss gemacht hatte, ging ich zu Carnegie Mellon und fing an, nach einem Thema zu suchen, an dem ich arbeiten konnte. Mir kam der Gedanke, dass sich die Informatik von einzelnen Computern hin zu Computernetzwerken verlagert hat. Multiprozessoren wären eine natürliche Fortsetzung des Fortschritts – das Wort „Multicore“ gab es noch nicht. Ich dachte: Was entspricht atomaren Transaktionen für ein Multi-Core-System? Auf keinen Fall normale Transaktionen, weil sie zu groß und zu schwer sind. Und so kam ich auf die Idee Linearisierbarkeit und so kam ich auf die ganze wartefreie Synchronisierung. Dies war ein Versuch, die Frage zu beantworten, was das Analogon zu atomaren Transaktionen für ein Multiprozessorsystem mit gemeinsam genutztem Speicher ist. Auf den ersten Blick mag dieses Werk völlig anders aussehen, tatsächlich ist es jedoch eine Fortsetzung des gleichen Themas.

Die Welt wartet auf Multicore

Vitaly: Sie haben erwähnt, dass es damals nur sehr wenige Multicore-Computer gab, oder?

Maurice: Sie waren einfach nicht da. Es gab mehrere sogenannte symmetrische Multiprozessoren, die grundsätzlich an denselben Bus angeschlossen waren. Das funktionierte nicht besonders gut, denn jedes Mal, wenn ein neues Unternehmen etwas Ähnliches entwickelte, brachte Intel einen einzelnen Prozessor heraus, der dem Multiprozessor überlegen war.

Alexey: Bedeutet das nicht, dass es sich in der Antike eher um eine theoretische Studie handelte?

Maurice: Es war keine theoretische Studie, sondern eher eine spekulative Studie. Dabei ging es nicht darum, mit vielen Theoremen zu arbeiten, sondern wir stellten Hypothesen über eine Architektur auf, die es damals noch nicht gab. Dafür ist Forschung da! Kein Unternehmen hätte so etwas getan, es war alles etwas aus ferner Zukunft. Tatsächlich war dies bis 2004 der Fall, als echte Mehrkernprozessoren auf den Markt kamen. Da Prozessoren überhitzen, können Sie den Prozessor noch kleiner, aber nicht schneller machen. Aus diesem Grund erfolgte der Übergang zu Multicore-Architekturen. Und das bedeutete dann plötzlich, dass es für alle Konzepte, die wir in der Vergangenheit entwickelt hatten, einen Nutzen gab.

Alexey: Warum, glauben Sie, tauchten Multicore-Prozessoren erst in den XNUMXer Jahren auf? Warum ist es also so spät?

Maurice: Das liegt an Hardware-Einschränkungen. Intel, AMD und andere Unternehmen sind sehr gut darin, die Prozessorgeschwindigkeit zu steigern. Als irgendwann die Prozessoren so klein wurden, dass sie die Taktrate nicht mehr erhöhen konnten, weil die Prozessoren anfingen auszubrennen. Sie können sie kleiner machen, aber nicht schneller. Was in ihrer Macht steht – statt eines sehr kleinen Prozessors können sie acht, sechzehn oder zweiunddreißig Prozessoren in das gleiche Gehäusevolumen unterbringen, wo bisher nur einer Platz fand. Jetzt haben Sie Multithreading und eine schnelle Kommunikation zwischen ihnen, da sie Caches gemeinsam nutzen. Aber man kann sie nicht dazu zwingen, schneller zu laufen – es gibt ein ganz bestimmtes Tempolimit. Sie verbessern sich nach und nach weiter, aber nicht mehr so ​​sehr. Die Gesetze der Physik standen Verbesserungen im Weg.

Eine neue Welt bringt neue Probleme mit sich. NUMA-, NVM- und Architektur-Hacking

Alexey: Klingt sehr vernünftig. Mit neuen Multicore-Prozessoren kamen neue Probleme. Haben Sie und Ihre Kollegen mit diesen Problemen gerechnet? Vielleicht haben Sie sie vorher studiert? In theoretischen Studien ist es oft nicht ganz einfach, solche Dinge vorherzusagen. Wenn Probleme auftraten, wie haben diese Ihre Erwartungen und die Ihrer Kollegen erfüllt? Oder waren sie völlig neu und Sie und Ihre Kollegen mussten viel Zeit damit verbringen, Probleme zu lösen, sobald sie auftauchten?

Vitaly: Ich füge Alexeys Frage hinzu: Haben Sie die Prozessorarchitektur richtig vorhergesagt, als Sie die Theorie studiert haben?

Maurice: Nicht 100 %. Aber ich denke, meine Kollegen und ich haben bei der Vorhersage von Multi-Cores mit Shared Memory gute Arbeit geleistet. Ich denke, wir haben die Schwierigkeiten bei der Entwicklung paralleler Datenstrukturen, die ohne Sperren funktionieren, richtig vorhergesagt. Solche Datenstrukturen waren für viele Anwendungen wichtig, wenn auch nicht für alle, aber oft braucht man wirklich eine nicht sperrende Datenstruktur. Als wir sie erfunden haben, argumentierten viele, das sei Unsinn, dass mit Schlössern alles gut funktioniere. Wir haben recht gut vorhergesagt, dass es für viele Programmierprobleme und Datenstrukturprobleme fertige Lösungen geben würde. Es gab auch komplexere Probleme, wie z NUMA – ungleichmäßiger Zugriff auf den Speicher. Tatsächlich wurden sie bis zur Erfindung der Multicore-Prozessoren gar nicht erst in Betracht gezogen, weil sie zu spezifisch waren. Die Forschungsgemeinschaft arbeitete an Fragen, die im Allgemeinen vorhersehbar waren. Einige mit bestimmten Architekturen verbundene Hardwareprobleme mussten in den Startlöchern warten – und zwar das Erscheinen dieser Architekturen. Beispielsweise hat niemand wirklich an GPU-spezifischen Datenstrukturen gearbeitet, da GPUs damals noch nicht existierten. Obwohl viel Arbeit geleistet wurde SIMDDiese Algorithmen waren einsatzbereit, sobald geeignete Hardware verfügbar war. Es ist jedoch unmöglich, alles vorherzusehen.

Alexey: Wenn ich das richtig verstehe, ist NUMA eine Art Kompromiss zwischen Kosten, Leistung und einigen anderen Dingen. Irgendwelche Ideen, warum NUMA so spät herauskam?

Maurice: Ich glaube, dass NUMA aufgrund von Problemen mit der Hardware zur Speicherproduktion existiert: Je weiter die Komponenten entfernt sind, desto langsamer ist der Zugriff darauf. Andererseits ist der zweite Wert dieser Abstraktion die Einheitlichkeit des Gedächtnisses. Eines der Merkmale des parallelen Rechnens ist also, dass alle Abstraktionen leicht unterbrochen sind. Wenn der Zugriff vollkommen einheitlich wäre, wäre der gesamte Speicher gleich weit entfernt, aber das ist wirtschaftlich und vielleicht sogar physikalisch unmöglich. Deshalb entsteht dieser Konflikt. Wenn Sie Ihr Programm so schreiben, als ob der Speicher einheitlich wäre, ist es höchstwahrscheinlich korrekt. In dem Sinne, dass es keine falschen Antworten gibt. Aber auch ihr Auftritt wird die Sterne vom Himmel nicht einfangen. Ebenso, wenn Sie schreiben Spinlocks Ohne Verständnis der Cache-Hierarchie ist die Blockierung selbst korrekt, aber Sie können die Leistung vergessen. В каком-то смысле, вы должны писать программы, живущие поверх очень простой абстракции, но вы должны перехитрить людей, которые эту абстракцию вам предоставили: вы обязаны знать, что под абстракцией лежит некая иерархия памяти, что есть шина между вами и этой памятью, usw. Somit besteht ein gewisser Konflikt zwischen individuell nützlichen Abstraktionen, was uns zu sehr konkreten und pragmatischen Problemen führt.

Vitaly: Wie sieht es mit der Zukunft aus? Können Sie vorhersagen, wie sich Prozessoren als nächstes entwickeln werden? Es besteht die Vorstellung, dass eine der Antworten das Transaktionsgedächtnis ist. Sie haben wahrscheinlich noch etwas anderes auf Lager.

Maurice: Vor uns liegen einige große Herausforderungen. Einer davon ist, dass kohärentes Gedächtnis eine wunderbare Abstraktion ist, aber in besonderen Fällen beginnt es zusammenzubrechen. So ist NUMA beispielsweise ein lebendiges Beispiel für etwas, bei dem man weiterhin so tun kann, als ob ein einheitliches Gedächtnis existiert. Eigentlich nein, Produktivität wird Sie zum Weinen bringen. Irgendwann müssen Architekten die Idee einer Single-Memory-Architektur aufgeben; man kann nicht ewig so tun. Es werden neue Programmiermodelle benötigt, die einfach zu bedienen und leistungsstark genug sind, um die zugrunde liegende Hardware effizient zu machen. Dies ist ein sehr schwieriger Kompromiss, denn wenn man Programmierern die Architektur zeigt, die tatsächlich in der Hardware verwendet wird, werden sie verrückt. Es ist zu kompliziert und nicht tragbar. Wenn Sie eine zu einfache Schnittstelle präsentieren, ist die Leistung schlecht. Daher müssen viele sehr schwierige Kompromisse eingegangen werden, um nützliche Programmiermodelle bereitzustellen, die auf wirklich große Mehrkernprozessoren anwendbar sind. Ich bin mir nicht sicher, ob irgendjemand außer einem Spezialisten in der Lage ist, auf einem 2000-Core-Computer zu programmieren. Und es sei denn, Sie beschäftigen sich mit sehr spezialisiertem oder wissenschaftlichem Rechnen oder Kryptographie oder etwas Ähnlichem – es ist immer noch überhaupt nicht klar, wie man es richtig macht. 

Ein weiterer ähnlicher Bereich sind spezialisierte Architekturen. Grafikbeschleuniger gibt es schon seit langem, aber sie sind zu einem klassischen Beispiel dafür geworden, wie man eine spezielle Art von Computern auf einem dedizierten Chip ausführen kann. Dies bringt eigene Herausforderungen mit sich: Wie kommuniziert man mit einem solchen Gerät, wie programmiert man es? Ich habe mich kürzlich mit Problemen in diesem Bereich beschäftigt Near-Memory-Computing. Sie nehmen einen kleinen Prozessor und kleben ihn an einen großen Speicherblock, sodass der Speicher mit L1-Cache-Geschwindigkeit läuft und dann mit einem Gerät wie z. B. kommuniziert TPU – Der Prozessor ist damit beschäftigt, neue Aufgaben in Ihren Speicherkern zu laden. Ein weiteres interessantes Beispiel ist der Entwurf von Datenstrukturen und Kommunikationsprotokollen für solche Dinge. Daher wird es bei benutzerdefinierten Prozessoren und Hardware noch einige Zeit lang Verbesserungen geben.

Alexey: Was ist mit dem nichtflüchtigen Speicher (nichtflüchtiger Speicher)?

Maurice: Oh, das ist ein weiteres tolles Beispiel! NVM wird die Art und Weise, wie wir Dinge wie Datenstrukturen betrachten, stark verändern. In gewisser Weise verspricht der nichtflüchtige Speicher, die Dinge wirklich zu beschleunigen. Aber es wird das Leben nicht einfacher machen, da die meisten Prozessoren, Caches und Register immer noch flüchtig sind. Wenn Sie nach einem Absturz starten, sind Ihr Zustand und der Zustand Ihres Gedächtnisses nicht mehr genau derselbe wie vor dem Absturz. Ich bin den Leuten, die an NVM arbeiten, sehr dankbar – es wird für Forscher noch lange viel zu tun geben, wenn sie versuchen, Korrektheitsbedingungen herauszufinden. Berechnungen sind korrekt, wenn sie einen Absturz überstehen, bei dem der Inhalt von Caches und Registern verloren geht, der Hauptspeicher jedoch intakt bleibt.

Compiler vs. Prozessoren, RISC vs. CISC, Shared Memory vs. Message Passing

Vladimir: Was denken Sie über das Dilemma „Compiler vs. Prozessoren“ aus der Sicht des Befehlssatzes? Lassen Sie es mich für diejenigen erklären, die sich nicht auskennen: Wenn wir auf verzerrten Speicher oder etwas Ähnliches umsteigen, könnten wir einen sehr einfachen Befehlssatz verwenden und den Compiler bitten, komplexen Code zu generieren, der die neuen Vorteile nutzen kann. Oder wir gehen den umgekehrten Weg: Implementieren Sie komplexe Anweisungen und bitten Sie den Prozessor, die Anweisungen neu anzuordnen und andere Manipulationen daran vorzunehmen. Was denkst du darüber?

Maurice: Ich habe keine wirkliche Antwort auf diese Frage. Diese Debatte wird seit vier Jahrzehnten geführt. Es gab eine Zeit dazwischen abgekürzt eine Reihe von Befehlen und komplex Bürgerkriege wurden durch eine Reihe von Kommandos geführt. Eine Zeit lang siegten die RISC-Leute, doch dann baute Intel seine Engines so um, dass intern ein reduzierter Befehlssatz verwendet wurde und der vollständige Satz extern exportiert wurde. Dies ist wahrscheinlich ein Thema, bei dem jede neue Generation ihre eigenen Kompromisse finden und ihre eigenen Entscheidungen treffen muss. Es ist sehr schwer vorherzusagen, welches dieser Dinge besser sein wird. Jede Vorhersage, die ich mache, wird also für eine gewisse Zeit wahr sein, dann wieder für eine Weile falsch und dann wieder wahr.

Alexey: Wie häufig kommt es in der Branche vor, dass einige Ideen mehrere Jahrzehnte lang gewinnen und im nächsten verlieren? Gibt es andere Beispiele für solche periodischen Veränderungen?

Maurice: Beim Thema verteiltes Rechnen gibt es Leute, die daran glauben geteilte Erinnerung und Menschen, die daran glauben Obmen soobscheniyami. Beim verteilten Rechnen bedeutet paralleles Rechnen zunächst die Weitergabe von Nachrichten. Dann entdeckte jemand, dass es viel einfacher war, mit Shared Memory zu programmieren. Die Gegenseite meinte, Shared Memory sei zu kompliziert, da es Sperren und Ähnliches benötige, weshalb es sich lohne, auf Sprachen umzusteigen, in denen nichts außer Message Passing einfach existiert. Jemand schaute sich an, was dabei herauskam, und sagte: „Wow, diese Messaging-Implementierung sieht einem Shared Memory sehr ähnlich, denn man erstellt viele, viele dieser kleinen Module, sie senden sich gegenseitig Nachrichten und sie alle.“ Verriegelung„Lasst uns eine bessere Shared-Memory-Datenbank erstellen!“ All dies wird immer wieder wiederholt, und es ist unmöglich zu sagen, dass eine der Parteien definitiv Recht hat. Eine Seite wird immer dominieren, denn sobald eine von ihnen fast gewinnt, erfinden die Leute immer wieder Möglichkeiten, die andere zu verbessern.

Die Kunst, brüchigen Multithread-Code zu schreiben

Alexey: Das ist sehr interessant. Wenn wir beispielsweise Code schreiben, müssen wir unabhängig von der Programmiersprache normalerweise Abstraktionen wie Zellen erstellen, die gelesen und geschrieben werden können. Tatsächlich kann dies jedoch auf einer physischen Ebene so aussehen, als würde eine Nachricht über einen Hardware-Bus zwischen verschiedenen Computern und anderen Geräten gesendet. Es stellt sich heraus, dass auf beiden Abstraktionsebenen gleichzeitig gearbeitet wird.

Maurice: Es ist absolut wahr, dass Shared Memory auf der Weitergabe von Nachrichten basiert – Busse, Caches und so weiter. Da es jedoch schwierig ist, Programme mithilfe der Nachrichtenübermittlung zu schreiben, lügt die Hardware absichtlich und gibt vor, dass Sie über eine Art einheitliches Gedächtnis verfügen. Dies erleichtert Ihnen das Schreiben einfacher, korrekter Programme, bevor die Leistung nachlässt. Dann wirst du sagen: Es scheint an der Zeit zu sein, dich mit dem Cache anzufreunden. Und dann fängt man an, sich Gedanken über den Standort des Caches zu machen, und von da an geht es weiter. In gewisser Weise hacken Sie die Abstraktion: Sie wissen, dass es sich nicht nur um einen flachen, einheitlichen Speicher handelt, und Sie werden dieses Wissen nutzen, um Cache-freundliche Programme zu schreiben. Dies ist, was Sie bei echten Problemen tun müssen. Bei diesem Konflikt zwischen der süßen, einfachen, netten Abstraktion, die Ihnen gegeben wurde, und der schrecklich komplexen Implementierung der zugrunde liegenden Hardware wird jeder seinen eigenen Kompromiss eingehen. Ich habe ein Buch über Multiprozessoren und Synchronisation, und irgendwann wollte ich ein Kapitel über Datenstrukturen schreiben java.util.concurrent. Wenn man sie sich ansieht, fallen Dinge auf wie Listen mit Auslassungen Das sind erstaunliche Kunstwerke. (Anmerkung der Redaktion: Wer mit der Java-Sprache vertraut ist, sollte sich zumindest die Implementierung ansehen ConcurrentSkipListMap, Sie können sich die Links unter ansehen API и Quellcode). Aber aus meiner Sicht wäre es unverantwortlich, sie den Schülern zu zeigen, denn eine solche Datenstruktur ist so etwas wie ein Zirkustyp, der auf einem Seil über einen Bärengraben läuft. Wenn Sie auch nur ein kleines Detail ändern, bricht die gesamte Struktur zusammen. Dieser Code ist sehr schnell und elegant, nur weil er perfekt geschrieben ist, aber die kleinste Änderung führt zum vollständigen Scheitern. Wenn ich Schülern diesen Code als Beispiel gebe, werden sie sofort sagen: Das kann ich auch! Und dann wird ein Flugzeug abstürzen oder ein Kernreaktor explodieren, und ich werde mich schuldig machen, ihnen zu viele Informationen zur falschen Zeit gegeben zu haben.

Alexey: Als ich etwas jünger war, habe ich oft versucht, den Quellcode von Doug Lee zu studieren, zum Beispiel java.util.concurrentDa es Open Source ist, ist es sehr einfach, es zu finden und zu verstehen, was dort vor sich geht. Es ist nicht so gut gelaufen: Oft ist völlig unklar, warum Doug sich entschieden hat, etwas so zu machen, während alle anderen es anders machen. Wie erklären Sie Ihren Schülern diese Dinge? Gibt es eine bestimmte korrekte Möglichkeit, beispielsweise bestimmte Details eines Hardcore-Algorithmus zu beschreiben? Wie machst Du das?

Maurice: Zeichenlehrer haben ein Klischee, an das sie sich zuerst erinnern: Wenn man wie Picasso zeichnen will, muss man zuerst lernen, einfache realistische Bilder zu zeichnen, und erst wenn man die Regeln kennt, kann man anfangen, sie zu brechen. Wenn Sie gleich damit beginnen, die Regeln zu brechen, geraten Sie ins Chaos. Zunächst bringe ich den Schülern bei, wie sie einfachen, korrekten Code schreiben können, ohne sich Gedanken über die Leistung machen zu müssen. Was ich damit sagen will ist, dass hier komplexe Timing-Probleme lauern, also machen Sie sich keine Sorgen über Caches, machen Sie sich keine Sorgen über Speichermodelle, stellen Sie einfach sicher, dass alles richtig funktioniert. Das ist schon schwierig genug: Modernes Programmieren ist an sich nicht einfach, insbesondere für Studienanfänger. Und wenn sie ein Gespür dafür haben, wie man die richtigen Programme schreibt, sage ich: Schauen Sie sich diese beiden Spinlock-Implementierungen an: Die eine ist sehr langsam, die zweite ebenfalls nicht sehr, aber besser. Mathematisch gesehen sind die beiden Algorithmen jedoch gleich. Tatsächlich verwendet einer von ihnen die Cache-Lokalität. Einer von ihnen läuft auf lokal zwischengespeicherten Daten und der andere führt wiederholt Operationen über den Bus aus. Sie können keinen effizienten Code schreiben, wenn Sie nicht verstehen, was er ist, und nicht wissen, wie Sie die Abstraktion durchbrechen und die zugrunde liegende Struktur betrachten können. Aber Sie werden nicht sofort damit beginnen können. Es gibt Leute, die sofort damit anfangen und an ihre eigene Genialität glauben, aber meist endet es schlecht, weil sie die Prinzipien nicht verstehen. Niemand zeichnet so gut wie Picasso oder schreibt Programme wie Doug Lee, der gleich in der ersten Woche sein Studium abgeschlossen hat. Es dauert Jahre, diesen Wissensstand zu erreichen.

Alexey: Es stellt sich heraus, dass Sie das Problem in zwei Teile unterteilen: Der erste ist die Korrektheit, der zweite die Leistung?

Maurice: Genau. Und zwar genau in dieser Reihenfolge. Ein Teil des Problems besteht darin, dass neue Studierende nicht verstehen, dass es schwierig ist, Korrektheit zu erreichen. Auf den ersten Blick heißt es: Das ist offensichtlich richtig, es bleibt nur noch, es zu beschleunigen. Deshalb erzähle ich ihnen manchmal von einem zunächst falschen Algorithmus, als ob er richtig wäre.

Wie man Schülern beibringt, komplexen Multithread-Code zu schreiben

Alexey: Nur um zu sehen, ob sie den Haken erkennen können?

Maurice: Ich warne immer im Voraus, dass ich manchmal falsche Algorithmen vorschlage. Du solltest die Leute nicht täuschen. Ich schlage vor, dass sie die Informationen mit Vorsicht genießen. Wenn ich etwas erzähle und sage: „Sehen Sie, das ist offensichtlich richtig“ – das ist ein Signal dafür, dass sie irgendwo versuchen, Sie zu täuschen, und Sie sollten anfangen, Fragen zu stellen. Als nächstes versuche ich die Schüler zu ermutigen, weiterhin Fragen zu stellen, und dann schlage ich vor: „Was passiert, wenn wir die Dinge so lassen, wie sie sind?“ Und sie sehen sofort den Fehler. Aber die Schüler davon zu überzeugen, dass sie sich um die Korrektheit kümmern müssen, ist viel schwieriger, als es auf den ersten Blick scheint. Viele dieser Schüler verfügen über Programmiererfahrung aus der High School, einige haben dort einen Job gefunden und dort programmiert, und sie sprühen alle vor Selbstvertrauen. Das ist so etwas wie bei der Armee: Man muss sie erst einmal in Stimmung bringen, um sie davon zu überzeugen, geduldig an die Lösung auftretender Probleme heranzugehen. Oder vielleicht ist es wie bei buddhistischen Mönchen: Zuerst lernen sie, über Korrektheit nachzudenken, und wenn sie erst einmal verstanden haben, wie man über Korrektheit argumentiert, dürfen sie auf die nächste Ebene übergehen und anfangen, sich Gedanken über die Leistung zu machen.

Alexey: Das heißt, manchmal zeigt man den Schülern nicht funktionierende Beispiele, wodurch man Feedback erhält, das zeigt, ob sie den Kern des Problems verstehen, ob sie den falschen Code und das falsche Ergebnis finden können. Machen Sie Studenten normalerweise glücklich oder traurig?

Maurice: Studenten finden den Fehler fast immer irgendwann. Wenn sie zu langsam suchen, stelle ich Leitfragen, und hier ist es wichtig zu verstehen, dass sie beginnen, Ihre Worte gedankenlos als die ultimative Wahrheit wahrzunehmen, wenn Sie sie niemals täuschen. Dann langweilen sie sich und beginnen einzuschlafen, während sie während des Unterrichts Facebook auf ihrem Laptop lesen. Aber wenn man ihnen im Voraus sagt, dass sie ausgetrickst werden und sie dumm aussehen werden, wenn sie keinen Trick bemerken, werden sie viel wachsamer. Das ist in verschiedener Hinsicht gut. Ich möchte, dass die Schüler nicht nur ihr Verständnis des Themas in Frage stellen, sondern auch die Autorität des Lehrers. Die Idee dahinter ist, dass ein Schüler jederzeit die Hand heben und sagen kann: „Ich denke, das, was Sie gerade gesagt haben, ist falsch.“ Es ist ein wichtiges Lernmittel. Ich möchte nicht, dass einer der Studenten dasitzt und still denkt: Das scheint alles völliger Unsinn zu sein, aber die Hand zu heben ist zu gruselig, und außerdem ist er Professor, also ist alles, was er sagt, die Wahrheit. Wenn sie daher im Voraus gewarnt werden, dass nicht alles, was gesagt wird, unbedingt wahr ist, besteht für sie ein Anreiz, dem Material mehr Aufmerksamkeit zu schenken. Ich mache deutlich, dass es in Ordnung ist, die Hand zu heben und Fragen zu stellen. Ihre Frage mag dumm oder naiv klingen, aber so entstehen oft die besten Fragen.

Alexey: Sehr interessant. Normalerweise haben Menschen eine Art psychologische Barriere, die es ihnen nicht erlaubt, einem Professor eine Frage zu stellen. Vor allem, wenn viele Leute im Raum sind und alle befürchten, dass die Diskussion Ihrer dummen Frage die ganze Zeit dieser Leute in Anspruch nimmt. Gibt es irgendwelche Tricks, um damit umzugehen?

Maurice: Ich bleibe oft stehen und stelle klassische Fragen. Ob eine Aussage richtig wäre oder wie sie das diskutierte Problem lösen würde. Dies ist eine Schlüsselaktion, insbesondere zu Beginn einer Unterrichtsstunde, wenn es den Leuten peinlich ist, auch nur die kleinste Sache zu sagen. Sie stellen den Schülern eine Frage und sagen nichts weiter. Es herrscht Stille, alle werden etwas angespannt, die Spannung wächst, dann hält es plötzlich jemand nicht mehr aus, bricht zusammen und sagt die Antwort. So drehen Sie die Situation um: Weiter zu schweigen wird schwieriger und unbequemer als zu antworten! Dies ist ein standardmäßiger pädagogischer Trick. Jeder Lehrer auf der Welt sollte wissen, wie das geht.

Alexey: Jetzt haben wir einen hervorragenden Titel für dieses Interview: „Es ist einfacher zu antworten als zu schweigen.“

Vitaly: Lass mich noch einmal fragen. Sie arbeiten an topologischen Beweisen. Wie sind Sie überhaupt dazu gekommen, denn verteiltes Rechnen und Topologie sind völlig unterschiedliche Dinge!

Maurice: Da gibt es eine versteckte Verbindung. Als Mathematikstudent habe ich reine Mathematik studiert. Ich hatte kein wirkliches Interesse an Computern, bis mein Studium zu Ende ging und ich vor der dringenden Notwendigkeit stand, einen Job zu suchen. Als Student habe ich algebraische Topologie studiert. Viele Jahre später, während ich an einem Problem arbeitete, rief ich an „k-Set-Vereinbarungsproblem“Ich habe das Problem mithilfe von Diagrammen modelliert und, wie es damals schien, eine Lösung gefunden. Man musste sich einfach hinsetzen und die Zählung durchgehen. Versuchen Sie, in dieser Grafik eine passende Antwort zu finden. Aber mein Algorithmus funktionierte nicht: Es stellte sich heraus, dass er für immer im Kreis laufen würde. Leider ließ sich das alles nicht mit der formalen Sprache der Graphentheorie erklären, die alle Informatiker kennen. Und dann fiel mir ein, dass wir vor vielen Jahren, damals im Topologieunterricht, das Konzept verwendet haben „einfacher Komplex“, was eine Verallgemeinerung von Graphen auf höhere Dimensionen ist. Dann fragte ich mich: Was würde passieren, wenn wir das Problem in Form von Simplizialkomplexen umformulieren würden? Dies wurde zum Schlüsselmoment. Durch die Verwendung eines leistungsfähigeren Formalismus wird das Problem plötzlich viel einfacher. Man hat lange Zeit dagegen gekämpft, indem man Diagramme verwendet hat, aber man konnte nichts dagegen tun. Und selbst jetzt können sie es nicht – die richtige Antwort war kein Algorithmus, sondern ein Beweis für die Unmöglichkeit, das Problem zu lösen. Das heißt, ein solcher Algorithmus existiert einfach nicht. Aber jeder Beweis der Unmöglichkeit basierend entweder auf Simplizialkomplexen oder auf Dingen, von denen die Leute vorgaben, dass sie nicht als Simplizialkomplexe gelten. Nur weil man etwas einen neuen Namen gibt, verliert es nicht seine Essenz.

Vitaly: Es stellte sich heraus, dass Sie einfach Glück hatten?

Maurice: Neben Glück auch готовность. Das bedeutet, dass Sie die „nutzlosen“ Dinge, die Sie zuvor gelernt haben, nicht vergessen sollten. Je mehr nutzlose Dinge Sie lernen, desto mehr Ideen können Sie gewinnen, wenn Sie mit einem neuen Problem konfrontiert werden. Diese Art des intuitiven Mustervergleichs ist wichtig, weil ... Machen wir das, das ist eine Kette: Zuerst stellte ich fest, dass die Diagramme überhaupt nicht oder überhaupt nicht funktionierten, es erinnerte mich an etwas aus den Ereignissen von Acht Vor Jahren und während meiner Studienzeit, als wir all diese einfachen Komplexe studierten. Dies wiederum ermöglichte es mir, mein altes Topologielehrbuch zu finden und es wieder in meinen Kopf zu laden. Aber ohne dieses alte Wissen wäre ich bei der Lösung des ursprünglichen Problems nie vorangekommen.

Neuauflage des Buches „The Art of Multiprocessor Programming“

Alexey: Du hast ein paar Worte zu deinem Buch gesagt. Es ist wahrscheinlich nicht das schlimmste Geheimnis, dass Sie das weltweit berühmteste Buch über Multithreading geschrieben haben. „Die Kunst der Multiprozessorprogrammierung“. Es ist bereits etwa 11 Jahre alt und wurde seitdem nur noch veröffentlicht  überarbeiteter Nachdruck. Wird es eine zweite Auflage geben?

Maurice: Gut, dass du gefragt hast! Es wird sehr bald soweit sein, in etwa drei Monaten. Es gibt zwei weitere Autoren, wir haben viel mehr Material hinzugefügt, den Abschnitt über Fork/Join-Parallelität verbessert, einen Abschnitt über MapReduce geschrieben, viele neue Dinge hinzugefügt und unnötige Dinge weggeworfen – etwas, das zum Zeitpunkt des Schreibens sehr interessant war die erste Ausgabe, ist aber heute nicht mehr vorhanden. Das Ergebnis war ein sehr ernsthaft überarbeitetes Buch.

Alexey: Alles ist bereits erledigt, es bleibt nur noch die Veröffentlichung?

Maurice: An ein paar Kapiteln muss noch gearbeitet werden. Unser Verleger (von dem ich glaube, dass er uns bereits hasst) versucht immer noch, die Botschaft zu vermitteln, dass wir schneller arbeiten sollten. Wir sind weit hinter dem Zeitplan zurück. Theoretisch hätten wir dieses Buch schon ein paar Jahre früher machen können.

Alexey: Gibt es eine Chance, noch vor Weihnachten eine neue Version des Buches zu bekommen?

Maurice: Das ist unser Ziel! Aber ich habe den Sieg so oft vorhergesagt, dass mir niemand mehr glaubt. Sie sollten mir in dieser Angelegenheit wahrscheinlich auch nicht zu sehr vertrauen.

Alexey: Auf jeden Fall sind das fantastische Neuigkeiten. Die erste Auflage des Buches hat mir sehr gut gefallen. Man könnte sagen, ich bin ein Fan.

Maurice: Ich hoffe, dass die neue Ausgabe Ihrer glühenden Begeisterung würdig ist, vielen Dank!

Wie das Transaktionsgedächtnis erfunden wurde

Vitaly: Die nächste Frage betrifft das Transaktionsgedächtnis. Soweit ich weiß, sind Sie ein Pionier auf diesem Gebiet, Sie haben es zu einer Zeit erfunden, als noch niemand über solche Dinge nachdachte. Warum haben Sie sich entschieden, in dieses Feld zu wechseln? Warum erschienen Ihnen Transaktionen wichtig? Dachten Sie, dass sie eines Tages in Hardware implementiert werden würden?

Maurice: Ich kenne Transaktionen seit meiner Forschungszeit.

Vitaly: Ja, aber das sind unterschiedliche Transaktionen!

Maurice: Ich habe mit Elliott Moss an der nicht blockierenden Garbage Collection gearbeitet. Unser Problem bestand darin, dass wir ein paar Wörter im Speicher atomar ändern wollten und die Algorithmen dann sehr einfach und zumindest einige davon effizienter würden. Benutzen vergleichen und tauschen für Load-Link/Store-ConditionalDurch die parallele Architektur ist es möglich, etwas zu tun, aber es ist sehr ineffizient und hässlich, da man sich mit Indirektionsebenen befassen müsste. Ich möchte Speicherwörter ändern und muss wechseln, weil ich nur einen Zeiger ändern kann, sodass sie auf eine Art verzeichnisähnliche Struktur zeigen müssen. Wir haben darüber gesprochen, wie großartig es wäre, wenn wir die Hardware so ändern könnten, dass gleichzeitige Aufnahmen möglich wären. Elliott scheint dies bemerkt zu haben: Wenn man sich Cache-Kohärenzprotokolle ansieht, stellen sie bereits den Großteil der erforderlichen Funktionalität bereit. Bei einer optimistischen Transaktion erkennt das Cache-Kohärenzprotokoll, dass ein Zeitkonflikt vorliegt, und der Cache wird blockiert ungültig. Was passiert, wenn Sie spekulativ eine Transaktion in Ihrem Cache ausführen und die Mechanismen des Kohärenzprotokolls verwenden, um Konflikte zu erkennen? Die spekulative Hardwarearchitektur war einfach zu entwerfen. Also haben wir das geschrieben die allererste Veröffentlichung über Transaktionsgedächtnis. Zur gleichen Zeit entwickelte die Firma Digital Equipment Corporation, für die ich arbeitete, einen neuen 64-Bit-Prozessor namens Alpha. Also ging ich hin und hielt der Alpha-Entwicklungsgruppe eine Präsentation über unser erstaunliches Transaktionsgedächtnis, und sie fragten: Wie viel zusätzlichen Umsatz würde unser Unternehmen erzielen, wenn wir all dies direkt zum Prozessor hinzufügen würden? Und darauf hatte ich überhaupt keine Antwort, denn ich bin Technologe und kein Marketingspezialist. Ich hatte wirklich nichts zu antworten. Sie waren nicht sehr beeindruckt, dass ich nichts wusste.

Vitaly: Milliarden! Sagen Sie einfach Milliarden!

Maurice: Ja, das hätte ich sagen sollen. Jetzt, im Zeitalter der Startups und allem, weiß ich, wie man einen Geschäftsplan schreibt. Dass Sie über die Höhe Ihres potenziellen Gewinns ein wenig lügen können. Aber damals schien es naiv, also sagte ich einfach: „Ich weiß es nicht.“ Wenn Sie sich die Geschichte der Veröffentlichung zum Transaktionsgedächtnis ansehen, werden Sie feststellen, dass es nach einem Jahr mehrere Verweise darauf gab und dass dieser Artikel dann etwa zehn Jahre lang überhaupt nicht mehr zitiert wurde. Die Zitate tauchten etwa im Jahr 2004 auf, als echte Multicores auf den Markt kamen. Als die Leute entdeckten, dass man mit dem Schreiben von parallelem Code Geld verdienen kann, begannen neue Forschungen. Ravi Rajwar einen Artikel geschrieben, was in gewisser Weise das Konzept des Transaktionsgedächtnisses in den Mainstream einführte. (Anmerkung des Herausgebers: Es gibt eine zweite Version dieses Artikels, die 2010 veröffentlicht wurde und frei verfügbar ist als PDF). Plötzlich wurde den Menschen klar, wie all dies genutzt werden konnte, wie traditionelle Algorithmen mit Sperren beschleunigt werden konnten. Ein gutes Beispiel für etwas, das in der Vergangenheit nur wie ein interessantes akademisches Problem schien. Und ja, wenn Sie mich damals gefragt hätten, ob ich glaube, dass das alles in Zukunft wichtig sein wird, hätte ich gesagt: Natürlich, aber wann genau, ist nicht klar. Vielleicht in 50 Jahren? In der Praxis stellte sich heraus, dass dies nur ein Jahrzehnt war. Es ist sehr schön, wenn man etwas tut und die Leute es schon nach zehn Jahren bemerken.

Warum es sich lohnt, im Bereich Distributed Computing zu forschen

Vitaly: Wenn wir über neue Forschungsergebnisse sprechen, was würden Sie den Lesern raten – verteiltes Rechnen oder Multicore und warum? 

Maurice: Heutzutage ist es einfach, einen Multi-Core-Prozessor zu bekommen, aber es ist schwieriger, ein wirklich verteiltes System einzurichten. Ich begann mit der Arbeit daran, weil ich etwas anderes als meine Doktorarbeit machen wollte. Dies ist der Rat, den ich neuen Studierenden immer gebe: Schreiben Sie keine Fortsetzung Ihrer Dissertation, sondern versuchen Sie, eine neue Richtung einzuschlagen. Und auch Multithreading ist einfach. Ich kann mit meinem eigenen Fork experimentieren, der auf meinem Laptop läuft, ohne aufzustehen. Aber wenn ich plötzlich ein echtes verteiltes System schaffen wollte, müsste ich viel Arbeit leisten, Studenten anwerben und so weiter. Ich bin ein fauler Mensch und arbeite lieber mit Multicore. Das Experimentieren mit Mehrkernsystemen ist auch einfacher als das Experimentieren mit verteilten Systemen, da selbst in einem dummen verteilten System zu viele Faktoren kontrolliert werden müssen.

Vitaly: Was machen Sie gerade? Erforschen Sie Blockchain? Auf welche Artikel sollten Sie zuerst achten?

Maurice: Kürzlich erschienen sehr guter Artikel, das ich zusammen mit meinem Studenten Vikram Saraf speziell für einen Vortrag bei geschrieben habe Tokenomcs-Konferenz in Paris vor drei Wochen. Dies ist ein Artikel über praktische verteilte Systeme, in dem wir vorschlagen, Ethereum multithreaded zu machen. Derzeit werden Smart Contracts (Code, der auf der Blockchain läuft) sequentiell ausgeführt. Wir haben vorhin einen Artikel geschrieben, in dem es um eine Möglichkeit ging, spekulative Transaktionen zu nutzen, um den Prozess zu beschleunigen. Wir haben viele Ideen aus dem Software-Transaktionsspeicher übernommen und gesagt, dass alles schneller funktionieren wird, wenn man diese Ideen in die virtuelle Etherium-Maschine integriert. Dafür ist es aber erforderlich, dass es in den Verträgen zu keinen Datenkonflikten kommt. Und dann gingen wir davon aus, dass es im wirklichen Leben solche Konflikte wirklich nicht gibt. Aber wir hatten keine Möglichkeit, das herauszufinden. Dann kam uns der Gedanke, dass wir fast ein Jahrzehnt realer Vertragshistorie in unseren Händen hatten, also ließen wir die Ethereum-Blockchain fallen und fragten uns: Was würde passieren, wenn diese historischen Aufzeichnungen parallel ausgeführt würden? Wir haben eine deutliche Geschwindigkeitssteigerung festgestellt. In den Anfängen von Ethereum ist die Geschwindigkeit stark gestiegen, doch heute ist alles etwas komplizierter, da es weniger Verträge gibt und die Wahrscheinlichkeit von Konflikten um Daten, die eine Serialisierung erfordern, höher geworden ist. Aber das alles ist experimentelle Arbeit mit echten historischen Daten. Das Schöne an der Blockchain ist, dass sie sich alles für immer merkt, sodass wir in die Vergangenheit reisen und untersuchen können, was passiert wäre, wenn wir andere Algorithmen zum Ausführen des Codes verwendet hätten. Wie hätte den Menschen früher unsere neue Idee gefallen? Eine solche Recherche ist viel einfacher und macht mehr Spaß, weil es etwas gibt, das alles überwacht und aufzeichnet. Dies ähnelt bereits eher der Soziologie als der Entwicklung von Algorithmen.

Ist die Entwicklung von Algorithmen gestoppt und wie geht es weiter?

Vitaly: Zeit für die letzte theoretische Frage! Haben Sie das Gefühl, dass der Fortschritt bei wettbewerbsorientierten Datenstrukturen jedes Jahr abnimmt? Glauben Sie, dass wir in unserem Verständnis von Datenstrukturen ein Plateau erreicht haben, oder wird es wesentliche Verbesserungen geben? Vielleicht gibt es ein paar clevere Ideen, die alles komplett verändern können?

Maurice: Wir haben möglicherweise ein Plateau bei den Datenstrukturen traditioneller Architekturen erreicht. Doch Datenstrukturen für neue Architekturen sind immer noch ein vielversprechendes Gebiet. Wenn Sie Datenstrukturen beispielsweise für Hardwarebeschleuniger erstellen möchten, unterscheiden sich die Datenstrukturen für eine GPU stark von den Datenstrukturen für eine CPU. Wenn Sie Datenstrukturen für Blockchains entwickeln, müssen Sie Datenstücke hashen und sie dann in etwas Ähnliches einfügen Merkle-Baum, um Fälschungen zu verhindern. In letzter Zeit gab es in diesem Bereich einen Aufschwung, und viele von ihnen leisteten sehr gute Arbeit. Aber ich denke, was passieren wird, ist, dass neue Architekturen und neue Anwendungen zu neuen Datenstrukturen führen werden. Legacy-Anwendungen und traditionelle Architektur – es gibt möglicherweise nicht mehr viel Raum für Erkundungen. Aber wenn man die ausgetretenen Pfade verlässt und über den Tellerrand hinausschaut, wird man verrückte Dinge sehen, die der Mainstream nicht ernst nimmt – und genau dort passieren all die aufregenden Dinge.

Vitaly: Um ein sehr berühmter Forscher zu sein, musste ich meine eigene Architektur erfinden :)

Maurice: Man kann die neue Architektur eines anderen „stehlen“ – das scheint viel einfacher zu sein!

Arbeitet an der Brown University

Vitaly: Könnten Sie uns mehr darüber erzählen? Universität Brownwo arbeitest du? Im Zusammenhang mit der Informationstechnologie ist nicht viel über ihn bekannt. Weniger als zum Beispiel über das MIT.

Maurice: Die Brown University ist eine der ältesten Universitäten in den Vereinigten Staaten. Ich denke, nur Harvard ist etwas älter. Brown ist Teil der sogenannten Ivy League, eine Sammlung der acht ältesten Universitäten. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Es ist eine Art alte, kleine und etwas aristokratische Universität. Der Schwerpunkt liegt auf der geisteswissenschaftlichen Ausbildung. Es geht nicht darum, wie das MIT zu sein, das MIT ist sehr spezialisiert und technisch. Brown ist ein großartiger Ort, um russische Literatur oder klassisches Griechisch und natürlich Informatik zu studieren. Der Schwerpunkt liegt auf umfassender Bildung. Die meisten unserer Studierenden nutzen Facebook, Apple, Google – daher denke ich, dass unsere Studierenden keine Probleme haben, einen Job in der Branche zu finden. Ich bin zu Brown gegangen, weil ich zuvor bei Digital Equipment Corporation in Boston gearbeitet hatte. Dies war ein Unternehmen, das viele interessante Dinge erfand, aber die Bedeutung von Personalcomputern leugnete. Ein Unternehmen mit schwerem Schicksal, dessen Gründer einst junge Revolutionäre waren, die nichts lernten und nichts vergaßen und sich so innerhalb von etwa einem Dutzend Jahren von Revolutionären zu Reaktionären wandelten. Sie scherzten gerne darüber, dass Personalcomputer in die Garage gehörten – natürlich in eine verlassene Garage. Es ist ganz offensichtlich, dass sie von flexibleren Unternehmen zerstört wurden. Als klar wurde, dass das Unternehmen in Schwierigkeiten steckte, rief ich einen Freund in Brown an, das etwa eine Stunde außerhalb von Boston liegt. Ich wollte Boston damals nicht verlassen, da es an anderen Universitäten nicht viele offene Stellen gab. Damals gab es in der Informatik noch nicht so viele Arbeitsplätze wie heute. Und Brown hatte eine offene Stelle, ich musste mein Zuhause nicht umziehen, ich musste meine Familie nicht umziehen und ich liebe es wirklich, in Boston zu leben! Deshalb habe ich beschlossen, zu Brown zu gehen. Es hat mir gefallen. Die Studenten sind wunderbar, deshalb habe ich nie versucht, woanders hinzugehen. Während meines Sabbaticals habe ich ein Jahr bei Microsoft gearbeitet, war ein Jahr am Technion in Haifa und jetzt werde ich bei Algorand sein. Ich habe überall viele Kollegen und daher ist der physische Standort unserer Klassenzimmer nicht so wichtig. Aber das Wichtigste sind die Studenten, sie sind hier die Besten. Ich habe nie versucht, woanders hinzugehen, weil ich hier sehr glücklich bin.

Doch trotz Browns Ruhm in den Vereinigten Staaten ist er im Ausland überraschend unbekannt. Wie Sie sehen, tue ich jetzt alles, um diesen Zustand zu korrigieren.

Unterschied zwischen Forschung an einer Universität und innerhalb eines Unternehmens

Vitaly: Okay, die nächste Frage betrifft digitale Ausrüstung. Sie waren als Forscher dort. Was ist der Unterschied zwischen der Arbeit in der Forschungs- und Entwicklungsabteilung eines großen Unternehmens und der Arbeit an einer Universität? Was sind die Vor- und Nachteile?

Maurice: Ich habe zwanzig Jahre lang bei Microsoft gearbeitet und eng mit Mitarbeitern von Sun Microsystems, Oracle, Facebook und jetzt Algorand zusammengearbeitet. Vor diesem Hintergrund möchte ich sagen, dass es möglich ist, sowohl in Unternehmen als auch an Universitäten erstklassige Forschung zu betreiben. Der wichtige Unterschied besteht darin, dass man in einem Unternehmen mit Kollegen zusammenarbeitet. Wenn ich plötzlich eine Idee für ein Projekt habe, die es noch nicht gibt, muss ich meine Kollegen davon überzeugen, dass dies eine gute Idee ist. Wenn ich an der Brown University bin, kann ich meinen Schülern sagen: Lasst uns an der Antigravitation arbeiten! Sie gehen entweder zu jemand anderem oder übernehmen ein Projekt. Ja, ich muss eine Finanzierung finden, ich muss einen Zuschussantrag schreiben und so weiter. In jedem Fall wird es immer viele Studierende geben und Sie können Entscheidungen einseitig treffen. Aber an der Universität wirst du höchstwahrscheinlich nicht mit Leuten auf deinem Niveau zusammenarbeiten. In der Welt der industriellen Forschung müssen Sie zunächst alle davon überzeugen, dass sich Ihr Projekt lohnt. Ich kann niemandem etwas bestellen. Und beide Arbeitsweisen sind wertvoll, denn wenn Sie an etwas wirklich Verrücktem arbeiten und Ihre Kollegen schwer zu überzeugen sind, ist es einfacher, Doktoranden zu überzeugen – vor allem, wenn Sie sie bezahlen. Wenn Sie an etwas arbeiten, das viel Erfahrung und tiefes Fachwissen erfordert, dann brauchen Sie Kollegen, die sagen können: „Nein, es ist einfach so, dass ich mich in diesem Bereich auskenne und Ihre Idee schlecht ist, es wird nicht funktionieren.“ Dies ist im Hinblick auf die Zeitverschwendung sehr nützlich. Und wenn man in Industrielaboren viel Zeit damit verbringt, Berichte zu schreiben, dann verbringt man diese Zeit an einer Universität damit, Geld zu finden. Wenn ich möchte, dass Studierende irgendwohin gehen können, muss ich das Geld dafür woanders aufbringen. Und je wichtiger Ihre Position an der Universität ist, desto mehr Zeit müssen Sie für die Geldbeschaffung aufwenden. Jetzt wissen Sie also, wofür ich arbeite – als professioneller Bettler! Wie einer dieser Mönche, die mit einem Opferteller herumlaufen. Im Allgemeinen ergänzen sich diese beiden Aktivitäten. Deshalb versuche ich, in beiden Welten zu leben und auf dem Boden der Tatsachen zu bleiben.

Vitaly: Es scheint, dass es schwieriger ist, ein Unternehmen zu überzeugen, als andere Wissenschaftler.

Maurice: Schwieriger und noch viel mehr. Darüber hinaus ist es in verschiedenen Bereichen unterschiedlich: Einige betreiben umfassende Forschung, während andere sich auf ihr Thema konzentrieren. Wenn ich zu Microsoft oder Facebook gehen und sagen würde: Lasst uns Anti-Schwerkraft machen, würden sie das kaum zu schätzen wissen. Aber wenn ich meinen Doktoranden genau das Gleiche sagen würde, würden sie höchstwahrscheinlich sofort mit der Arbeit beginnen, obwohl ich jetzt Probleme hätte – schließlich muss ich dafür Geld aufbringen. Aber solange Sie etwas tun möchten, das mit den Zielen des Unternehmens übereinstimmt, kann dieses Unternehmen ein sehr guter Ort für Recherchen sein.

Hydra und SPTDC

Vitaly: Meine Fragen gehen zu Ende, also reden wir ein wenig über die bevorstehende Reise nach Russland.

Maurice: Ja, ich freue mich auf die Rückkehr nach St. Petersburg.

Alexey: Es ist mir eine Ehre, Sie dieses Jahr bei uns zu haben. Das ist Ihr zweites Mal in St. Petersburg, oder?

Maurice: Schon der Dritte!

Alexey: Ich verstehe, aber SPTDC – definitiv der Zweite. Das letzte Mal wurde die Schule angerufen SPTCC, haben wir nun einen Buchstaben geändert (C in D, Concurrent in Distributed), um hervorzuheben, dass es in diesem Jahr mehr Bereiche gibt, die sich speziell auf verteiltes Rechnen beziehen. Können Sie ein paar Worte zu Ihren Berichten an der Schule sagen? Hydra-Konferenz?

Maurice: An der Schule möchte ich über die Grundlagen der Blockchain sprechen und darüber, was man damit machen kann. Ich möchte zeigen, dass Blockchains der uns bekannten Multithread-Programmierung sehr ähnlich sind, jedoch ihre eigenen Nuancen aufweisen, und es ist wichtig, diese Unterschiede zu verstehen. Wenn Sie in einer normalen Webanwendung einen Fehler machen, ist das nur ärgerlich. Wenn Sie fehlerhaften Code in eine Finanzanwendung schreiben, wird jemand mit Sicherheit Ihr gesamtes Geld stehlen. Dabei handelt es sich um völlig unterschiedliche Ebenen der Verantwortung und Konsequenzen. Ich werde ein wenig über Proof-of-Work, über Smart Contracts und über Transaktionen zwischen verschiedenen Blockchains sprechen.

Neben mir werden weitere Referenten arbeiten, die ebenfalls etwas zum Thema Blockchain zu sagen haben, und wir haben vereinbart, uns untereinander abzustimmen, damit unsere Geschichten gut zusammenpassen. Aber für den technischen Bericht möchte ich einem breiten Publikum eine verständliche Erklärung geben, warum man nicht alles glauben sollte, was man über Blockchains hört, warum Blockchains ein großartiges Feld sind, wie es zu anderen bekannten Ideen passt und warum wir mutig hinschauen sollten in die Zukunft.

Alexey: Darüber hinaus möchte ich sagen, dass dies nicht wie vor zwei Jahren im Format eines Meetups oder einer Benutzergruppe stattfinden wird. Wir beschlossen, eine kleine Konferenz in der Nähe der Schule abzuhalten. Der Grund dafür ist, dass wir nach der Kommunikation mit Peter Kuznetsov festgestellt haben, dass die Schule auf nur hundert, vielleicht 120 Personen begrenzt ist. Gleichzeitig gibt es viele Ingenieure, die mit Ihnen kommunizieren möchten, Vorträge besuchen und sich generell für das Thema interessieren. Aus diesem Grund haben wir eine neue Konferenz ins Leben gerufen namens Hydra. Übrigens, habt ihr eine Idee, warum Hydra?

Maurice: Weil es sieben Redner geben wird? Und ihre Köpfe können abgeschlagen werden und an ihrer Stelle werden neue Sprecher wachsen?

Alexey: Tolle Idee für die Entwicklung neuer Lautsprecher. Aber tatsächlich gibt es hier eine Geschichte. Erinnern Sie sich an die Legende von Odysseus, zwischen der er hin und her segeln musste Skylla und Charybdis? Hydra ist so etwas wie Charybdis. Die Geschichte ist, dass ich einmal auf einer Konferenz gesprochen und über Multithreading gesprochen habe. Auf dieser Konferenz gab es nur zwei Tracks. Zu Beginn des Berichts habe ich den Zuschauern im Saal gesagt, dass sie nun die Wahl zwischen Skylla und Charybdis haben. Mein Geistestier ist Charybdis, weil Charybdis viele Köpfe hat und mein Thema Multithreading ist. So erscheinen die Namen der Konferenzen.

Auf jeden Fall sind uns die Fragen und die Zeit ausgegangen. Vielen Dank, Freunde, für das tolle Interview und wir sehen uns bei der SPTDC School und Hydra 2019!

Sie können Ihr Gespräch mit Maurice auf der Hydra 2019-Konferenz fortsetzen, die vom 11. bis 12. Juli 2019 in St. Petersburg stattfindet. Er wird mit einem Bericht kommen „Blockchains und die Zukunft des verteilten Rechnens“. Tickets können erworben werden auf der offiziellen Website.

Source: habr.com

Kommentar hinzufügen