- als hoogleraar computerwetenschappen aan de Universiteit van Rochester, en aan de Universiteit van Wisconsin-Madison bij hem thuis, was hij vijf jaar decaan. Hij onderzoekt en onderwijst studenten over parallelle en gedistribueerde programmering en taalontwerp.
De wereld kent Michael uit het leerboek , En werk dan ontving de Dijkstra-prijs als een van de bekendste op het gebied van gedistribueerd computergebruik. Je kent hem misschien ook als de auteur van datzelfde algoritme .
Samen met Doug Lee ontwikkelde hij de niet-blokkerende algoritmen en synchrone wachtrijen die de Java-bibliotheken aandrijven. Implementatie in JavaSE 6 verbeterde de prestatie met 10 keer ThreadPoolExecutor.
Inhoud:
- Vroege carrière, Universiteit van Rochester. Project Charlotte, Lynx-taal;
- IEEE schaalbare coherente interface, MCS-vergrendeling;
- Overleven in een steeds veranderende wereld;
- Worden studenten dommer? Mondiale trends, internationalisering;
- Effectief werken met studenten;
- Hoe je de voorbereiding van nieuwe cursussen en boeken kunt bijhouden;
- Verbindingen tussen het bedrijfsleven en de academische wereld;
- Praktische implementatie van ideeën. MCS, MS, CLH, JSR 166, in samenwerking met Doug Lee en meer;
- Transactioneel geheugen;
- Nieuwe architecturen. De overwinning van het transactionele geheugen is nabij;
- Niet-vluchtig geheugen, Optane DIMM, ultrasnelle apparaten;
- De volgende grote trend. Dubbele datastructuren. Hydra.
Het interview wordt afgenomen door:
Vitaly Aksenov — momenteel postdoc bij IST Oostenrijk en lid 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.
Vroege carrière, Universiteit van Rochester. Charlotte-project, Lynx-taal.
Alexey: Om te beginnen wilde ik je vertellen dat we in Rusland allemaal heel erg van computerwetenschappen, datawetenschap en algoritmen houden. Het is ronduit obsceen. Wij hebben alles gelezen . Daarom zouden de komende conferentie, school en dit interview zelf erg populair moeten zijn. We hebben voor dit interview veel vragen ontvangen van studenten, programmeurs en leden van de gemeenschap, dus we zijn erg dankbaar voor deze kans. Krijgt Computer Science dezelfde liefde in de VS?
Michael: Ons vakgebied is zo divers, het heeft zoveel richtingen en het beïnvloedt de samenleving op zoveel verschillende manieren dat het voor mij moeilijk is om u een definitief antwoord te geven. Maar feit is dat het de afgelopen dertig jaar enorme veranderingen heeft teweeggebracht in het bedrijfsleven, de industrie, de kunst en de samenleving in het algemeen.
Виталий: Laten we beginnen met iets ver weg. Op veel universiteiten bestaat er zoiets als specialisatie op een bepaald gebied. Voor Carnegie Mellon University is dit parallel computing, voor MIT is het cryptografie, robots en multithreading. Bestaat er een dergelijke specialisatie aan de Universiteit van Rochester?
Michael: Om eerlijk te zijn zou ik zeggen dat CMU en MIT zich op alle gebieden specialiseren. Onze afdeling heeft altijd de meeste aandacht besteed aan kunstmatige intelligentie. De helft van de mensen die voor ons werken, houdt zich bezig met AI of mens-computerinteractie – dit aandeel is hoger dan op andere afdelingen, en dat is altijd zo geweest. Maar toen ik op de universiteit zat, heb ik geen cursussen in AI gevolgd, en ik heb nooit in dit vakgebied gewerkt. Mijn afdeling is dus gespecialiseerd in een probleem waar ik niets mee te maken heb. De troost is dat het op één na belangrijkste probleem voor onze afdeling parallelle en multi-threaded programmering is, dat wil zeggen mijn specialisatie.
Виталий: Je begon te werken in de computerwetenschappen toen het vakgebied van multi-threaded programmeren net in opkomst was. Uit de lijst van uw publicaties blijkt dat uw eerste werken een vrij breed scala aan onderwerpen behandelden: geheugenbeheer in systemen met meerdere threads, gedistribueerde bestandssystemen, besturingssystemen. Waarom zo’n veelzijdigheid? Heeft u geprobeerd uw plek in de onderzoeksgemeenschap te vinden?
Michael: Als student heb ik hieraan deelgenomen aan de Universiteit van Wisconsin, waar een van de eerste gedistribueerde besturingssystemen werd ontwikkeld. Daar werkte ik samen met Rafael Finkel () en Marvin Salomon (). Mijn proefschrift was gewijd aan de ontwikkeling van een taal voor systeemsoftware voor gedistribueerde systemen - nu is iedereen het vergeten, en godzijdank. Ik heb de programmeertaal Lynx gemaakt, die bedoeld was om het eenvoudiger te maken servers te maken voor een losjes gekoppeld gedistribueerd besturingssysteem. Omdat ik me destijds vooral bezighield met besturingssystemen, ging ik ervan uit dat mijn carrière daar vooral mee te maken zou hebben. Maar Rochester was een heel kleine universiteit en daardoor stonden de verschillende groepen daar heel nauw met elkaar samen. Er waren niet een tiental mensen met andere besturingssystemen waarmee ik kon praten, dus al mijn contacten waren met mensen die op totaal verschillende gebieden werkten. Ik heb er echt van genoten, een allrounder zijn is voor mij een groot voordeel. Als we het specifiek hebben over multi-threaded datastructuren en synchronisatie-algoritmen, dan begon ik er volledig per ongeluk aan te werken.
IEEE schaalbare coherente interface, MCS-vergrendeling.
Виталий: Kunt u mij hier iets meer over vertellen?
Michael: Dit is een grappig verhaal dat ik nooit moe word om het aan iedereen te vertellen. Het gebeurde op een conferentie in Boston - dit was eind jaren 80 of begin jaren 90. John Mellor-Crummey (), een afgestudeerde van onze faculteit. Ik kende hem, maar we hadden nog niet eerder gezamenlijk onderzoek gedaan. Maria Vernon () uit Wisconsin gaven een lezing over een multiprocessorsysteem dat ze in Wisconsin aan het ontwikkelen waren: . Deze Multicube had een synchronisatiemechanisme op hardwareniveau genaamd de Q on Sync Bit, en later werd hij omgedoopt tot de Q on Lock Bit omdat het klonk als Colby-kaas, wat een woordspeling was. Als je geïnteresseerd bent in multithreading-mechanismen, weet je waarschijnlijk dat Colby uiteindelijk de synchronisatie-engine werd voor de IEEE Scalable Coherent Interface-standaard. Dit was een vergrendelingsmechanisme dat op hardwareniveau verwijzingen creëerde van de ene cache naar de andere, zodat elke slothouder wist wie aan de beurt was. Toen John en ik hiervan hoorden, keken we elkaar aan en zeiden: waarom doen we dit op hardwareniveau? Kan hetzelfde niet worden bereikt met behulp van 'vergelijken en ruilen'? We pakten een van de notitieboekjes die in de klas lagen en krabbelden erop , terwijl Mary haar rapport voortzette. Vervolgens hebben we het geïmplementeerd, geëxperimenteerd, het idee bleek succesvol en we hebben het artikel gepubliceerd. Destijds leek dit onderwerp voor mij gewoon een leuke afleiding, waarna ik van plan was terug te keren naar de besturingssystemen. Maar toen deed zich een ander probleem in dezelfde trant voor, en uiteindelijk werden synchronisatie, multithreading en datastructuren mijn specialiteit. Zoals je kunt zien, gebeurde dit allemaal per ongeluk.
Виталий: Ik ben al heel lang bekend met MCS-blokkering, maar tot nu toe wist ik niet dat het jouw werk was en begreep ik niet dat het een acroniem was voor je achternaam.
Hoe overleven in een steeds veranderende wereld?
Alexey: Ik heb een vraag over een gerelateerd onderwerp. 30 of 40 jaar geleden was er meer vrijheid in verschillende specialismen. Als je een carrière wilt beginnen in multithreading of gedistribueerde systemen, dan ben je welkom. Als je je wilt verdiepen in besturingssystemen, geen probleem. Op elk gebied waren er veel open vragen en weinig experts. Er zijn inmiddels smalle specialisaties ontstaan: er zijn niet alleen experts op het gebied van besturingssystemen in het algemeen, er zijn specialisten op het gebied van individuele systemen. Hetzelfde geldt voor multithreading en gedistribueerde systemen. Maar het probleem is dat onze levens niet eindeloos zijn; iedereen kan slechts enkele decennia aan onderzoek besteden. Hoe te overleven in deze nieuwe wereld?
Michael: Wij zijn in dit opzicht niet bijzonder; op andere gebieden is hetzelfde al eens gebeurd. Ik had het geluk dat ik in de computerwetenschappen begon te werken toen het vakgebied zich nog in de tienerjaren bevond. Sommige fundamenten waren al gelegd, maar alles was nog erg onvolwassen. Deze kans komt niet vaak voorbij. Elektrotechniek bestaat al heel lang, natuurkunde nog langer, wiskunde bijna sinds het begin der tijden. Maar dit betekent niet dat niemand meer interessante ontdekkingen in de wiskunde doet. Er zijn nog steeds veel openstaande problemen, maar tegelijkertijd moet er meer worden geleerd. U hebt gelijk als u opmerkt dat er nu veel meer specialisaties zijn dan voorheen, maar dit betekent alleen maar dat we ons in dezelfde situatie bevinden als de meeste andere gebieden van menselijke activiteit.
Alexey: Ik ben geïnteresseerd in het meer praktische aspect van de kwestie hier. Ik heb een wiskundeachtergrond en tijdens mijn studie bezocht ik vaak conferenties en werkte ik aan verschillende wetenschappelijke onderwerpen. Ik ontdekte dat niemand in het publiek mijn verslagen begreep, en op dezelfde manier waren de verslagen van andere mensen alleen voor henzelf begrijpelijk. Bij onderwerpen op hoog niveau is dat niet het geval, maar zodra je je ergens in gaat verdiepen, kan het publiek je niet meer bijhouden. Hoe ga je hiermee om?
Michael: Niet altijd succesvol. Ik heb onlangs een rapport opgesteld waarin ik te diep op technische details ben ingegaan. Naarmate de lezing vorderde, werd het duidelijk dat het grootste deel van het publiek mij niet begreep, dus moest ik mij ter plekke aan de situatie aanpassen. De dia's konden niet worden gewijzigd, dus het pakte niet zo goed uit - dus over het algemeen probeer ik geen dia's te gebruiken. Over het algemeen is mijn advies om rekening te houden met uw publiek. Je moet weten met wie je praat, wat hun kennisniveau is en wat ze moeten horen om je werk te waarderen.
Виталий: Kunt u ons een hint geven waar deze lezing over ging?
Michael: Eerlijk gezegd ga ik liever niet verder in op dit onderwerp om de personen in kwestie anoniem te laten. Het punt is dat we vaak te diep ingaan op de complexiteit van het probleem waaraan we werken, waardoor het moeilijk voor ons wordt om aan het begin van de lezing uit te leggen waarom het probleem interessant en belangrijk is en hoe het zich verhoudt tot kwesties die de publiek weet het al. Volgens mijn observaties hebben studenten het moeilijkst om deze vaardigheid te leren. En dit was ook meteen het zwakke punt van mijn recente rapport. Een goed gestructureerd rapport moet vanaf het allereerste begin contact maken met het publiek, hen uitleggen wat het probleem precies is en hoe dit zich verhoudt tot onderwerpen die al bij het publiek bekend zijn. Hoe technisch deze introductie is, hangt af van het publiek. Als het helemaal bont is, kan het rapport uit meerdere fasen bestaan. De inleiding moet voor iedereen toegankelijk zijn, en tegen het einde kan het stuk je misschien niet meer bijbenen, maar mensen die relatief bekend zijn met jouw vakgebied zullen het wel kunnen begrijpen.
Worden studenten dommer? Mondiale trends, internationalisering.
Alexey: Je observeert studenten al tientallen jaren. Worden studenten van decennium tot decennium of van jaar tot jaar dommer of slimmer? In Rusland klagen professoren voortdurend dat studenten elk jaar dommer worden, en het is eigenlijk niet duidelijk wat we daaraan moeten doen.
Michael: Je hoort echt veel negativiteit van ons, oude mensen. Onbewust hebben we de neiging om van studenten te verwachten dat ze alle dertig jaar ervaring die we al hebben, in zich opnemen. Als ik een dieper begrip heb dan in 30, waarom hebben de studenten dat dan niet? Waarschijnlijk omdat ze 1985 jaar oud zijn, wat denk jij? Ik denk dat de belangrijkste veranderingen van de afgelopen decennia te maken hebben met de demografische samenstelling: we hebben nu aanzienlijk meer internationale studenten, met uitzondering van Canadezen. Vroeger waren er veel Canadezen omdat we heel dicht bij de Canadese grens zitten en studenten van daaruit in het weekend naar huis kunnen reizen. Maar nu zijn er veel goede universiteiten in Canada, en Canadezen studeren hier het liefst; aanzienlijk minder van hen komen naar de VS.
Alexey: Denkt u dat dit een lokale trend is of een mondiale trend?
Michael: Ik weet niet meer precies wie, maar iemand zei dat de wereld plat is. Ons vakgebied is veel internationaler geworden. Voorheen werden ze uitsluitend in de Verenigde Staten gehouden, daarna besloten ze ze eens in de vier jaar in andere landen te houden, en nu worden ze over de hele wereld gehouden. Deze veranderingen hadden nog meer gevolgen , omdat het altijd een meer internationale organisatie is geweest dan de ACM. En er zijn programmavoorzitters uit China, India, Rusland, Duitsland en vele andere landen, want er gebeurt nu overal veel.
Alexey: Maar waarschijnlijk zijn er ook enkele negatieve aspecten aan een dergelijke internationalisering?
Michael: Ik zou zeggen dat alle negatieve aspecten geen betrekking hebben op de technologie, maar op de politiek. Ooit was het grootste probleem het feit dat de VS de slimste en meest getalenteerde mensen uit landen over de hele wereld stalen. En nu zijn het grootste probleem de politieke spelletjes tussen verschillende landen rond visa en immigratie.
Alexey: Dat wil zeggen, barrières en dat soort dingen. Het is duidelijk.
Vladimir: Persoonlijk ben ik geïnteresseerd in de aanpak die je hanteert als je een nieuw vak aan studenten geeft. Er zijn verschillende opties: je kunt allereerst proberen ze te inspireren iets nieuws te proberen, of je kunt meer aandacht besteden aan de details van hoe een bepaalde technologie werkt. Wat verkies je?
Effectief werken met studenten
Alexey: En hoe vind je die verdomde balans tussen het eerste en het tweede?
Michael: Het probleem is dat de lessen niet altijd verlopen zoals ik zou willen. Meestal geef ik studenten vooraf leesmateriaal, zodat ze zich erin verdiepen, het zo goed mogelijk begrijpen en vragen formuleren over de onderdelen die ze niet konden begrijpen. Dan kun je je tijdens de les concentreren op de moeilijkste momenten en deze samen verkennen. Dit is de manier waarop ik het liefst les geef. Maar gezien de last die nu op studenten rust, kan ik er niet altijd voor zorgen dat ze zich van tevoren voorbereiden. Als gevolg hiervan moet je veel meer tijd besteden aan het algemeen opnieuw vertellen van het materiaal dan je zou willen. Desondanks probeer ik onze lessen interactief te houden. Anders is het makkelijker om eenmalig een video op te nemen, die leerlingen vervolgens thuis kunnen bekijken. Het punt van live lessen is menselijke interactie. In de klas gebruik ik liever krijt en een schoolbord dan dia's, behalve in bepaalde gevallen waarin een diagram te complex is om op het bord weer te geven. Hierdoor hoef ik me niet aan een strak lesplan te houden. Omdat er geen strikte volgorde is waarin ik het materiaal geef, kan ik het afstemmen op het publiek, afhankelijk van de vragen die ik krijg. Over het algemeen probeer ik de lessen zo interactief mogelijk te maken, zodat de stof die ik presenteer afhankelijk is van de vragen die aan mij worden gesteld.
Vladimir: Het is geweldig. Mijn ervaring is dat het best lastig is om luisteraars vragen te laten stellen. Zelfs als je van tevoren vraagt om vragen te stellen, hoe dom of slim ook, ze zwijgen nog steeds. Hoe ga je hiermee om?
Michael: Je zult lachen, maar als je lang genoeg in stilte blijft staan, zal vroeg of laat iedereen zich ongemakkelijk voelen en zal iemand een vraag stellen. Of u kunt een eenvoudige technische vraag stellen met een ja of nee als antwoord om te bepalen of mensen begrijpen wat er zojuist is gezegd. Is er bijvoorbeeld sprake van een datarace in het bovenstaande voorbeeld? Wie denkt dat? Wie denkt van niet? Wie begrijpt er helemaal niets van, want in totaal ging maar de helft van de handen omhoog?
Виталий: En als je fout antwoordt, word je uit de klas gezet :)
Michael: Als u niets heeft geantwoord, moet u een vraag stellen. Ik moet begrijpen wat de leerling precies moet weten om de vraag te kunnen beantwoorden die ik zojuist heb gesteld. Ik heb ze nodig om mij te helpen. Ik ben bereid me aan hen aan te passen, zodat ze het probleem begrijpen. Maar als ik niet weet wat er in hun hoofd omgaat, kan ik het niet doen. En als je studenten niet lang genoeg rust geeft, stellen ze soms uiteindelijk wel de juiste vragen, waardoor ik kan zien wat er precies in de hoofden van de studenten omgaat.
Alexey: Leiden deze vragen soms tot ideeën waar u zelf nog niet eerder aan had gedacht? Zijn ze onverwacht? Staan ze je toe om een probleem in een nieuw licht te bekijken?
Michael: Er zijn vragen die een nieuwe manier openen om materiaal te presenteren. Er zijn vaak vragen die tot interessante problemen leiden waar ik niet over wilde praten. Studenten vertellen mij vaak dat ik de neiging heb om van het onderwerp af te wijken als dit gebeurt. En volgens hen is dit vaak het meest interessante deel van de les. Zeer zelden, slechts een paar keer, stelden studenten vragen die een nieuwe richting in het onderzoek inluidden en uitgroeiden tot een artikel. Dit gebeurt veel vaker in gesprekken met studenten dan tijdens de lessen, maar af en toe gebeurde het tijdens de lessen.
Alexey: Dus de studenten stelden je vragen op basis waarvan het vervolgens mogelijk was een artikel te publiceren?
Michael: Ja.
Виталий: Hoe vaak voer je deze gesprekken met studenten? Wanneer willen ze meer leren dan wat er tijdens de les is behandeld?
Michael: Met mijn afgestudeerde studenten - de hele tijd. Ik heb er ongeveer vijf of zes, en we bespreken voortdurend iets met ze. En dit soort gesprekken met studenten die alleen maar mijn lessen volgen, zijn niet zo gebruikelijk. Al zou ik willen dat dit vaker zou gebeuren. Ik vermoed dat ze simpelweg bang zijn om tijdens spreekuren naar de faculteit te komen. Elk semester slagen sommige studenten erin deze psychologische barrière te overwinnen, en het is altijd erg interessant om na de les met ze te praten. Toegegeven, als alle studenten zo dapper waren, zou ik simpelweg niet genoeg tijd hebben. Dus misschien werkt alles zoals het zou moeten.
Виталий: Hoe slaag je erin tijd te vinden om met studenten te communiceren? Voor zover ik weet hebben leraren in de VS veel werk: het aanvragen van beurzen en dergelijke.
Michael: Eerlijk gezegd is het werken met studenten het aspect van mijn werk dat ik het leukst vind. Ik heb hier dus genoeg motivatie voor. De meeste tijd die ik op kantoor doorbreng, besteed ik aan allerlei soorten vergaderingen. Het is nu zomer, dus mijn agenda is minder druk, maar tijdens het schooljaar heb ik elke dag van 9 tot 17 uur alles ingepakt. Onderzoekswerk, recensies, subsidies - voor dit alles zijn er alleen avonden en weekenden.
Hoe u de voorbereiding van nieuwe cursussen en boeken kunt bijhouden.
Alexey: Geeft u momenteel nog cursussen die u al heel lang geeft? Zoiets als een inleiding tot informatica.
Michael: Het eerste dat hier in je opkomt is een cursus programmeertalen.
Alexey: Hoe anders is de huidige versie van deze cursus dan 10, 20, 30 jaar geleden? Wat hier misschien interessanter is, zijn niet de details van een bepaalde cursus, maar de algemene trends.
Michael: Mijn cursus over programmeertalen was enigszins ongebruikelijk toen ik hem maakte. Ik begon het eind jaren tachtig te lezen, ter vervanging van mijn collega Doug Baldwin (). Het onderwerp van de cursus had slechts zijdelings betrekking op mijn specialiteit, maar toen hij vertrok, was ik de beste kandidaat om de cursus te geven. Ik vond geen van de leerboeken die er toen bestonden leuk, dus heb ik het leerboek voor deze cursus uiteindelijk zelf geschreven. (Noot van de redactie: we hebben het over het boek) Het wordt nu gebruikt op meer dan 200 universiteiten over de hele wereld. Mijn aanpak is ongebruikelijk omdat het doelbewust de problemen van taalontwerp en -implementatie met elkaar vermengt, en veel aandacht besteedt aan de interactie tussen deze aspecten op alle mogelijke gebieden. De basisbenadering is onveranderd gebleven, evenals veel basisconcepten: abstracties, naamruimten, modulariteit, typen. Maar de reeks talen waarmee deze concepten worden gedemonstreerd, is volledig veranderd. Toen de cursus voor het eerst werd gemaakt, waren er veel voorbeelden in Pascal, maar tegenwoordig hebben veel van mijn studenten nog nooit van deze taal gehoord. Maar ze kennen Swift, Go, Rust, dus ik moet het hebben over de talen die tegenwoordig in gebruik zijn. Bovendien zijn studenten nu goed thuis in scripttalen, maar toen ik deze cursus begon te geven, draaide het allemaal om gecompileerde talen. Nu hebben we veel materiaal nodig over Python, Ruby en zelfs Perl, want dit is de code die tegenwoordig wordt geschreven, en er gebeuren veel interessante dingen in deze talen, ook op het gebied van taalontwerp.
Виталий: Dan zal mijn volgende vraag verband houden met de vorige. Hoe blijf je op dit gebied bij? Ik vermoed dat het updaten van een cursus als deze veel werk vergt - je moet nieuwe talen begrijpen, de belangrijkste ideeën begrijpen. Hoe doe je dit?
Michael: Ik kan niet opscheppen dat ik altijd 100% slaag. Maar meestal doe ik gewoon wat iedereen doet: internet lezen. Als ik Rust wil begrijpen, google ik het, ga naar de Mozilla-pagina en lees de daar geplaatste handleiding. Dit maakt deel uit van de dingen die gebeuren bij commerciële ontwikkeling. Als we het over wetenschap hebben, moet je de rapporten op de belangrijkste conferenties volgen.
Verbinding tussen het bedrijfsleven en de academische wereld
Виталий: Laten we het hebben over het verband tussen zakelijk en wetenschappelijk onderzoek. In je lijst met werken heb ik verschillende artikelen gevonden over cache-coherentie. Ik begrijp dat de algoritmen voor cacheconsistentie onstabiel waren op het moment dat ze werden gepubliceerd? Of niet wijdverspreid genoeg. Hoe gebruikelijk waren uw ideeën in de praktijk?
Michael: Ik weet niet precies over welke publicaties je het hebt. Ik heb heel wat werk gedaan met mijn studenten Bill Bolosky () en Leonidas Kontotanassis () begin jaren negentig over geheugenbeheer van Neumann-machines. In die tijd had het bedrijfsleven nog geen inzicht in hoe je op de juiste manier een multiprocessorsysteem kon maken: is het de moeite waard om ondersteuning te creëren voor toegang tot extern geheugen op hardwareniveau, is het de moeite waard om het geheugen te distribueren, is het mogelijk om de cache te laden van extern geheugen, of is het nodig om pagina's in het operatiekamersysteem te verplaatsen? Bill en Leonidas werkten allebei op dit gebied en onderzochten benaderingen zonder het laden van caches op afstand. Dit hield niet direct verband met de cache-coherentie, maar er werd nog steeds gewerkt aan NUMA-geheugenbeheer, en vervolgens kwamen hieruit moderne benaderingen voor het plaatsen van pagina's in moderne besturingssystemen voort. Over het geheel genomen hebben Bill en Leonidas belangrijk werk verricht, hoewel niet het meest invloedrijke op dit gebied; er waren destijds veel andere mensen die aan hetzelfde werk werkten. Later werkte ik aan een onderwerp dat verband hield met cache-coherentie in de context van hardware-transactioneel geheugen. De groep waarmee ik aan dit probleem werkte, ontving uiteindelijk verschillende patenten. Er zitten een aantal behoorlijk interessante ideeën achter, maar ik denk niet dat ze uiteindelijk in de praktijk zullen worden geïmplementeerd. Op de een of andere manier is het voor mij moeilijk om hun winstgevendheid te beoordelen.
Alexey: In dit verband een meer persoonlijke vraag: hoe belangrijk is het voor u dat uw ideeën in de praktijk worden gebracht? Of denk je er niet over na?
Michael: Ik stel deze vraag graag in interviews met andere mensen, sollicitanten of kandidaten die bij de faculteit willen komen werken. Ik denk niet dat er een juist antwoord op deze vraag bestaat. Mensen die coole dingen doen, kunnen heel verschillende motivaties hebben. Ik voel mij aangetrokken tot problemen omdat ik ze persoonlijk interessant vind, niet vanwege hun praktische voordelen. Maar aan de andere kant, als iets interessants nog steeds toepassing vindt, vind ik het echt leuk. Het is hier dus niet gemakkelijk. Maar aan het begin van mijn werk word ik nog steeds niet gedreven door het idee van een eindgebruik in de wereld, maar door de harmonie van het idee en de wens om het te verkennen en te zien wat ervan komt. Als het uiteindelijk praktische resultaten oplevert, prima.
Alexey: Door uw opleiding en ervaring bent u beter dan de meesten in staat de waarde van de ideeën van anderen te beoordelen. Je kunt ze vergelijken en bepalen welke beter bij welke werkt. Jij hebt vast wel een mening over zaken die momenteel in de praktijk gebruikt worden door grote fabrikanten als Intel. Hoe correct is vanuit uw standpunt de koers die deze bedrijven volgen?
Michael: De praktijk draait altijd om wat commercieel succesvol kan zijn, dat wil zeggen winst creëren, en dat kun je beter aan iemand anders vragen. Mijn werk resulteert vooral in publicaties, en op het gebied van besturingssystemen worden deze beoordeeld op basis van prestatie-indicatoren: snelheid, energieverbruik, codegrootte. Maar het leek mij altijd dat deze empirische resultaten alleen aan artikelen worden toegevoegd zodat ze kunnen worden gepubliceerd, en dat de echte motieven van mensen om te werken esthetisch zijn. Onderzoekers beoordelen oplossingen vanuit een artistiek perspectief, ze vinden het belangrijk hoe elegant de ideeën zijn, en ze proberen iets beters te creëren dan de bestaande benaderingen. Onderzoekers worden gedreven door persoonlijke, subjectieve, esthetische motieven. Maar daarover kun je in het artikel zelf niet schrijven; dit zijn geen argumenten voor de programmacommissie. Gelukkig zijn elegante oplossingen vaak ook snel en goedkoop. Een tiental van mijn collega's en ik bespraken dit onderwerp ongeveer 15 jaar geleden en schreven er uiteindelijk een artikel over. Ik denk dat je het nu nog steeds kunt vinden, het heet of iets dergelijks, het heeft meer dan een dozijn auteurs. Dit is het enige artikel waarvan ik samen de auteur ben , dus als je op haar naam zoekt in mijn publicatielijst, vind je wat je nodig hebt. Het gaat over het evalueren van systeemonderzoek en hoe belangrijk elegantie is.
Alexey: Er is dus een verschil tussen de standaard van wat als goed wordt beschouwd in de wetenschap en in het bedrijfsleven. De wetenschap evalueert prestaties, energieverbruik, TDP, implementatiegemak en nog veel meer. Heeft u de mogelijkheid om dit soort onderzoek aan de universiteit te doen? Heb je een laboratorium met verschillende machines en verschillende architecturen waarin je experimenten zou kunnen uitvoeren?
Michael: Ja, onze afdeling heeft veel verschillende interessante machines. Meestal zijn ze klein, we hebben een klein cluster en veel multiprocessorsystemen met verschillende versnellers. Daarnaast beschikt de campus over een enorm rekencentrum dat wetenschappers uit enkele tientallen verschillende disciplines bedient. Het heeft ongeveer duizend knooppunten en twintigduizend kernen, allemaal op Linux. Als de behoefte zich voordoet, kunt u altijd wat AWS kopen. We hebben dus geen significante beperkingen met hardware.
Alexey: Hoe was het dertig jaar geleden? Waren er toen problemen?
Michael: Toen was het een beetje anders. Halverwege de jaren tachtig werd aangenomen dat de wetenschap een tekort aan computerbronnen had. Om deze situatie te verhelpen, heeft de National Science Foundation ) creëerde een programma voor gecoördineerd experimenteel onderzoek (Coulated Experimental Research, CER). De missie van het programma was het bieden van computerinfrastructuur voor afdelingen Computerwetenschappen, en het heeft aanzienlijke veranderingen teweeggebracht. Met het geld dat zij verstrekte, kochten wij aan de Universiteit van Rochester in 1984 een 128-knopen BBN-vlinder, dit was een jaar voordat ik daar aankwam. Destijds was het 's werelds grootste multiprocessorsysteem met gedeeld geheugen. Het had 128 processors, elk op een apart moederbord, en bezette vier racks. Elke processor beschikte over een megabyte geheugen, 128 megabyte RAM was in die tijd een onvoorstelbare hoeveelheid. Op deze machine hebben we voor het eerst MCS-vergrendeling geïmplementeerd.
Alexey: Dus als ik je goed begrijp, is het probleem met de hardware op dit moment opgelost?
Michael: Over het algemeen wel. Er zijn een paar kanttekeningen: ten eerste: als je computerarchitectuur op chipniveau doet, is het moeilijk om dit in een academische omgeving te doen, omdat er veel betere tools zijn om dit in het bedrijfsleven te doen. Als je iets nodig hebt dat kleiner is dan 10 nanometer, dan zul je het bij iemand anders moeten bestellen. Op dit gebied is het veel gemakkelijker om onderzoeker bij Intel te zijn. Als je werkt aan optische communicatie op chips of aan solid-state geheugen, zul je in het bedrijfsleven technologieën aantreffen die nog niet in de wetenschap zijn opgenomen, dus je moet allianties aangaan. Bijvoorbeeld Stephen Swanson () gemaakt voor nieuwe geheugentechnologieën. Deze vorm werkt niet altijd, maar kan in sommige gevallen behoorlijk succesvol zijn. Bovendien is in de wetenschap de ontwikkeling van de krachtigste computersystemen moeilijker. De grootste supercomputerprojecten die momenteel in de VS, Japan en China plaatsvinden, zijn allemaal gericht op het bedrijfsleven.
Praktische implementatie van ideeën. MCS, MS, CLH, JSR 166, in samenwerking met Doug Lee en meer.
Виталий: Je hebt al verteld hoe je begon te werken aan synchronisatie-algoritmen. Je hebt twee zeer bekende artikelen over и , die in zekere zin in Java zijn geïmplementeerd. (Noot van de redactie: alle publicaties zijn in te zien ). Daar werd deze blokkering met enkele wijzigingen doorgevoerd en dat bleek ook en de wachtrij is geïmplementeerd zoals bedoeld. Maar er gingen vele jaren voorbij tussen de publicatie van uw artikelen en de praktische toepassing ervan.
Alexey: Het lijkt ongeveer 10 jaar in het geval van de wachtrij.
Michael: Voordat deze functies in de Java-standaardbibliotheek verschenen?
Виталий: Ja. Wat heb je gedaan om dit mogelijk te maken? Of deden ze niets?
Michael: Ik kan je vertellen hoe MS Queue in Java 5 terechtkwam. Een paar jaar voordat het uitkwam, werkte ik samen met de groep van Mark Moyers bij Sun Microsystems in hun laboratorium in de buurt van Boston. Hij organiseerde een workshop voor mensen die hij kende en die aan interessante problemen op het gebied van multithreading werkten, omdat hij onderwerpen wilde vinden die hij aan hun bedrijf kon verkopen. Daar ontmoette ik Doug Lea voor het eerst. Doug en ik en ongeveer 25 andere mensen van Sun bespraken samen Dougs presentatie , wat later java.util.concurrent werd. Onderweg zei Doug dat hij graag de MS-wachtrij wilde gebruiken, maar daarvoor had hij een teller nodig voor het aantal elementen in de wachtrij voor de interface. Dat wil zeggen, dit had op een aparte manier moeten gebeuren, atomair, nauwkeurig en snel. Ik stelde voor om simpelweg serienummers aan de knooppunten toe te voegen, het nummer van het eerste en het laatste knooppunt te nemen en de ene van de andere af te trekken. Doug krabde op zijn hoofd, zei ‘waarom niet’, en deed uiteindelijk precies dat. We bespraken de implementatie van deze aanpak in de bibliotheek, maar Doug deed het meeste werk zelf. Als gevolg hiervan slaagde hij erin uitstekende multithreading-ondersteuning in Java op te zetten.
Alexey: Dus als ik het goed begrijp, had de methode .size() deel moeten uitmaken van de standaard wachtrij-interface, en zou deze een algoritmische complexiteit van O(1) moeten hebben?
Michael: Ja, en daarnaast is er een apart loket nodig.
Alexey: Omdat als u de methode .size() in Java aanroept, wordt verwacht dat het resultaat onmiddellijk beschikbaar is en niet gebaseerd is op de werkelijke grootte van de verzameling. Ik zie het, dank je.
Michael: Een paar jaar later werkte ik samen met mijn student Bill Scherer aan dubbele datastructuren - sterker nog, dit is waar ik het over zal hebben . Doug kwam naar ons toe en zei dat hij ze kon gebruiken in het Java Executor Framework. Samen met Bill creëerden ze twee implementaties, de zogenaamde eerlijke en oneerlijke wachtrijen. Ik adviseerde hen over dit project, hoewel ik niet meewerkte aan het schrijven van de daadwerkelijke code. Hierdoor is de snelheid van executeurs-testamentairen aanzienlijk toegenomen.
Vladimir: Bent u onjuiste implementaties van uw algoritmen tegengekomen of verzoeken om nieuwe functies toe te voegen? Over het algemeen zou de praktijk moeten samenvallen met de theorie, maar vaak verschillen ze. Stel dat je een algoritme hebt geschreven, en op papier werkt het, maar de mensen die bij de implementatie betrokken zijn, beginnen je te vragen om meer functies of een of andere aanpassing van het algoritme. Heeft u ooit zulke situaties gehad?
Michael: Het enige voorbeeld waarin iemand naar mij toe kwam en vroeg “hoe het te implementeren” was de vraag van Doug, waar ik het al over had. Maar er zijn een paar gevallen geweest waarin interessante veranderingen zijn aangebracht om aan praktische behoeften te voldoen. Het K42-team bij IBM heeft bijvoorbeeld het MCS-slot omgezet en er een standaardinterface van gemaakt, zodat het niet nodig was om het wachtrijknooppunt heen en weer te sturen naar de acquisitie- en release-routines. Dankzij deze standaardinterface begon een idee dat in theorie mooi was, in de praktijk te werken. Het is verrassend dat ze er nooit een artikel over hebben gepubliceerd, en hoewel ze een patent hebben gekregen, hebben ze er later afstand van gedaan. Het idee was geweldig en ik probeer er waar mogelijk over te praten.
Er zijn andere gevallen geweest waarin mensen verbeteringen hebben aangebracht in de algoritmen die ik heb gepubliceerd. De MS-wachtrij heeft bijvoorbeeld een installatiemechanisme in twee stappen, wat betekende dat er twee CAS's op het kritieke pad van de wachtrij stonden. Bij oudere auto's waren CAS behoorlijk duur. Intel en andere fabrikanten hebben ze de laatste tijd vrij goed geoptimaliseerd, maar ooit waren dit instructies voor 30 cycli, dus het was onwenselijk om er meer dan één op het kritieke pad te hebben. Als gevolg hiervan werd een andere wachtrij ontwikkeld die vergelijkbaar was met de MS-wachtrij, maar die slechts één atomaire bewerking op het kritieke pad had. Dit werd bereikt doordat de operatie gedurende een bepaalde periode O(n) tijd kon duren, in plaats van O(1). Het was onwaarschijnlijk, maar mogelijk. Dit gebeurde vanwege het feit dat het algoritme op bepaalde momenten de wachtrij van het begin tot de huidige positie in deze wachtrij doorkruiste. Over het algemeen bleek het algoritme zeer succesvol. Voor zover ik weet wordt het niet op grote schaal gebruikt, deels omdat atomaire operaties aanzienlijk minder middelen vereisen dan voorheen. Maar het idee was geweldig. Ik hou ook erg van het werk van Dave Dice van Oracle. Alles wat hij doet is heel praktisch en hij gebruikt ijzer heel slim. Hij had een hand in veel van de NUMA-bewuste synchronisatie-algoritmen en multi-threaded datastructuren.
Vladimir: Wanneer je algoritmen schrijft of studenten lesgeeft, is het resultaat van je werk niet meteen zichtbaar. De community heeft wat tijd nodig om vertrouwd te raken met bijvoorbeeld een nieuw artikel. Het nieuwe algoritme vindt niet meteen toepassing.
Michael: Het is verre van meteen duidelijk of het artikel significant zal zijn of niet. Ik denk dat het interessant zou zijn om onderzoek te doen naar artikelen die op conferenties prijzen hebben gewonnen. Dat wil zeggen, kijk naar de artikelen die mensen in de programmacommissies ooit als de beste beschouwden. Je moet proberen aan de hand van het aantal links en de impact op het bedrijfsleven te berekenen hoe invloedrijk deze artikelen over 10, 20, 25 jaar werkelijk zijn gebleken. Ik betwijfel of er een sterke correlatie tussen de twee zou bestaan. Het zal niet nul zijn, maar hoogstwaarschijnlijk zal het veel zwakker zijn dan we zouden willen. Veel ideeën blijven lange tijd onopgeëist voordat ze wijdverspreid worden. Laten we bijvoorbeeld transactioneel geheugen nemen. Er zijn meer dan tien jaar verstreken vanaf het moment dat het originele artikel werd gepubliceerd tot het moment dat mensen er daadwerkelijk machines mee begonnen te bouwen. En vóór de verschijning van dit geheugen in commerciële producten - en alle 10. Heel lang besteedde niemand aandacht aan het artikel, en toen nam het aantal links ernaar sterk toe. Het zou moeilijk zijn om dit op voorhand te voorspellen. Aan de andere kant vinden ideeën soms onmiddellijk implementatie. Een paar jaar geleden schreef ik samen met Joe Izraelevitz voor DISC een paper waarin een nieuwe formele definitie van validiteit werd voorgesteld voor persistente datastructuren die gebruikt zouden kunnen worden nadat de computer waarop ze draaien crasht. Ik vond het artikel vanaf het begin leuk, maar het bleek veel populairder dan ik had verwacht. Het werd door verschillende groepen gebruikt en werd uiteindelijk de standaarddefinitie van persistentiestructuren. Wat natuurlijk leuk is.
Vladimir: Zijn er technieken die u gebruikt voor beoordeling? Probeert u zelfs uw artikelen en uw studenten te evalueren? In termen van de vraag of de persoon die u lesgeeft de goede kant op gaat.
Michael: Net als iedereen let ik op dit moment meer op wat ik doe. Nogmaals, net als iedereen controleer ik af en toe Google Scholar om te zien of mijn eerdere artikelen worden geciteerd, maar dat is meer uit nieuwsgierigheid. Ik ga vooral op in wat mijn studenten nu doen. Als het gaat om het evalueren van huidig werk, gaat het voor een deel om esthetische overwegingen, wat elegant is en wat niet. En op het alledaagse niveau spelen open vragen een grote rol. Een student komt bijvoorbeeld naar mij toe met een grafiek van enkele resultaten, en we proberen te begrijpen waar een vreemd gedrag van de grafiek vandaan komt. Over het algemeen proberen we in ons werk voortdurend dingen te begrijpen die we nog niet begrijpen.
Transactioneel geheugen
Виталий: Misschien kunnen we het even hebben over transactioneel geheugen?
Michael: Ik denk dat het de moeite waard is om er op zijn minst een beetje over te zeggen, omdat ik er veel moeite in heb gestoken. Dit is een onderwerp waarover ik meer publicaties heb dan welk ander onderwerp dan ook. Maar tegelijkertijd was ik, vreemd genoeg, altijd erg sceptisch over het transactionele geheugen. Naar mijn mening, (M. Herlihy, J.E.B. Moss) werd zijn tijd ver vooruit gepubliceerd. Begin jaren negentig suggereerden ze dat transactioneel geheugen getalenteerde programmeurs zou kunnen helpen bij het werken aan multi-threaded datastructuren, zodat deze structuren vervolgens door gewone programmeurs als bibliotheken zouden kunnen worden gebruikt. Dat wil zeggen, het zou een hulp zijn voor Doug Lee bij het maken van zijn JSR 1990. Maar transactioneel geheugen was niet bedoeld om programmeren met meerdere threads gemakkelijk te maken. Maar dit is precies hoe het begin jaren 166 werd waargenomen, toen het wijdverspreid werd. Het werd geadverteerd als een manier om het probleem van parallel programmeren op te lossen. Deze aanpak heeft mij altijd hopeloos geleken. Transactioneel geheugen zou het alleen maar eenvoudiger kunnen maken om parallelle datastructuren te schrijven. Dit is volgens mij wat ze heeft bereikt.
Over de moeilijkheid van het schrijven van multi-threaded code
Alexey: Heel interessant. Er lijkt een zekere barrière te bestaan tussen reguliere programmeurs en degenen die multi-threaded code kunnen schrijven. Vorig jaar sprak ik verschillende keren met mensen die een algoritmisch raamwerk aan het implementeren waren. Bijvoorbeeld met Martin Thomson, maar ook met programmeurs die werken aan multi-threaded bibliotheken. (Noot van de redactie: Martin Thompson is een zeer bekende ontwikkelaar, schreef hij и . En dat heeft hij ook op onze Joker 2015-conferentie, video-opname . Hij is dezelfde deze conferentie ook beschikbaar). De belangrijkste uitdaging is volgens hen dat de algoritmen zowel snel als gebruiksvriendelijk moeten zijn. Dat wil zeggen, ze proberen deze barrière te overwinnen en zoveel mogelijk mensen naar dit gebied te trekken. Wat denk je er van?
Michael: Dit is het grootste probleem van multithreading: hoe hoge prestaties te bereiken zonder de complexiteit van het systeem te vergroten.
Alexey: Omdat wanneer ze complexiteit proberen te vermijden, het algoritme minder universeel wordt.
Michael: De sleutel hier is goed ontworpen abstracties. Het lijkt mij dat dit over het algemeen het belangrijkste is voor computersystemen als vakgebied. Butler Lampson gebruikt deze term graag en hij noemt ons ‘handelaren in abstracties’. Eenvoudige technologieën bestaan vandaag de dag niet meer. De processors die we gebruiken hebben 10 miljard transistors; van eenvoud is geen sprake. Tegelijkertijd is de ISA veel eenvoudiger dan de processor, omdat we er heel lang aan hebben gewerkt om hem hoge prestaties en een relatief eenvoudige interface te bieden. Maar ook bij haar verloopt niet alles soepel. Hetzelfde probleem doet zich voor bij versnellers die nu op de markt verschijnen. Er rijzen vragen: hoe maak je de juiste interface voor de GPU, een versleutelingsmechanisme, compressie, een transcoderingsmechanisme, een lineair algebra-mechanisme of zelfs een flexibelere FPGA. Hoe creëer je een interface die de tool gebruiksvriendelijk maakt en de complexiteit verbergt? Het zal het niet verwijderen, maar het eerder verbergen voor een eenvoudige programmeur.
Alexey: Zoals ik het begrijp, hebben we nog steeds een barrière bij het begrijpen van abstracties. Laten we het geheugenmodel nemen; in onze ontwikkelingsfase van wetenschap en technologie is dit een van de belangrijkste abstracties. Dankzij dit systeem zijn alle programmeurs in twee groepen verdeeld: het grootste deel zijn degenen die het niet begrijpen, en het kleinere deel zijn degenen die het wel begrijpen, of denken te begrijpen.
Michael: Dat is een goede vraag: begrijpt iemand van ons het geheugenmodel echt?
Виталий: Vooral in C++.
Michael: Praat eens met Hans Boehm. Hij is een van de slimste mensen die ik ken, een vooraanstaand expert op het gebied van geheugenmodellen. Hij zal je meteen vertellen dat hij veel niet begrijpt. Maar als we terugkeren naar de kwestie van abstracties, dan werd naar mijn mening het belangrijkste idee op het gebied van geheugenmodellen van de afgelopen dertig jaar uitgedrukt . (Noot van de redactie: er is een volledige lijst met publicaties beschikbaar ).
Alexey: Mijn vraag is: komt deze barrière voort uit de aard van het concept?
Michael: Nee. Sarita kwam tot de conclusie dat je met de juiste aanpak met succes alle complexiteit kunt verbergen, hoge prestaties kunt krijgen en de programmeur een eenvoudige API kunt geven. En als u deze API volgt, kunt u consistente consistentie bereiken. Ik denk dat dit het juiste model is. Schrijf code zonder dataraces en zorg voor sequentiële consistentie. Om de kans op racen te verkleinen zijn uiteraard speciaal gereedschap nodig, maar dat is een andere zaak.
Vladimir: Zijn er momenten in uw carrière geweest waarop een probleem dat opgelost leek plotseling in een catastrofe veranderde, of dat dit probleem onoplosbaar bleek te zijn? In theorie kun je bijvoorbeeld elk getal ontbinden of bepalen of een getal een priemgetal is. Maar in de praktijk kan dit lastig zijn; met de huidige hardware is het moeilijk om getallen te ontbinden. Is jou iets soortgelijks overkomen?
Michael: Zoiets herinner ik me niet meteen. Er zijn momenten geweest dat het mij leek alsof er op een bepaald gebied niets meer te doen was, maar dan gebeurde er iets nieuws en interessants. Ik dacht bijvoorbeeld dat het gebied van onbeperkt wachtrijen al volwassen was geworden. Na verschillende verbeteringen aan de MNS-wachtrij gebeurde er niet veel meer. En toen bedachten Morrison (Adam Morrison) en Afek (Yehuda Afek). . Het werd duidelijk dat een onbeperkte wachtrij met meerdere threads mogelijk was, waarbij er meestal alleen een fetch-and-increment-instructie op het kritieke pad stond. En dit maakte het mogelijk om een orde van grootte betere prestaties te bereiken. Het is niet zo dat we niet weten dat fetch-and-increment een erg nuttig iets is. Eric Freudenthal schreef hierover eind jaren tachtig in zijn werk over de Ultracomputer met Allan Gottlieb, maar het ging over beperkte wachtrijen. Morrison en Afek konden fetch-and-increment gebruiken voor een onbegrensde wachtrij.
Nieuwe architecturen. Is de overwinning van het transactionele geheugen nabij?
Vladimir: Bent u op zoek naar nieuwe architecturale oplossingen die nuttig kunnen zijn voor algoritmen?
Michael: Natuurlijk zijn er veel dingen die ik graag geïmplementeerd zou willen zien.
Vladimir: Wat voor soort bijvoorbeeld?
Michael: Allereerst een paar eenvoudige uitbreidingen van ons transactionele geheugen op hardwareniveau in Intel- en IBM-processors. In het bijzonder zou ik graag willen dat de niet-transactionele belasting en opslag die zojuist is opgetreden, onmiddellijk beschikbaar is binnen transacties. Ze leiden onmiddellijk tot lussen in de 'gebeurt vóór'-reeks, dus ze kunnen moeilijk zijn. Maar als je de abstractielagen handhaaft, zijn er heel veel interessante dingen die je buiten de transactie kunt doen terwijl deze plaatsvindt. Ik weet niet hoe moeilijk dit zou zijn om te implementeren, maar het zou erg nuttig zijn.
Een ander handig ding is het laden van de cache vanuit extern geheugen. Ik denk dat dit vroeg of laat wel zal gebeuren. Deze technologie maakt het mogelijk systemen met gedesaggregeerd geheugen te creëren. Het zou mogelijk zijn om bijvoorbeeld 100 terabytes aan niet-vluchtig geheugen in een rack te bewaren, en het besturingssysteem zelf zou dynamisch beslissen welke delen van dat geheugen moeten overeenkomen met de fysieke adresruimte van de processors. Dit zou uiterst nuttig zijn voor cloud computing, omdat hierdoor grote hoeveelheden geheugen ter beschikking kunnen worden gesteld voor de taken die dit nodig hebben. Ik denk dat iemand het zal doen.
Виталий: Om het gesprek over transactioneel geheugen af te ronden, heb ik nog een vraag over dit onderwerp. Zal transactioneel geheugen uiteindelijk de standaard multi-threaded datastructuren vervangen?
Michael: Nee. Transacties zijn een speculatief mechanisme. Op programmeerniveau zijn dit atomaire sloten, maar van binnen zijn het speculaties. Dergelijke voorspellingen werken als de meeste gissingen correct zijn. Daarom werkt transactioneel geheugen goed als threads nauwelijks met elkaar communiceren, en je hoeft er alleen maar voor te zorgen dat er geen interacties zijn. Maar als een bericht tussen threads begint, hebben transacties weinig zin. Laat me het uitleggen, we hebben het over het geval waarin transacties rond de hele atomaire operatie zijn gewikkeld. Ze kunnen nog steeds met succes worden gebruikt als componenten voor datastructuren met meerdere threads. Als je bijvoorbeeld een CAS van drie woorden nodig hebt, en je moet drie kleine dingen multithreaden in het midden van een echt multithreaded algoritme dat met twintig threads tegelijk werkt. Over het algemeen kunnen transacties nuttig zijn, maar ze zullen de noodzaak om multi-threaded datastructuren goed te ontwerpen niet wegnemen.
Niet-vluchtig geheugen, Optane DIMM, ultrasnelle apparaten.
Виталий: Het laatste waar ik het over wil hebben is het onderwerp van uw huidige onderzoek: niet-vluchtig geheugen. Wat kunnen we de komende tijd op dit gebied verwachten? Misschien kent u effectieve implementaties die al bestaan?
Michael: Ik ben geen hardware-expert, ik weet alleen wat ik in het nieuws lees en wat mijn collega's mij vertellen. Iedereen heeft al gehoord dat Intel verkoopt , die ongeveer 3 keer de leeslatentie en 10 keer de schrijflatentie hebben dan dynamisch RAM. Ze zullen binnenkort beschikbaar zijn in versies met een zeer groot volume. Het is grappig om te denken dat je een laptop zou kunnen hebben met meerdere terabytes aan byte-adresseerbaar RAM-geheugen. Het is waarschijnlijk dat we over tien jaar zullen besluiten deze nieuwe technologie te gebruiken, aangezien we DRAM gebruiken - verhoog gewoon het volume. Maar dankzij de energieonafhankelijkheid gaan er compleet nieuwe mogelijkheden voor ons open. We kunnen de opslagstack fundamenteel veranderen, zodat er geen scheiding is tussen byte-adresseerbaar werkgeheugen en blokgestructureerd persistent geheugen. We hoeven dus niet alles wat van het ene programma naar het andere moet worden overgebracht, in blokgestructureerde bestanden te serialiseren. Hieruit kunnen we veel belangrijke principes afleiden die van invloed zijn op besturingssystemen, runtime-omgevingen en gedistribueerde datastores. Dit gebied is erg interessant om in te werken. Persoonlijk kan ik moeilijk voorspellen waar dit allemaal toe zal leiden, maar de problemen hier zijn buitengewoon vermakelijk. Er kunnen hier revolutionaire veranderingen plaatsvinden, en deze vloeien heel natuurlijk voort uit het werk op het gebied van multithreading, aangezien herstel van fouten een "multithreading"-proces is naast de normale werking van het systeem.
Het tweede hoofdonderwerp waar ik momenteel aan werk is het beheren van ultrasnelle apparaten en het beveiligen van toegang tot apparaten vanuit de gebruikersruimte met systemische beleidscontrole. De afgelopen jaren is er een trend geweest om de toegang tot het apparaat naar de gebruikersruimte te verplaatsen. Dit wordt gedaan omdat de TCP-IP-kernelstack niet kan functioneren bovenop een netwerkinterface die elke 5 microseconden een nieuw pakket nodig heeft; het kan het eenvoudigweg niet bijhouden. Daarom bieden fabrikanten directe toegang tot apparaten. Maar dit betekent dat het besturingssysteem de controle over het proces verliest en geen goede toegang tot het apparaat kan bieden voor concurrerende applicaties. Ons onderzoeksteam is van mening dat deze tekortkoming kan worden vermeden. We zullen hierover deze maand een artikel publiceren op USENIX ATC. Het houdt verband met het werk aan persistentie, aangezien byte-adresseerbaar persistent geheugen met een lange levensduur in wezen een apparaat is met ultrasnelle I/O waartoe toegang moet worden verkregen in de gebruikersruimte. Dit onderzoek maakt nieuwe benaderingen mogelijk van microkernels, exokernels en andere traditionele pogingen om functionaliteit veilig van de OS-kernel naar de gebruikersruimte te verplaatsen.
Vladimir: Byte-adresseerbaar geheugen is geweldig, maar er is een fysieke beperking: de snelheid van het licht. Dit betekent dat er onvermijdelijk een vertraging zal optreden bij de interactie met het apparaat.
Michael: Absoluut gelijk.
Vladimir: Zal er voldoende capaciteit zijn om de nieuwe ladingen aan te kunnen?
Michael: Dit is een uitstekende vraag, maar het zal voor mij moeilijk zijn om deze te beantwoorden. Het idee van verwerking in het geheugen bestaat al een tijdje, het is erg interessant, maar ook erg complex. Ik heb niet op dit gebied gewerkt, maar het zou geweldig zijn als daar enkele ontdekkingen zouden worden gedaan. Ik ben bang dat ik niets meer toe te voegen heb.
Vladimir: Er is nog een probleem. Nieuwe, aanzienlijk grotere hoeveelheden RAM zullen onmogelijk in de CPU passen. Vanwege fysieke beperkingen moet dit RAM-geheugen daarom worden geïsoleerd.
Michael: Het hangt allemaal af van het aantal defecten in de productie van geïntegreerde schakelingen. Als het mogelijk zou zijn om halfgeleiderwafels geheel zonder defecten te maken, dan zou het mogelijk zijn om er een hele microschakeling van te maken. Maar nu weten we niet hoe we microschakelingen groter moeten maken dan postzegels.
Vladimir: Maar we hebben het nog steeds over enorme maten, over centimeters. Dit heeft onvermijdelijk gevolgen voor de latentie.
Michael: Ja. Aan de snelheid van het licht kun je niets doen.
Vladimir: Helaas.
De volgende grote trend. Dubbele datastructuren. Hydra.
Виталий: Voor zover ik het begrijp, vang je nieuwe trends heel snel op. Je was een van de eersten die met transactioneel geheugen werkte, en een van de eersten die met niet-vluchtig geheugen werkte. Wat wordt volgens jou de volgende grote trend? Of misschien is het een geheim?
Michael: Eerlijk gezegd weet ik het niet. Hopelijk merk ik het als er iets nieuws opduikt. Ik heb niet het geluk gehad om zelf een nieuw vakgebied uit te vinden, maar ik heb wel wat geluk gehad en ben al vrij vroeg in staat geweest om te gaan werken in nieuwe velden die door anderen zijn gecreëerd. Ik hoop dat ik dit in de toekomst zal kunnen doen.
Alexey: De laatste vraag in dit interview gaat over je prestaties op Hydra en je activiteiten op school. Als ik het goed begrijp, gaat het rapport op school over blokkeringsvrije algoritmen, en op de conferentie over dubbele datastructuren. Kunt u iets zeggen over deze rapporten?
Michael: Gedeeltelijk hebben we deze onderwerpen in dit interview al met u besproken. Het gaat over het werk dat ik deed met mijn leerling Bill Scherer. Hij schreef er een proefschrift over, en Doug Lee droeg er ook aan bij, en het werd uiteindelijk onderdeel van de multi-threaded synchrone wachtrijen in de Java-bibliotheek. Laten we aannemen dat de datastructuur zonder blokkering wordt gelezen en geschreven, dat wil zeggen dat elke bewerking een beperkt aantal instructies op het kritieke pad heeft. Wanneer u gegevens probeert te verwijderen uit een lege container, of bepaalde gegevens probeert te verwijderen die niet in deze container zitten, krijgt u direct de melding dat dit niet lukt. Maar dit gedrag is mogelijk niet acceptabel als de thread deze gegevens echt nodig heeft. Dan is het eerste dat in je opkomt het creëren van een lus die voortdurend zal vragen of de benodigde gegevens zijn verschenen. Maar dan is er interferentie voor alle anderen. Bovendien kun je met deze aanpak 10 minuten wachten, en dan komt er een andere thread, die per ongeluk eerst de benodigde gegevens ontvangt. Dubbele datastructuren hebben nog steeds geen vergrendelingen, maar zorgen er wel voor dat threads goed kunnen wachten. De term 'dubbel' betekent dat de structuur gegevens of verzoeken om gegevens bevat, laten we ze anti-gegevens noemen. Als u dus iets uit een lege container probeert te halen, wordt er een verzoek in de container geplaatst. Nu kan de thread wachten op een verzoek zonder iemand anders te storen. Bovendien kent de datastructuur prioriteiten toe aan verzoeken, zodat deze bij ontvangst aan de juiste persoon worden doorgegeven. Het resultaat is een niet-vergrendelend mechanisme dat nog steeds een formele specificatie heeft en in de praktijk goed presteert.
Alexey: Wat zijn uw verwachtingen van deze datastructuur? Zal het de prestaties in alle voorkomende gevallen verbeteren, of is het beter geschikt voor bepaalde situaties?
Michael: Dit is handig als u ten eerste een container nodig heeft zonder vergrendeling, en ten tweede moet wachten in een situatie waarin u gegevens moet ophalen uit de container die er niet in zit. Voor zover ik weet, biedt ons raamwerk optimaal gedrag wanneer aan deze twee voorwaarden wordt voldaan. Daarom raad ik in deze gevallen aan om het te gebruiken. Het belangrijkste voordeel van lockless datastructuren is dat ze prestatieproblemen voorkomen. En wachten is in veel algoritmen erg belangrijk als gegevens van de ene thread naar de andere worden overgedragen.
Виталий: Even verduidelijken: ga je zowel op school als op de conferentie over hetzelfde praten?
Michael: Op school in het algemeen over multi-threaded datastructuren, waarbij de basisprincipes aan het begin van de les worden uiteengezet. Ik neem aan dat het publiek weet wat threads zijn en bekend is met sloten. Op basis van deze basiskennis zal ik het hebben over lock-free datastructuren. Ik zal een overzicht geven van de belangrijkste problemen op dit gebied, waarbij ik onderwerpen als geheugenbeheer aanroer. Ik denk niet dat er iets ingewikkelder zal zijn dan de MS-wachtrij.
Alexey: Bent u van plan om aan het einde van uw les op school les te geven over dubbele datastructuren?
Michael: Ik zal ze noemen, maar ik zal er niet veel tijd aan besteden. Het Hydra-rapport zal aan hen worden opgedragen. Het zal het project behandelen dat uiteindelijk Java heeft gemaakt, evenals de samenwerking met Joe Israelevich om een dubbele variant van de LCRQ-wachtrij te creëren, en een vrijwel universeel ontwerp voor dubbele datastructuren te creëren.
Alexey: Dus de lezing op school kan worden aanbevolen voor beginners, en de lezing over dubbele datastructuren op Hydra - voor mensen die al enige ervaring hebben?
Michael: Corrigeer me als ik het mis heb, maar het publiek bij Hydra zal behoorlijk divers zijn, waaronder veel Java-experts, en in het algemeen mensen die niet specifiek betrokken zijn bij programmeren met meerdere threads.
Виталий: Ja het is waar.
Alexey: Dat hopen wij tenminste.
Michael: In dit geval word ik geconfronteerd met hetzelfde probleem waarmee we dit interview begonnen: hoe maak je een rapport dat zowel voldoende rijk is aan technische details als toegankelijk voor alle luisteraars.
Виталий: Ga je op dezelfde manier verslag uitbrengen als hoorcolleges? Dat wil zeggen, met het publiek praten en je aanpassen aan de situatie?
Michael: Ik ben bang dat het zo niet zal werken, omdat het rapport dia's zal bevatten. Dia's zijn belangrijk wanneer luisteraars in eerste instantie verschillende talen spreken. Veel mensen zullen het moeilijk vinden om mij in het Engels te verstaan, vooral als ik te snel spreek. Ik heb deze onderwerpen gekozen omdat vroeg me om te praten over lock-free datastructuren op de SPTDC School; en toen had ik een rapport nodig voor een Java-gebruikersgroepconferentie, en ik wilde iets kiezen dat specifiek van belang zou zijn voor Java-programmeurs. De gemakkelijkste manier was om te praten over die dingen in de Java-bibliotheek waar ik op de een of andere manier de hand in had.
Alexey: We gaan ervan uit dat het publiek op Hydra al iets weet over lock-free programmeren en wellicht enige ervaring op dit gebied heeft. Maar dit is slechts een veronderstelling; de situatie zal duidelijker worden op de conferentie zelf. Hoe dan ook, bedankt voor je tijd. Ik ben er zeker van dat het interview zeer interessant zal zijn voor onze lezers. Hartelijk bedankt!
Виталий: Bedankt.
Michael: Ik zal blij zijn je te ontmoeten in Sint-Petersburg.
Alexey: Wij ook, we hebben een prachtige stad. Ben je hier ooit geweest?
Michael: Nee, ik ben helemaal nooit in Rusland geweest. Maar Sint-Petersburg heeft altijd op de lijst gestaan van plaatsen waar ik nog niet ben geweest, maar waar ik heel graag heen wil, dus ik was erg blij met de uitnodiging.
Alexey: We hebben trouwens een excursieprogramma voor sprekers. Hartelijk dank voor het interview en een fijne dag!
U kunt uw gesprek met Michael 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