"Empiriska resultat är endast för publicering, de verkliga motiven för verket är estetiska." Bra intervju med Michael Scott

"Empiriska resultat är endast för publicering, de verkliga motiven för verket är estetiska." Bra intervju med Michael Scott Michael Scott - i 34 år som professor i datavetenskap vid University of Rochester, och vid sitt hem University of Wisconsin–Madison var han dekanus i fem år. Han forskar och undervisar studenter om parallell och distribuerad programmering och språkdesign.

Världen känner till Michael från läroboken "Programmeringsspråkpragmatik", hur är det med jobbet "Algoritmer för skalbar synkronisering på multiprocessorer med delat minne" fick Dijkstra-priset som ett av de mest kända inom området distribuerad datoranvändning. Du kanske också känner honom som författaren till just den algoritmen Michael-Scott.

Tillsammans med Doug Lee utvecklade han de icke-blockerande algoritmerna och synkrona köerna som driver Java-biblioteken. Genomförande "dubbla datastrukturer" i JavaSE 6 förbättrade prestandan med 10 gånger ThreadPoolExecutor.

Innehåll:

  • Tidig karriär, University of Rochester. Projekt Charlotte, Lynx språk;
  • IEEE Scalable Coherent Interface, MCS-låsning;
  • Överlevnad i en ständigt föränderlig värld;
  • Blir eleverna dummare? Globala trender, internationalisering;
  • Effektivt arbete med studenter;
  • Hur man hänger med i utarbetandet av nya kurser och böcker;
  • Länkar mellan näringsliv och akademi;
  • Praktisk implementering av idéer. MCS, MS, CLH, JSR 166, arbetar med Doug Lee och mer;
  • Transaktionsminne;
  • Nya arkitekturer. Segern för transaktionsminnet är nära;
  • Icke-flyktigt minne, Optane DIMM, ultrasnabba enheter;
  • Nästa stora trend. Dubbla datastrukturer. Hydra.

Intervjuer genomförs av:

Vitaly Aksenov — för närvarande postdoc vid IST Österrike och medlem av avdelningen för datorteknik vid ITMO University. Bedriver forskning inom området teori och praktik av konkurrenskraftiga datastrukturer. Innan han arbetade på IST tog han sin doktorsexamen från Paris Diderot University och ITMO University under ledning av professor Peter Kuznetsov.

Alexey Fedorov är producent på JUG Ru Group, ett ryskt företag som anordnar konferenser för utvecklare. Alexey deltog i förberedelserna av mer än 50 konferenser, och hans CV innehåller allt från positionen som utvecklingsingenjör på Oracle (JCK, Java Platform Group) till positionen som utvecklare på Odnoklassniki.

Vladimir Sitnikov är ingenjör på Netcracker. I tio år har han arbetat med prestanda och skalbarhet hos NetCracker OS, programvara som används av telekomoperatörer för att automatisera processer för hantering av nätverk och nätverksutrustning. Intresserad av prestandaproblem i Java och Oracle Database. Författare till över ett dussin prestandaförbättringar i den officiella PostgreSQL JDBC-drivrutinen.

Tidig karriär, University of Rochester. Charlotte-projektet, Lynx-språk.

Alex: Till att börja med ville jag berätta att vi alla verkligen älskar datavetenskap, datavetenskap och algoritmer i Ryssland. Det är rent obscent. Vi har läst allt bok av Cormen, Leiserson och Rivest. Därför borde den kommande konferensen, skolan och den här intervjun i sig bli väldigt populär. Vi fick många frågor till den här intervjun från studenter, programmerare och community-medlemmar, så vi är mycket tacksamma för denna möjlighet. Får datavetenskap samma kärlek i USA?

Michael: Vårt område är så mångsidigt, det har så många riktningar och det påverkar samhället på så många olika sätt att det är svårt för mig att ge dig ett definitivt svar. Men faktum är att det har åstadkommit enorma förändringar inom näringslivet, industrin, konsten och samhället i stort under de senaste 30 åren.

Виталий: Låt oss börja med något avlägset. På många universitet finns det något som specialiserar sig inom ett visst område. För Carnegie Mellon University är detta parallell beräkning, för MIT är det kryptografi, robotar och multithreading. Finns det en sådan specialisering vid University of Rochester?

Michael: För att vara ärlig skulle jag säga att CMU och MIT är specialiserade på alla områden. Vår avdelning har alltid ägnat mest uppmärksamhet åt artificiell intelligens. Hälften av de personer som arbetar för oss är engagerade i AI eller interaktion mellan människa och dator – denna andel är högre än på andra avdelningar, och har alltid varit så. Men när jag gick på universitetet hade jag inga kurser i AI, och jag jobbade aldrig inom det här området. Så min avdelning är specialiserad på ett problem som jag inte har något att göra med. Trösten är att det näst viktigaste problemet för vår avdelning är parallell och flertrådig programmering, det vill säga min specialisering.

Виталий: Du började arbeta inom datavetenskap när området flertrådad programmering precis växte fram. Listan över dina publikationer visar att dina första verk handlade om ett ganska brett spektrum av frågor: minneshantering i flertrådade system, distribuerade filsystem, operativsystem. Varför sådan mångsidighet? Har du försökt hitta din plats i forskarsamhället?

Michael: Som student deltog jag i Charlotte projekt vid University of Wisconsin, där ett av de första distribuerade operativsystemen utvecklades. Där arbetade jag tillsammans med Rafael Finkel (Raphael Finkel) och Marvin Solomon (Marvin Solomon). Min avhandling ägnades åt utvecklingen av ett språk för systemprogramvara för distribuerade system – nu har alla glömt det, och tack och lov. Jag skapade programmeringsspråket Lynx, som var tänkt att göra det lättare att skapa servrar för ett löst kopplat distribuerat operativsystem. Eftersom jag på den tiden främst ägnade mig åt operativsystem antog jag att min karriär främst skulle vara kopplad till dem. Men Rochester var ett mycket litet universitet, och på grund av detta interagerade de olika grupperna där mycket nära varandra. Det fanns inte ett dussin andra operativsystem-folk där för mig att prata med, så alla mina kontakter var med människor som arbetade inom helt andra områden. Jag gillade det verkligen, att vara en allrounder är en stor fördel för mig. Om vi ​​pratar specifikt om flertrådiga datastrukturer och synkroniseringsalgoritmer, så började jag arbeta med dem helt av en slump.

IEEE Scalable Coherent Interface, MCS-låsning.

Виталий: Kan du berätta lite mer om detta?

Michael: Det här är en rolig historia som jag aldrig tröttnar på att berätta för alla. Det hände på en konferens ASPLOS i Boston - detta var i slutet av 80-talet eller början av 90-talet. John Mellor-Crummey (John Mellor-Crummey), en examen från vår fakultet. Jag kände honom, men vi hade inte gjort gemensam forskning tidigare. Mary Vernon (Mary Vernon) från Wisconsin höll ett föredrag om ett multiprocessorsystem som de utvecklade i Wisconsin: Wisconsin Multicube. Denna Multicube hade en synkroniseringsmekanism på hårdvarunivå som kallas Q on Sync Bit, och senare döptes den om till Q på Lock Bit eftersom det lät som Colby cheese, vilket var en ordlek. Om du är intresserad av multithreading-mekanismer vet du förmodligen att Colby så småningom blev synkroniseringsmotorn för IEEE Scalable Coherent Interface-standarden. Detta var en låsmekanism som skapade pekare från en cache till en annan på hårdvarunivå så att varje låshållare visste vems tur det var. När John och jag hörde talas om detta tittade vi på varandra och sa: varför gör vi det här på hårdvarunivå? Kan inte samma sak uppnås med jämför-och-byt? Vi tog en av anteckningsböckerna som låg i klassrummet och klottrade på den MCS-blockering, medan Mary fortsatte sin rapport. Därefter implementerade vi det, experimenterade, idén visade sig vara framgångsrik och vi publicerade artikeln. På den tiden, för mig, verkade detta ämne bara vara en rolig distraktion, varefter jag planerade att återgå till operativsystem. Men sedan uppstod ett annat problem i samma linje, och så småningom blev synkronisering, multitrådning och datastrukturer min specialitet. Som du kan se hände allt detta av en slump.

Виталий: Jag har varit bekant med MCS-blockering länge, men tills nu visste jag inte att det var ditt arbete, och förstod inte att det var en akronym för dina efternamn.

Hur överlever man i en ständigt föränderlig värld?

Alex: Jag har en fråga om ett relaterat ämne. För 30 eller 40 år sedan var det mer frihet i olika specialiteter. Om du vill börja en karriär inom multithreading eller distribuerade system är du välkommen, om du vill komma in i operativsystem, inga problem. Inom varje område fanns många öppna frågor och få experter. Snäva specialiseringar har nu vuxit fram: det finns inga bara experter på operativsystem i allmänhet, det finns specialister på enskilda system. Det är samma sak med multithreading och distribuerade system. Men problemet är att våra liv inte är oändliga, alla kan bara ägna några decennier åt forskning. Hur överlever man i denna nya värld?

Michael: Vi är inte speciella i detta avseende, samma sak hände en gång i andra områden. Jag hade turen att jag började arbeta inom datavetenskap när fältet var i "tonåren". En del grunder hade redan lagts, men allt var fortfarande väldigt omoget. Denna möjlighet kommer inte ofta. Elektroteknik har funnits väldigt länge, fysik ännu längre, matematik nästan sedan tidernas begynnelse. Men det betyder inte att ingen längre gör intressanta upptäckter inom matematiken. Det finns fortfarande många öppna problem, men samtidigt behöver mer läras. Du har rätt i att konstatera att det nu finns många fler specialiseringar än vad det fanns tidigare, men detta betyder bara att vi befinner oss i samma situation som de flesta andra områden av mänsklig verksamhet.

Alex: Jag är intresserad av den mer praktiska aspekten av frågan här. Jag har en matematikbakgrund och under mina studier har jag ofta varit på konferenser och arbetat med olika vetenskapliga ämnen. Jag upptäckte att ingen i publiken förstod mina rapporter, och på samma sätt var andra människors rapporter bara förståeliga för dem själva. Så är det inte i ämnen på hög nivå, men så fort du börjar fördjupa dig i något kan publiken inte längre hänga med dig. Hur hanterar du detta?

Michael: Inte alltid framgångsrik. Jag utarbetade nyligen en rapport där jag gick för djupt in på tekniska detaljer. Allt eftersom samtalet fortskred stod det klart att de flesta av publiken inte förstod mig, så jag var tvungen att anpassa mig till situationen i farten. Bilderna gick inte att ändra, så det blev inte så bra - så generellt sett försöker jag att inte använda bilder. Sammantaget är mitt råd att ta hänsyn till din publik. Du måste veta vem du pratar med, vad deras kunskapsnivå är och vad de behöver höra för att uppskatta ditt arbete.

Виталий: Kan du ge oss en hint om vad den här föreläsningen handlade om?

Michael: För att vara ärlig, skulle jag föredra att inte utvidga detta ämne för att lämna personerna i fråga anonyma. Poängen är att vi ofta går för djupt in i det problem vi arbetar med, så det blir svårt för oss att i början av talet förklara varför problemet är intressant och viktigt och hur det relaterar till frågor som publiken redan vet. Enligt mina observationer har eleverna svårast att lära sig denna färdighet. Och detta var också den svaga punkten i mitt senaste betänkande. En ordentligt strukturerad rapport bör redan från början hitta kontakt med publiken, förklara för dem exakt vad problemet är och hur det relaterar till ämnen som redan är kända för den. Hur teknisk denna introduktion är beror på publiken. Om den är helt brokig kan rapporten vara flerstegs. Introduktionen bör vara tillgänglig för alla, och i slutet kanske verket inte kan hänga med dig, men personer som är relativt bekanta med ditt område kommer att kunna lista ut det.

Blir eleverna dummare? Globala trender, internationalisering.

Alex: Du har observerat elever i flera decennier. Blir eleverna dummare eller smartare från decennium till decennium eller år till år? I Ryssland klagar professorer ständigt på att studenterna blir dummare för varje år, och det är verkligen inte klart vad de ska göra åt det.

Michael: Man kan verkligen höra mycket negativitet från oss gamla. Undermedvetet har vi en tendens att förvänta oss att eleverna ska ta till sig alla de 30 års erfarenhet som vi redan har. Om jag har en djupare förståelse än vad jag hade 1985, varför har inte eleverna det? Förmodligen för att de är 20 år, vad tror du? Jag tror att de mest betydande förändringarna under de senaste decennierna har varit i den demografiska sammansättningen: vi har nu betydligt fler internationella studenter, med undantag för kanadensare. Tidigare var det många kanadensare eftersom vi ligger väldigt nära den kanadensiska gränsen och studenter därifrån kan resa hem på helgerna. Men nu finns det många bra universitet i Kanada, och kanadensare föredrar att studera här, betydligt färre av dem kommer till USA.

Alex: Tror du att detta är en lokal trend eller en global?

Michael: Jag kommer inte ihåg exakt vem, men någon sa att världen är platt. Vårt område har blivit mycket mer internationellt. ACM-konferenser Tidigare hölls de uteslutande inom USA, sedan bestämde de sig för att hålla dem en gång vart fjärde år i andra länder, och nu hålls de över hela världen. Dessa förändringar påverkade ännu mer IEEE, eftersom det alltid har varit en mer internationell organisation än ACM. Och det finns programstolar från Kina, Indien, Ryssland, Tyskland och många andra länder, för det händer mycket överallt nu.

Alex: Men förmodligen finns det några negativa aspekter av en sådan internationalisering?

Michael: Jag skulle säga att alla negativa aspekter inte relaterar till teknik, utan till politik. En gång i tiden var huvudproblemet det faktum att USA stal de smartaste och mest begåvade människorna från länder runt om i världen. Och nu är huvudproblemet det politiska spelet mellan olika länder kring visum och immigration.

Alex: Det vill säga barriärer och sånt. Kusten är klar.

vladimir: Personligen är jag intresserad av vilket förhållningssätt du tar när du undervisar i ett nytt ämne för elever. Det finns olika alternativ: du kan först av allt försöka inspirera dem att prova något nytt, eller så kan du ägna mer uppmärksamhet åt detaljerna i hur en viss teknik fungerar. Vad föredrar du?

Effektivt arbete med elever

Alex: Och hur hittar man den jäkla balansen mellan ettan och tvåan?

Michael: Problemet är att klasserna inte alltid går som jag skulle vilja. Jag brukar ge eleverna läsmaterial i förväg så att de fördjupar sig i det, förstår det efter bästa förmåga och formulerar frågor om de delar som de inte kunde förstå. Sedan kan du i klassen fokusera på de svåraste ögonblicken och utforska dem tillsammans. Det är så jag gillar att hålla klasser mest. Men med tanke på den belastning som nu ligger på eleverna kan jag inte alltid se till att de förbereder sig i förväg. Som ett resultat måste du ägna mycket mer tid åt den allmänna återberättelsen av materialet än du skulle vilja. Trots detta försöker jag hålla våra klasser interaktiva. Annars är det lättare att spela in en video en gång som eleverna sedan kan titta på hemma. Poängen med levande klasser är mänsklig interaktion. I klassen föredrar jag att använda krita och en svart tavla snarare än diabilder, utom i vissa fall när ett diagram är för komplext för att avbilda på tavlan. Tack vare detta behöver jag inte hålla mig till en stel lektionsplan. Eftersom det inte finns någon strikt ordning i vilken jag ger materialet, gör detta att jag kan skräddarsy det till publiken beroende på vilka frågor jag får. I allmänhet försöker jag göra klasserna så interaktiva som möjligt, så att materialet jag presenterar beror på de frågor som ställs till mig.

vladimir: Det är toppen. Enligt min erfarenhet är det ganska svårt att få lyssnare att ställa frågor. Även om du i förväg ber om att få ställa några frågor, hur dumma eller smarta än är, så är de fortfarande tysta. Hur hanterar du detta?

Michael: Du kommer att skratta, men om du står tyst tillräckligt länge kommer alla förr eller senare att bli obekväma och någon ställer en fråga. Eller så kan du ställa en enkel teknisk fråga med ett ja eller nej svar för att avgöra om folk förstår vad som just sas. Finns det till exempel ett datarace i exemplet ovan? Vem tror det? Vem tror inte? Vem förstår ingenting alls, för totalt gick bara hälften av händerna upp?

Виталий: Och om du svarat fel så blir du utslängd ur klassen :)

Michael: Om du inte har svarat på något bör du ställa en fråga. Jag måste förstå exakt vad eleven behöver veta för att svara på frågan jag just ställde. Jag behöver dem för att hjälpa mig att hjälpa dem. Jag är redo att anpassa mig till dem så att de förstår problemet. Men om jag inte vet vad som händer i deras huvuden så kan jag inte göra det. Och om man inte ger eleverna ro under tillräckligt lång tid, ibland ställer de i slutändan de rätta frågorna, det vill säga sådana som gör att jag kan se exakt vad som pågår i elevernas huvuden. 

Alex: Leder dessa frågor ibland till idéer som du själv inte hade tänkt på tidigare? Är de oväntade? Tillåter de dig att se på ett problem i ett nytt ljus?

Michael: Det finns frågor som öppnar för ett nytt sätt att presentera material. Det finns ofta frågor som leder till intressanta problem som jag inte tänkt prata om. Elever säger ofta till mig att jag har en tendens att gå utanför ämnet när detta händer. Och enligt dem är detta väldigt ofta den mest intressanta delen av lektionen. Mycket sällan, bara några få gånger, ställde eleverna frågor som ledde till en ny riktning i forskningen och växte till en artikel. Detta händer mycket oftare i samtal med elever snarare än under lektionerna, men ibland hände det under lektionerna. 

Alex: Så eleverna ställde frågor till dig utifrån vilka det sedan var möjligt att publicera en artikel?

Michael: Ja. 

Виталий: Hur ofta har du dessa samtal med elever? När vill de lära sig mer än vad som behandlades under lektionen?

Michael: Med mina doktorander - hela tiden. Jag har ungefär 5 eller 6 av dem, och vi diskuterar något med dem hela tiden. Och samtal av det här slaget med elever som helt enkelt går på mina lektioner är inte särskilt vanliga. Även om jag önskar att detta hände oftare. Jag misstänker att de helt enkelt är rädda för att komma till fakulteten under kontorstid. Varje termin lyckas vissa elever övervinna denna psykologiska barriär, och det är alltid väldigt intressant att prata med dem efter lektionen. Det är sant att om alla elever var lika modiga skulle jag helt enkelt inte ha tillräckligt med tid. Så kanske allt fungerar som det ska. 

Виталий: Hur lyckas du hitta tid att kommunicera med eleverna? Så vitt jag vet har lärare i USA mycket arbete - att söka bidrag och liknande. 

Michael: Ärligt talat, att arbeta med studenter är den aspekt av mitt jobb som jag tycker mest om. Så jag har tillräckligt med motivation för detta. Den mesta tiden jag spenderar på mitt kontor går åt till möten av alla slag. Det är sommar nu, så mitt schema är mindre späckat, men under läsåret, varje dag från 9 till 17 har jag allt packat. Forskningsarbete, recensioner, anslag – till allt detta finns bara kvällar och helger. 

Hur man hänger med i förberedelserna av nya kurser och böcker.

Alex: Fortsätter du för närvarande att undervisa i några kurser som du har undervisat länge? Något som en introduktion till datavetenskap.

Michael: Det första som kommer att tänka på här är en kurs i programmeringsspråk. 

Alex: Hur annorlunda är dagens version av den här kursen från vad den var för 10, 20, 30 år sedan? Det som kanske är mer intressant här är inte detaljerna i en viss kurs, utan de allmänna trenderna.

Michael: Min kurs i programmeringsspråk var något ovanlig när jag skapade den. Jag började läsa den i slutet av 1980-talet och ersatte min kollega Doug Baldwin (Doug Baldwin). Ämnet för kursen var bara tangentiellt relaterat till min specialitet, men när han slutade var jag den bästa kandidaten att undervisa i kursen. Jag gillade inte någon av läroböckerna som fanns på den tiden, så det slutade med att jag skrev läroboken till den här kursen själv. (Redaktörens anmärkning: vi pratar om boken "Programmeringsspråkpragmatik") Den används nu på mer än 200 universitet runt om i världen. Mitt tillvägagångssätt är ovanligt genom att det medvetet blandar problemen med språkdesign och implementering, och lägger stor vikt vid samspelet mellan dessa aspekter inom alla möjliga områden. Det grundläggande tillvägagångssättet har förblivit oförändrat, liksom många grundläggande begrepp: abstraktioner, namnutrymmen, modularitet, typer. Men uppsättningen språk som dessa begrepp demonstreras med har förändrats helt. När kursen först skapades fanns det många exempel i Pascal, men idag har många av mina elever inte ens hört talas om detta språk. Men de kan Swift, Go, Rust, så jag måste prata om språken som används idag. Dessutom är eleverna nu väl bevandrade i skriptspråk, men när jag började undervisa i den här kursen handlade allt om sammanställda språk. Nu behöver vi mycket material om Python, Ruby och till och med Perl, för det här är vad kod skrivs i dessa dagar, och det händer många intressanta saker på dessa språk, inklusive inom språkdesign. 

Виталий: Då kommer min nästa fråga att vara relaterad till den föregående. Hur ska man hänga med på det här området? Jag misstänker att det krävs mycket arbete för att uppdatera en sådan här kurs – du måste förstå nya språk, förstå huvudidéerna. Hur gör du det här?

Michael: Jag kan inte skryta med att jag alltid lyckas till 100 %. Men för det mesta gör jag bara det som alla andra gör – läser internet. Om jag vill förstå Rust så googlar jag det, går till Mozilla-sidan och läser manualen som finns där. Detta är en del av de saker som händer inom kommersiell utveckling. Om vi ​​pratar om vetenskap, då måste du följa rapporterna på huvudkonferenserna. 

Länk mellan näringsliv och akademi

Виталий: Låt oss prata om kopplingen mellan näringsliv och vetenskaplig forskning. I din lista över verk hittade jag flera artiklar om cachekoherens. Jag förstår att cachekonsistensalgoritmerna var instabila när de publicerades? Eller inte tillräckligt utbredd. Hur vanliga var dina idéer i praktiken?

Michael: Jag är inte riktigt säker på vilka publikationer du pratar om. Jag har gjort en hel del arbete med mina elever Bill Bolosky (William Bolosky) och Leonidas Kontotanassis (Leonidas Kontothanassis) i början av 1990-talet om minneshantering av Neumann-maskiner. Vid den tiden hade företag ännu inte en förståelse för hur man korrekt gör ett multiprocessorsystem: är det värt att skapa stöd för åtkomst till fjärrminne på hårdvarunivå, är det värt att distribuera minnet, är det möjligt att ladda cachen från fjärrminne, eller är det nödvändigt att flytta sidor i operationssalen? Bill och Leonidas arbetade båda i det här området och utforskade tillvägagångssätt utan fjärrcacheladdning. Detta var inte direkt relaterat till cachekoherens, men det var fortfarande arbete med NUMA-minneshantering, och senare växte moderna metoder för sidplacering i moderna operativsystem från detta. Sammantaget gjorde Bill och Leonidas ett viktigt arbete, även om det inte var det mest inflytelserika inom detta område - det fanns många andra som arbetade med samma sak vid den tiden. Senare arbetade jag med ett ämne relaterat till cachekoherens i samband med hårdvarutransaktionsminne. Gruppen jag arbetade med på detta problem fick till slut flera patent. Det finns några ganska intressanta idéer bakom dem, men jag tror inte att de kommer att genomföras i praktiken. På ett eller annat sätt är det svårt för mig att bedöma deras lönsamhet. 

Alex: I detta avseende en mer personlig fråga: hur viktigt är det för dig att dina idéer omsätts i praktiken? Eller tänker du inte på det?

Michael: Jag älskar att ställa den här frågan i intervjuer med andra människor, sökande eller kandidater som vill gå med på fakulteten. Jag tror inte att det finns ett korrekt svar på denna fråga. Människor som gör coola saker kan ha väldigt olika motivation. Jag attraheras av problem för att jag personligen tycker att de är intressanta, inte på grund av deras praktiska fördelar. Men å andra sidan, när någon intressant sak fortfarande finner tillämpning, gillar jag det verkligen. Så det är inte lätt här. Men i början av mitt arbete drivs jag fortfarande inte av idén om en slutanvändning i världen, utan av idéns harmoni och viljan att utforska den och se vad som kommer av den. Om det i slutändan ger praktiska resultat, bra. 

Alex: På grund av din utbildning och erfarenhet kan du bättre än de flesta bedöma värdet av andras idéer. Du kan jämföra dem och avgöra vilken som fungerar bäst med vilken. Jag är säker på att du har en åsikt om saker som för närvarande används i praktiken av stora tillverkare som Intel. Ur din synvinkel, hur korrekt är den kurs som dessa företag tar?

Michael: Övning kretsar alltid kring vad som kan vara kommersiellt framgångsrikt, det vill säga skapa vinst, och det är bäst att du frågar någon annan om det. Mitt arbete resulterar mest i publikationer och inom området operativsystem utvärderas de utifrån prestandaindikatorer: hastighet, energiförbrukning, kodstorlek. Men det föreföll mig alltid som om dessa empiriska resultat läggs till artiklar bara för att de ska kunna publiceras, och människors verkliga motiv för arbete är estetiska. Forskare utvärderar lösningar ur ett konstnärligt perspektiv, de bryr sig om hur eleganta idéerna är och de försöker skapa något bättre än befintliga tillvägagångssätt. Forskare drivs av personliga, subjektiva, estetiska motiv. Men du kan inte skriva om detta i själva artikeln, det här är inga argument för programkommittén. Som tur är är eleganta lösningar ofta också snabba och billiga. Ett dussin av mina kollegor och jag diskuterade detta ämne för ungefär 15 år sedan och slutade med att skriva en artikel om det. Jag tror att du fortfarande kan hitta den nu, heter den "Hur man utvärderar systemforskning" eller något liknande, den har mer än ett dussin författare. Detta är den enda artikeln där jag är författare tillsammans med Sasha Fedorova, så om du gör en sökning på hennes namn i min publikationslista hittar du det du behöver. Den talar om att utvärdera systemforskning och hur viktigt elegans är. 

Alex: Så det finns en skillnad mellan standarden på vad som anses vara bra inom vetenskapen och i näringslivet. Vetenskapen utvärderar prestanda, strömförbrukning, TDP, enkel implementering och mycket mer. Har du möjlighet att bedriva den här typen av forskning vid universitetet? Har du ett laboratorium med olika maskiner och olika arkitekturer där du kan utföra experiment?

Michael: Ja, vår avdelning har många olika intressanta maskiner. Oftast är de små, vi har ett litet kluster och många multiprocessorsystem med olika acceleratorer. Dessutom har campus ett enormt datacenter som betjänar forskare från flera dussin olika discipliner. Den har ungefär tusen noder och tjugo tusen kärnor, allt på Linux. Om behovet uppstår kan du alltid köpa lite AWS. Så vi har inga betydande begränsningar med hårdvara. 

Alex: Hur var det för trettio år sedan? Var det problem då?

Michael: Det var lite annorlunda då. I mitten till slutet av 1980-talet ansågs vetenskapen sakna datorresurser. För att åtgärda denna situation, National Science Foundation (Nationella vetenskapsfonden) skapade ett program för samordnad experimentell forskning (Coordinated Experimental Research, CER). Programmets uppdrag var att tillhandahålla datorinfrastruktur för datavetenskapsavdelningar, och det har uppnått betydande förändringar. Med pengarna hon gav köpte vi på University of Rochester en 1984-knops BBN Butterfly 128, det här var ett år innan jag kom dit. På den tiden var det världens största multiprocessorsystem med delat minne. Den hade 128 processorer, var och en på ett separat moderkort, och upptog fyra rack. Varje processor hade en megabyte minne, 128 megabyte RAM var en ofattbar mängd på den tiden. På den här maskinen implementerade vi MCS-låsning för första gången. 

Alex: Så, om jag förstår dig rätt, är problemet med hårdvaran löst för tillfället? 

Michael: I allmänhet, ja. Det finns några varningar: för det första, om du gör datorarkitektur på chipnivå är det svårt att göra i en akademisk miljö eftersom det finns mycket bättre verktyg för att göra det i affärer. Om du behöver något mindre än 10 nanometer måste du beställa det från någon annan. Inom detta område är det mycket lättare att vara forskare på Intel. Om du arbetar med optisk kommunikation på chips eller på solid-state-minne, kommer du att hitta teknologier i näringslivet som ännu inte är inom vetenskapen, så du måste skapa allianser. Till exempel, Stephen Swanson (Steven Swanson) skapat ett sådant partnerskap för ny minnesteknik. Denna form fungerar inte alltid, men i vissa fall kan den vara ganska framgångsrik. Dessutom är utvecklingen av de mest kraftfulla datorsystemen inom vetenskapen svårare. De största superdatorprojekten för närvarande i USA, Japan och Kina är alla inriktade på affärer. 

Praktisk implementering av idéer. MCS, MS, CLH, JSR 166, arbetar med Doug Lee och mer.

Виталий: Du har redan pratat om hur du började arbeta med synkroniseringsalgoritmer. Du har två mycket kända artiklar om MCS-blockering и Michael-Scott kö (MS), som på sätt och vis implementerades i Java. (Redaktörens anmärkning: alla publikationer kan ses по ссылке). Där implementerades denna blockering med vissa ändringar och det visade sig CLH lås, och kön implementerades som avsett. Men det gick många år mellan publiceringen av dina artiklar och deras praktiska tillämpning. 

Alex: Det verkar ungefär 10 år i fallet med kön.

Michael: Innan dessa funktioner dök upp i Java-standardbiblioteket?

Виталий: Ja. Vad gjorde du för att få detta att hända? Eller gjorde de ingenting?

Michael: Jag kan berätta hur MS Queue kom in i Java 5. Några år innan det kom ut arbetade jag med Mark Moyers grupp på Sun Microsystems i deras labb nära Boston. Han organiserade en workshop för personer han kände som arbetade med intressanta problem inom multithreading eftersom han ville hitta ämnen som han kunde sälja till deras företag. Det var där jag först träffade Doug Lea. Doug och jag och cirka 25 andra personer från Sun diskuterade tillsammans Dougs presentation om JSR 166, som senare blev java.util.concurrent. På vägen sa Doug att han skulle vilja använda MS-kön, men för detta behövde han en räknare för antalet element i kön för gränssnittet. Det vill säga, detta borde ha gjorts med en separat metod, atomär, exakt och snabb. Jag föreslog att man helt enkelt skulle lägga till serienummer till noderna, ta numret på den första noden och den sista och subtrahera den ena från den andra. Doug kliade sig i huvudet, sa "varför inte", och det slutade med att han gjorde just det. Vi diskuterade att implementera detta tillvägagångssätt i biblioteket, men Doug gjorde det mesta själv. Som ett resultat lyckades han etablera utmärkt multithreading-stöd i Java. 

Alex: Så, om jag förstår rätt, borde .size()-metoden ha varit en del av standardkögränssnittet, och den borde ha haft en algoritmisk komplexitet på O(1)?

Michael: Ja, och utöver detta krävs en separat räknare.

Alex: För om du anropar metoden .size() i Java förväntas resultatet bli tillgängligt omedelbart och inte baserat på den faktiska storleken på samlingen. Jag förstår tack.

Michael: Några år senare arbetade jag på dubbla datastrukturer med min elev Bill Scherer - det är faktiskt det här jag kommer att prata om rapport om Hydra. Doug kom till oss och sa att han kunde använda dem i Java Executor Framework. Tillsammans med Bill skapade de två implementeringar, de så kallade rättvisa och orättvisa köerna. Jag gav dem råd om detta projekt, även om jag inte deltog i att skriva själva koden. Som ett resultat har hastigheten för exekutörer ökat avsevärt. 

vladimir: Har du stött på felaktiga implementeringar av dina algoritmer eller förfrågningar om att lägga till nya funktioner? I allmänhet bör praktiken sammanfalla med teori, men ganska ofta skiljer de sig åt. Anta att du skrev en algoritm, och på pappret fungerar den, men personerna som är involverade i implementeringen började be dig om fler funktioner eller någon form av justering av algoritmen. Har du någonsin haft sådana situationer?

Michael: Det enda exemplet där någon kom till mig och frågade "hur man implementerar det" var Dougs fråga, som jag redan pratat om. Men det har förekommit några fall där intressanta förändringar har gjorts för att passa praktiska behov. Till exempel konverterade K42-teamet på IBM MCS-låset och gjorde det till ett standardgränssnitt så att det inte fanns något behov av att skicka könoden fram och tillbaka till rutinerna för förvärv och släpp. Tack vare detta standardgränssnitt började en idé som var vacker i teorin att fungera i praktiken. Det är förvånande att de aldrig publicerade en artikel om det, och även om de fick ett patent övergav de det senare. Idén var underbar, och jag försöker prata om den när det är möjligt. 

Det har funnits andra fall där människor har gjort förbättringar av de algoritmer jag har publicerat. Till exempel har MS-kön en installationsmekanism i två steg, vilket innebar att det fanns två CAS på den kritiska vägen till kön. På äldre bilar var CAS ganska dyra. Intel och andra tillverkare har optimerat dem ganska bra nyligen, men en gång i tiden var det 30-cyklers instruktioner, så att ha mer än en på den kritiska vägen var inte önskvärt. Som ett resultat utvecklades en annan kö som liknade MS-kön, men som bara hade en atomoperation på den kritiska vägen. Detta uppnåddes på grund av att operationen under en viss tidsperiod kunde ta O(n) tid, snarare än O(1). Det var osannolikt, men möjligt. Detta hände på grund av det faktum att algoritmen vid vissa ögonblick korsade kön från början till den aktuella positionen i denna kö. Generellt sett visade sig algoritmen vara mycket framgångsrik. Så vitt jag vet är det inte särskilt flitigt använt, bland annat för att atomoperationer kräver betydligt mindre resurser än tidigare. Men idén var jättebra. Jag gillar också verkligen arbetet av Dave Dice från Oracle. Allt han gör är väldigt praktiskt och han använder järn väldigt smart. Han hade ett finger med i mycket av de NUMA-medvetna synkroniseringsalgoritmerna och flertrådiga datastrukturer. 

vladimir: När du skriver algoritmer eller undervisar elever är resultatet av ditt arbete inte direkt synligt. Samhället behöver lite tid för att bli bekant med, säg, en ny artikel. Den nya algoritmen hittar inte omedelbart tillämpning. 

Michael: Det är långt ifrån direkt klart om artikeln kommer att ha betydelse eller inte. Jag tycker att det skulle vara intressant att göra en studie av artiklar som vunnit priser på konferenser. Det vill säga titta på de artiklar som folk i programnämnderna en gång ansåg vara bäst. Du måste försöka beräkna hur inflytelserika dessa artiklar verkligen visade sig vara på 10, 20, 25 år utifrån antalet länkar och påverkan på verksamheten. Jag tvivlar på att det skulle finnas ett starkt samband mellan de två. Det blir inte noll, men troligtvis blir det mycket svagare än vad vi skulle vilja. Många idéer förblir outtagna under lång tid innan de får stor spridning. Låt oss till exempel ta transaktionsminne. Det gick mer än 10 år från det att den ursprungliga artikeln publicerades till det att folk faktiskt började bygga maskiner med den. Och före uppkomsten av detta minne i kommersiella produkter - och alla 20. Under mycket lång tid var det ingen som uppmärksammade artikeln, och sedan ökade antalet länkar till den kraftigt. Det skulle vara svårt att förutse detta i förväg. Å andra sidan, ibland hittar idéer genomförande omedelbart. För några år sedan skrev jag en artikel med Joe Izraelevitz för DISC som föreslog en ny formell definition av giltighet för beständiga datastrukturer som kan användas efter att datorn som kör dem kraschar. Jag gillade artikeln från första början, men den visade sig vara mycket mer populär än jag förväntade mig. Det användes av flera olika grupper och blev så småningom standarddefinitionen av beständighetsstrukturer. Vilket såklart är trevligt.

vladimir: Finns det några tekniker som du använder för bedömning? Försöker du ens att utvärdera dina artiklar och dina elever? När det gäller om personen du undervisat går åt rätt håll.

Michael: Som alla andra lägger jag mer uppmärksamhet på vad jag gör för tillfället. Återigen, som alla andra, kollar jag ibland Google Scholar för att se om mina tidigare uppsatser citeras, men det är mer av nyfikenhet. För det mesta är jag uppslukad av vad mina elever gör nu. När det gäller att utvärdera aktuellt arbete är en del av det estetiska överväganden, vad som är elegant och vad som inte är det. Och på det vardagliga planet spelar öppna frågor en stor roll. Till exempel kommer en elev till mig med en graf över några resultat, och vi försöker förstå varifrån något konstigt beteende i grafen kom. I allmänhet försöker vi i vårt arbete ständigt förstå saker som vi ännu inte förstår. 

Transaktionsminne

Виталий: Vi kanske kan prata lite om transaktionsminne?

Michael: Jag tycker att det är värt att säga åtminstone lite eftersom jag lägger mycket kraft på det. Det här är ett ämne som jag har fler publikationer om än någon annan. Men samtidigt var jag konstigt nog alltid väldigt skeptisk till transaktionsminne. Enligt min åsikt, artikel av Herlihy och Moss (M. Herlihy, J. E. B. Moss) publicerades före sin tid. I början av 1990-talet föreslog de att transaktionsminne kunde hjälpa begåvade programmerare att arbeta med flertrådiga datastrukturer, så att dessa strukturer sedan kunde användas som bibliotek av vanliga programmerare. Det vill säga, det skulle vara en hjälp för Doug Lee att göra sin JSR 166. Men transaktionsminnet var inte avsett att göra flertrådsprogrammering enkel. Men det var precis så det började uppfattas i början av 2000-talet, när det fick stor spridning. Det annonserades som ett sätt att lösa problemet med parallell programmering. Detta tillvägagångssätt har alltid verkat hopplöst för mig. Transaktionsminne kan bara göra det lättare att skriva parallella datastrukturer. Det tycks mig vara detta som hon uppnådde. 

Om svårigheten att skriva flertrådig kod

Alex: Mycket intressant. Det verkar finnas en viss barriär mellan vanliga programmerare och de som kan skriva flertrådad kod. Förra året pratade jag flera gånger med personer som implementerade något algoritmiskt ramverk. Till exempel med Martin Thomson, såväl som med programmerare som arbetar med flertrådiga bibliotek. (Redaktörens anmärkning: Martin Thompson är en mycket känd utvecklare, skrev han disruptor и Aeron. Och det har han också Rapportera på vår Joker 2015-konferens, videoinspelning tillgängligt på YouTube. Han är sig lik öppnad denna konferens keynote inspelning också tillgänglig). Den största utmaningen, säger de, är att göra algoritmerna både snabba och enkla att använda. Det vill säga, de försöker övervinna denna barriär och locka så många människor som möjligt till detta område. Vad tycker du om det?

Michael: Detta är huvudproblemet med multithreading: hur man uppnår hög prestanda utan att öka komplexiteten i systemet. 

Alex: För när de försöker undvika komplexitet blir algoritmen mindre universell.

Michael: Nyckeln här är korrekt designade abstraktioner. Det förefaller mig som att detta generellt sett är det viktigaste för datorsystem som fält. Butler Lampson gillar att använda denna term, och han kallar oss "handlare av abstraktioner." Enkla tekniker finns inte idag. Processorerna vi använder har 10 miljarder transistorer – enkelhet är uteslutet. Samtidigt är ISA mycket enklare än processorn, eftersom vi arbetat väldigt länge för att ge den hög prestanda och ett relativt enkelt gränssnitt. Men allt är inte smidigt med henne heller. Samma problem är med acceleratorer som nu dyker upp på marknaden. Frågor uppstår - hur man gör rätt gränssnitt för GPU, en krypteringsmekanism, komprimering, en omkodningsmekanism, en linjär algebramekanism eller till och med en mer flexibel FPGA. Hur skapar man ett gränssnitt som gör verktyget lätt att använda och döljer komplexitet? Det kommer inte att bli av med det, utan snarare dölja det för en enkel programmerare. 

Alex: Som jag förstår det har vi fortfarande en barriär när det gäller att förstå abstraktioner. Låt oss ta minnesmodellen; i vårt utvecklingsstadium av vetenskap och teknik är detta en av de viktigaste abstraktionerna. Tack vare det är alla programmerare indelade i två grupper: den större delen är de som inte förstår det, och den mindre delen är de som förstår, eller tror att de förstår. 

Michael: Det är en bra fråga - förstår någon av oss verkligen minnesmodellen?

Виталий: Speciellt i C++.

Michael: Prata med Hans Boehm någon gång. Han är en av de smartaste människorna jag känner, en ledande expert på minnesmodeller. Han kommer genast att berätta för dig att det är mycket han inte förstår. Men om vi återvänder till frågan om abstraktioner, så uttrycktes enligt min mening den viktigaste idén inom området minnesmodeller under de senaste 30 åren i Sarita Adves avhandling. (Redaktörens anmärkning: en komplett lista över publikationer finns tillgänglig по ссылке).

Alex: Min fråga är: kommer denna barriär från själva begreppets natur? 

Michael: Nej. Sarita kom fram till att med rätt tillvägagångssätt kan du framgångsrikt dölja all komplexitet, få hög prestanda och ge programmeraren ett enkelt API. Och om du följer detta API kan du uppnå konsekvent konsekvens. Jag tror att detta är rätt modell. Skriv kod utan datarace och få sekventiell konsekvens. Naturligtvis, för att minska sannolikheten för racing, behövs specialverktyg, men det är en annan sak. 

vladimir: Har det funnits tillfällen i din karriär när ett problem som verkade löst plötsligt förvandlades till en katastrof, eller det visade sig att det här problemet var olösligt? Till exempel, i teorin kan du faktorisera vilket tal som helst eller avgöra om något tal är primtal. Men i praktiken kan detta vara svårt att göra, med nuvarande hårdvara är det svårt att faktorisera siffror. Har något liknande hänt dig?

Michael: Jag kommer inte direkt ihåg något sådant. Det har funnits tillfällen då det verkade för mig att det inte fanns något kvar att göra i ett visst område, men sedan hände något nytt och intressant där. Till exempel trodde jag att området med obegränsad kö redan hade nått mognad. Efter flera förbättringar av MNS-kön hände inte mycket längre. Och sedan uppfann Morrison (Adam Morrison) och Afek (Yehuda Afek). LCRQ-kö. Det blev tydligt att en obegränsad flertrådig kö var möjlig, där det mesta av tiden bara fanns en hämta-och-ökningsinstruktion på den kritiska vägen. Och detta gjorde det möjligt att uppnå en storleksordning bättre prestanda. Det är inte så att vi inte vet att hämta-och-öka är en mycket användbar sak. Eric Freudenthal skrev om detta i sitt arbete med Ultradatorn med Allan Gottlieb i slutet av 1980-talet, men det handlade om begränsade köer. Morrison och Afek kunde använda hämta-och-öka på en obegränsad kö.

Nya arkitekturer. Är transaktionsminnets seger nära?

vladimir: Letar du efter nya arkitektoniska lösningar som kan vara användbara för algoritmer? 

Michael: Naturligtvis finns det många saker som jag skulle vilja se implementerade. 

vladimir: Vilken sort till exempel?

Michael: Först och främst några enkla tillägg till vårt transaktionsminne på hårdvarunivå i Intel- och IBM-processorer. I synnerhet skulle jag vilja att den icke-transaktionella belastningen och butiken som just har inträffat är omedelbart tillgänglig inom transaktioner. De leder omedelbart till loopar i händer-före-sekvensen, så de kan vara svåra. Men om du upprätthåller lager av abstraktion finns det många mycket intressanta saker du kan göra utanför transaktionen medan den pågår. Jag vet inte hur svårt detta skulle vara att genomföra, men det skulle vara väldigt användbart. 

En annan användbar sak är att ladda cache från fjärrminnet. Jag tror att detta kommer att göras förr eller senare. Denna teknik kommer att möjliggöra skapandet av system med disaggregerat minne. Det skulle vara möjligt att behålla till exempel 100 terabyte beständigt minne i ett rack, och operativsystemet självt skulle dynamiskt bestämma vilka delar av det minnet som ska motsvara processorernas fysiska adressutrymme. Detta skulle vara extremt användbart för cloud computing, eftersom det skulle tillåta stora mängder minne att tillhandahållas för de uppgifter som behöver det. Jag tror att någon kommer att göra det.

Виталий: För att avsluta med att prata om transaktionsminne har jag ytterligare en fråga om detta ämne. Kommer transaktionsminne så småningom att ersätta standard flertrådiga datastrukturer?

Michael: Nej. Transaktioner är en spekulativ mekanism. På programmeringsnivå är dessa atomlås, men inuti är de spekulationer. Sådana prognoser fungerar om de flesta gissningar är korrekta. Därför fungerar transaktionsminne bra när trådar knappast interagerar med varandra, och du behöver bara se till att det inte finns några interaktioner. Men om ett meddelande startar mellan trådarna är transaktioner till liten nytta. Låt mig förklara, vi talar om fallet när transaktioner lindas runt hela atomoperationen. De kan fortfarande framgångsrikt användas som komponenter för flertrådiga datastrukturer. Till exempel, om du behöver ett treords CAS, och du behöver flertråda tre små saker mitt i en verkligt flertrådad algoritm som fungerar med tjugo trådar samtidigt. I allmänhet kan transaktioner vara användbara, men de kommer inte att eliminera behovet av att korrekt designa flertrådade datastrukturer. 

Icke-flyktigt minne, Optane DIMM, ultrasnabba enheter.

Виталий: Det sista jag skulle vilja prata om är ämnet för din nuvarande forskning: icke-flyktigt minne. Vad kan vi förvänta oss inom detta område inom en snar framtid? Kanske känner du till några effektiva implementeringar som redan finns? 

Michael: Jag är ingen hårdvaruexpert, jag vet bara vad jag läser i nyheterna och vad mina kollegor säger till mig. Alla har redan hört att Intel säljer Optane DIMM, som har cirka 3 gånger läslatens och 10 gånger skrivlatens än dynamiskt RAM. De kommer snart att finnas tillgängliga i versioner med mycket stora volymer. Det är lustigt att tänka på att du skulle kunna ha en bärbar dator med flera terabyte byteadresserbart RAM-minne. Det är troligt att vi om 10 år kommer att besluta oss för att använda denna nya teknik, eftersom vi använder DRAM - bara öka volymen. Men tack vare energioberoende öppnar sig helt nya möjligheter för oss. Vi kan fundamentalt ändra lagringsstacken så att det inte finns någon separation mellan byteadresserbart arbetsminne och blockstrukturerat persistent minne. Vi behöver alltså inte serialisera allt som behöver överföras från ett program som körs till ett annat till blockstrukturerade filer. Ur detta kan vi härleda många viktiga principer som påverkar operativsystem, runtime-miljöer och distribuerade datalager. Det här området är väldigt intressant att arbeta inom. Personligen är det svårt för mig att förutse vad allt detta kommer att leda till, men problemen här är extremt underhållande. Det kan finnas revolutionerande förändringar här, och de följer mycket naturligt av arbetet med multithreading, eftersom felåterställning är en "multithreading"-process bredvid den normala driften av systemet. 

Det andra huvudämnet jag för närvarande arbetar med är att hantera ultrasnabba enheter och säker åtkomst till enheter från användarutrymmet med systemisk policykontroll. Under de senaste åren har det funnits en trend att flytta åtkomsten till enheten till användarutrymmet. Detta görs eftersom TCP-IP-kärnstacken inte kan fungera ovanpå ett nätverksgränssnitt som behöver ett nytt paket var 5:e mikrosekund, det kommer helt enkelt inte att hänga med. Därför ger tillverkare direkt åtkomst till enheter. Men detta innebär att operativsystemet tappar kontrollen över processen och det kan inte ge korrekt åtkomst till enheten för konkurrerande applikationer. Vårt forskarteam anser att denna brist kan undvikas. Vi kommer att ha en artikel om detta på USENIX ATC den här månaden. Det är relaterat till arbete med persistens, eftersom långlivat byte-adresserbart persistent minne i huvudsak är en enhet med ultrasnabb I/O som måste nås i användarutrymmet. Denna forskning möjliggör nya tillvägagångssätt för mikrokärnor, exokernelar och andra traditionella försök att säkert flytta funktionalitet från OS-kärnan till användarutrymmet. 

vladimir: Byteadresserbart minne är bra, men det finns en fysisk begränsning - ljusets hastighet. Detta innebär att det oundvikligen kommer att uppstå en fördröjning vid interaktion med enheten. 

Michael: Fullständigt rätt.

vladimir: Kommer det att finnas tillräckligt med kapacitet för att klara de nya lasterna?

Michael: Det här är en utmärkt fråga, men det blir svårt för mig att svara på. Idén om att bearbeta i minnet har funnits ganska länge, det är väldigt intressant, men också väldigt komplext. Jag har inte arbetat inom det här området, men det skulle vara fantastiskt om några upptäckter gjordes där. Jag är rädd att jag inte har något mer att tillägga. 

vladimir: Det finns ett problem till. Nya, betydligt större mängder RAM kommer att vara omöjliga att passa in i CPU:n. Därför, på grund av fysiska begränsningar, måste detta RAM-minne isoleras. 

Michael: Allt beror på antalet defekter i produktionen av integrerade kretsar. Om det var möjligt att skapa halvledarskivor helt utan defekter, skulle det vara möjligt att göra en hel mikrokrets av den. Men nu vet vi inte hur man gör mikrokretsar större än frimärken. 

vladimir: Men vi pratar fortfarande om enorma storlekar, ungefär centimeter. Detta har oundvikligen en inverkan på latensen. 

Michael: Ja. Det finns inget du kan göra åt ljusets hastighet. 

vladimir: Tyvärr. 

Nästa stora trend. Dubbla datastrukturer. Hydra.

Виталий: Vad jag förstår fångar man upp nya trender väldigt snabbt. Du var en av de första som arbetade i transaktionsminne, och en av de första som arbetade i icke-flyktigt minne. Vad tror du blir nästa stora trend? Eller kanske det är en hemlighet?

Michael: För att vara ärlig så vet jag inte. Förhoppningsvis kommer jag att kunna märka när något nytt dyker upp. Jag har inte haft turen att uppfinna något nytt fält på egen hand, men jag har haft lite tur och kunnat börja jobba ganska tidigt inom nya fält skapade av andra. Jag hoppas att jag kommer att kunna göra detta i framtiden.

Alex: Den sista frågan i den här intervjun kommer att handla om din prestation på Hydra och dina aktiviteter i skolan. Om jag förstår det rätt kommer rapporten på skolan att handla om blockeringsfria algoritmer, och på konferensen om dubbla datastrukturer. Kan du säga några ord om dessa rapporter?

Michael: Delvis har vi redan berört dessa ämnen med dig i den här intervjun. Det handlar om det arbete jag gjorde med min elev Bill Scherer. Han skrev en avhandling om den, och Doug Lee bidrog också till den, och den blev så småningom en del av de flertrådiga synkrona köerna i Java-biblioteket. Låt oss anta att datastrukturen läses och skrivs utan blockering, det vill säga att varje operation har ett begränsat antal instruktioner på den kritiska vägen. Om du försöker ta bort data från en tom container, eller försöker ta bort viss data som inte finns i denna container, informeras du omedelbart om att detta inte kan göras. Men detta beteende kanske inte är acceptabelt om tråden verkligen behöver dessa data. Sedan är det första som kommer att tänka på att skapa en loop som ständigt kommer att fråga om nödvändig data har dykt upp. Men sedan finns det störningar för alla andra. Dessutom, med det här tillvägagångssättet, kan du vänta 10 minuter, och sedan kommer någon annan tråd, och den kommer av misstag att få nödvändig information först. Dubbla datastrukturer har fortfarande inga lås, men de tillåter trådar att vänta ordentligt. Termen "dubbel" betyder att strukturen innehåller antingen data eller förfrågningar om data, låt oss kalla dem antidata. Så om du försöker hämta något från en tom behållare, kommer en begäran att läggas i behållaren istället. Nu kan tråden vänta på en förfrågan utan att störa någon annan. Dessutom tilldelar datastrukturen prioriteringar till förfrågningar så att när de tas emot skickar den dem till rätt person. Resultatet är en icke-låsande mekanism som fortfarande har en formell specifikation och bra prestanda i praktiken. 

Alex: Vilka förväntningar har du på den här datastrukturen? Kommer det att förbättra prestandan i alla vanliga fall, eller är det bättre lämpat för vissa situationer? 

Michael: Det är användbart om du för det första behöver en behållare utan låsning, och för det andra behöver du vänta i en situation där du behöver hämta data från behållaren som inte finns i den. Så vitt jag vet ger vårt ramverk optimalt beteende när dessa två villkor är uppfyllda. Därför rekommenderar jag att du använder den i dessa fall. Den största fördelen med låslösa datastrukturer är att de undviker prestandaproblem. Och att vänta är mycket viktigt i många algoritmer om data överförs från en tråd till en annan.

Виталий: Låt mig förtydliga: kommer du att prata om samma sak både i skolan och på konferensen?

Michael: I skolan jag kommer tala i allmänhet om flertrådade datastrukturer, med de grundläggande principerna som beskrivs i början av lektionen. Jag antar att publiken vet vad trådar är och är bekanta med lås. Utifrån denna grundläggande kunskap kommer jag att prata om låsfria datastrukturer. Jag ska ge en översikt över de viktigaste problemen inom detta område, och berör ämnen som minneshantering. Jag tror inte det blir något mer komplicerat än MS-kön.

Alex: Planerar du att undervisa om dubbla datastrukturer i slutet av din klass i skolan?

Michael: Jag kommer att nämna dem, men jag kommer inte lägga mycket tid på dem. Hydra-rapporten kommer att tillägnas dem. Det kommer att täcka projektet som så småningom kom in i Java, samt att arbeta med Joe Israelevich för att skapa en dubbel variant av LCRQ-kön och skapa en nästan universell design för dubbla datastrukturer.

Alex: Så föreläsningen i skolan kan rekommenderas för nybörjare, och föreläsningen om dubbla datastrukturer på Hydra - för personer som redan har lite erfarenhet?

Michael: Rätta mig om jag har fel, men publiken på Hydra kommer att vara ganska mångsidig, inklusive många Java-experter och i allmänhet människor som inte är specifikt involverade i flertrådsprogrammering. 

Виталий: Ja det är sant.

Alex: Vi hoppas det åtminstone.

Michael: I det här fallet kommer jag att ställas inför samma problem som vi började den här intervjun med: hur man gör en rapport både tillräckligt rik på tekniska detaljer och tillgänglig för alla lyssnare.

Виталий: Kommer du att ge en rapport på samma sätt som du håller föreläsningar? Det vill säga prata med publiken och anpassa sig efter situationen?

Michael: Jag är rädd att det inte kommer att fungera så, eftersom rapporten kommer att ha bilder. Slides är viktiga när lyssnare initialt talar olika språk. Många kommer att ha svårt att förstå mig på engelska, speciellt om jag pratar för snabbt. Jag valde dessa ämnen pga Pjotr ​​Kuznetsov bad mig prata om låsfria datastrukturer på SPTDC School; och sedan behövde jag en rapport för en Java-användargruppskonferens, och jag ville välja något som skulle vara av intresse specifikt för Java-programmerare. Det enklaste sättet var att prata om de där sakerna i Java-biblioteket som jag hade en hand på ett eller annat sätt. 

Alex: Vi antar att publiken på Hydra redan kan något om låsfri programmering och kanske har lite erfarenhet inom detta område. Men detta är bara ett antagande, situationen kommer att bli tydligare på själva konferensen. Hur som helst, tack för din tid. Jag är säker på att intervjun kommer att vara mycket intressant för våra läsare. Tack så mycket!

Виталий: Tack. 

Michael: Jag kommer att vara glad att träffa dig i St. Petersburg. 

Alex: Vi också, vi har en vacker stad. Har du någonsin varit här?

Michael: Nej, jag har aldrig varit i Ryssland alls. Men St. Petersburg har alltid funnits på listan över platser där jag inte har varit ännu, men dit jag verkligen vill åka, så jag blev väldigt glad över inbjudan. 

Alex: Vi kommer förresten att ha ett program med utflykter för talare. Tack så mycket för intervjun och ha en trevlig dag!

Du kan fortsätta ditt samtal med Michael på Hydra 2019-konferensen, som kommer att hållas den 11-12 juli 2019 i St. Petersburg. Han kommer med en rapport "Dubbla datastrukturer". Biljetter kan köpas på den officiella webbplatsen.

Källa: will.com

Lägg en kommentar