— som professor i datalogi ved University of Rochester, og ved sit hjem University of Wisconsin-Madison var han dekan i fem år. Han forsker i og underviser elever i parallel og distribueret programmering og sprogdesign.
Verden kender Michael fra lærebogen , hvad med arbejdet modtaget Dijkstra-prisen som en af de mest berømte inden for distribueret databehandling. Du kender ham måske også som forfatter til netop den algoritme .
Sammen med Doug Lee udviklede han de ikke-blokerende algoritmer og synkrone køer, der driver Java-bibliotekerne. Implementering i JavaSE 6 forbedret ydeevnen med 10 gange ThreadPoolExecutor.
Indhold:
- Tidlig karriere, University of Rochester. Projekt Charlotte, Lynx-sprog;
- IEEE Scalable Coherent Interface, MCS-låsning;
- Overlevelse i en verden i konstant forandring;
- Er eleverne ved at blive dummere? Globale tendenser, internationalisering;
- Effektivt arbejde med studerende;
- Sådan følger du med i forberedelsen af nye kurser og bøger;
- Forbindelser mellem erhvervslivet og den akademiske verden;
- Praktisk implementering af ideer. MCS, MS, CLH, JSR 166, arbejder med Doug Lee og mere;
- Transaktionel hukommelse;
- Nye arkitekturer. Transaktionshukommelsens sejr er nær;
- Ikke-flygtig hukommelse, Optane DIMM, ultrahurtige enheder;
- Den næste store trend. Dobbelte datastrukturer. Hydra.
Interviewet er foretaget af:
Vitaly Aksenov — i øjeblikket postdoc ved IST Østrig og medlem af afdelingen for computerteknologi på ITMO University. Udfører forskning inden for teori og praksis af konkurrerende datastrukturer. Før han arbejdede på IST, modtog han sin ph.d. fra Paris Diderot University og ITMO University under vejledning af professor Peter Kuznetsov.
Alexey Fedorov - Producer hos JUG Ru Group, en russisk virksomhed, der arrangerer konferencer for udviklere. Alexey deltog i forberedelsen af mere end 50 konferencer, og hans CV omfatter alt fra stillingen som udviklingsingeniør hos Oracle (JCK, Java Platform Group) til stillingen som udvikler hos Odnoklassniki.
Vladimir Sitnikov - Ingeniør hos Netcracker. Ti års arbejde med ydeevnen og skalerbarheden af NetCracker OS, software, der bruges af teleoperatører til at automatisere netværks- og netværksudstyrsstyringsprocesser. Interesseret i Java og Oracle Database-ydelsesproblemer. Forfatter til mere end et dusin præstationsforbedringer i den officielle PostgreSQL JDBC-driver.
Tidlig karriere, University of Rochester. Charlotte-projekt, Lynx-sprog.
Alexey: Til at begynde med ville jeg fortælle dig, at vi i Rusland alle virkelig elsker Computer Science, Data Science og algoritmer. Det er direkte uanstændigt. Vi har læst alt . Derfor burde den kommende konference, skolen og selve dette interview blive meget populært. Vi modtog mange spørgsmål til dette interview fra studerende, programmører og fællesskabsmedlemmer, så vi er meget taknemmelige for denne mulighed. Får datalogi den samme kærlighed i USA?
Michael: Vores felt er så mangfoldigt, det har så mange retninger, og det påvirker samfundet på så mange forskellige måder, at det er svært for mig at give dig et endegyldigt svar. Men faktum er, at det har medført voldsomme forandringer i erhvervslivet, industrien, kunsten og samfundet generelt gennem de seneste 30 år.
Vitali: Lad os starte med noget fjernt. På mange universiteter er der noget i retning af specialisering inden for et bestemt område. For Carnegie Mellon University er dette parallel computing, for MIT er det kryptografi, robotter og multithreading. Findes der en sådan specialisering på University of Rochester?
Michael: For at være ærlig vil jeg sige, at CMU og MIT er specialiserede inden for alle områder. Vores afdeling har altid været mest opmærksom på kunstig intelligens. Halvdelen af de mennesker, der arbejder for os, er engageret i AI eller menneske-computer-interaktion - denne andel er højere end i andre afdelinger, og har altid været det. Men da jeg var på universitetet, havde jeg ingen kurser i AI, og jeg har aldrig arbejdet inden for dette felt. Så min afdeling er specialiseret i et problem, som jeg ikke har noget med at gøre. Trøsten er, at det næstvigtigste problem for vores afdeling er parallel og flertrådet programmering, altså mit speciale.
Vitali: Du begyndte at arbejde i datalogi, da feltet multi-threaded programmering lige var ved at dukke op. Listen over dine publikationer viser, at dine første værker beskæftigede sig med en temmelig bred vifte af problemer: hukommelseshåndtering i flertrådede systemer, distribuerede filsystemer, operativsystemer. Hvorfor sådan en alsidighed? Har du prøvet at finde din plads i forskningsmiljøet?
Michael: Som studerende deltog jeg i ved University of Wisconsin, hvor et af de første distribuerede operativsystemer blev udviklet. Der arbejdede jeg sammen med Rafael Finkel () og Marvin Solomon (). Min afhandling var helliget udviklingen af et sprog til systemsoftware til distribuerede systemer – nu har alle glemt det, og gudskelov. Jeg lavede programmeringssproget Lynx, som havde til formål at gøre det nemmere at lave servere til et løst koblet distribueret operativsystem. Da jeg på det tidspunkt hovedsageligt var involveret i operativsystemer, gik jeg ud fra, at min karriere primært ville være forbundet med dem. Men Rochester var et meget lille universitet, og på grund af dette interagerede de forskellige grupper der meget tæt med hinanden. Der var ikke et dusin andre operativsystemfolk der, som jeg kunne tale med, så alle mine kontakter var med folk, der arbejdede inden for helt andre områder. Jeg nød det virkelig, at være en allrounder er en stor fordel for mig. Hvis vi taler specifikt om multi-threaded datastrukturer og synkroniseringsalgoritmer, så begyndte jeg at arbejde på dem helt ved et tilfælde.
IEEE Scalable Coherent Interface, MCS-låsning.
Vitali: Kan du fortælle mig lidt mere om dette?
Michael: Dette er en sjov historie, som jeg aldrig bliver træt af at fortælle alle. Det skete på en konference i Boston - dette var i slutningen af 80'erne eller begyndelsen af 90'erne. John Mellor-Crummey (), en kandidat fra vores fakultet. Jeg kendte ham, men vi havde ikke lavet fælles research før. Mary Vernon () fra Wisconsin holdt et foredrag om et multiprocessorsystem, de var ved at udvikle i Wisconsin: . Denne Multicube havde en synkroniseringsmekanisme på hardwareniveau kaldet Q on Sync Bit, og senere blev den omdøbt til Q på Lock Bit, fordi den lød som Colby cheese, hvilket var et ordspil. Hvis du er interesseret i multithreading-mekanismer, ved du sikkert, at Colby til sidst blev synkroniseringsmotoren for IEEE Scalable Coherent Interface-standarden. Dette var en låsemekanisme, der skabte pointere fra en cache til en anden på hardwareniveau, så hver låseholder vidste, hvis tur det var. Da John og jeg hørte om dette, så vi på hinanden og sagde: hvorfor gør vi det her på hardwareniveau? Kan det samme ikke opnås ved at sammenligne-og-bytte? Vi tog en af de notesbøger, der lå i klasseværelset, og skrev på den , mens Mary fortsatte sin rapport. Efterfølgende implementerede vi det, eksperimenterede, ideen viste sig at være vellykket, og vi publicerede artiklen. På det tidspunkt virkede dette emne for mig bare en sjov distraktion, hvorefter jeg planlagde at vende tilbage til operativsystemer. Men så opstod et andet problem i samme retning, og til sidst blev synkronisering, multithreading og datastrukturer mit speciale. Som du kan se, skete det hele ved et uheld.
Vitali: Jeg har været bekendt med MCS-blokering i lang tid, men indtil nu vidste jeg ikke, at det var dit arbejde, og forstod ikke, at det var et akronym for dine efternavne.
Hvordan overlever man i en verden i konstant forandring?
Alexey: Jeg har et spørgsmål om et relateret emne. For 30 eller 40 år siden var der mere frihed i forskellige specialer. Hvis du vil starte en karriere inden for multithreading eller distribuerede systemer, er du velkommen, hvis du vil ind i operativsystemer, er det ikke noget problem. På hvert område var der mange åbne spørgsmål og få eksperter. Snævre specialiseringer er nu opstået: Der er ikke kun eksperter i operativsystemer generelt, der er specialister i individuelle systemer. Det er det samme med multithreading og distribuerede systemer. Men problemet er, at vores liv ikke er uendeligt; alle kan kun afsætte et par årtier til forskning. Hvordan overlever man i denne nye verden?
Michael: Vi er ikke specielle i denne henseende; det samme skete en gang på andre områder. Jeg var heldig, at jeg begyndte at arbejde i datalogi, da faget var i "teenage"-årene. Nogle fundamenter var allerede lagt, men alt var stadig meget umodent. Denne mulighed kommer ikke ofte. Elektroteknik har eksisteret i meget lang tid, fysik endnu længere, matematik næsten siden tidernes begyndelse. Men det betyder ikke, at ingen længere gør interessante opdagelser i matematik. Der er stadig mange åbne problemer, men samtidig skal der læres mere. Du har ret i at bemærke, at der nu er mange flere specialiseringer, end der var før, men det betyder kun, at vi befinder os i samme situation som de fleste andre områder af menneskelig aktivitet.
Alexey: Jeg er interesseret i det mere praktiske aspekt af problemet her. Jeg har en matematikbaggrund, og under mit studie har jeg ofte deltaget i konferencer og arbejdet med forskellige videnskabelige emner. Jeg opdagede, at ingen i publikum forstod mine rapporter, og på samme måde var andre menneskers rapporter kun forståelige for dem selv. Sådan er det ikke i emner på højt niveau, men så snart du begynder at dykke ned i noget, kan publikum ikke længere følge med dig. Hvordan håndterer du dette?
Michael: Ikke altid vellykket. Jeg har for nylig udarbejdet en rapport, hvor jeg gik for dybt i tekniske detaljer. Efterhånden som snakken skred frem, stod det klart, at de fleste af tilhørerne ikke forstod mig, så jeg måtte tilpasse mig situationen med det samme. Sliderne kunne ikke ændres, så det blev ikke særlig godt - så generelt prøver jeg at undlade at bruge slides. Samlet set er mit råd at overveje dit publikum. Du skal vide, hvem du taler med, hvad deres vidensniveau er, og hvad de har brug for at høre for at værdsætte dit arbejde.
Vitali: Kan du give os et hint om, hvad dette foredrag handlede om?
Michael: For at være ærlig, ville jeg foretrække ikke at uddybe dette emne for at efterlade de pågældende personer anonyme. Pointen er, at vi ofte kommer for dybt ind i forviklingerne af det problem, vi arbejder med, så det bliver svært for os at forklare i begyndelsen af talen, hvorfor problemet er interessant og vigtigt, og hvordan det hænger sammen med emner, som publikum ved det allerede. Ifølge mine observationer har eleverne sværest ved at lære denne færdighed. Og det var også det svage punkt i min seneste betænkning. En ordentligt struktureret rapport skal lige fra begyndelsen finde kontakt til publikum, forklare dem, hvad problemet præcist er, og hvordan det forholder sig til emner, som den allerede kender. Hvor teknisk denne introduktion er afhænger af publikum. Hvis den er helt broget, så kan rapporten være flertrinsrig. Introduktionen bør være tilgængelig for alle, og i slutningen kan stykket muligvis ikke følge med dig, men folk, der er relativt fortrolige med dit felt, vil være i stand til at finde ud af det.
Er eleverne ved at blive dummere? Globale tendenser, internationalisering.
Alexey: Du har observeret elever i flere årtier. Bliver eleverne dummere eller klogere fra årti til årti eller år til år? I Rusland klager professorer konstant over, at studerende bliver dummere hvert år, og det er virkelig ikke klart, hvad de skal gøre ved det.
Michael: Man kan virkelig høre en masse negativitet fra os gamle mennesker. Ubevidst har vi en tendens til at forvente, at eleverne absorberer alle de 30 års erfaring, som vi allerede har. Hvis jeg har en dybere forståelse, end jeg havde i 1985, hvorfor har eleverne det så ikke? Sikkert fordi de er 20 år, hvad synes du? Jeg tror, at de væsentligste ændringer i de seneste årtier har været i den demografiske sammensætning: Vi har nu betydeligt flere internationale studerende, med undtagelse af canadiere. Tidligere var der mange canadiere, fordi vi er meget tæt på den canadiske grænse, og studerende derfra kan rejse hjem i weekenden. Men nu er der mange gode universiteter i Canada, og canadiere foretrækker at studere her, markant færre af dem kommer til USA.
Alexey: Tror du, det er en lokal trend eller en global trend?
Michael: Jeg kan ikke huske præcis hvem, men nogen sagde, at verden er flad. Vores felt er blevet meget mere internationalt. Tidligere blev de udelukkende afholdt i USA, så besluttede de at afholde dem en gang hvert 4. år i andre lande, og nu afholdes de over hele verden. Disse ændringer påvirkede endnu mere , da det altid har været en mere international organisation end ACM. Og der er programledere fra Kina, Indien, Rusland, Tyskland og mange andre lande, for der sker en masse overalt nu.
Alexey: Men der er sandsynligvis nogle negative aspekter ved en sådan internationalisering?
Michael: Jeg vil sige, at alle de negative aspekter ikke vedrører teknologi, men til politik. Engang var hovedproblemet det faktum, at USA stjal de klogeste og mest talentfulde mennesker fra lande rundt om i verden. Og nu er hovedproblemet de politiske spil mellem forskellige lande omkring visa og immigration.
Alexey: Altså barrierer og den slags. Det er klart.
Vladimir: Personligt er jeg interesseret i, hvilken tilgang du har, når du underviser i et nyt fag for elever. Der er forskellige muligheder: Du kan først og fremmest prøve at inspirere dem til at prøve noget nyt, eller du kan være mere opmærksom på detaljerne om, hvordan en bestemt teknologi fungerer. Hvad foretrækker du?
Effektivt arbejde med elever
Alexey: Og hvordan finder man den pokkers balance mellem første og anden?
Michael: Problemet er, at undervisningen ikke altid går, som jeg gerne ville. Jeg plejer at give eleverne læsestof på forhånd, så de dykker ned i det, forstår det bedst muligt og formulerer spørgsmål om de dele, som de ikke kunne forstå. Så kan du i klassen fokusere på de sværeste øjeblikke og udforske dem sammen. Det er sådan, jeg bedst kan lide at undervise i klasser. Men med den belastning, der nu ligger på eleverne, er jeg ikke altid i stand til at sikre mig, at de forbereder sig på forhånd. Som følge heraf skal du bruge meget mere tid på den generelle genfortælling af materialet, end du ønsker. På trods af dette forsøger jeg at holde vores klasser interaktive. Ellers er det nemmere at optage en video én gang, som eleverne så kan se derhjemme. Pointen med live klasser er menneskelig interaktion. I klassen foretrækker jeg at bruge kridt og en tavle frem for dias, undtagen i visse tilfælde, hvor et diagram er for komplekst til at afbilde på tavlen. Takket være dette behøver jeg ikke holde mig til en stiv lektionsplan. Da der ikke er nogen streng rækkefølge, jeg giver materialet i, giver det mig mulighed for at skræddersy det til publikum afhængigt af de spørgsmål, jeg modtager. Generelt forsøger jeg at gøre undervisningen så interaktiv som muligt, så det materiale, jeg præsenterer, afhænger af de spørgsmål, der stilles til mig.
Vladimir: Det er godt. Efter min erfaring er det ret svært at få lytterne til at stille spørgsmål. Selvom du på forhånd beder om at stille spørgsmål, uanset hvor dumt eller smart, er de stadig tavse. Hvordan håndterer du dette?
Michael: Du vil grine, men hvis du står stille længe nok, vil alle før eller siden blive utilpas, og nogen vil stille et spørgsmål. Eller du kan stille et simpelt teknisk spørgsmål med et ja eller nej svar for at afgøre, om folk forstår, hvad der lige blev sagt. Er der for eksempel et dataræs i eksemplet ovenfor? Hvem tror det? Hvem tror ikke? Hvem forstår slet ikke noget, for i alt gik kun halvdelen af hænderne op?
Vitali: Og hvis du svarede forkert, bliver du smidt ud af klassen :)
Michael: Hvis du ikke har svaret på noget, så skal du stille et spørgsmål. Jeg skal forstå, hvad den studerende præcis skal vide for at svare på det spørgsmål, jeg lige har stillet. Jeg har brug for dem til at hjælpe mig med at hjælpe dem. Jeg er klar til at tilpasse mig dem, så de forstår problemet. Men hvis jeg ikke ved, hvad der foregår i deres hoved, kan jeg ikke gøre det. Og hvis man ikke giver eleverne ro i lang nok tid, stiller de nogle gange i sidste ende de rigtige spørgsmål, altså dem der giver mig mulighed for at se, hvad der præcist foregår i elevernes hoveder.
Alexey: Fører disse spørgsmål nogle gange til ideer, som du ikke selv havde tænkt på før? Er de uventede? Giver de dig mulighed for at se på et problem i et nyt lys?
Michael: Der er spørgsmål, der åbner op for en ny måde at præsentere stof på. Der er ofte spørgsmål, der fører til interessante problemer, som jeg ikke havde tænkt mig at tale om. Studerende fortæller mig ofte, at jeg har en tendens til at gå væk fra emnet, når dette sker. Og ifølge dem er dette meget ofte den mest interessante del af lektionen. Meget sjældent, kun nogle få gange, stillede eleverne spørgsmål, der fik en ny retning i forskningen og voksede til en artikel. Dette sker meget oftere i samtaler med elever i stedet for under timerne, men nogle gange skete det i timerne.
Alexey: Så eleverne stillede dig spørgsmål, ud fra hvilke det så var muligt at udgive en artikel?
Michael: Ja.
Vitali: Hvor ofte har du disse samtaler med elever? Hvornår ønsker de at lære mere end det, der blev dækket under lektionen?
Michael: Med mine kandidatstuderende - hele tiden. Jeg har omkring 5 eller 6 af dem, og vi diskuterer noget med dem hele tiden. Og samtaler af denne art med elever, der blot deltager i mine timer, er ikke særlig almindelige. Selvom jeg ville ønske det skete oftere. Jeg formoder, at de simpelthen er bange for at komme på fakultetet i kontortiden. Hvert semester formår nogle studerende at overvinde denne psykologiske barriere, og det er altid meget interessant at tale med dem efter undervisningen. Sandt nok, hvis alle eleverne var lige så modige, ville jeg simpelthen ikke have tid nok. Så måske fungerer alt som det skal.
Vitali: Hvordan formår du at finde tid til at kommunikere med eleverne? Så vidt jeg ved, har lærere i USA meget arbejde - at søge legater og lignende.
Michael: Helt ærligt, at arbejde med studerende er det aspekt af mit job, som jeg nyder mest. Så jeg har nok motivation til dette. Det meste af tiden, jeg bruger på mit kontor, bruges på møder af enhver art. Det er sommer nu, så min tidsplan er mindre travl, men i løbet af skoleåret, hver dag fra 9 til 17, har jeg alt pakket. Forskningsarbejde, anmeldelser, bevillinger - til alt dette er der kun aftener og weekender.
Sådan følger du med i forberedelsen af nye kurser og bøger.
Alexey: Fortsætter du i øjeblikket med at undervise i nogle kurser, som du har undervist i længe? Noget som en introduktion til datalogi.
Michael: Det første, der kommer til at tænke på her, er et kursus i programmeringssprog.
Alexey: Hvor forskellig er dagens version af dette kursus fra, hvad det var for 10, 20, 30 år siden? Det, der måske er mere interessant her, er ikke detaljerne i et bestemt kursus, men de generelle tendenser.
Michael: Mit kursus i programmeringssprog var noget usædvanligt på det tidspunkt, jeg oprettede det. Jeg begyndte at læse den i slutningen af 1980'erne og afløste min kollega, Doug Baldwin (). Emnet for kurset var kun tangentielt relateret til mit speciale, men da han gik, var jeg den bedste kandidat til at undervise på kurset. Jeg kunne ikke lide nogen af de lærebøger, der fandtes på det tidspunkt, så jeg endte med at skrive lærebogen til dette kursus selv. (Redaktørens note: vi taler om bogen) Det bruges nu på mere end 200 universiteter rundt om i verden. Min tilgang er usædvanlig ved, at den bevidst blander problemerne med sprogdesign og -implementering og lægger stor vægt på samspillet mellem disse aspekter på alle mulige områder. Den grundlæggende tilgang er forblevet uændret, ligesom mange grundlæggende begreber: abstraktioner, navnerum, modularitet, typer. Men det sæt af sprog, som disse begreber demonstreres med, har ændret sig fuldstændig. Da kurset først blev oprettet, var der mange eksempler i Pascal, men i dag har mange af mine elever ikke engang hørt om dette sprog. Men de kender Swift, Go, Rust, så jeg er nødt til at tale om de sprog, der er i brug i dag. Også eleverne er nu velbevandret i scriptsprog, men da jeg begyndte at undervise i dette kursus, handlede det om kompilerede sprog. Nu har vi brug for en masse materiale om Python, Ruby og endda Perl, for det er den kode, der bliver skrevet i disse dage, og der sker en masse interessante ting på disse sprog, herunder inden for sprogdesign.
Vitali: Så vil mit næste spørgsmål være relateret til det forrige. Hvordan kan man følge med på dette område? Jeg formoder, at det kræver meget arbejde at opdatere et kursus som dette - du skal forstå nye sprog, forstå hovedideerne. Hvordan gør du dette?
Michael: Jeg kan ikke prale af, at jeg altid lykkes 100%. Men det meste af tiden gør jeg bare, hvad alle andre gør – læser internettet. Hvis jeg vil forstå Rust, googler jeg det, går til Mozilla-siden og læser manualen, der er lagt ud der. Dette er en del af de ting, der sker i kommerciel udvikling. Hvis vi taler om videnskab, så skal du følge rapporterne på hovedkonferencerne.
Link mellem erhvervslivet og den akademiske verden
Vitali: Lad os tale om sammenhængen mellem erhvervslivet og videnskabelig forskning. I din liste over værker fandt jeg flere artikler om cache-sammenhæng. Jeg forstår, at cache-konsistensalgoritmerne var ustabile på det tidspunkt, de blev offentliggjort? Eller ikke udbredt nok. Hvor almindelige var dine ideer i praksis?
Michael: Jeg er ikke helt sikker på, hvilke publikationer du taler om. Jeg har lavet en del arbejde med mine elever Bill Bolosky () og Leonidas Kontotanassis () i begyndelsen af 1990'erne om hukommelsesstyring af Neumann-maskiner. På det tidspunkt havde virksomheden endnu ikke en forståelse af, hvordan man korrekt laver et multiprocessorsystem: er det værd at skabe understøttelse for adgang til fjernhukommelse på hardwareniveau, er det værd at distribuere hukommelsen, er det muligt at indlæse cachen fra fjernhukommelse, eller er det nødvendigt at flytte sider i operationsstuens system. Bill og Leonidas arbejdede begge i dette område og udforskede tilgange uden fjernindlæsning af cache. Dette var ikke direkte relateret til cache-kohærens, men det var stadig arbejde med NUMA-hukommelseshåndtering, og efterfølgende voksede moderne tilgange til sideplacering i moderne operativsystemer fra dette. Samlet set udførte Bill og Leonidas et vigtigt arbejde, selvom det ikke var det mest indflydelsesrige på dette område - der var mange andre mennesker, der arbejdede med det samme på det tidspunkt. Senere arbejdede jeg med et emne relateret til cache-kohærens i forbindelse med hardwaretransaktionshukommelse. Den gruppe, jeg arbejdede med på dette problem, endte med at modtage flere patenter. Der er nogle ret interessante ideer bag dem, men jeg tror ikke, de ender med at blive implementeret i praksis. På en eller anden måde er det svært for mig at bedømme deres rentabilitet.
Alexey: I den forbindelse et mere personligt spørgsmål: Hvor vigtigt er det for dig, at dine ideer bliver omsat i praksis? Eller tænker du ikke over det?
Michael: Jeg elsker at stille dette spørgsmål i interviews med andre mennesker, ansøgere eller kandidater, der ønsker at blive medlem af fakultetet. Jeg tror ikke, der er et korrekt svar på dette spørgsmål. Folk, der laver seje ting, kan have meget forskellige motivationer. Jeg er tiltrukket af problemer, fordi jeg personligt finder dem interessante, ikke på grund af deres praktiske fordele. Men på den anden side, når nogle interessante ting stadig finder anvendelse, kan jeg virkelig godt lide det. Så det er ikke nemt her. Men i begyndelsen af mit arbejde er jeg stadig ikke drevet af ideen om en slutanvendelse i verden, men af ideens harmoni og ønsket om at udforske den og se, hvad der kommer ud af den. Hvis det i sidste ende giver praktiske resultater, fantastisk.
Alexey: På grund af din uddannelse og erfaring er du bedre end de fleste i stand til at bedømme værdien af andres ideer. Du kan sammenligne dem og afgøre, hvilken der fungerer bedst med hvilken. Jeg er sikker på, at du har en mening om ting, der i øjeblikket bliver brugt i praksis af store producenter som Intel. Fra dit synspunkt, hvor korrekt er den kurs, som disse virksomheder tager?
Michael: Praksis kredser altid om, hvad der kan være kommercielt succesfuldt, altså skabe overskud, og det må du hellere spørge en anden om. Mit arbejde resulterer for det meste i publikationer, og inden for operativsystemer bliver de vurderet ud fra præstationsindikatorer: hastighed, energiforbrug, kodestørrelse. Men det forekom mig altid, at disse empiriske resultater kun føjes til artikler, så de kan publiceres, og folks egentlige motiver for arbejde er æstetiske. Forskere vurderer løsninger ud fra et kunstnerisk perspektiv, de bekymrer sig om, hvor elegante ideerne er, og de forsøger at skabe noget bedre end eksisterende tilgange. Forskere er drevet af personlige, subjektive, æstetiske motiver. Men det kan man ikke skrive om i selve artiklen, det er ikke et argument for programudvalget. Heldigvis er elegante løsninger ofte også hurtige og billige. Et dusin af mine kolleger og jeg diskuterede dette emne for omkring 15 år siden og endte med at skrive en artikel om det. Jeg tror, du stadig kan finde den nu, hedder den eller noget i den stil, den har mere end et dusin forfattere. Dette er den eneste artikel, hvor jeg er forfatter sammen med , så hvis du søger efter hendes navn på min liste over publikationer, finder du det, du har brug for. Den taler om evaluering af systemforskning, og hvor vigtig elegance er.
Alexey: Så der er forskel på standarden for, hvad der anses for godt i videnskaben og i erhvervslivet. Videnskaben evaluerer ydeevne, strømforbrug, TDP, nem implementering og meget mere. Har du mulighed for at udføre denne type forskning på universitetet? Har du et laboratorium med forskellige maskiner og forskellige arkitekturer, hvor du kan udføre eksperimenter?
Michael: Ja, vores afdeling har en masse forskellige interessante maskiner. Oftest er de små, vi har en lille klynge og mange multiprocessorsystemer med forskellige acceleratorer. Derudover har campus et enormt computercenter, der betjener forskere fra flere dusin forskellige discipliner. Den har omkring tusind noder og tyve tusinde kerner, alle på Linux. Hvis behovet opstår, kan du altid købe noget AWS. Så vi har ingen væsentlige begrænsninger med hardware.
Alexey: Hvordan var det for tredive år siden? Var der problemer dengang?
Michael: Det var lidt anderledes dengang. I midten til slutningen af 1980'erne blev videnskaben anset for at mangle computerressourcer. For at afhjælpe denne situation, National Science Foundation ) oprettet et program for koordineret eksperimentel forskning (Coordinated Experimental Research, CER). Programmets mission var at levere computerinfrastruktur til datalogiafdelinger, og det har opnået betydelige ændringer. Med de penge, hun skaffede, købte vi på University of Rochester en 1984 knob BBN Butterfly i 128, det var et år før jeg ankom der. På det tidspunkt var det verdens største multiprocessorsystem med delt hukommelse. Den havde 128 processorer, hver på et separat bundkort, og optog fire racks. Hver processor havde en megabyte hukommelse, 128 megabyte RAM var en ufattelig mængde på det tidspunkt. På denne maskine implementerede vi MCS-låsning for første gang.
Alexey: Så hvis jeg forstår dig rigtigt, så er problemet med hardwaren løst i øjeblikket?
Michael: Generelt, ja. Der er et par forbehold: For det første, hvis du laver computerarkitektur på chip-niveau, er det svært at gøre i et akademisk miljø, fordi der er meget bedre værktøjer til at gøre det i erhvervslivet. Hvis du har brug for noget mindre end 10 nanometer, skal du bestille det hos en anden. På dette område er det meget nemmere at være forsker hos Intel. Hvis du arbejder med optisk kommunikation på chips eller på solid-state hukommelse, vil du finde teknologier i erhvervslivet, som endnu ikke er i videnskaben, så du er nødt til at skabe alliancer. For eksempel, Stephen Swanson () oprettet til nye hukommelsesteknologier. Denne formular virker ikke altid, men i nogle tilfælde kan den være ganske vellykket. Derudover er udviklingen af de mest kraftfulde computersystemer inden for videnskaben vanskeligere. De største supercomputerprojekter i øjeblikket i USA, Japan og Kina er alle fokuseret på forretning.
Praktisk implementering af ideer. MCS, MS, CLH, JSR 166, arbejder med Doug Lee og mere.
Vitali: Du har allerede talt om, hvordan du begyndte at arbejde med synkroniseringsalgoritmer. Du har to meget berømte artikler om и , som på en måde blev implementeret i Java. (Redaktørens bemærkning: alle publikationer kan ses ). Der blev denne blokering implementeret med nogle ændringer, og det viste sig , og køen blev implementeret efter hensigten. Men der gik mange år mellem udgivelsen af dine artikler og deres praktiske anvendelse.
Alexey: Det ser ud til at være omkring 10 år i køens tilfælde.
Michael: Før disse funktioner dukkede op i Java-standardbiblioteket?
Vitali: Ja. Hvad gjorde du for at få det til at ske? Eller gjorde de ingenting?
Michael: Jeg kan fortælle dig, hvordan MS Queue kom ind i Java 5. Et par år før det kom ud, arbejdede jeg med Mark Moyers' gruppe hos Sun Microsystems i deres laboratorium nær Boston. Han organiserede en workshop for folk, han kendte, som arbejdede med interessante problemer i multithreading, fordi han ønskede at finde emner, som han kunne sælge til deres virksomhed. Det var der, jeg mødte Doug Lea første gang. Doug og jeg og omkring 25 andre mennesker fra Sun diskuterede sammen Dougs præsentation vedr , som senere blev til java.util.concurrent. Undervejs sagde Doug, at han gerne ville bruge MS-køen, men til dette havde han brug for en tæller for antallet af elementer i køen til grænsefladen. Det vil sige, at dette skulle være gjort ved en separat metode, atomær, præcis og hurtig. Jeg foreslog blot at tilføje serienumre til noderne, tage nummeret på den første node og den sidste og trække den ene fra den anden. Doug kløede sig i hovedet, sagde "hvorfor ikke", og endte med at gøre netop det. Vi diskuterede implementering af denne tilgang i biblioteket, men Doug lavede det meste af arbejdet selv. Som et resultat lykkedes det ham at etablere fremragende multithreading-understøttelse i Java.
Alexey: Så hvis jeg forstår det rigtigt, skulle .size()-metoden have været en del af standardkøgrænsefladen, og den skulle have haft en algoritmisk kompleksitet på O(1)?
Michael: Ja, og udover dette kræves en separat tæller.
Alexey: For hvis du kalder .size()-metoden i Java, forventes resultatet at være tilgængeligt med det samme og ikke baseret på den faktiske størrelse af samlingen. Jeg kan se, tak.
Michael: Et par år senere arbejdede jeg på dobbelte datastrukturer med min elev Bill Scherer - faktisk er det det, jeg vil tale om . Doug kom til os og sagde, at han kunne bruge dem i Java Executor Framework. Sammen med Bill skabte de to implementeringer, de såkaldte fair og unfair køer. Jeg rådgav dem om dette projekt, selvom jeg ikke var med til at skrive selve koden. Som følge heraf er eksekutørernes hastighed steget betydeligt.
Vladimir: Er du stødt på forkerte implementeringer af dine algoritmer eller anmodninger om at tilføje nye funktioner? Generelt bør praksis falde sammen med teori, men ret ofte er de forskellige. Antag, at du skrev en algoritme, og på papiret virker den, men de mennesker, der er involveret i implementeringen, begyndte at bede dig om flere funktioner eller en form for justering af algoritmen. Har du nogensinde haft sådanne situationer?
Michael: Det eneste eksempel, hvor nogen kom til mig og spurgte "hvordan man implementerer det", var Dougs spørgsmål, som jeg allerede talte om. Men der har været enkelte tilfælde, hvor der er foretaget interessante ændringer for at passe til praktiske behov. For eksempel konverterede K42-teamet hos IBM MCS-låsen og gjorde den til en standardgrænseflade, så der ikke var behov for at sende kønoden frem og tilbage til rutinerne for erhvervelse og frigivelse. Takket være denne standardgrænseflade begyndte en idé, der var smuk i teorien, at virke i praksis. Det er overraskende, at de aldrig publicerede en artikel om det, og selvom de modtog et patent, opgav de det senere. Idéen var vidunderlig, og jeg forsøger at tale om den, når det er muligt.
Der har været andre tilfælde, hvor folk har lavet forbedringer af de algoritmer, jeg har offentliggjort. For eksempel har MS-køen en to-trins installationsmekanisme, hvilket betød, at der var to CAS'er på den kritiske vej i køen. På ældre biler var CAS ret dyre. Intel og andre producenter har optimeret dem ganske godt for nylig, men engang var det 30-cyklus instruktioner, så det var uønsket at have mere end én på den kritiske vej. Som et resultat blev der udviklet en anden kø, der lignede MS-køen, men som kun havde én atomoperation på den kritiske vej. Dette blev opnået på grund af det faktum, at operationen i et vist tidsrum kunne tage O(n) tid i stedet for O(1). Det var usandsynligt, men muligt. Dette skete på grund af det faktum, at algoritmen i visse øjeblikke krydsede køen fra begyndelsen til den aktuelle position i denne kø. Generelt viste algoritmen sig at være meget vellykket. Så vidt jeg ved, er det ikke særlig udbredt, blandt andet fordi atomoperationer kræver væsentligt færre ressourcer end tidligere. Men ideen var god. Jeg kan også rigtig godt lide arbejdet af Dave Dice fra Oracle. Alt, hvad han gør, er meget praktisk, og han bruger jern meget smart. Han havde en finger med i mange af de NUMA-bevidste synkroniseringsalgoritmer og multi-threaded datastrukturer.
Vladimir: Når du skriver algoritmer eller underviser elever, er resultatet af dit arbejde ikke umiddelbart synligt. Samfundet har brug for lidt tid til at blive fortrolig med f.eks. en ny artikel. Den nye algoritme finder ikke umiddelbart anvendelse.
Michael: Det er langt fra umiddelbart klart, om artiklen bliver væsentlig eller ej. Jeg synes, det ville være interessant at lave en undersøgelse af artikler, der har vundet priser på konferencer. Det vil sige, se på de artikler, som folk i programudvalgene på et tidspunkt anså for de bedste. Du skal prøve at beregne ud fra antallet af links og indvirkningen på erhvervslivet, hvor indflydelsesrige disse artikler virkelig viste sig at være om 10, 20, 25 år. Jeg tvivler på, at der ville være en stærk sammenhæng mellem de to. Det bliver ikke nul, men højst sandsynligt vil det være meget svagere, end vi gerne vil. Mange ideer forbliver uanmeldt i lang tid, før de bliver udbredt. Lad os for eksempel tage transaktionshukommelse. Der gik mere end 10 år fra det tidspunkt, den oprindelige artikel blev publiceret til det tidspunkt, hvor folk rent faktisk begyndte at bygge maskiner med den. Og før udseendet af denne hukommelse i kommercielle produkter - og alle 20. I meget lang tid var der ingen, der var opmærksomme på artiklen, og derefter steg antallet af links til den kraftigt. Det ville være svært at forudsige dette på forhånd. På den anden side finder ideer nogle gange implementering med det samme. For et par år siden skrev jeg et papir med Joe Izraelevitz for DISC, der foreslog en ny formel definition af gyldighed for vedvarende datastrukturer, der kunne bruges, efter at computeren, der kører dem, styrtede ned. Jeg kunne godt lide artiklen lige fra begyndelsen, men den viste sig at være meget mere populær, end jeg havde forventet. Det blev brugt af flere forskellige grupper og blev til sidst standarddefinitionen af persistensstrukturer. Hvilket selvfølgelig er rart.
Vladimir: Er der nogen teknikker, du bruger til vurdering? Forsøger du overhovedet at evaluere dine artikler og dine elever? I forhold til om personen du underviste går i den rigtige retning.
Michael: Som alle andre er jeg mere opmærksom på, hvad jeg laver i øjeblikket. Igen, som alle andre, tjekker jeg af og til Google Scholar for at se, om mine tidligere papirer bliver citeret, men det er mere af nysgerrighed. For det meste er jeg opslugt af, hvad mine elever laver nu. Når det kommer til at vurdere aktuelt arbejde, er en del af det æstetiske overvejelser, hvad der er elegant og hvad der ikke er. Og på det daglige plan spiller åbne spørgsmål en stor rolle. For eksempel kommer en elev til mig med en graf over nogle resultater, og vi forsøger at forstå, hvor en underlig opførsel af grafen kom fra. Generelt forsøger vi i vores arbejde konstant at forstå ting, som vi endnu ikke forstår.
Transaktionel hukommelse
Vitali: Måske kan vi snakke lidt om transaktionshukommelse?
Michael: Jeg synes, det er værd at sige i det mindste lidt, fordi jeg lægger mange kræfter i det. Dette er et emne, som jeg har flere publikationer om end noget andet. Men på samme tid var jeg mærkeligt nok altid meget skeptisk over for transaktionshukommelse. Efter min mening, (M. Herlihy, J. E. B. Moss) blev udgivet forud for sin tid. I begyndelsen af 1990'erne foreslog de, at transaktionshukommelse kunne hjælpe talentfulde programmører med at arbejde på multitrådede datastrukturer, så disse strukturer derefter kunne bruges som biblioteker af almindelige programmører. Det vil sige, det ville være en hjælp for Doug Lee at lave sin JSR 166. Men transaktionshukommelsen var ikke beregnet til at gøre multi-threaded programmering let. Men det er præcis sådan, det begyndte at blive opfattet i begyndelsen af 2000'erne, da det blev udbredt. Det blev annonceret som en måde at løse problemet med parallel programmering. Denne tilgang har altid virket håbløs for mig. Transaktionshukommelse kunne kun gøre det lettere at skrive parallelle datastrukturer. Det forekommer mig at være det, hun opnåede.
Om vanskeligheden ved at skrive flertrådet kode
Alexey: Meget interessant. Der ser ud til at være en vis barriere mellem almindelige programmører og dem, der kan skrive multi-threaded kode. Sidste år talte jeg flere gange med folk, der implementerede en eller anden algoritmisk ramme. For eksempel med Martin Thomson, såvel som med programmører, der arbejder på multi-threaded biblioteker. (Redaktørens note: Martin Thompson er en meget berømt udvikler, skrev han и . Og det har han også ved vores Joker 2015 konference, videooptagelse . Han er den samme denne konference også tilgængelig). Den største udfordring, siger de, er at gøre algoritmerne både hurtige og nemme at bruge. Det vil sige, at de forsøger at overvinde denne barriere og tiltrække så mange mennesker som muligt til dette område. Hvad synes du om det?
Michael: Dette er hovedproblemet ved multithreading: hvordan man opnår høj ydeevne uden at øge systemets kompleksitet.
Alexey: For når de forsøger at undgå kompleksitet, bliver algoritmen mindre universel.
Michael: Nøglen her er korrekt designede abstraktioner. Det forekommer mig, at dette generelt er det vigtigste for computersystemer som et felt. Butler Lampson kan lide at bruge dette udtryk, og han kalder os "abstraktionernes købmænd." Simple teknologier findes ikke i dag. De processorer, vi bruger, har 10 milliarder transistorer – enkelhed er udelukket. Samtidig er ISA'en meget enklere end processoren, da vi i meget lang tid har arbejdet på at give den høj ydeevne og en forholdsvis enkel grænseflade. Men alt er heller ikke lige med hende. Det samme problem er med acceleratorer, der nu dukker op på markedet. Spørgsmål opstår - hvordan man laver den rigtige grænseflade til GPU'en, en krypteringsmekanisme, komprimering, en transkodningsmekanisme, en lineær algebramekanisme eller endda en mere fleksibel FPGA. Hvordan laver man en grænseflade, der gør værktøjet nemt at bruge og skjuler kompleksitet? Det vil ikke slippe af med det, men snarere skjule det for en simpel programmør.
Alexey: Som jeg forstår det, har vi stadig en barriere i at forstå abstraktioner. Lad os tage hukommelsesmodellen; på vores udviklingsstadium af videnskab og teknologi er dette en af de vigtigste abstraktioner. Takket være det er alle programmører opdelt i to grupper: Den største del er dem, der ikke forstår det, og den mindre del er dem, der forstår eller tror, at de forstår.
Michael: Det er et godt spørgsmål - forstår nogen af os virkelig hukommelsesmodellen?
Vitali: Især i C++.
Michael: Tal med Hans Boehm engang. Han er en af de klogeste mennesker, jeg kender, en førende ekspert i hukommelsesmodeller. Han vil fortælle dig med det samme, at der er meget, han ikke forstår. Men hvis vi vender tilbage til spørgsmålet om abstraktioner, så blev efter min mening den vigtigste idé inden for hukommelsesmodeller gennem de sidste 30 år udtrykt . (Redaktørens note: en komplet liste over publikationer er tilgængelig ).
Alexey: Mit spørgsmål er: kommer denne barriere fra selve konceptets natur?
Michael: Nej. Sarita kom til den konklusion, at med den rigtige tilgang kan du med held skjule al kompleksiteten, få høj ydeevne og give programmøren en simpel API. Og hvis du følger denne API, kan du opnå ensartet konsistens. Jeg tror, det er den rigtige model. Skriv kode uden dataløb og få sekventiel konsistens. For at mindske sandsynligheden for væddeløb er der selvfølgelig brug for specialværktøj, men det er en anden sag.
Vladimir: Har der været tidspunkter i din karriere, hvor et problem, der syntes løst, pludselig blev til en katastrofe, eller det viste sig, at dette problem var uløseligt? For eksempel kan du i teorien faktorisere et hvilket som helst tal eller bestemme, om et hvilket som helst tal er primtal. Men i praksis kan dette være svært at gøre, med den nuværende hardware er det svært at faktorisere tal. Er der sket noget lignende for dig?
Michael: Jeg husker ikke umiddelbart sådan noget. Der har været tidspunkter, hvor det forekom mig, at der ikke var noget tilbage at lave i et bestemt område, men så skete der noget nyt og interessant der. For eksempel troede jeg, at området med ubegrænset kø allerede havde nået modenhed. Efter adskillige forbedringer af MNS-køen skete der ikke meget mere. Og så opfandt Morrison (Adam Morrison) og Afek (Yehuda Afek). . Det blev klart, at en ubegrænset multi-threaded-kø var mulig, hvor der for det meste kun var en hent-og-increment-instruktion på den kritiske vej. Og dette gjorde det muligt at opnå en størrelsesorden bedre ydeevne. Det er ikke, fordi vi ikke ved, at hent-og-stigning er en meget nyttig ting. Eric Freudenthal skrev om dette i sit arbejde med Ultracomputeren med Allan Gottlieb i slutningen af 1980'erne, men det handlede om begrænsede køer. Morrison og Afek var i stand til at bruge hent-og-increment på en ubegrænset kø.
Nye arkitekturer. Er transaktionshukommelsens sejr tæt på?
Vladimir: Leder du efter nye arkitektoniske løsninger, der kan være nyttige til algoritmer?
Michael: Selvfølgelig er der mange ting, som jeg gerne ser implementeret.
Vladimir: Hvilken slags f.eks.?
Michael: Først og fremmest et par enkle udvidelser til vores transaktionshukommelse på hardwareniveau i Intel- og IBM-processorer. Især vil jeg gerne have, at den ikke-transaktionelle belastning og butik, der lige er opstået, er umiddelbart tilgængelig inden for transaktioner. De fører straks til sløjfer i sker-før-sekvensen, så de kan være svære. Men hvis du opretholder lag af abstraktion, er der en masse meget interessante ting, du kan gøre uden for transaktionen, mens den sker. Jeg ved ikke, hvor svært det ville være at implementere, men det ville være meget nyttigt.
En anden nyttig ting er at indlæse cache fra fjernhukommelsen. Jeg tror, før eller siden, det bliver gjort. Denne teknologi vil tillade oprettelsen af systemer med disaggregeret hukommelse. Det ville være muligt at beholde f.eks. 100 terabyte af ikke-flygtig hukommelse i et rack, og selve operativsystemet ville dynamisk bestemme, hvilke dele af denne hukommelse der skulle svare til processorernes fysiske adresserum. Dette ville være yderst nyttigt til cloud computing, da det ville tillade store mængder hukommelse at blive leveret til de opgaver, der har brug for det. Jeg tror, nogen vil gøre det.
Vitali: For at afslutte med at tale om transaktionshukommelse har jeg endnu et spørgsmål om dette emne. Vil transaktionshukommelse i sidste ende erstatte standard flertrådede datastrukturer?
Michael: Nej. Transaktioner er en spekulativ mekanisme. På programmeringsniveau er disse atomlåse, men indeni er de spekulationer. Sådanne prognoser virker, hvis de fleste af gættene er korrekte. Derfor fungerer transaktionshukommelsen godt, når tråde næsten ikke interagerer med hinanden, og du skal blot sikre dig, at der ikke er nogen interaktioner. Men hvis en besked starter mellem tråde, er transaktioner af ringe nytte. Lad mig forklare, vi taler om tilfældet, hvor transaktioner er pakket rundt om hele atomoperationen. De kan stadig med succes bruges som komponenter til multi-threaded datastrukturer. For eksempel, hvis du har brug for et tre-ords CAS, og du skal multithreade tre små ting midt i en virkelig multithreaded algoritme, der fungerer med tyve tråde på samme tid. Generelt kan transaktioner være nyttige, men de vil ikke eliminere behovet for korrekt design af flertrådede datastrukturer.
Ikke-flygtig hukommelse, Optane DIMM, ultrahurtige enheder.
Vitali: Den sidste ting, jeg gerne vil tale om, er emnet for din nuværende forskning: ikke-flygtig hukommelse. Hvad kan vi forvente på dette område i den nærmeste fremtid? Måske kender du til nogle effektive implementeringer, der allerede findes?
Michael: Jeg er ikke hardwareekspert, jeg ved kun, hvad jeg læser i nyhederne, og hvad mine kolleger fortæller mig. Alle har allerede hørt, at Intel sælger , som har omkring 3 gange læselatens og 10 gange skrivelatens end dynamisk RAM. De vil snart være tilgængelige i meget store versioner. Det er sjovt at tænke på, at du kunne have en bærbar computer med flere terabyte byte-adresserbar RAM. Det er sandsynligt, at vi om 10 år beslutter os for at bruge denne nye teknologi, da vi bruger DRAM - bare øg lydstyrken. Men takket være energiuafhængighed åbner der sig helt nye muligheder for os. Vi kan fundamentalt ændre lagerstakken, så der ikke er adskillelse mellem byteadresserbar arbejdshukommelse og blokstruktureret persistent hukommelse. Vi behøver således ikke at serialisere alt, hvad der skal overføres fra et program, der køres til et andet, til blokstrukturerede filer. Ud fra dette kan vi udlede mange vigtige principper, der påvirker operativsystemer, runtime-miljøer og distribuerede datalagre. Dette område er meget interessant at arbejde i. Personligt er det svært for mig at forudsige, hvad det hele vil føre til, men problemerne her er ekstremt underholdende. Der kan være revolutionerende ændringer her, og de følger meget naturligt af arbejdet med multithreading, da fejlgendannelse er en "multithreading"-proces ved siden af den normale drift af systemet.
Det andet hovedemne, jeg i øjeblikket arbejder på, er administration af ultrahurtige enheder og sikker adgang til enheder fra brugerområdet med systemisk politikkontrol. I de senere år har der været en tendens til at flytte adgangen til enheden til brugerområdet. Dette gøres, fordi TCP-IP-kernestakken ikke kan fungere oven på en netværksgrænseflade, der har brug for en ny pakke hvert 5. mikrosekund; den vil simpelthen ikke følge med. Derfor giver producenterne direkte adgang til enheder. Men det betyder, at operativsystemet mister kontrollen over processen, og det kan ikke give ordentlig adgang til enheden til konkurrerende applikationer. Vores forskerhold mener, at denne mangel kan undgås. Vi har en artikel om dette på USENIX ATC i denne måned. Det er relateret til arbejde med persistens, da langlivet byte-adresserbar persistent hukommelse i bund og grund er en enhed med ultrahurtig I/O, der skal tilgås i brugerområdet. Denne forskning muliggør nye tilgange til mikrokerner, exokerneler og andre traditionelle forsøg på sikkert at flytte funktionalitet fra OS-kernen til brugerområdet.
Vladimir: Byte-adresserbar hukommelse er fantastisk, men der er en fysisk begrænsning - lysets hastighed. Det betyder, at der uundgåeligt vil være en forsinkelse ved interaktion med enheden.
Michael: Fuldstændig ret.
Vladimir: Vil der være kapacitet nok til at klare de nye belastninger?
Michael: Det er et glimrende spørgsmål, men det bliver svært for mig at svare på. Ideen om at behandle i hukommelsen har eksisteret i et stykke tid, det er meget interessant, men også meget komplekst. Jeg har ikke arbejdet på dette område, men det ville være fantastisk, hvis der blev gjort nogle opdagelser der. Jeg er bange for, at jeg ikke har mere at tilføje.
Vladimir: Der er et problem mere. Nye, væsentligt større mængder RAM vil være umulige at passe ind i CPU'en. På grund af fysiske begrænsninger skal denne RAM derfor være isoleret.
Michael: Det hele afhænger af antallet af defekter i produktionen af integrerede kredsløb. Hvis det var muligt at skabe halvlederwafere helt uden defekter, så ville det være muligt at lave et helt mikrokredsløb ud af det. Men nu ved vi ikke, hvordan man laver mikrokredsløb større end frimærker.
Vladimir: Men vi taler stadig om enorme størrelser, cirka centimeter. Dette har uundgåeligt indflydelse på latens.
Michael: Ja. Der er intet du kan gøre ved lysets hastighed.
Vladimir: Desværre.
Den næste store trend. Dobbelte datastrukturer. Hydra.
Vitali: Så vidt jeg forstår, fanger man nye trends meget hurtigt. Du var en af de første, der arbejdede i transaktionshukommelse, og en af de første, der arbejdede i ikke-flygtig hukommelse. Hvad tror du bliver den næste store trend? Eller måske er det en hemmelighed?
Michael: For at være ærlig, så ved jeg det ikke. Forhåbentlig vil jeg kunne mærke, når der kommer noget nyt. Jeg har ikke været så heldig at opfinde noget nyt felt på egen hånd, men jeg har haft lidt held og været i stand til at begynde at arbejde ret tidligt i nye områder skabt af andre. Jeg håber, at jeg vil være i stand til at gøre dette i fremtiden.
Alexey: Det sidste spørgsmål i dette interview vil handle om din præstation på Hydra og dine aktiviteter på skolen. Hvis jeg forstår det rigtigt, vil rapporten på skolen handle om blokeringsfrie algoritmer, og på konferencen om dobbelte datastrukturer. Kan du sige et par ord om disse rapporter?
Michael: Til dels har vi allerede berørt disse emner med dig i dette interview. Det handler om det arbejde, jeg lavede med min elev Bill Scherer. Han skrev et speciale om det, og Doug Lee bidrog også til det, og det blev til sidst en del af de flertrådede synkrone køer i Java-biblioteket. Lad os antage, at datastrukturen læses og skrives uden blokering, det vil sige, at hver operation har et begrænset antal instruktioner på den kritiske vej. Hvis du forsøger at fjerne data fra en tom container, eller forsøger at fjerne visse data, der ikke er i denne container, får du straks besked om, at dette ikke kan lade sig gøre. Men denne adfærd er muligvis ikke acceptabel, hvis tråden virkelig har brug for disse data. Så er det første, der kommer til at tænke på, at lave en loop, der konstant vil spørge, om de nødvendige data er dukket op. Men så er der indblanding for alle andre. Derudover kan du med denne tilgang vente 10 minutter, og så kommer der en anden tråd, og den vil ved et uheld modtage de nødvendige data først. Dobbelte datastrukturer har stadig ikke låse, men de tillader tråde at vente ordentligt. Udtrykket "dobbelt" betyder, at strukturen indeholder enten data eller anmodninger om data, lad os kalde dem anti-data. Så hvis du forsøger at hente noget fra en tom container, vil der i stedet blive lagt en anmodning ind i containeren. Nu kan tråden vente på en anmodning uden at forstyrre andre. Derudover tildeler datastrukturen prioriteter til anmodninger, så den, når den modtages, videregiver dem til den rigtige person. Resultatet er en ikke-låsende mekanisme, der stadig har en formel specifikation og god ydeevne i praksis.
Alexey: Hvad er dine forventninger til denne datastruktur? Vil det forbedre ydeevnen i alle almindelige tilfælde, eller er det bedre egnet til visse situationer?
Michael: Det er nyttigt, hvis du for det første har brug for en container uden låsning, og for det andet skal du vente i en situation, hvor du skal hente data fra den container, der ikke er i den. Så vidt jeg ved, giver vores rammer optimal adfærd, når disse to betingelser er opfyldt. Derfor anbefaler jeg i disse tilfælde at bruge det. Den største fordel ved låseløse datastrukturer er, at de undgår ydeevneproblemer. Og at vente er meget vigtigt i mange algoritmer, hvis data overføres fra en tråd til en anden.
Vitali: Lad mig præcisere: vil du tale om det samme både i skolen og på konferencen?
Michael: I skole generelt om flertrådede datastrukturer, med de grundlæggende principper skitseret i begyndelsen af lektionen. Jeg går ud fra, at publikum ved, hvad tråde er og kender til låse. Med udgangspunkt i denne grundlæggende viden vil jeg tale om låsefri datastrukturer. Jeg vil give et overblik over de vigtigste problemer på dette område, idet jeg berører emner som hukommelseshåndtering. Jeg tror ikke, der vil være noget mere kompliceret end MS-køen.
Alexey: Planlægger du at undervise om dobbelte datastrukturer i slutningen af din klasse i skolen?
Michael: Jeg vil nævne dem, men jeg vil ikke bruge meget tid på dem. Hydra-rapporten vil blive dedikeret til dem. Det vil dække det projekt, der til sidst kom ind i Java, samt arbejde med Joe Israelevich om at skabe en dobbelt variant af LCRQ-køen og skabe et næsten universelt design for dobbelte datastrukturer.
Alexey: Så foredraget på skolen kan anbefales til begyndere, og foredraget om dobbelte datastrukturer på Hydra - for folk der allerede har lidt erfaring?
Michael: Ret mig, hvis jeg tager fejl, men publikum hos Hydra vil være ret forskelligartet, herunder mange Java-eksperter og generelt folk, der ikke specifikt er involveret i multi-threaded programmering.
Vitali: Ja det er sandt.
Alexey: Det håber vi i hvert fald.
Michael: I dette tilfælde vil jeg blive konfronteret med det samme problem, som vi begyndte dette interview med: hvordan man gør en rapport både tilstrækkelig rig på tekniske detaljer og tilgængelig for alle lyttere.
Vitali: Vil du holde en rapport på samme måde, som du holder foredrag? Altså tale med publikum og tilpasse sig situationen?
Michael: Jeg er bange for, at det ikke går sådan, for rapporten vil have slides. Slides er vigtige, når lyttere til at begynde med taler forskellige sprog. Mange mennesker vil finde det svært at forstå mig på engelsk, især hvis jeg taler for hurtigt. Jeg valgte disse emner pga bad mig om at tale om låsefri datastrukturer på SPTDC Skolen; og så havde jeg brug for en rapport til en Java-brugergruppekonference, og jeg ville vælge noget, der ville være af interesse specifikt for Java-programmører. Den nemmeste måde var at tale om de ting i Java-biblioteket, som jeg havde en hånd med på den ene eller anden måde.
Alexey: Vi går ud fra, at publikum på Hydra allerede ved noget om låsefri programmering og måske har en vis erfaring på området. Men dette er kun en antagelse, situationen vil blive tydeligere på selve konferencen. Anyway, tak for din tid. Jeg er sikker på, at interviewet vil være meget interessant for vores læsere. Mange tak!
Vitali: Tak skal du have.
Michael: Jeg vil være glad for at møde dig i St. Petersborg.
Alexey: Vi har også en smuk by. Har du nogensinde været her?
Michael: Nej, jeg har aldrig været i Rusland overhovedet. Men Sankt Petersborg har altid været på listen over steder, hvor jeg endnu ikke har været, men hvor jeg virkelig gerne vil hen, så jeg var meget glad for invitationen.
Alexey: Vi vil i øvrigt have et program med udflugter for talere. Mange tak for interviewet, og hav en god dag!
Du kan fortsætte din samtale med Michael på Hydra 2019-konferencen, som afholdes den 11.-12. juli 2019 i St. Petersborg. Han kommer med en rapport . Billetter kan købes .
Kilde: www.habr.com