- eigenaar van twee. De eerste is om aan te werken (Brown University) en de tweede, recentere, - (Virginia Tech Universiteit). De Dijkstraprijs wordt uitgereikt voor werk waarvan de betekenis en invloed al zeker tien jaar zichtbaar zijn en Maurice is uiteraard een van de bekendste specialisten op dit gebied. Hij werkt momenteel als professor aan de Brown University en heeft talloze prestaties geleverd die een paragraaf lang zijn. Momenteel doet hij onderzoek naar blockchain in de context van klassiek gedistribueerd computergebruik.
Eerder was Maurice al naar Rusland gekomen voor SPTCC () en een uitstekende bijeenkomst gehad van de JUG.ru Java-ontwikkelaarsgemeenschap in St. Petersburg ().
Deze habrapost is een geweldig interview met Maurice Herlihy. Er worden de volgende onderwerpen besproken:
- Interactie tussen de academische wereld en de industrie;
- Stichting Blockchainonderzoek;
- Waar komen baanbrekende ideeën vandaan? De invloed van populariteit;
- PhD onder supervisie van Barbara Liskov;
- De wereld wacht op multi-core;
- Een nieuwe wereld brengt nieuwe problemen met zich mee. NVM, NUMA en architectuurhacking;
- Compilers versus processors, RISC versus CISC, gedeeld geheugen versus het doorgeven van berichten;
- De kunst van het schrijven van fragiele multi-threaded code;
- Hoe studenten te leren complexe multi-threaded code te schrijven;
- Nieuwe editie van het boek “The Art of Multiprocessor Programming”;
- Hoe transactioneel geheugen werd uitgevonden;
- Waarom het de moeite waard is om onderzoek te doen op het gebied van gedistribueerd computergebruik;
- Is de ontwikkeling van algoritmen gestopt en hoe moeten we verder?
- Werk aan de Brown Universiteit;
- Het verschil tussen onderzoek aan een universiteit en binnen een bedrijf;
- Hydra en SPTDC.
Het interview wordt afgenomen door:
Vitaly Aksenov — momenteel postdoc bij IST Oostenrijk en medewerker van de afdeling Computertechnologieën van de ITMO Universiteit. Doet onderzoek op het gebied van theorie en praktijk van competitieve datastructuren. Voordat hij bij IST ging werken, promoveerde hij aan de Paris Diderot University en ITMO University onder supervisie van professor Peter Kuznetsov.
Alexey Fedorov - Producent bij JUG Ru Group, een Russisch bedrijf dat conferenties voor ontwikkelaars organiseert. Alexey nam deel aan de voorbereiding van meer dan 50 conferenties en zijn cv omvat alles, van de functie van ontwikkelingsingenieur bij Oracle (JCK, Java Platform Group) tot de functie van ontwikkelaar bij Odnoklassniki.
Vladimir Sitnikov - Ingenieur bij Netcracker. Tien jaar werk aan de prestaties en schaalbaarheid van NetCracker OS, software die door telecomoperatoren wordt gebruikt om netwerk- en netwerkapparatuurbeheerprocessen te automatiseren. Geïnteresseerd in prestatieproblemen met Java en Oracle Database. Auteur van meer dan een dozijn prestatieverbeteringen in het officiële PostgreSQL JDBC-stuurprogramma.
Interactie tussen de academische wereld en de industrie
Alexey: Maurice, je hebt heel lang in een academische omgeving gewerkt en de eerste vraag is de interactie tussen de academische en industriële sfeer. Kunt u vertellen hoe de interacties tussen hen de laatste tijd zijn veranderd? Wat gebeurde er twintig tot dertig jaar geleden en wat gebeurt er nu?
Maurice: Ik heb altijd geprobeerd nauw samen te werken met commerciële bedrijven, omdat zij interessante problemen hebben. Zij zijn in de regel niet erg geïnteresseerd in het publiceren van hun resultaten of in gedetailleerde uitleg van hun problemen aan de wereldgemeenschap. Ze zijn alleen geïnteresseerd in het oplossen van deze problemen. Ik heb een tijdje voor dergelijke bedrijven gewerkt. Ik heb vijf jaar fulltime gewerkt in een onderzoekslaboratorium bij Digital Equipment Corporation, voorheen een groot computerbedrijf. Ik werkte een dag per week bij Sun, bij Microsoft, bij Oracle en deed wat werk bij Facebook. Nu ga ik met sabbatical leave (een professor aan een Amerikaanse universiteit mag zo’n eens in de zes jaar zo’n verlof opnemen) en werken in , dit is een cryptocurrency-bedrijf in Boston. Nauw samenwerken met bedrijven is altijd een plezier geweest, want zo leer je over nieuwe en interessante dingen. Mogelijk bent u zelfs de eerste of tweede persoon die een artikel over een gekozen onderwerp publiceert, in plaats van te werken aan het stapsgewijs verbeteren van oplossingen voor problemen waar alle anderen al aan werken.
Alexey: Kun je ons gedetailleerder vertellen hoe dit gebeurt?
Maurits: Natuurlijk. Weet je, toen ik bij de Digital Equipment Corporation werkte, hebben Elliot Moss en ik het transactionele geheugen uitgevonden. Het was een zeer vruchtbare periode waarin iedereen geïnteresseerd begon te raken in informatietechnologie. Parallellisme, inclusief, hoewel multi-coresystemen nog niet bestonden. Tijdens de Sun- en Oracle-dagen heb ik veel gewerkt aan parallelle datastructuren. Bij Facebook heb ik aan hun blockchain-project gewerkt, waar ik niet over kan praten, maar ik hoop dat het snel openbaar wordt. Volgend jaar ga ik bij Algorand werken in een onderzoeksgroep die slimme contracten bestudeert.
Alexey: Blockchain is de afgelopen jaren een zeer populair onderwerp geworden. Zal dit uw onderzoek helpen? Misschien wordt het daardoor gemakkelijker om subsidies te verkrijgen of toegang te verlenen tot middelen van bedrijven die in de sector actief zijn?
Maurice: Ik heb al een kleine subsidie ontvangen van de Ethereum Foundation. De populariteit van blockchain is zeer behulpzaam bij het inspireren van studenten om op dit gebied te werken. Ze zijn er erg in geïnteresseerd en hebben er zin in om mee te doen, maar realiseren zich soms niet dat het onderzoek dat van buitenaf spannend klinkt, heel hard werken blijkt te zijn. Ik ben echter erg enthousiast om al deze mystiek rond blockchain te gebruiken om studenten aan te trekken.
Maar dat is niet alles. Ik zit in de adviesraad van verschillende blockchain-startups. Sommigen van hen zullen misschien slagen, anderen misschien niet, maar het is altijd erg interessant om hun ideeën te zien, te bestuderen en mensen te adviseren. Het spannendste is als je mensen waarschuwt iets niet te doen. Veel dingen lijken in eerste instantie een goed idee, maar zijn ze dat ook echt?
Stichting voor Blockchainonderzoek
Vitaly: Sommige mensen denken dat de toekomst bij de blockchain en zijn algoritmen ligt. En andere mensen zeggen dat het gewoon weer een zeepbel is. Kunt u uw mening over deze kwestie delen?
Maurice: Veel van wat er in de blockchain-wereld gebeurt, is verkeerd, sommige zijn gewoon oplichterij, veel wordt overschat. Ik denk echter dat er een solide wetenschappelijke basis bestaat voor deze onderzoeken. Het feit dat de blockchain-wereld vol ideologische verschillen is, toont het niveau van opwinding en toewijding aan. Aan de andere kant is dit niet bepaald gunstig voor wetenschappelijk onderzoek. Als je nu een artikel publiceert waarin wordt gesproken over de tekortkomingen van een bepaald algoritme, is de resulterende reactie niet altijd volledig wetenschappelijk. Vaak gooien mensen hun emoties weg. Ik denk dat dit soort opwinding op dit gebied voor sommigen misschien aantrekkelijk lijkt, maar uiteindelijk zijn er echte wetenschappelijke en technische problemen die moeten worden aangepakt. Er is hier veel computerwetenschappen.
Vitaly: Dus je probeert de basis te leggen voor blockchain-onderzoek, toch?
Maurice: Ik probeer de basis te leggen voor een solide, wetenschappelijk en wiskundig verantwoorde discipline. En een deel van het probleem is dat je soms de overdreven harde standpunten van andere mensen moet tegenspreken en negeren. Soms vragen mensen waarom ik in een gebied werk waar alleen terroristen en drugshandelaren geïnteresseerd zijn. Zo’n reactie is net zo zinloos als het gedrag van volgers die blindelings jouw woorden herhalen. Ik denk dat de waarheid ergens in het midden ligt. Blockchain zal een diepgaande impact hebben op de samenleving en de wereldeconomie. Maar dankzij de moderne technologie zal dit waarschijnlijk niet gebeuren. Moderne technologieën zullen zich ontwikkelen en wat in de toekomst blockchain zal worden genoemd, zal erg belangrijk worden. Het lijkt misschien niet eens op moderne blockchains, dat is een open vraag.
Als mensen nieuwe technologieën uitvinden, zullen ze het blockchain blijven noemen. Ik bedoel, net zoals het huidige Fortran niets te maken heeft met de Fortran-taal uit de jaren zestig, maar iedereen blijft het Fortran noemen. Hetzelfde voor UNIX. Wat ‘blockchain’ wordt genoemd, zal nog steeds zijn revolutie doormaken. Maar ik betwijfel of deze nieuwe blockchain zoiets zal zijn als wat iedereen vandaag de dag graag gebruikt.
Waar komen baanbrekende ideeën vandaan? Impact van populariteit
Alexey: Heeft de populariteit van blockchain vanuit wetenschappelijk oogpunt tot nieuwe resultaten geleid? Meer interactie, meer studenten, meer bedrijven in de omgeving. Zijn er al resultaten van deze toename in populariteit?
Maurice: Ik raakte hierin geïnteresseerd toen iemand mij een officiële flyer overhandigde van een bedrijf dat net flink wat geld had ingezameld. Er werd over geschreven , waarmee ik meer dan vertrouwd ben. Wat in de bijsluiter stond, was duidelijk technisch onjuist. De mensen die dit allemaal schreven, begrepen het model achter het probleem niet echt... en toch haalde dit bedrijf veel geld op. Vervolgens heeft het bedrijf deze bijsluiter stilletjes vervangen door een veel correctere versie - en ik zal niet zeggen wat de naam van dit bedrijf was. Ze zijn er nog steeds en doen het heel goed. Dit incident overtuigde mij ervan dat blockchain in de eerste plaats eenvoudigweg een vorm van gedistribueerd computergebruik is. Ten tweede was de instapdrempel (althans toen, vier jaar geleden) vrij laag. De mensen die op dit gebied werkten waren zeer energiek en intelligent, maar lazen geen wetenschappelijke artikelen. Ze probeerden bekende dingen opnieuw uit te vinden en deden het verkeerd. Vandaag is het drama afgenomen.
Alexey: Dit is heel interessant, omdat we een paar jaar geleden een andere trend hadden. Het lijkt een beetje op front-end-ontwikkeling, waarbij browsergebaseerde front-end-ontwikkelaars hele technologieën opnieuw uitvonden die al populair waren in de back-end: systemen bouwen, continue integratie, dat soort dingen.
Maurits: Ik ben het ermee eens. Maar dit is niet verrassend, omdat werkelijk baanbrekende ideeën altijd van buiten de gevestigde gemeenschap komen. Het is onwaarschijnlijk dat gevestigde onderzoekers, vooral gevestigde academici, iets werkelijk baanbrekends zullen doen. Het is gemakkelijk om voor de volgende conferentie een paper te schrijven over hoe u de resultaten van uw eerdere werk enigszins hebt verbeterd. Ga naar een conferentie, kom samen met vrienden, praat over dezelfde dingen. En de mensen die met baanbrekende ideeën binnenstormen, komen vrijwel altijd van buitenaf. Ze kennen de regels niet, ze kennen de taal niet, maar toch... Als je binnen een gevestigde gemeenschap zit, raad ik je aan om aandacht te besteden aan nieuwe dingen, aan iets dat niet in het totaalbeeld past. In zekere zin kan een poging worden gedaan om externe, meer vloeiende ontwikkelingen te combineren met methoden die we al begrijpen. Probeer als eerste stap een wetenschappelijke basis te leggen en deze vervolgens te veranderen, zodat deze kan worden toegepast op nieuwe baanbrekende ideeën. Ik denk dat blockchain geweldig is omdat het een fris, disruptief idee is.
Alexey: Waarom denk je dat dit gebeurt? Omdat mensen ‘buiten’ geen specifieke barrières hebben die inherent zijn aan de gemeenschap?
Maurice: Er is hier een patroon aan de hand. Als je de geschiedenis van de impressionisten op het gebied van de schilderkunst en de kunst in het algemeen leest, hebben beroemde kunstenaars ooit het impressionisme afgewezen. Ze zeiden dat het een beetje kinderachtig was. Een generatie later werd deze voorheen afgewezen kunstvorm de standaard. Wat ik in mijn vakgebied zie: de uitvinders van blockchain waren niet geïnteresseerd in macht, in het verhogen van publicaties en citatie-index, ze wilden gewoon iets goeds doen. En dus gingen ze zitten en begonnen het te doen. Ze misten een bepaalde technische diepgang, maar dat is te verhelpen. Het is veel moeilijker om met nieuwe creatieve ideeën te komen dan om onvoldoende volwassen ideeën te corrigeren en te versterken. Dankzij deze uitvinders heb ik nu iets te doen!
Alexey: Dit is vergelijkbaar met het verschil tussen startups en bestaande projecten. We erven veel beperkingen van ons denken, barrières, speciale vereisten, enzovoort.
Maurice: Een goede analogie is gedistribueerd computergebruik. Beschouw blockchain alsof het een startup is en gedistribueerde computergebruik als een groot, gevestigd bedrijf. Gedistribueerde computers worden momenteel overgenomen en samengevoegd met blockchain.
PhD onder supervisie van Barbara Liskov
Vitaly: We hebben nog veel vragen! We zochten naar je achtergrond en kwamen een interessant weetje over je doctoraat tegen. Ja, dit is lang geleden, maar het lijkt een belangrijk onderwerp te zijn. Je promoveerde onder begeleiding van jezelf ! Barbara is zeer bekend in de programmeertaalgemeenschap en een zeer bekend persoon in het algemeen. Het is logisch dat uw onderzoek zich op het gebied van programmeertalen bevond. Hoe bent u overgestapt op parallel computergebruik? Waarom heb je besloten om van onderwerp te veranderen?
Maurice: Barbara en haar groep keken destijds alleen maar naar gedistribueerd computergebruik, wat een heel nieuw idee was. Er waren ook mensen die zeiden dat gedistribueerd computergebruik onzin was en dat computers die met elkaar communiceerden zinloos was. Een van de problemen die bij gedistribueerd computergebruik worden aangepakt en die het onderscheidt van gecentraliseerd computergebruik, is fouttolerantie. Na veel onderzoek kwamen we tot de conclusie dat een programmeertaal voor gedistribueerde computers zoiets als atomaire transacties moest hebben, omdat je er nooit zeker van kunt zijn dat een oproep op afstand zal slagen. Zodra u transacties heeft, doet zich het probleem van gelijktijdigheidsbeheer voor. Vervolgens werd er veel gewerkt aan het verkrijgen van zeer parallelle transactionele datastructuren. Toen ik afstudeerde, ging ik naar en ging op zoek naar een onderwerp om aan te werken. Het viel me op dat computergebruik is verschoven van individuele computers naar netwerken van computers. Multiprocessors zouden een natuurlijke voortzetting van de vooruitgang zijn; het woord ‘multi-core’ bestond nog niet. Ik dacht: wat is het equivalent van atomaire transacties voor een multi-core systeem? Absoluut geen reguliere transacties omdat ze te groot en zwaar zijn. En zo kwam ik op het idee en zo kwam ik op de hele wachtvrije synchronisatie. Dit was een poging om de vraag te beantwoorden wat de analogie is van atomaire transacties voor een multiprocessorsysteem met gedeeld geheugen. Op het eerste gezicht ziet dit werk er misschien heel anders uit, maar in feite is het een voortzetting van hetzelfde thema.
De wereld wacht op multi-core
Vitaly: Je zei dat er destijds heel weinig multi-core computers waren, toch?
Maurice: Ze waren er gewoon niet. Er waren verschillende zogenaamde symmetrische multiprocessors, die in principe op dezelfde bus waren aangesloten. Dit werkte niet zo goed, want elke keer dat een nieuw bedrijf iets soortgelijks creëerde, bracht Intel een enkele processor uit die superieur was aan de multiprocessor.
Alexey: Betekent dit niet dat het in die oudheid meer een theoretische studie was?
Maurice: Het was geen theoretisch onderzoek, maar eerder een speculatief onderzoek. Dit alles ging niet over het werken met veel stellingen; we brachten eerder hypothesen naar voren over een architectuur die toen nog niet bestond. Daar is onderzoek voor! Geen enkel bedrijf zou zoiets hebben gedaan; het was allemaal iets uit de verre toekomst. In feite was dit het geval tot 2004, toen echte multi-coreprocessors verschenen. Omdat processors oververhit raken, kun je de processor nog kleiner maken, maar niet sneller. Hierdoor was er een overgang naar multi-core architecturen. En toen betekende dat dat er ineens een toepassing was voor alle concepten die we in het verleden hadden ontwikkeld.
Alexey: Waarom denk je dat multi-coreprocessors pas in de jaren XNUMX verschenen? Dus waarom is het zo laat?
Maurice: Dit komt door hardwarebeperkingen. Intel, AMD en andere bedrijven zijn erg goed in het verhogen van de processorsnelheid. Toen de processors op een gegeven moment zo klein werden dat ze de kloksnelheid niet meer konden verhogen omdat de processors doorbrandden. Je kunt ze kleiner maken, maar niet sneller. Wat ligt in hun macht: in plaats van een heel kleine processor kunnen ze acht, zestien of tweeëndertig processors in hetzelfde volume van de behuizing plaatsen, waar voorheen er maar één in kon passen. Nu heb je multithreading en snelle communicatie tussen hen, omdat ze caches delen. Maar je kunt ze niet dwingen sneller te rennen; er is een heel specifieke snelheidslimiet. Ze blijven beetje bij beetje verbeteren, maar niet zoveel meer. De wetten van de natuurkunde stonden verbeteringen in de weg.
Een nieuwe wereld brengt nieuwe problemen met zich mee. NUMA, NVM en architectuurhacking
Alexey: Klinkt heel redelijk. Met nieuwe multi-coreprocessors kwamen er nieuwe problemen. Hadden jij en je collega’s deze problemen verwacht? Misschien heb je ze van tevoren bestudeerd? In theoretische studies is het vaak niet zo eenvoudig om zulke dingen te voorspellen. Wanneer er zich problemen voordeden, hoe voldeden deze dan aan de verwachtingen van u en uw collega’s? Of waren ze compleet nieuw en moesten jij en je collega's veel tijd besteden aan het oplossen van problemen zodra ze zich voordeden?
Vitaly: Ik zal aan de vraag van Alexey toevoegen: heb je de processorarchitectuur correct voorspeld terwijl je de theorie bestudeerde?
Maurice: Niet 100%. Maar ik denk dat mijn collega's en ik goed werk hebben geleverd bij het voorspellen van multi-cores met gedeeld geheugen. Ik denk dat we de moeilijkheden bij het ontwikkelen van parallelle datastructuren die zonder vergrendelingen werken, correct hebben voorspeld. Dergelijke datastructuren zijn voor veel toepassingen belangrijk geweest, hoewel niet voor alle, maar wat je vaak echt nodig hebt is een niet-vergrendelende datastructuur. Toen we ze uitvonden, beweerden velen dat dit onzin was, dat alles prima werkte met sloten. We voorspelden heel goed dat er kant-en-klare oplossingen zouden zijn voor veel programmeerproblemen en datastructuurproblemen. Er waren ook meer complexe problemen, zoals – ongelijke toegang tot het geheugen. Sterker nog, ze werden niet eens overwogen totdat multi-coreprocessors werden uitgevonden, omdat ze te specifiek waren. De onderzoeksgemeenschap werkte aan vragen die over het algemeen voorspelbaar waren. Sommige hardwareproblemen die verband hielden met specifieke architecturen moesten in de coulissen wachten - sterker nog, het verschijnen van deze architecturen. Niemand werkte bijvoorbeeld echt aan GPU-specifieke datastructuren omdat GPU's toen nog niet bestonden. Ondanks dat er veel aan is gewerkt , waren deze algoritmen klaar voor gebruik zodra geschikte hardware beschikbaar kwam. Het is echter onmogelijk om alles te voorzien.
Alexey: Als ik het goed begrijp, is NUMA een soort compromis tussen kosten, prestaties en nog wat andere dingen. Enig idee waarom NUMA zo laat uitkwam?
Maurice: Ik denk dat NUMA bestaat vanwege problemen met de hardware die wordt gebruikt om geheugen te produceren: hoe verder weg de componenten zijn, hoe langzamer het is om er toegang toe te krijgen. Aan de andere kant is de tweede waarde van deze abstractie geheugenuniformiteit. Een van de kenmerken van parallel computergebruik is dus dat alle abstracties enigszins gebroken zijn. Als de toegang volkomen uniform zou zijn, zou al het geheugen op gelijke afstanden liggen, maar dit is economisch, en misschien zelfs fysiek, onmogelijk. Daarom ontstaat dit conflict. Als u uw programma schrijft alsof het geheugen uniform is, zal het hoogstwaarschijnlijk correct zijn. In de zin dat het geen verkeerde antwoorden zal opleveren. Maar ook haar optreden zal de sterren niet uit de lucht halen. Zo ook als je schrijft Zonder de cachehiërarchie te begrijpen, zal de blokkering zelf correct zijn, maar u kunt de prestaties vergeten. In zekere zin moet je programma's schrijven die bovenop een heel eenvoudige abstractie leven, maar je moet de mensen die je die abstractie hebben gegeven te slim af zijn: je moet weten dat er onder de abstractie een bepaalde hiërarchie van het geheugen zit, dat er een bus tussen jou en deze herinnering, enzovoort. Er bestaat dus enig conflict tussen individueel bruikbare abstracties, wat ons tot zeer concrete en pragmatische problemen leidt.
Vitaly: Hoe zit het met de toekomst? Kun je voorspellen hoe processors zich hierna zullen ontwikkelen? Er bestaat een idee dat een van de antwoorden het transactionele geheugen is. Waarschijnlijk heb je nog iets anders op voorraad.
Maurice: Er staan ons een aantal grote uitdagingen te wachten. Eén daarvan is dat het coherente geheugen een prachtige abstractie is, maar dat het in bijzondere gevallen begint af te brokkelen. NUMA is dus bijvoorbeeld een levend voorbeeld van iets waarbij je kunt blijven doen alsof er een uniform geheugen bestaat. Nee, eigenlijk niet, productiviteit zal je aan het huilen maken. Op een gegeven moment zullen architecten het idee van één enkele geheugenarchitectuur moeten laten varen; je kunt niet eeuwig doen alsof. Er zullen nieuwe programmeermodellen nodig zijn die eenvoudig genoeg zijn om te gebruiken en krachtig genoeg om de onderliggende hardware efficiënt te maken. Dit is een heel moeilijk compromis, want als je programmeurs de architectuur laat zien die daadwerkelijk in de hardware wordt gebruikt, worden ze gek. Het is te ingewikkeld en niet draagbaar. Als u een interface presenteert die te eenvoudig is, zullen de prestaties slecht zijn. Er zullen dus veel zeer moeilijke afwegingen moeten worden gemaakt om bruikbare programmeermodellen te verschaffen die toepasbaar zijn op echt grote multi-core processors. Ik weet niet zeker of iemand anders dan een specialist in staat is om te programmeren op een computer met 2000 cores. En tenzij je zeer gespecialiseerd of wetenschappelijk computergebruik of cryptografie of iets dergelijks doet, is het nog steeds helemaal niet duidelijk hoe je het correct moet doen.
Een ander vergelijkbaar gebied zijn gespecialiseerde architecturen. Grafische versnellers bestaan al heel lang, maar ze zijn een klassiek voorbeeld geworden van hoe je een gespecialiseerd type computer kunt gebruiken en dit op een speciale chip kunt laten draaien. Dit voegt zijn eigen uitdagingen toe: hoe je met zo’n apparaat communiceert, hoe je het programmeert. Ik heb de laatste tijd gewerkt aan problemen in de omgeving . Je neemt een kleine processor en plakt deze op een groot stuk geheugen, zodat het geheugen op L1-cachesnelheid draait en vervolgens communiceert met een apparaat zoals – de processor is bezig met het laden van nieuwe taken in uw geheugenkern. Het ontwerpen van datastructuren en communicatieprotocollen voor dit soort dingen is een ander interessant voorbeeld. Aangepaste processors en hardware zullen dus nog geruime tijd verbeteringen blijven zien.
Alexey: Hoe zit het met niet-vluchtig geheugen ()?
Maurice: Oh, dat is nog een mooi voorbeeld! NVM zal de manier waarop we naar zaken als datastructuren kijken enorm veranderen. Niet-vluchtig geheugen belooft in zekere zin de zaken echt te versnellen. Maar het zal het leven er niet eenvoudiger op maken, omdat de meeste processors, caches en registers nog steeds vluchtig zijn. Wanneer u na een crash start, zullen uw toestand en de toestand van uw geheugen niet precies hetzelfde zijn als vóór de crash. Ik ben de mensen die aan NVM werken erg dankbaar; er zal voor onderzoekers nog heel lang genoeg te doen zijn om de correctheidsvoorwaarden te achterhalen. Berekeningen zijn correct als ze een crash kunnen overleven waarbij de inhoud van caches en registers verloren gaat, maar het hoofdgeheugen intact blijft.
Compilers versus processors, RISC versus CISC, gedeeld geheugen versus het doorgeven van berichten
Vladimir: Wat denk je van het dilemma ‘compilers versus processors’ vanuit het oogpunt van instructiesets? Laat me het uitleggen voor degenen die het niet weten: als we naar scheef geheugen of iets dergelijks gaan, kunnen we een heel eenvoudige reeks opdrachten gebruiken en de compiler vragen complexe code te genereren die kan profiteren van de nieuwe voordelen. Of we kunnen de andere kant op gaan: complexe instructies implementeren en de processor vragen de instructies opnieuw te ordenen en er andere manipulaties mee uit te voeren. Wat denk jij ervan?
Maurice: Ik heb niet echt een antwoord op die vraag. Dit debat duurt al vier decennia. Er was een tijd dat er tussen zat een reeks opdrachten en burgeroorlogen werden uitgevochten door een reeks commando's. Een tijdlang wonnen de RISC-mensen, maar daarna herbouwde Intel hun motoren, zodat intern een kleinere set instructies werd gebruikt en de volledige set extern werd geëxporteerd. Dit is waarschijnlijk een onderwerp waarin elke nieuwe generatie haar eigen compromissen moet vinden en haar eigen beslissingen moet nemen. Het is heel moeilijk om te voorspellen welke van deze dingen beter zullen zijn. Dus elke voorspelling die ik doe, zal een bepaalde tijd waar zijn, en dan weer een tijdje onwaar, en dan weer waar.
Alexey: Hoe gebruikelijk is het in de sector dat sommige ideeën tientallen jaren lang winnen en de volgende decennia verliezen? Zijn er andere voorbeelden van dergelijke periodieke veranderingen?
Maurice: Er zijn mensen die erin geloven als het gaat om gedistribueerd computergebruik en mensen die erin geloven . In eerste instantie betekent parallel computergebruik bij gedistribueerd computergebruik het doorgeven van berichten. Toen ontdekte iemand dat het veel gemakkelijker was om te programmeren met gedeeld geheugen. De andere kant zei dat gedeeld geheugen te ingewikkeld is, omdat er sloten en dergelijke voor nodig zijn, dus het is de moeite waard om over te stappen op talen waar niets anders bestaat dan het doorgeven van berichten. Iemand keek naar wat hieruit voortkwam en zei: “Wauw, deze berichtenimplementatie lijkt veel op gedeeld geheugen, omdat je heel veel van deze kleine modules maakt, ze berichten naar elkaar sturen, en ze allemaal “Laten we een betere gedeelde geheugendatabase maken!” Dit alles wordt keer op keer herhaald en het is onmogelijk om te zeggen dat een van de partijen absoluut gelijk heeft. Eén van de partijen zal altijd domineren, want zodra een van hen bijna wint, bedenken mensen keer op keer manieren om de ander te verbeteren.
De kunst van het schrijven van brosse multithreaded code
Alexey: Dit is heel interessant. Wanneer we bijvoorbeeld code schrijven, ongeacht welke programmeertaal, moeten we meestal abstracties creëren zoals cellen die kunnen worden gelezen en geschreven. Maar in feite kan dit op een bepaald fysiek niveau lijken op het verzenden van een bericht via een hardwarebus tussen verschillende computers en andere apparaten. Het blijkt dat er tegelijkertijd op beide abstractieniveaus wordt gewerkt.
Maurice: Het is absoluut waar dat gedeeld geheugen is gebaseerd op het doorgeven van berichten – bussen, caches, enzovoort. Maar het is moeilijk om programma's te schrijven met behulp van het doorgeven van berichten, dus liegt de hardware opzettelijk en doet alsof je een soort uniform geheugen hebt. Dit maakt het gemakkelijker voor u om eenvoudige, correcte programma's te schrijven voordat de prestaties achteruitgaan. Dan zul je zeggen: het lijkt erop dat het tijd is om vrienden te maken met de cache. En dan begin je je zorgen te maken over de locatie van de cache, en vanaf daar gaat het verder. In zekere zin hack je de abstractie: je weet dat het niet alleen om plat, uniform geheugen gaat, en je gaat die kennis gebruiken om cache-vriendelijke programma's te schrijven. Dit is wat je moet doen bij echte problemen. Dit conflict tussen de lieve, eenvoudige, mooie abstractie die je hebt gekregen en de vreselijk complexe implementatie van de onderliggende hardware is waar iedereen zijn eigen compromis zal sluiten. Ik heb een boek over multiprocessors en synchronisatie, en op een gegeven moment wilde ik een hoofdstuk schrijven over datastructuren in java.util.concurrent. Als je naar ze kijkt, dingen zoals Dit zijn geweldige kunstwerken. (Noot van de redactie: degenen die bekend zijn met de Java-taal moeten op zijn minst eens naar de implementatie kijken GelijktijdigeSkipListMap, je kunt de links bekijken op и ). Maar vanuit mijn standpunt zou het onverantwoord zijn om ze aan studenten te laten zien, omdat zo'n datastructuur lijkt op een man in een circus die op een koord over een berenkuil rent. Als je ook maar één klein detail verandert, stort de hele structuur in. Deze code is erg snel en elegant, alleen maar omdat hij perfect is geschreven, maar de kleinste verandering zal tot een volledige mislukking leiden. Als ik deze code als voorbeeld aan studenten geef, zeggen ze meteen: dat kan ik ook! En dan zal er een vliegtuig neerstorten of zal een kernreactor ontploffen, en ik zal me schuldig maken aan het geven van te veel informatie op het verkeerde moment.
Alexey: Toen ik wat jonger was, probeerde ik vaak de broncode van Doug Lee te bestuderen, bijvoorbeeld java.util.concurrent, omdat het open source is, is het heel gemakkelijk om te vinden en te proberen te begrijpen wat daar aan de hand is. Het pakte niet zo goed uit: vaak is het volkomen onduidelijk waarom Doug besloot iets op deze manier te doen, terwijl iedereen het anders doet. Hoe leg je deze dingen uit aan je leerlingen? Is er bijvoorbeeld een bepaalde correcte manier om specifieke details van een hardcore algoritme te beschrijven? Hoe doe je dit?
Maurice: Tekendocenten hebben een cliché dat ze zich het eerst herinneren: als je wilt tekenen zoals Picasso, moet je eerst leren hoe je eenvoudige, realistische afbeeldingen kunt tekenen, en pas als je de regels kent, kun je beginnen ze te overtreden. Als je meteen begint met het overtreden van de regels, kom je in een puinhoop terecht. Ten eerste leer ik studenten hoe ze eenvoudige, correcte code kunnen schrijven zonder zich zorgen te hoeven maken over de prestaties. Wat ik wil zeggen is dat hier complexe timingproblemen op de loer liggen, dus maak je geen zorgen over caches, maak je geen zorgen over geheugenmodellen, zorg er gewoon voor dat alles correct werkt. Dit is al moeilijk genoeg: modern programmeren is op zichzelf niet eenvoudig, zeker niet voor nieuwe studenten. En als ze een intuïtie hebben over hoe ze de juiste programma's moeten schrijven, zeg ik: kijk eens naar deze twee spinlock-implementaties: de ene is erg langzaam, en de tweede is ook niet erg, maar wel beter. Wiskundig gezien zijn de twee algoritmen echter hetzelfde. In feite gebruikt een van hen cachelocatie. Eén ervan draait op lokaal in de cache opgeslagen gegevens, terwijl de andere herhaaldelijk bewerkingen op de bus uitvoert. Je kunt geen efficiënte code schrijven als je niet begrijpt wat het is, en niet weet hoe je de abstractie moet doorbreken en naar de onderliggende structuur kunt kijken. Maar je kunt hier niet meteen mee beginnen. Er zijn mensen die hier meteen mee beginnen en in hun eigen genialiteit geloven, maar meestal loopt het slecht af omdat ze de principes niet begrijpen. Niemand tekent zoals Picasso of schrijft programma's zoals Doug Lee, die in zijn eerste week net van de universiteit komt. Het duurt jaren om dit kennisniveau te bereiken.
Alexey: Het blijkt dat je het probleem in twee delen verdeelt: de eerste is correctheid, de tweede is prestatie?
Maurits: Precies. En precies in die volgorde. Een deel van het probleem is dat nieuwe studenten niet begrijpen dat correctheid moeilijk te bereiken is. Op het eerste gezicht zeggen ze: dit klopt uiteraard, het enige dat overblijft is het versnellen. Dus soms vertel ik ze over een aanvankelijk onjuist algoritme alsof het correct is.
Hoe studenten te leren complexe multithreaded code te schrijven
Alexey: Gewoon om te zien of ze de vangst kunnen voelen?
Maurice: Ik waarschuw altijd vooraf dat ik soms onjuiste algoritmen zal voorstellen. Je moet mensen niet misleiden. Ik stel voor dat ze de informatie met een korreltje zout nemen. Als ik iets vertel en zeg: "kijk, dit is duidelijk correct" - dit is een signaal dat ze je ergens proberen te misleiden, en dat je vragen moet gaan stellen. Vervolgens probeer ik de leerlingen aan te moedigen vragen te blijven stellen, en dan stel ik voor: “Wat gebeurt er als we de dingen laten zoals ze zijn?” En ze zien meteen de fout. Maar studenten ervan overtuigen dat ze zich zorgen moeten maken over de correctheid is veel moeilijker dan het op het eerste gezicht lijkt. Veel van deze leerlingen hebben op de middelbare school programmeerervaring opgedaan, sommigen hebben daar een baan gekregen en hebben daar geprogrammeerd, en ze lopen allemaal vol zelfvertrouwen. Dit is zoiets als het leger: je moet eerst hun humeur veranderen om ze ervan te overtuigen de problemen die zich voordoen geduldig te benaderen. Of misschien is het net als boeddhistische monniken: eerst leren ze redeneren over correctheid, en zodra ze de manieren begrijpen om over correctheid te redeneren, mogen ze naar het volgende niveau gaan en zich zorgen gaan maken over de prestaties.
Alexey: Dat wil zeggen dat je studenten soms niet-werkende voorbeelden laat zien, waardoor je feedback krijgt die laat zien of ze de essentie van het probleem begrijpen, of ze de verkeerde code en het verkeerde resultaat kunnen vinden. Maken studenten je meestal blij of verdrietig?
Maurice: Studenten vinden de fout bijna altijd uiteindelijk. Als ze te langzaam zoeken, stel ik suggestieve vragen, en hier is het belangrijk om te begrijpen dat als je ze nooit misleidt, ze je woorden gedachteloos als de ultieme waarheid zullen gaan zien. Dan vervelen ze zich en vallen ze in slaap terwijl ze tijdens de les Facebook op hun laptop lezen. Maar als je ze van tevoren vertelt dat ze voor de gek gehouden zullen worden, en dat ze er stom uit zullen zien als ze een truc niet doorhebben, worden ze veel waakzamer. Dit is op verschillende manieren goed. Ik zou graag willen dat leerlingen niet alleen hun begrip van de kwestie in twijfel trekken, maar ook de autoriteit van de leraar in twijfel trekken. Het idee is dat een leerling op elk moment zijn hand kan opsteken en zeggen: ik denk dat wat je net zei verkeerd is. Het is een belangrijk leermiddel. Ik wil niet dat een van de studenten stil bij zichzelf gaat zitten denken: dit lijkt allemaal complete onzin, maar je hand opsteken is te eng, en hoe dan ook, hij is een professor, dus alles wat hij zegt is de waarheid. Als ze van tevoren worden gewaarschuwd dat niet alles wat wordt verteld noodzakelijkerwijs waar is, hebben ze dus een prikkel om meer aandacht aan de stof te besteden. Ik maak duidelijk dat het oké is om uw hand op te steken en vragen te stellen. Je vraag klinkt misschien stom of naïef, maar zo ontstaan vaak de beste vragen.
Alexey: Heel interessant. Meestal hebben mensen een soort psychologische barrière waardoor ze geen vraag aan een professor kunnen stellen. Vooral als er veel mensen in de kamer zijn en iedereen bang is dat het bespreken van je stomme vraag al de tijd van deze mensen in beslag zal nemen. Zijn er trucjes om hiermee om te gaan?
Maurice: Ik stop vaak en stel klassieke vragen. Of een uitspraak juist zou zijn, of hoe ze het besproken probleem zouden oplossen. Dit is een belangrijke actie, vooral aan het begin van een les, wanneer mensen zich schamen om zelfs maar het kleinste ding te zeggen. Je stelt de leerlingen een vraag en zegt verder niets. Er valt een stilte, iedereen wordt een beetje gespannen, de spanning neemt toe, dan kan iemand het opeens niet meer uithouden, stort in en zegt het antwoord. Zo draai je de situatie om: blijven zwijgen wordt lastiger en lastiger dan antwoorden! Dit is een standaard pedagogische truc. Elke leraar ter wereld zou moeten weten hoe hij dit moet doen.
Alexey: Nu hebben we een uitstekende titel voor dit interview: “het is gemakkelijker om te antwoorden dan te zwijgen.”
Vitaly: Laat me het nog eens vragen. Je werkt aan topologische bewijzen. Hoe ben je hierbij betrokken geraakt, want gedistribueerd computergebruik en topologie zijn totaal verschillende dingen!
Maurice: Er is daar een verborgen verband. Toen ik wiskunde studeerde, studeerde ik zuivere wiskunde. Ik had geen echte interesse in computers totdat mijn studie ten einde liep en ik geconfronteerd werd met de dringende noodzaak om werk te zoeken. Als student heb ik algebraïsche topologie gestudeerd. Vele jaren later, terwijl ik aan een probleem werkte genaamd Ik gebruikte grafieken om het probleem te modelleren en, zoals het destijds leek, had ik een oplossing gevonden. Je hoefde alleen maar te gaan zitten en de telling te doorlopen. Probeer in deze grafiek een passend antwoord te vinden. Maar mijn algoritme werkte niet: het bleek dat hij voor altijd in cirkels zou blijven rondrennen. Helaas kon dit alles niet worden verklaard in de formele taal van de grafentheorie – de taal die alle computerwetenschappers kennen. En toen herinnerde ik me dat we vele jaren geleden, in de topologielessen, het concept gebruikten , wat een generalisatie is van grafieken naar hogere dimensies. Toen vroeg ik mij af: wat zou er gebeuren als we het probleem zouden herformuleren in termen van simpliciële complexen? Dit werd het sleutelmoment. Door een krachtiger formalisme te gebruiken, wordt het probleem plotseling veel eenvoudiger. Mensen hebben er lange tijd tegen gevochten, met behulp van grafieken, maar ze konden niets doen. En zelfs nu kunnen ze dat niet - het juiste antwoord bleek geen algoritme te zijn, maar een bewijs van de onmogelijkheid om het probleem op te lossen. Dat wil zeggen dat een dergelijk algoritme eenvoudigweg niet bestaat. Maar gebaseerd op simpliciële complexen of op dingen waarvan mensen beweerden dat ze niet als simpliciële complexen werden beschouwd. Alleen al omdat je iets een nieuwe naam geeft, verliest het zijn essentie niet.
Vitaly: Het blijkt dat je gewoon geluk hebt gehad?
Maurice: Naast geluk is dat ook zo готовность. Dit betekent dat je de “nutteloze” dingen die je eerder hebt geleerd niet mag vergeten. Hoe meer nutteloze dingen je leert, hoe meer ideeën je eruit kunt halen als je met een nieuw probleem wordt geconfronteerd. Dit soort intuïtieve patroonmatching is belangrijk omdat... Laten we dit doen, dit is een ketting: in eerste instantie ontdekte ik dat de grafieken helemaal niet of helemaal niet werkten, het deed me denken aan iets uit de gebeurtenissen van acht jaar geleden en mijn studententijd, toen we al deze simpliciële complexen bestudeerden. Hierdoor kon ik mijn oude leerboek over topologie terugvinden en weer in mijn hoofd laden. Maar zonder die oude kennis zou ik nooit enige vooruitgang hebben geboekt bij het oplossen van het oorspronkelijke probleem.
Nieuwe editie van het boek “The Art of Multiprocessor Programming”
Alexey: Je zei een paar woorden over je boek. Het is waarschijnlijk niet het grootste geheim dat je het beroemdste boek ter wereld over multithreading hebt geschreven. . Hij is inmiddels zo'n 11 jaar oud en sindsdien alleen maar uitgebracht . Komt er een tweede editie?
Maurice: Goed dat je het vraagt! Het zal zeer binnenkort zijn, over een maand of drie. Er zijn nog twee auteurs, we hebben veel meer materiaal toegevoegd, de sectie over fork/join parallellisme verbeterd, een sectie over MapReduce geschreven, veel nieuwe dingen toegevoegd en onnodige dingen weggegooid - iets dat erg interessant was op het moment van schrijven de eerste editie, maar is er vandaag niet meer. Het resultaat was een zeer serieus herzien boek.
Alexey: Alles is al gedaan, het enige dat overblijft is het vrijgeven ervan?
Maurice: Een paar hoofdstukken hebben nog wat werk nodig. Onze uitgever (die ons volgens mij nu al haat) probeert nog steeds de boodschap over te brengen dat we sneller moeten werken. We liggen ver achter op schema. Theoretisch hadden we dit boek een paar jaar eerder kunnen maken.
Alexey: Is er een kans om vóór Kerstmis een nieuwe versie van het boek te krijgen?
Maurice: Dit is ons doel! Maar ik heb de overwinning zo vaak voorspeld dat niemand me meer gelooft. Ook in deze kwestie moet je mij waarschijnlijk niet te veel vertrouwen.
Alexey: Hoe dan ook, dit is fantastisch nieuws. Ik vond de eerste editie van het boek erg leuk. Je zou kunnen zeggen dat ik een fan ben.
Maurice: Ik hoop dat de nieuwe editie jouw vurige enthousiasme waard zal zijn, dank je wel!
Hoe transactioneel geheugen werd uitgevonden
Vitaly: De volgende vraag gaat over het transactionele geheugen. Voor zover ik het begrijp ben je een pionier op dit gebied, je hebt het uitgevonden in een tijd dat niemand aan zulke dingen dacht. Waarom heb je besloten om in dit vakgebied te gaan werken? Waarom leken transacties belangrijk voor u? Dacht je dat ze ooit in hardware zouden worden geïmplementeerd?
Maurice: Ik ben al sinds mijn afstudeeronderzoek op de hoogte van transacties.
Vitaly: Ja, maar dit zijn verschillende transacties!
Maurice: Ik heb met Elliott Moss samengewerkt aan een niet-blokkerende afvalinzameling. Ons probleem was dat we een paar woorden in het geheugen atomair wilden veranderen, waardoor de algoritmen heel eenvoudig zouden worden, en op zijn minst enkele daarvan efficiënter zouden worden. Gebruik makend van voor Door de parallelle architectuur is het mogelijk om iets te doen, maar het is erg inefficiënt en lelijk omdat je te maken zou krijgen met lagen van indirectheid. Ik wil geheugenwoorden veranderen en ik moet overschakelen omdat ik maar één aanwijzer kan veranderen, dus ze moeten naar een soort directory-achtige structuur verwijzen. We spraken erover hoe geweldig het zou zijn als we de hardware konden veranderen, zodat er gelijktijdig opgenomen kon worden. Elliott lijkt dit te hebben opgemerkt: als je naar cache-coherentieprotocollen kijkt, bieden ze al de meeste vereiste functionaliteit. Bij een optimistische transactie zal het cache-coherentieprotocol merken dat er een timingconflict is en zal de cache veranderen . Wat gebeurt er als u speculatief een transactie op uw cache uitvoert en de mechanismen van het coherentieprotocol gebruikt om conflicten op te sporen? Speculatieve hardware-architectuur was eenvoudig te ontwerpen. Dus die hebben we geschreven over transactioneel geheugen. Tegelijkertijd was het bedrijf waar ik voor werkte, Digital Equipment Corporation, bezig met het creëren van een nieuwe 64-bits processor genaamd Alpha. Dus ging ik een presentatie geven aan de Alpha-ontwikkelingsgroep over ons verbazingwekkende transactionele geheugen en zij vroegen: Hoeveel extra inkomsten zou ons bedrijf krijgen als we dit allemaal rechtstreeks aan de processor zouden toevoegen? En ik had hier absoluut geen antwoord op, omdat ik een technoloog ben en geen marketingspecialist. Ik had werkelijk niets te antwoorden. Ze waren niet erg onder de indruk dat ik niets wist.
Vitaly: Miljarden! Zeg maar miljarden!
Maurice: Ja, dat had ik moeten zeggen. Nu, in het tijdperk van startups en zo, weet ik hoe ik een businessplan moet schrijven. Dat je een beetje kunt liegen over de omvang van je potentiële winst. Maar in die tijd leek het naïef, dus zei ik alleen maar: ‘Ik weet het niet.’ Als je naar de geschiedenis van de publicatie over transactioneel geheugen kijkt, zul je merken dat er na een jaar verschillende verwijzingen naar waren, en dat gedurende ongeveer tien jaar helemaal niemand dit artikel citeerde. De citaten verschenen rond 2004, toen echte multi-cores verschenen. Toen mensen ontdekten dat het schrijven van parallelle code geld kon opleveren, begon nieuw onderzoek. Ravi Rajwar , die op de een of andere manier het concept van transactioneel geheugen in de mainstream introduceerde. (Noot van de redactie: er is een tweede versie van dit artikel, uitgebracht in 2010 en gratis beschikbaar ). Plots beseften mensen hoe dit allemaal precies gebruikt kon worden, hoe traditionele algoritmen met sloten versneld konden worden. Een goed voorbeeld van iets dat in het verleden slechts een interessant academisch probleem leek. En ja, als je mij destijds had gevraagd of ik dacht dat dit allemaal van belang zou zijn in de toekomst, dan had ik gezegd: natuurlijk, maar wanneer precies is niet duidelijk. Misschien over 50 jaar? In de praktijk bleek dit slechts een decennium te zijn. Het is heel leuk als je iets doet en al na tien jaar merken mensen het.
Waarom het de moeite waard is om onderzoek te doen op het gebied van gedistribueerd computergebruik
Vitaly: Als we het over nieuw onderzoek hebben, wat zou je de lezers dan adviseren: gedistribueerd computergebruik of multi-core, en waarom?
Maurice: Tegenwoordig is het gemakkelijk om een multi-coreprocessor te krijgen, maar het is moeilijker om een echt gedistribueerd systeem op te zetten. Ik ben ermee begonnen omdat ik iets anders wilde doen dan mijn proefschrift. Dit is het advies dat ik altijd aan nieuwe studenten geef: schrijf geen vervolg op je proefschrift, maar probeer een nieuwe richting in te slaan. En bovendien is multithreading eenvoudig. Ik kan experimenteren met mijn eigen vork op mijn laptop zonder uit bed te komen. Maar als ik plotseling een echt gedistribueerd systeem zou willen creëren, zou ik veel werk moeten verzetten, studenten moeten aantrekken, enzovoort. Ik ben een lui persoon en werk liever aan multi-core. Experimenteren op multi-core systemen is ook gemakkelijker dan experimenten op gedistribueerde systemen, omdat er zelfs in een dom gedistribueerd systeem te veel factoren zijn die moeten worden gecontroleerd.
Vitaly: Wat doe je nu, blockchain onderzoeken? Op welke artikelen moet u eerst letten?
Maurice: Onlangs verschenen , die ik samen met mijn leerling, Vikram Saraf, speciaal voor een lezing schreef in Parijs drie weken geleden. Dit is een artikel over praktische gedistribueerde systemen, waarin we voorstellen om Ethereum multi-threaded te maken. Momenteel worden slimme contracten (code die op de blockchain draait) sequentieel uitgevoerd. We schreven eerder een artikel waarin werd gesproken over een manier om speculatieve transacties te gebruiken om het proces te versnellen. We hebben veel ideeën uit het transactionele softwaregeheugen gehaald en gezegd dat als je deze ideeën onderdeel maakt van de virtuele Etherium-machine, alles sneller zal werken. Maar hiervoor is het noodzakelijk dat er geen gegevensconflicten in de contracten staan. En toen gingen we ervan uit dat dergelijke conflicten in het echte leven eigenlijk niet bestaan. Maar we konden er op geen enkele manier achter komen. Toen kwam het bij ons op dat we bijna een decennium aan echte contractgeschiedenis in handen hadden, dus dumpten we de Ethereum-blockchain en vroegen ons af: wat zou er gebeuren als deze historische gegevens parallel zouden worden uitgevoerd? We constateerden een aanzienlijke snelheidstoename. In de begindagen van Ethereum is de snelheid enorm toegenomen, maar tegenwoordig is alles wat ingewikkelder, omdat er minder contracten zijn en de kans op conflicten over gegevens die serialisatie vereisen groter is geworden. Maar dit is allemaal experimenteel werk met echte historische gegevens. Het leuke van de blockchain is dat hij alles voor altijd onthoudt, zodat we terug in de tijd kunnen gaan en kunnen bestuderen wat er zou zijn gebeurd als we andere algoritmen hadden gebruikt om de code uit te voeren. Hoe zouden mensen in het verleden ons nieuwe idee hebben gevonden? Dergelijk onderzoek is veel gemakkelijker en leuker om te doen, omdat er iets is dat alles in de gaten houdt en alles registreert. Dit lijkt al meer op de sociologie dan op de ontwikkeling van algoritmen.
Is de ontwikkeling van algoritmen gestopt en hoe moeten we verder?
Vitaly: Tijd voor de laatste theoretische vraag! Heeft u het gevoel dat de vooruitgang op het gebied van concurrerende datastructuren elk jaar afneemt? Denkt u dat we een plateau hebben bereikt in ons begrip van datastructuren of zullen er enkele belangrijke verbeteringen plaatsvinden? Misschien zijn er slimme ideeën die alles volledig kunnen veranderen?
Maurice: Mogelijk hebben we een plateau bereikt in de datastructuren voor traditionele architecturen. Maar datastructuren voor nieuwe architecturen zijn nog steeds een veelbelovend gebied. Als je datastructuren wilt maken voor bijvoorbeeld hardwareversnellers, dan zijn de datastructuren voor een GPU heel anders dan de datastructuren voor een CPU. Wanneer je datastructuren voor blockchains ontwikkelt, moet je stukjes data hashen en ze vervolgens in zoiets als , om namaak te voorkomen. Er is de laatste tijd sprake van een enorme activiteit op dit gebied, waarbij velen zeer goed werk verrichten. Maar ik denk dat wat er zal gebeuren is dat nieuwe architecturen en nieuwe toepassingen tot nieuwe datastructuren zullen leiden. Oudere toepassingen en traditionele architectuur: er is misschien niet veel ruimte meer voor onderzoek. Maar als je buiten de gebaande paden gaat en verder kijkt dan de randen, zul je gekke dingen zien die de mainstream niet serieus neemt – dat is waar alle opwindende dingen echt gebeuren.
Vitaly: Daarom moest ik, om een zeer beroemde onderzoeker te worden, mijn eigen architectuur uitvinden :)
Maurice: Je kunt de nieuwe architectuur van iemand anders "stelen" - het lijkt veel gemakkelijker!
Werkt bij Brown University
Vitaly: Kunt u ons daar meer over vertellen? waar werk je? Er is niet veel over hem bekend in de context van informatietechnologie. Minder dan over MIT bijvoorbeeld.
Maurice: Brown University is een van de oudste universiteiten in de Verenigde Staten. Ik denk dat alleen Harvard iets ouder is. Brown maakt deel uit van de zogenaamde , een verzameling van acht oudste universiteiten. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Het is een beetje een oude, kleine en een beetje aristocratische universiteit. De nadruk ligt vooral op het vrije kunstonderwijs. Het probeert niet zoals MIT te zijn, MIT is zeer gespecialiseerd en technisch. Brown is een geweldige plek om Russische literatuur of Klassiek Grieks te studeren, en natuurlijk informatica. Het richt zich op integraal onderwijs. De meeste van onze studenten gaan naar Facebook, Apple, Google - dus ik denk dat onze studenten geen problemen hebben met het vinden van een baan in de branche. Ik ging bij Brown werken omdat ik eerder bij Digital Equipment Corporation in Boston had gewerkt. Dit was een bedrijf dat veel interessante dingen uitvond, maar het belang van personal computers ontkende. Een bedrijf met een moeilijk lot, waarvan de oprichters ooit jonge revolutionairen waren. Ze leerden niets en vergaten niets, en dus veranderden ze binnen ongeveer twaalf jaar van revolutionairen in reactionairen. Ze maakten er graag grapjes over dat pc's in de garage thuishoorden - een verlaten garage natuurlijk. Het is overduidelijk dat ze zijn vernietigd door flexibelere bedrijven. Toen duidelijk werd dat het bedrijf in de problemen zat, belde ik een vriend van mij in Brown, ongeveer een uur buiten Boston. Ik wilde Boston destijds niet verlaten omdat er niet veel vacatures waren bij andere universiteiten. Dit was een tijd waarin er nog niet zoveel banen in de informatica waren als nu. En Brown had een vacature, ik hoefde mijn huis niet te verhuizen, ik hoefde mijn gezin niet te verhuizen, en ik vind het echt heerlijk om in Boston te wonen! Zo besloot ik naar Brown te gaan. Ik vind het leuk. De studenten zijn geweldig, dus ik heb zelfs nooit geprobeerd ergens anders heen te gaan. Tijdens mijn sabbatical heb ik een jaar bij Microsoft gewerkt, een jaar naar Technion in Haifa geweest en nu zit ik bij Algorand. Ik heb overal veel collega's en daarom is de fysieke locatie van onze klaslokalen niet zo belangrijk. Maar het allerbelangrijkste zijn de studenten, zij zijn hier de beste. Ik heb nooit geprobeerd ergens anders heen te gaan, want ik ben hier best gelukkig.
Maar ondanks Browns bekendheid in de Verenigde Staten is hij in het buitenland verrassend onbekend. Zoals u kunt zien, doe ik er nu alles aan om deze situatie recht te zetten.
Verschil tussen onderzoek aan een universiteit en binnen een bedrijf
Vitaly: Oké, de volgende vraag gaat over digitale apparatuur. Jij was daar als onderzoeker. Wat is het verschil tussen werken op de R&D-afdeling van een groot bedrijf en werken aan een universiteit? Wat zijn de voor- en nadelen?
Maurice: Twintig jaar heb ik bij Microsoft gewerkt, nauw samengewerkt met medewerkers van Sun Microsystems, Oracle, Facebook en nu Algorand. Op basis van dit alles wil ik zeggen dat het mogelijk is om eersteklas onderzoek te doen, zowel in bedrijven als aan universiteiten. Het belangrijke verschil is dat je in een bedrijf samenwerkt met collega’s. Als ik ineens een idee heb voor een project dat nog niet bestaat, moet ik mijn collega’s ervan overtuigen dat dit een goed idee is. Als ik bij Brown ben, kan ik tegen mijn studenten zeggen: laten we werken aan anti-zwaartekracht! Ze vertrekken naar iemand anders of nemen een project aan. Ja, ik zal financiering moeten vinden, ik zal een subsidieaanvraag moeten schrijven, enzovoort. Er zullen sowieso altijd veel studenten zijn en je kunt eenzijdig beslissingen nemen. Maar op de universiteit werk je waarschijnlijk niet met mensen van jouw niveau. In de wereld van industrieel onderzoek moet je eerst iedereen ervan overtuigen dat jouw project de moeite waard is. Ik kan aan niemand iets bestellen. En beide manieren van werken zijn waardevol, want als je aan iets heel geks werkt en je collega's moeilijk te overtuigen zijn, is het gemakkelijker om afgestudeerde studenten te overtuigen - vooral als je ze betaalt. Als je aan iets werkt dat veel ervaring en diepgaande expertise vereist, dan heb je collega's nodig die kunnen zeggen: "Nee, het is zo dat ik het op dit gebied begrijp en je idee slecht is, het zal niet werken." Dit is erg handig als het gaat om tijdverspilling. En als je in industriële laboratoria veel tijd besteedt aan het schrijven van rapporten, dan besteed je deze tijd op een universiteit aan het zoeken naar geld. Als ik wil dat studenten ergens heen kunnen, moet ik het geld daarvoor ergens anders vinden. En hoe belangrijker je positie op de universiteit, hoe meer tijd je moet besteden aan het inzamelen van geld. Dus nu weet je waar ik voor werk: een professionele bedelaar! Zoals zo'n monnik die met een offerschaal rondloopt. Over het algemeen vullen deze twee activiteiten elkaar aan. Daarom probeer ik in beide werelden te leven en met beide voeten op de grond te blijven.
Vitaly: Het lijkt erop dat het overtuigen van een bedrijf moeilijker is dan het overtuigen van andere wetenschappers.
Maurice: Moeilijker, en nog veel meer. Bovendien is het op verschillende gebieden anders: sommigen doen grootschalig onderzoek, terwijl anderen zich op hun onderwerp concentreren. Als ik naar Microsoft of Facebook zou gaan en zou zeggen: laten we anti-zwaartekracht maken, zouden ze dat nauwelijks op prijs stellen. Maar als ik precies hetzelfde tegen mijn afgestudeerde studenten zou zeggen, zouden ze hoogstwaarschijnlijk meteen aan de slag gaan, hoewel ik nu problemen zou krijgen - ik moet hier tenslotte geld voor vinden. Maar zolang je iets wilt doen dat aansluit bij de doelstellingen van het bedrijf, kan dat bedrijf een zeer goede plek zijn om onderzoek te doen.
Hydra en SPTDC
Vitaly: Mijn vragen lopen ten einde, dus laten we het even hebben over de aanstaande reis naar Rusland.
Maurice: Ja, ik kijk ernaar uit om terug te keren naar St. Petersburg.
Alexey: Ik ben vereerd dat je dit jaar bij ons bent. Dit is je tweede keer in Sint-Petersburg, toch?
Maurice: Al de derde!
Alexey: Ik begrijp het, maar – zeker de tweede. De laatste keer werd de school gebeld , hebben we nu één letter gewijzigd (C in D, Concurrent in Distributed) om te benadrukken dat er dit jaar meer gebieden zijn die specifiek verband houden met gedistribueerd computergebruik. Kunt u iets zeggen over uw rapporten op de school en ?
Maurice: Op de school wil ik het hebben over de basisprincipes van blockchain en wat je ermee kunt doen. Ik zou willen laten zien dat blockchains sterk lijken op de multi-threaded programmering waarmee we bekend zijn, maar met hun eigen nuances, en deze verschillen zijn belangrijk om te begrijpen. Als je in een reguliere webapplicatie een fout maakt, is dat gewoon vervelend. Als u foutieve code in een financiële toepassing schrijft, zal iemand zeker al uw geld stelen. Dit zijn totaal verschillende niveaus van verantwoordelijkheid en gevolgen. Ik zal het even hebben over proof-of-work, over slimme contracten, over transacties tussen verschillende blockchains.
Naast mij zullen er nog andere sprekers werken die ook iets te zeggen hebben over blockchain, en we hebben afgesproken om met elkaar af te stemmen zodat onze verhalen goed bij elkaar passen. Maar voor het technische rapport wil ik een breed publiek een begrijpelijke uitleg geven over waarom je niet alles moet geloven wat je over blockchains hoort, waarom blockchains een geweldig vakgebied zijn, hoe het aansluit bij andere bekende ideeën, en waarom we moedig moeten zoeken naar de toekomst.
Alexey: Daarnaast wil ik zeggen dat dit niet zal plaatsvinden in de vorm van een bijeenkomst of gebruikersgroep, zoals twee jaar geleden. We besloten een kleine conferentie in de buurt van de school te houden. De reden is dat we na communicatie met Peter Kuznetsov beseften dat de school beperkt is tot slechts honderd, misschien 120 mensen. Tegelijkertijd zijn er veel ingenieurs die met u willen communiceren, presentaties willen bijwonen en over het algemeen geïnteresseerd zijn in het onderwerp. Om deze reden hebben we een nieuwe conferentie gecreëerd . Trouwens, enig idee waarom Hydra?
Maurice: Omdat er zeven sprekers zullen zijn? En hun hoofden kunnen worden afgehakt en er zullen nieuwe luidsprekers in hun plaats groeien?
Alexey: Geweldig idee om nieuwe luidsprekers te laten groeien. Maar in feite is er hier een verhaal. Denk aan de legende van Odysseus, waar hij tussendoor moest varen ? Hydra lijkt op Charybdis. Het verhaal is dat ik ooit op een conferentie sprak en sprak over multithreading. Er waren slechts twee tracks op deze conferentie. Aan het begin van de reportage vertelde ik het publiek in de zaal dat ze nu de keuze hebben tussen Scylla en Charybdis. Mijn geestdier is Charybdis omdat Charybdis veel hoofden heeft en mijn thema multi-threading is. Dit is hoe de namen van conferenties verschijnen.
Hoe dan ook, onze vragen en tijd zijn op. Dus bedankt, vrienden, voor een geweldig interview, en tot ziens op SPTDC School en Hydra 2019!
U kunt uw gesprek met Maurice voortzetten op de Hydra 2019-conferentie, die wordt gehouden op 11-12 juli 2019 in St. Petersburg. Hij komt met een rapport . Er kunnen kaartjes worden gekocht .
Bron: www.habr.com