- ejer af to. Den første er til arbejde på (Brown University) og den anden, nyere, - (Virginia Tech University). Dijkstra-prisen gives for arbejde, hvis betydning og indflydelse har været synlig i mindst ti år, og Maurice er naturligvis en af de mest berømte specialister på området. Han arbejder i øjeblikket som professor ved Brown University og har adskillige præstationer, der er et afsnit langt. Han forsker i øjeblikket i blockchain i forbindelse med klassisk distribueret computing.
Tidligere var Maurice allerede kommet til Rusland for SPTCC () og holdt et fremragende møde med JUG.ru Java-udviklerfællesskabet i St. Petersborg ().
Denne habrapost er et godt interview med Maurice Herlihy. Den diskuterer følgende emner:
- Interaktion mellem akademi og industri;
- Foundation for Blockchain Research;
- Hvor kommer gennembrudsideer fra? Påvirkningen af popularitet;
- Ph.d. under vejledning af Barbara Liskov;
- Verden venter på multi-core;
- En ny verden bringer nye problemer. NVM, NUMA og arkitektur hacking;
- Compilere vs processorer, RISC vs CISC, delt hukommelse vs meddelelsesoverførsel;
- Kunsten at skrive skrøbelig flertrådskode;
- Hvordan man lærer eleverne at skrive kompleks flertrådskode;
- Ny udgave af bogen "The Art of Multiprocessor Programming";
- Hvordan transaktionel hukommelse blev opfundet;
- Hvorfor det er værd at udføre forskning inden for distribueret computing;
- Er udviklingen af algoritmer stoppet, og hvordan kommer man videre;
- Arbejder hos Brown University;
- Forskellen mellem forskning på et universitet og inden for en virksomhed;
- Hydra og SPTDC.
Interviewet er foretaget af:
Vitaly Aksenov — i øjeblikket post-doc ved IST Østrig og ansat ved 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.
Samspil mellem akademi og industri
Alexey: Maurice, du har arbejdet i et akademisk miljø i meget lang tid, og det første spørgsmål er samspillet mellem den akademiske og industrielle sfære. Kunne du fortælle om, hvordan interaktioner mellem dem har ændret sig for nylig? Hvad skete der for 20-30 år siden, og hvad sker der nu?
Maurice: Jeg har altid forsøgt at arbejde tæt sammen med kommercielle virksomheder, fordi de har interessante problemer. De er som regel ikke særlig interesserede i hverken at offentliggøre deres resultater eller i detaljerede forklaringer af deres problemer til verdenssamfundet. De er kun interesserede i at løse disse problemer. Jeg arbejdede for sådanne virksomheder i nogen tid. Jeg tilbragte fem år på fuld tid i et forskningslaboratorium hos Digital Equipment Corporation, som plejede at være et stort computerfirma. Jeg arbejdede en dag om ugen hos Sun, hos Microsoft, hos Oracle og arbejdede lidt på Facebook. Nu skal jeg på sabbatsorlov (en professor ved et amerikansk universitet har lov til at tage sådan en orlov i et år cirka en gang hvert sjette år) og arbejde i , dette er et kryptovalutafirma i Boston. At arbejde tæt sammen med virksomheder har altid været en fornøjelse, fordi det er sådan, man lærer om nye og interessante ting. Du kan endda være den første eller anden person, der udgiver en artikel om et valgt emne, i stedet for at arbejde på gradvist at forbedre løsninger på problemer, som alle andre allerede arbejder på.
Alexey: Kan du fortælle os mere detaljeret, hvordan dette sker?
Maurice: Selvfølgelig. Du ved, da jeg arbejdede hos Digital Equipment Corporation, mig og Elliot Moss, opfandt vi transaktionshukommelsen. Det var en meget frugtbar periode, hvor alle begyndte at interessere sig for informationsteknologi. Parallelisme, herunder, selvom multi-core systemer endnu ikke eksisterede. I løbet af Sun- og Oracle-dagene arbejdede jeg meget med parallelle datastrukturer. På Facebook arbejdede jeg på deres blockchain-projekt, som jeg ikke kan tale om, men jeg håber, at det snart bliver offentligt. Næste år vil jeg hos Algorand arbejde i en forskergruppe, der studerer smarte kontrakter.
Alexey: Blockchain er blevet et meget populært emne i de sidste par år. Vil dette hjælpe din forskning? Måske vil det gøre det nemmere at opnå tilskud eller give adgang til ressourcer fra virksomheder, der opererer i branchen?
Maurice: Jeg har allerede modtaget et lille tilskud fra Ethereum Foundation. Populariteten af blockchain er meget nyttig til at inspirere studerende til at arbejde inden for dette felt. De er meget interesserede i det og er spændte på at blive involveret, men nogle gange indser de ikke, at den forskning, der lyder spændende udefra, viser sig at involvere rigtig hårdt arbejde. Men jeg er virkelig begejstret for at bruge al denne mystik omkring blockchain til at hjælpe med at tiltrække studerende.
Men det er ikke alt. Jeg er i advisory board for flere blockchain-startups. Nogle af dem kan lykkes, nogle af dem måske ikke, men det er altid meget interessant at se deres ideer, studere dem og rådgive folk. Det mest spændende er, når man advarer folk mod at gøre noget. Mange ting virker umiddelbart som en god idé, men er de virkelig?
Foundation for Blockchain Research
Vitaly: Nogle mennesker tror, at fremtiden ligger hos blockchain og dens algoritmer. Og andre siger, at det bare er endnu en boble. Kan du dele din mening om denne sag?
Maurice: Meget af det, der foregår i blockchain-verdenen, er forkert, noget er bare et fupnummer, meget er overvurderet. Jeg mener dog, at der er et solidt videnskabeligt grundlag for disse undersøgelser. Det faktum, at blockchain-verdenen er fuld af ideologiske forskelle, viser niveauet af spænding og dedikation. På den anden side er dette ikke særlig gavnligt for videnskabelig forskning. Hvis du nu udgiver en artikel, der taler om manglerne ved en bestemt algoritme, er den resulterende reaktion ikke altid fuldt videnskabelig. Ofte smider folk deres følelser ud. Jeg tror, at denne form for spænding på dette område kan virke attraktiv for nogle, men i sidste ende er der virkelige videnskabelige og tekniske problemer, der skal løses. Der er meget datalogi her.
Vitaly: Så du forsøger at lægge grundlaget for blockchain-forskning, ikke?
Maurice: Jeg forsøger at lægge grundlaget for en solid, videnskabelig og matematisk forsvarlig disciplin. Og en del af problemet er, at nogle gange er man nødt til at modsige nogle af andre menneskers alt for hårde holdninger og ignorere dem. Nogle gange spørger folk, hvorfor jeg arbejder i et område, hvor kun terrorister og narkotikasmuglere er interesserede. En sådan reaktion er lige så meningsløs som adfærden hos følgere, der blindt gentager dine ord. Jeg tror, sandheden er et sted i midten. Blockchain vil have en dyb indvirkning på samfundet og den globale økonomi. Men det sker nok ikke takket være moderne teknologi. Moderne teknologier vil udvikle sig, og det, der i fremtiden vil blive kaldt blockchain, bliver meget vigtigt. Det ligner måske ikke engang moderne blockchains, det er et åbent spørgsmål.
Hvis folk opfinder nye teknologier, vil de fortsætte med at kalde det blockchain. Jeg mener, ligesom nutidens Fortran intet har at gøre med Fortran-sproget fra 1960'erne, men alle bliver ved med at kalde det Fortran. Samme for UNIX. Det, der kaldes "blockchain", vil stadig gøre sin revolution. Men jeg tvivler på, at denne nye blockchain vil være noget som det, alle nyder at bruge i dag.
Hvor kommer gennembrudsideer fra? Indvirkning af popularitet
Alexey: Har blockchains popularitet ført til nye resultater fra et videnskabeligt synspunkt? Mere interaktion, flere studerende, flere virksomheder i området. Er der allerede nogen resultater fra denne stigning i popularitet?
Maurice: Jeg blev interesseret i dette, da nogen gav mig en officiel flyer til et firma, der lige havde rejst ret mange penge. Den skrev om , som jeg er mere end bekendt med. Det, der stod i folderen, var klart teknisk forkert. De mennesker, der skrev alt dette, forstod ikke rigtig modellen bag problemet... og alligevel rejste dette firma en masse penge. Efterfølgende udskiftede firmaet stille og roligt denne folder med en meget mere korrekt version - og jeg vil ikke sige, hvad dette firma hed. De er stadig omkring og har det rigtig godt. Denne hændelse overbeviste mig om, at for det første er blockchain simpelthen en form for distribueret computing. For det andet var adgangstærsklen (i det mindste dengang for fire år siden) ret lav. De mennesker, der arbejdede på dette felt, var meget energiske og intelligente, men de læste ikke videnskabelige artikler. De forsøgte at genopfinde kendte ting og gjorde det forkert. I dag er dramaet blevet mindre.
Alexey: Det er meget interessant, for for et par år siden havde vi en anden tendens. Det er lidt ligesom frontend-udvikling, hvor browser-baserede front-end-udviklere genopfandt hele teknologier, der allerede var populære i back-end: bygge systemer, kontinuerlig integration, sådan noget.
Maurice: Jeg er enig. Men det er ikke overraskende, for virkelig gennembrudsideer kommer altid uden for det etablerede samfund. Etablerede forskere, især etablerede akademikere, vil næppe gøre noget virkelig banebrydende. Det er nemt at skrive et referat til den næste konference om, hvordan du en smule forbedrede resultaterne af dit tidligere arbejde. Gå til en konference, vær sammen med venner, tal om de samme ting. Og de mennesker, der brager ind med banebrydende ideer, kommer næsten altid udefra. De kender ikke reglerne, de kan ikke sproget, men ikke desto mindre... Hvis du er inden for et etableret fællesskab, råder jeg dig til at være opmærksom på nye ting, på noget der ikke passer ind i det samlede billede. På en måde kan man forsøge at kombinere eksterne, mere flydende udviklinger med metoder, som vi allerede forstår. Prøv som et første skridt at etablere et videnskabeligt grundlag og derefter ændre det, så det kan anvendes på nye gennembrudsideer. Jeg tror, at blockchain er fantastisk til at være en frisk, forstyrrende idé.
Alexey: Hvorfor tror du, det sker? Fordi folk "udenfor" ikke har nogle specifikke barrierer iboende i fællesskabet?
Maurice: Der foregår et mønster her. Hvis du læser impressionisternes historie i maleri og kunst generelt, så afviste berømte kunstnere på et tidspunkt impressionismen. De sagde, det var lidt barnligt. En generation senere blev denne tidligere afviste kunstform standarden. Hvad jeg ser inden for mit felt: opfinderne af blockchain var ikke interesserede i magt, i at øge publikationer og citationsindeks, de ville bare gøre noget godt. Så de satte sig ned og begyndte at gøre det. De manglede en vis mængde teknisk dybde, men det kan løses. Det er meget sværere at komme med nye kreative ideer end at rette og styrke utilstrækkeligt modne. Takket være disse opfindere har jeg nu noget at lave!
Alexey: Dette svarer til forskellen mellem startups og legacy-projekter. Vi arver mange begrænsninger af tænkning, barrierer, særlige krav og så videre.
Maurice: En god analogi er distribueret databehandling. Tænk på blockchain, som om det var en startup og distribueret computing som en stor, etableret virksomhed. Distribueret computing er i færd med at blive erhvervet og fusioneret med blockchain.
Ph.d. under vejledning af Barbara Liskov
Vitaly: Vi har stadig mange spørgsmål! Vi undersøgte din baggrund og stødte på en interessant kendsgerning om din doktorgrad. Ja, det er længe siden, men det ser ud til at være et vigtigt emne. Du modtog din ph.d. under vejledning af dig selv ! Barbara er meget kendt i programmeringssprogsamfundet og en meget kendt person generelt. Det er logisk, at din forskning var inden for programmeringssprog. Hvordan skiftede du til parallel computing? Hvorfor besluttede du dig for at skifte emne?
Maurice: På det tidspunkt kiggede Barbara og hendes gruppe bare på distribueret databehandling, hvilket var en meget ny idé. Der var også dem, der sagde, at distribueret databehandling var nonsens, og at computere, der kommunikerer med hinanden, var meningsløst. Et af de problemer, der behandles i distribueret databehandling, der adskiller det fra centraliseret databehandling, er fejltolerance. Efter megen research besluttede vi, at et distribueret programmeringssprog skulle have noget som atomtransaktioner, fordi du aldrig kan være sikker på, at et fjernopkald vil lykkes. Når du har transaktioner, opstår problemet med samtidighedsstyring. Derefter var der meget arbejde med at opnå meget parallelle transaktionsdatastrukturer. Så, da jeg var færdiguddannet, gik jeg til og begyndte at lede efter et emne at arbejde med. Det gik op for mig, at computing er flyttet fra individuelle computere til netværk af computere. Multiprocessorer ville være en naturlig fortsættelse af fremskridt - ordet "multi-core" eksisterede endnu ikke. Jeg tænkte: hvad svarer til atomtransaktioner for et multi-core system? Absolut ikke almindelige transaktioner, fordi de er for store og tunge. Og det var sådan jeg kom på ideen og det var sådan jeg kom frem til hele den ventefri synkronisering. Dette var et forsøg på at besvare spørgsmålet om, hvad der er analogen til atomtransaktioner for et multiprocessorsystem med delt hukommelse. Ved første øjekast kan dette værk se helt anderledes ud, men faktisk er det en fortsættelse af samme tema.
Verden venter på multi-core
Vitaly: Du nævnte, at der på det tidspunkt var meget få multi-core computere, ikke?
Maurice: De var der bare ikke. Der var flere såkaldte symmetriske multiprocessorer, som stort set var forbundet til samme bus. Dette fungerede ikke særlig godt, for hver gang et nyt firma skabte noget lignende, ville Intel frigive en enkelt processor, der var overlegen i forhold til multiprocessoren.
Alexey: Betyder det ikke, at det i de gamle tider var mere et teoretisk studie?
Maurice: Det var ikke et teoretisk studie, men snarere et spekulativt studie. Alt dette handlede ikke om at arbejde med mange teoremer; snarere fremsatte vi hypoteser om en arkitektur, der ikke eksisterede på det tidspunkt. Det er hvad forskning er til for! Ingen virksomhed ville have gjort noget lignende, det var alt sammen noget fra en fjern fremtid. Faktisk var dette tilfældet indtil 2004, hvor rigtige multi-core processorer dukkede op. Fordi processorer overophedes, kan du gøre processoren endnu mindre, men du kan ikke gøre den hurtigere. På grund af dette var der en overgang til multi-core arkitekturer. Og så betød det, at der pludselig var brug for alle de koncepter, som vi havde udviklet tidligere.
Alexey: Hvorfor tror du, at multi-core-processorer først dukkede op i XNUMX'erne? Så hvorfor er det så sent?
Maurice: Dette skyldes hardwarebegrænsninger. Intel, AMD og andre virksomheder er meget gode til at øge processorhastigheden. Da processorerne på et tidspunkt blev små nok til, at de ikke længere kunne øge clockhastigheden, fordi processorerne ville begynde at brænde ud. Du kan gøre dem mindre, men ikke hurtigere. Hvad er i deres magt - i stedet for en meget lille processor, kan de passe otte, seksten eller toogtredive processorer i samme volumen af kabinettet, hvor der tidligere kun kunne passe én. Nu har du multithreading og hurtig kommunikation mellem dem, fordi de deler caches. Men du kan ikke tvinge dem til at løbe hurtigere – der er en helt bestemt hastighedsgrænse. De bliver ved med at forbedre sig lidt efter lidt, men ikke så meget længere. Fysikkens love stod i vejen for forbedringer.
En ny verden bringer nye problemer. NUMA, NVM og arkitekturhacking
Alexey: Det lyder meget fornuftigt. Med nye multi-core processorer kom nye problemer. Forventede du og dine kolleger disse problemer? Måske har du studeret dem på forhånd? I teoretiske studier er det ofte ikke særlig let at forudsige sådanne ting. Når problemerne opstod, hvordan levede de så op til dine og dine kollegers forventninger? Eller var de helt nye, og du og dine kolleger skulle bruge meget tid på at løse problemer, som de dukkede op?
Vitaly: Jeg vil tilføje Alexeys spørgsmål: forudsagde du processorarkitekturen korrekt, mens du studerede teorien?
Maurice: Ikke 100%. Men jeg synes, mine kolleger og jeg har gjort et godt stykke arbejde med at forudsige multikerner med delt hukommelse. Jeg tror, vi korrekt forudsagde vanskelighederne ved at udvikle parallelle datastrukturer, der fungerer uden låse. Sådanne datastrukturer har været vigtige for mange applikationer, men ikke alle, men ofte er det, du virkelig har brug for, en ikke-låsende datastruktur. Da vi opfandt dem, argumenterede mange for, at det var noget sludder, at alt fungerede fint med låse. Vi forudsagde ganske godt, at der ville være færdige løsninger til mange programmeringsproblemer og datastrukturproblemer. Der var også mere komplekse problemer, som f.eks – ujævn adgang til hukommelsen. Faktisk blev de ikke engang overvejet, før multi-core processorer blev opfundet, fordi de var for specifikke. Forskermiljøet arbejdede med spørgsmål, der generelt var forudsigelige. Nogle hardwareproblemer forbundet med specifikke arkitekturer måtte vente i kulissen – faktisk udseendet af disse arkitekturer. For eksempel arbejdede ingen rigtig på GPU-specifikke datastrukturer, fordi GPU'er ikke eksisterede dengang. Selvom der er arbejdet meget på , var disse algoritmer klar til brug, så snart passende hardware blev tilgængelig. Det er dog umuligt at forudse alt.
Alexey: Hvis jeg forstår det rigtigt, er NUMA en slags kompromis mellem omkostninger, ydeevne og nogle andre ting. Nogle ideer til, hvorfor NUMA kom så sent ud?
Maurice: Jeg tror, at NUMA eksisterer på grund af problemer med den hardware, der bruges til at producere hukommelse: jo længere væk komponenterne er, jo langsommere er det at få adgang til dem. På den anden side er den anden værdi af denne abstraktion hukommelsesensartethed. Så en af kendetegnene ved parallel computing er, at alle abstraktioner er lidt brudt. Hvis adgangen var fuldstændig ensartet, ville al hukommelse være lige langt væk, men dette er økonomisk, og måske endda fysisk, umuligt. Derfor opstår denne konflikt. Hvis du skriver dit program, som om hukommelsen var ensartet, så vil det højst sandsynligt være korrekt. I den forstand, at det ikke vil give forkerte svar. Men hendes præstation vil heller ikke fange stjernerne fra himlen. Ligeledes hvis du skriver Uden at forstå cachehierarkiet vil selve blokeringen være korrekt, men du kan glemme alt om ydeevne. I en vis forstand skal du skrive programmer, der lever oven på en meget simpel abstraktion, men du skal overliste de mennesker, der gav dig den abstraktion: du skal vide, at der under abstraktionen er et eller andet hierarki af hukommelse, at der er en bus mellem dig og dette minde og så videre. Der er således en vis konflikt mellem individuelt brugbare abstraktioner, hvilket fører os til meget konkrete og pragmatiske problemer.
Vitaly: Hvad med fremtiden? Kan du forudsige, hvordan processorer vil udvikle sig næste gang? Der er en idé om, at et af svarene er transaktionshukommelse. Du har sikkert noget andet på lager.
Maurice: Der er et par store udfordringer forude. Den ene er, at sammenhængende hukommelse er en vidunderlig abstraktion, men den begynder at bryde sammen i særlige tilfælde. Så for eksempel er NUMA et levende eksempel på noget, hvor man kan blive ved med at lade som om der eksisterer ensartet hukommelse. Faktisk nej, produktivitet vil få dig til at græde. På et tidspunkt bliver arkitekter nødt til at opgive ideen om en enkelt hukommelsesarkitektur; du kan ikke lade som om for evigt. Der vil være behov for nye programmeringsmodeller, der er nemme nok at bruge og kraftfulde nok til at gøre den underliggende hardware effektiv. Dette er et meget svært kompromis, for hvis du viser programmører den arkitektur, der faktisk bruges i hardwaren, vil de gå amok. Det er for kompliceret og ikke bærbart. Hvis du præsenterer en grænseflade, der er for enkel, bliver ydeevnen dårlig. Der vil således skulle foretages mange meget vanskelige afvejninger for at give nyttige programmeringsmodeller, der kan anvendes til virkelig store multi-core processorer. Jeg er ikke sikker på, at andre end en specialist er i stand til at programmere på en 2000-core computer. Og medmindre du laver meget specialiseret eller videnskabelig databehandling eller kryptografi eller sådan noget - er det stadig slet ikke klart, hvordan man gør det korrekt.
Et andet lignende område er specialiserede arkitekturer. Grafikacceleratorer har eksisteret i lang tid, men de er blevet noget af et klassisk eksempel på, hvordan man kan tage en specialiseret type computer og køre den på en dedikeret chip. Dette tilføjer sine egne udfordringer: hvordan du kommunikerer med sådan en enhed, hvordan du programmerer den. Jeg har for nylig arbejdet på problemer i området . Du tager en lille processor og limer den fast på en stor del af hukommelsen, så hukommelsen kører med L1 cache-hastighed og derefter kommunikerer med en enhed som f.eks. – processoren har travlt med at indlæse nye opgaver i din hukommelseskerne. At designe datastrukturer og kommunikationsprotokoller til denne slags ting er et andet interessant eksempel. Så brugerdefinerede processorer og hardware vil fortsætte med at se forbedringer i et stykke tid.
Alexey: Hvad med ikke-flygtig hukommelse ()?
Maurice: Åh, det er endnu et godt eksempel! NVM vil i høj grad ændre den måde, vi ser på ting som datastrukturer. Ikke-flygtig hukommelse lover på en måde virkelig at fremskynde tingene. Men det vil ikke gøre livet nemmere, fordi de fleste processorer, caches og registre stadig er flygtige. Når du starter efter et nedbrud, vil din tilstand og din hukommelses tilstand ikke være helt den samme som før nedbruddet. Jeg er meget taknemmelig for de mennesker, der arbejder på NVM - der vil være masser for forskere at gøre i lang tid for at finde ud af korrekthedsbetingelser. Beregninger er korrekte, hvis de kan overleve et nedbrud, hvor indholdet af caches og registre går tabt, men hovedhukommelsen forbliver intakt.
Compilere vs processorer, RISC vs CISC, delt hukommelse vs meddelelsesoverførsel
Vladimir: Hvad synes du om "kompilatorer vs. processorer" dilemmaet fra et instruktionssæt synspunkt? Lad mig forklare for dem, der ikke ved det: Hvis vi går til skæv hukommelse eller noget lignende, kan vi bruge et meget simpelt sæt kommandoer og bede compileren om at generere kompleks kode, der kan drage fordel af de nye fordele. Eller vi kan gå den anden vej: implementere komplekse instruktioner og bede processoren om at omarrangere instruktionerne og udføre andre manipulationer med dem. Hvad synes du om det?
Maurice: Jeg har ikke rigtig et svar på det spørgsmål. Denne debat har stået på i fire årtier. Der var engang imellem et sæt kommandoer og borgerkrige blev udkæmpet af en række kommandoer. I et stykke tid vandt RISC-folkene, men så genopbyggede Intel deres motorer, så et reduceret sæt instruktioner blev brugt internt, og hele sættet blev eksporteret eksternt. Dette er formentlig et emne, hvor hver ny generation skal finde sine egne kompromiser og træffe sine egne beslutninger. Det er meget svært at forudsige, hvilken af disse ting der vil være bedre. Så enhver forudsigelse, jeg laver, vil være sand i en vis tid, og så falsk igen i et stykke tid, og så sand igen.
Alexey: Hvor almindeligt er det for industrien, at nogle ideer vinder i flere årtier og taber i de næste? Er der andre eksempler på sådanne periodiske ændringer?
Maurice: Med hensyn til distribueret databehandling er der folk, der tror på og folk der tror på . Til at begynde med, i distribueret databehandling, betyder parallel databehandling meddelelsesoverførsel. Så opdagede nogen, at det var meget nemmere at programmere med delt hukommelse. Den modsatte side sagde, at delt hukommelse er for kompliceret, fordi det kræver låse og lignende, så det er værd at flytte til sprog, hvor intet andet end meddelelsesoverførsel simpelthen eksisterer. Nogen kiggede på, hvad der kom ud af dette og sagde, "wow, denne messaging-implementering ligner meget delt hukommelse, fordi du opretter mange og mange af disse små moduler, de sender beskeder til hinanden, og de alle sammen "Lad os lave en bedre database med delt hukommelse!" Alt dette gentages igen og igen, og det er umuligt at sige, at en af parterne helt sikkert har ret. En af siderne vil altid dominere, for så snart en af dem næsten vinder, opfinder folk igen og igen måder at forbedre den anden på.
Kunsten at skrive skør flertrådskode
Alexey: Det er meget interessant. For eksempel, når vi skriver kode, uanset hvilket programmeringssprog, skal vi normalt skabe abstraktioner som celler, der kan læses og skrives. Men faktisk kan dette på et fysisk niveau se ud som at sende en besked over en hardwarebus mellem forskellige computere og andre enheder. Det viser sig, at der arbejdes på begge abstraktionsniveauer på én gang.
Maurice: Det er helt rigtigt, at delt hukommelse er bygget på, at beskeder sendes - busser, caches og så videre. Men det er svært at skrive programmer ved hjælp af meddelelsesoverførsel, så hardwaren lyver bevidst og foregiver, at du har en form for ensartet hukommelse. Dette vil gøre det lettere for dig at skrive enkle, korrekte programmer, før ydeevnen begynder at blive dårligere. Så vil du sige: det ser ud til, at det er tid til at blive venner med cachen. Og så begynder man at bekymre sig om cachens placering, og derfra går det. På en måde hacker du abstraktionen: du ved, at det ikke kun er flad, ensartet hukommelse, og du kommer til at bruge den viden til at skrive cache-venlige programmer. Dette er, hvad du bliver nødt til at gøre i virkelige problemer. Denne konflikt mellem den søde, enkle, pæne abstraktion, du har fået, og den forfærdeligt komplekse implementering af den underliggende hardware er, hvor alle vil indgå deres eget kompromis. Jeg har en bog om multiprocessorer og synkronisering, og på et tidspunkt skulle jeg skrive et kapitel om datastrukturer i java.util.samtidig. Hvis man ser på dem, f.eks Det er fantastiske kunstværker. (Redaktørens note: De, der er fortrolige med Java-sproget, bør i det mindste tage et kig på implementeringen ConcurrentSkipListMap, du kan se på links på и ). Men fra mit synspunkt ville det være uansvarligt at vise dem til eleverne, for sådan en datastruktur er ligesom en fyr i et cirkus, der løber på stram reb over en bjørnegrav. Hvis du ændrer blot en lille detalje, vil hele strukturen kollapse. Denne kode er meget hurtig og elegant, bare fordi den er skrevet perfekt, men den mindste ændring vil føre til fuldstændig fiasko. Hvis jeg giver denne kode som eksempel til eleverne, vil de straks sige: Det kan jeg også! Og så vil et fly styrte ned, eller en atomreaktor vil eksplodere, og jeg vil være skyldig i at give dem for meget information på det forkerte tidspunkt.
Alexey: Da jeg var lidt yngre, forsøgte jeg mange gange at studere Doug Lees kildekode, f.eks. java.util.samtidig, fordi det er open source, er det meget nemt at finde og prøve at forstå, hvad der foregår der. Det viste sig ikke særlig godt: ofte er det fuldstændig uklart, hvorfor Doug besluttede at gøre noget på denne måde, når alle andre gør det anderledes. Hvordan forklarer du disse ting til dine elever? Er der en bestemt korrekt måde at beskrive specifikke detaljer i en hardcore-algoritme, for eksempel? Hvordan gør du dette?
Maurice: Tegnelærere har en kliché, som de husker først: Hvis du vil tegne som Picasso, skal du først lære at tegne simple realistiske billeder, og først når du kender reglerne, kan du begynde at bryde dem. Hvis du starter med at bryde reglerne med det samme, ender du i et rod. Først lærer jeg eleverne, hvordan man skriver enkel, korrekt kode uden at bekymre sig om ydeevne. Det, jeg siger, er, at der lurer komplekse timing-problemer her, så du skal ikke bekymre dig om caches, ikke bekymre dig om hukommelsesmodeller, bare sørg for at alt fungerer korrekt. Dette er allerede svært nok: moderne programmering er ikke let i sig selv, især for nye studerende. Og når de har en intuition om, hvordan man skriver de rigtige programmer, siger jeg: se på disse to spinlock-implementeringer: den ene er meget langsom, og den anden er heller ikke særlig, men bedre. Men matematisk er de to algoritmer de samme. Faktisk bruger en af dem cache-lokalitet. En af dem kører på lokalt cachelagrede data, og den anden udfører gentagne gange operationer på tværs af bussen. Du kan ikke skrive effektiv kode, hvis du ikke forstår, hvad det er, og ikke ved, hvordan du skal bryde abstraktionen og se på den underliggende struktur. Men du vil ikke være i stand til at begynde at gøre dette med det samme. Der er mennesker, der begynder at gøre dette med det samme og tror på deres eget geni, som regel ender det galt, fordi de ikke forstår principperne. Ingen tegner som Picasso eller skriver programmer som Doug Lee frisk ude af college i sin første uge. Det tager år at nå dette vidensniveau.
Alexey: Det viser sig, at du deler problemet op i to dele: den første er korrekthed, den anden er ydeevne?
Maurice: Præcis. Og præcis i den rækkefølge. En del af problemet er, at nye studerende ikke forstår, at korrekthed er svær at opnå. Ved første øjekast siger de: det er åbenbart korrekt, det eneste der mangler er at fremskynde det. Så nogle gange fortæller jeg dem om en oprindeligt forkert algoritme, som om den var korrekt.
Hvordan man lærer eleverne at skrive kompleks flertrådskode
Alexey: Bare for at se, om de kan mærke fangsten?
Maurice: Jeg advarer altid på forhånd om, at jeg nogle gange vil foreslå forkerte algoritmer. Man skal ikke snyde folk. Jeg foreslår, at de tager oplysningerne med et gran salt. Hvis jeg fortæller noget og siger: "se, det er åbenlyst korrekt" - dette er et signal om, at de et eller andet sted forsøger at bedrage dig, og du bør begynde at stille spørgsmål. Dernæst forsøger jeg at opmuntre eleverne til at blive ved med at stille spørgsmål, og så foreslår jeg: "Hvad vil der ske, hvis vi lader tingene være som de er?" Og de ser straks fejlen. Men at overbevise eleverne om, at de skal bekymre sig om korrekthed, er meget sværere, end det ser ud ved første øjekast. Mange af disse elever kommer med programmeringserfaring i gymnasiet, nogle har fået job og har lavet programmering der, og de er alle fyldt med selvtillid. Dette er noget som hæren: du skal først ændre deres humør for at overbevise dem om tålmodigt at nærme sig at løse problemer, der opstår. Eller måske er det ligesom buddhistiske munke: Først lærer de at ræsonnere om korrekthed, og når de først forstår måderne at ræsonnere om korrekthed på, får de lov til at bevæge sig til næste niveau og begynde at bekymre sig om præstationer.
Alexey: Det vil sige, nogle gange viser du eleverne eksempler, der ikke fungerer, takket være dem får du feedback, der viser, om de forstår essensen af problemet, om de kan finde den forkerte kode og det forkerte resultat. Så gør studerende dig normalt glad eller ked af det?
Maurice: Studerende finder næsten altid fejlen til sidst. Hvis de søger for langsomt, stiller jeg ledende spørgsmål, og her er det vigtigt at forstå, at hvis du aldrig bedrager dem, vil de åndssvagt begynde at opfatte dine ord som den ultimative sandhed. Så vil de kede sig og begynde at falde i søvn, mens de læser Facebook på deres bærbare computer i timen. Men når man på forhånd fortæller dem, at de bliver snydt, og de vil se dumme ud, hvis de ikke fornemmer et trick, bliver de meget mere årvågne. Det er godt på forskellige måder. Jeg vil gerne have, at eleverne ikke kun sætter spørgsmålstegn ved deres forståelse af problemstillingen, men også sætter spørgsmålstegn ved lærerens autoritet. Tanken er, at en elev til enhver tid kan række hånden op og sige: Jeg synes, det du lige har sagt er forkert. Det er et vigtigt læringsredskab. Jeg ønsker ikke, at nogen af eleverne skal sidde og stille og roligt tænke for sig selv: alt det her virker fuldstændig nonsens, men at række hånden op er for skræmmende, og alligevel er han professor, så alt, hvad han siger, er sandheden. Hvis de derfor på forhånd advares om, at ikke alt, der fortælles, nødvendigvis er sandt, har de et incitament til at være mere opmærksom på materialet. Jeg gør det klart, at det er okay at række hånden op og stille spørgsmål. Dit spørgsmål lyder måske dumt eller naivt, men det er ofte sådan, de bedste spørgsmål opstår.
Alexey: Meget interessant. Normalt har folk en form for psykologisk barriere, der ikke tillader dem at stille et spørgsmål til en professor. Især hvis der er mange mennesker i lokalet, og alle er bange for, at det vil tage al disse menneskers tid at diskutere dit dumme spørgsmål. Er der nogle tricks til at håndtere dette?
Maurice: Jeg stopper ofte op og stiller klassiske spørgsmål. Om et udsagn ville være korrekt, eller hvordan de ville løse det problem, der diskuteres. Dette er en nøglehandling, især i begyndelsen af en lektion, når folk er flov over at sige selv den mindste ting. Du stiller eleverne et spørgsmål og siger ikke mere. Der er stille, alle bliver lidt anspændte, spændingen vokser, så pludselig er der nogen, der ikke kan holde det ud, bryder sammen og siger svaret. Sådan vender du situationen: At fortsætte med at tie bliver sværere og ubelejligt end at svare! Dette er et standard pædagogisk trick. Enhver lærer i verden burde vide, hvordan man gør dette.
Alexey: Nu har vi en fremragende titel til dette interview: "det er nemmere at svare end at tie."
Vitaly: Lad mig spørge igen. Du arbejder på topologiske beviser. Hvordan blev du overhovedet involveret i dette, for distribueret databehandling og topologi er helt forskellige ting!
Maurice: Der er en skjult forbindelse der. Da jeg var elev og læste matematik, læste jeg ren matematik. Jeg havde ingen reel interesse for computere, før mine studier sluttede, og jeg stod over for det presserende behov for at søge job. Som studerende studerede jeg algebraisk topologi. Mange år senere, mens du arbejder på et problem kaldet , brugte jeg grafer til at modellere problemet, og som det så ud på det tidspunkt, havde jeg fundet en løsning. Man skulle bare sætte sig ned og gå rundt om tællingen. Prøv at finde et passende svar på denne graf. Men min algoritme virkede ikke: det viste sig, at han ville løbe i cirkler for evigt. Desværre kunne alt dette ikke forklares i grafteoriens formelle sprog - det som alle dataloger kender. Og så huskede jeg, at vi for mange år siden, tilbage i topologitimerne, brugte konceptet , som er en generalisering af grafer til højere dimensioner. Så spurgte jeg mig selv: hvad ville der ske, hvis vi omformulerede problemet i form af simple komplekser? Dette blev nøgleøjeblikket. Ved at bruge en mere kraftfuld formalisme bliver problemet pludselig meget enklere. Folk kæmpede imod det i lang tid ved at bruge grafer, men de kunne ikke gøre noget. Og selv nu kan de ikke - det rigtige svar viste sig ikke at være en algoritme, men et bevis på umuligheden af at løse problemet. Det vil sige, at sådan en algoritme simpelthen ikke eksisterer. Men baseret enten på simple komplekser eller på ting, som folk lod, som om de ikke betragtede simple komplekser. Bare fordi du kalder noget et nyt navn, mister det ikke sin essens.
Vitaly: Det viser sig, at du bare var heldig?
Maurice: Udover held er det også parathed. Det betyder, at du ikke skal glemme de "ubrugelige" ting, du har lært tidligere. Jo flere ubrugelige ting du lærer, jo flere ideer kan du udvinde, når du står over for et nyt problem. Denne form for intuitiv mønstermatchning er vigtig, fordi... Lad os gøre dette, dette er en kæde: Først opdagede jeg, at graferne slet ikke virkede eller slet ikke virkede, det mindede mig om noget fra begivenhederne i otte år siden og mine studieår, da vi studerede alle disse simple komplekser. Dette tillod mig igen at finde min gamle topologi lærebog og indlæse den tilbage i mit hoved. Men hvis det ikke var for den gamle viden, ville jeg aldrig have gjort fremskridt med at løse det oprindelige problem.
Ny udgave af bogen "The Art of Multiprocessor Programming"
Alexey: Du sagde et par ord om din bog. Det er nok ikke den værste hemmelighed, at du skrev verdens mest berømte bog om multithreading, . Den er allerede omkring 11 år gammel, og siden er den kun udkommet . Kommer der en anden udgave?
Maurice: Det er godt, du spurgte! Det vil være meget snart, om tre måneder eller deromkring. Der er to forfattere mere, vi tilføjede meget mere materiale, forbedrede afsnittet om gaffel/sammenføjningsparallelisme, skrev et afsnit om MapReduce, tilføjede en masse nye ting og smed unødvendige ting ud - noget der var meget interessant i skrivende stund den første udgave, men er der ikke længere i dag. Resultatet blev en meget seriøst revideret bog.
Alexey: Alt er allerede blevet gjort, det eneste der er tilbage er at frigive det?
Maurice: Et par kapitler mangler stadig noget arbejde. Vores udgiver (som jeg tror allerede hader os) forsøger stadig at få budskabet ud om, at vi skal arbejde hurtigere. Vi er langt bagud i tidsplanen. Teoretisk set kunne vi have lavet denne bog et par år tidligere.
Alexey: Er der nogen chance for at få en ny version af bogen inden jul?
Maurice: Dette er vores mål! Men jeg har forudset sejr så mange gange, at ingen tror på mig længere. Du skal nok heller ikke stole for meget på mig i denne sag.
Alexey: Under alle omstændigheder er dette fantastiske nyheder. Jeg kunne virkelig godt lide den første udgave af bogen. Man kan sige, at jeg er fan.
Maurice: Jeg håber, at den nye udgave vil være din inderlige entusiasme værdig, tak!
Hvordan transaktionshukommelse blev opfundet
Vitaly: Det næste spørgsmål handler om transaktionshukommelse. Så vidt jeg forstår, er du en pioner på dette område, du opfandt det på et tidspunkt, hvor ingen tænkte på sådanne ting. Hvorfor besluttede du at flytte ind på dette felt? Hvorfor syntes transaktioner vigtige for dig? Troede du, at de en dag ville blive implementeret i hardware?
Maurice: Jeg har kendt til transaktioner siden min studietid.
Vitaly: Ja, men det er forskellige transaktioner!
Maurice: Jeg arbejdede med Elliott Moss om ikke-blokerende affaldsindsamling. Vores problem var, at vi ønskede at atomært ændre nogle få ord i hukommelsen, og så ville algoritmerne blive meget enkle, og i det mindste nogle af dem ville blive mere effektive. Ved brug af for leveret af den parallelle arkitektur, er det muligt at gøre noget, men det er meget ineffektivt og grimt, fordi du ville være nødt til at håndtere lag af indirekte. Jeg vil ændre hukommelsesord, og jeg skal skifte, fordi jeg kun kan ændre én pointer, så de skal pege på en form for mappelignende struktur. Vi talte om, hvor fantastisk det ville være, hvis vi kunne ændre hardwaren, så den kunne lave samtidig optagelse. Elliott ser ud til at have bemærket dette: Hvis du ser på cache-kohærensprotokoller, leverer de allerede det meste af den nødvendige funktionalitet. I en optimistisk transaktion vil cachekohærensprotokollen bemærke, at der er en tidskonflikt, og cachen bliver . Hvad sker der, hvis du spekulativt kører en transaktion på din cache og bruger kohærensprotokollens mekanismer til at opdage konflikter? Spekulativ hardwarearkitektur var let at designe. Så det skrev vi om transaktionshukommelse. Samtidig var firmaet, jeg arbejdede for, Digital Equipment Corporation, ved at skabe en ny 64-bit processor kaldet Alpha. Så jeg gik hen og holdt en præsentation for Alpha-udviklingsgruppen om vores fantastiske transaktionshukommelse, og de spurgte: Hvor meget ekstra indtægt ville vores virksomhed få, hvis vi tilføjede alt dette direkte til processoren? Og jeg havde absolut intet svar på dette, for jeg er teknolog, jeg er ikke marketingspecialist. Jeg havde virkelig ikke noget at svare på. De var ikke særlig imponerede over, at jeg ikke vidste noget.
Vitaly: Milliarder! Sig bare milliarder!
Maurice: Ja, det skulle jeg have sagt. Nu, i en tid med startups og alt muligt, ved jeg, hvordan man skriver en forretningsplan. At du kan lyve lidt om størrelsen af dit potentielle overskud. Men dengang virkede det naivt, så jeg sagde bare: "Jeg ved det ikke." Hvis du ser på historien om publikationen om transaktionshukommelse, vil du bemærke, at der efter et år var flere referencer til den, og så i omkring ti år var der slet ingen, der citerede dette papir. Citaterne dukkede op omkring 2004, hvor ægte multikerner dukkede op. Da folk opdagede, at det at skrive parallel kode kunne tjene penge, begyndte ny forskning. Ravi Rajwar , som på en eller anden måde introducerede begrebet transaktionshukommelse til mainstream. (Redaktørens note: Der er en anden version af denne artikel, udgivet i 2010 og frit tilgængelig ). Pludselig indså folk præcis, hvordan alt dette kunne bruges, hvordan traditionelle algoritmer med låse kunne accelereres. Et godt eksempel på noget, der før i tiden bare virkede som et interessant akademisk problem. Og ja, hvis du på det tidspunkt havde spurgt mig, om jeg troede, at alt det her ville være vigtigt i fremtiden, ville jeg have sagt: selvfølgelig, men hvornår præcist står ikke klart. Måske om 50 år? I praksis viste det sig kun at være et årti. Det er meget rart, når man gør noget, og efter bare ti år lægger folk mærke til det.
Hvorfor det er værd at udføre forskning inden for distribueret computing
Vitaly: Hvis vi taler om ny forskning, hvad vil du så råde læsere til - distribueret computere eller multi-core og hvorfor?
Maurice: I disse dage er det nemt at få en multi-core processor, men det er sværere at opsætte et ægte distribueret system. Jeg begyndte at arbejde på dem, fordi jeg ville lave noget andet end min ph.d.-afhandling. Dette er det råd, jeg altid giver til nye studerende: skriv ikke en fortsættelse af din afhandling - prøv at gå i en ny retning. Og også, multithreading er nemt. Jeg kan eksperimentere med min egen gaffel, der kører på min bærbare computer uden at komme ud af sengen. Men hvis jeg pludselig ville lave et rigtigt distribueret system, skulle jeg lave en masse arbejde, tiltrække studerende og så videre. Jeg er en doven person og vil hellere arbejde på multi-core. Det er også nemmere at eksperimentere på multi-core systemer end at lave eksperimenter på distribuerede systemer, for selv i et dumt distribueret system er der for mange faktorer, der skal kontrolleres.
Vitaly: Hvad laver du nu og forsker i blockchain? Hvilke artikler skal du være opmærksom på først?
Maurice: Dukkede for nylig op , som jeg skrev sammen med min elev, Vikram Saraf, specielt til en snak kl i Paris for tre uger siden. Dette er en artikel om praktiske distribuerede systemer, hvor vi foreslår at gøre Ethereum multi-threaded. I øjeblikket udføres smarte kontrakter (kode, der kører på blockchain) sekventielt. Vi skrev en artikel tidligere, der talte om en måde at bruge spekulative transaktioner til at fremskynde processen. Vi tog en masse ideer fra softwaretransaktionshukommelsen og sagde, at hvis du gør disse ideer til en del af den virtuelle Etherium-maskine, så vil alt fungere hurtigere. Men hertil er det nødvendigt, at der ikke er datakonflikter i kontrakterne. Og så antog vi, at der i virkeligheden ikke er sådanne konflikter. Men vi kunne ikke finde ud af det. Så gik det op for os, at vi havde næsten et årti med ægte kontrakthistorie på vores hænder, så vi dumpede Ethereum-blockchainen og spurgte os selv: hvad ville der ske, hvis disse historiske optegnelser blev udført parallelt? Vi fandt en markant stigning i hastigheden. I de tidlige dage af Ethereum steg hastigheden meget, men i dag er alt noget mere kompliceret, fordi der er færre kontrakter, og sandsynligheden for konflikter om data, der kræver serialisering, er blevet højere. Men alt dette er eksperimentelt arbejde med rigtige historiske data. Det fine ved blockchain er, at den husker alt for altid, så vi kan gå tilbage i tiden og studere, hvad der ville være sket, hvis vi havde brugt forskellige algoritmer til at køre koden. Hvordan ville folk tidligere have kunnet lide vores nye idé? Sådan forskning er meget nemmere og sjovere at lave, fordi der er en ting, der overvåger alt og registrerer alt. Dette ligner allerede noget mere sociologi end udviklingen af algoritmer.
Er udviklingen af algoritmer stoppet, og hvordan kommer man videre?
Vitaly: Tid til det sidste teoretiske spørgsmål! Føles det som om fremskridt inden for konkurrencedygtige datastrukturer falder hvert år? Tror du, vi har nået et plateau i vores forståelse af datastrukturer, eller vil der være nogle store forbedringer? Måske er der nogle smarte ideer, som fuldstændig kan ændre alt?
Maurice: Vi har muligvis nået et plateau i datastrukturer for traditionelle arkitekturer. Men datastrukturer til nye arkitekturer er stadig et meget lovende område. Hvis du vil oprette datastrukturer til f.eks. hardwareacceleratorer, så er datastrukturerne for en GPU meget forskellige fra datastrukturerne for en CPU. Når du udvikler datastrukturer til blockchains, skal du hash stykker af data og derefter sætte dem ind i noget som f.eks. , for at forhindre forfalskning. Der har været en bølge af aktivitet på dette område på det seneste, hvor mange har udført et meget godt arbejde. Men jeg tror, at det, der vil ske, er, at nye arkitekturer og nye applikationer vil føre til nye datastrukturer. Ældre applikationer og traditionel arkitektur - der er måske ikke meget plads til udforskning længere. Men hvis du kommer uden for den slagne vej og kigger ud over kanterne, vil du se skøre ting, som mainstream ikke tager seriøst – det er der, alt det spændende virkelig sker.
Vitaly: Derfor, for at være en meget berømt forsker, var jeg nødt til at opfinde min egen arkitektur :)
Maurice: Du kan "stjæle" en andens nye arkitektur - det virker meget nemmere!
Arbejder på Brown University
Vitaly: Kan du fortælle os mere om hvor arbejder du? Ikke meget er kendt om ham i forbindelse med informationsteknologi. Mindre end om MIT, for eksempel.
Maurice: Brown University er et af de ældste universiteter i USA. Jeg tror kun Harvard er lidt ældre. Brun er en del af den såkaldte , som er en samling af otte ældste universiteter. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Det er lidt et gammelt, lille og lidt aristokratisk universitet. Hovedfokus er på liberal kunstuddannelse. Det forsøger ikke at være som MIT, MIT er meget specialiseret og teknisk. Brown er et godt sted at studere russisk litteratur eller klassisk græsk, og selvfølgelig datalogi. Det fokuserer på omfattende uddannelse. De fleste af vores elever går på Facebook, Apple, Google – så jeg tror, at vores elever ikke har problemer med at finde et job i branchen. Jeg gik på arbejde hos Brown, fordi jeg tidligere havde arbejdet hos Digital Equipment Corporation i Boston. Dette var et firma, der opfandt mange interessante ting, men benægtede vigtigheden af personlige computere. Et selskab med en vanskelig skæbne, hvis grundlæggere engang var unge revolutionære, de lærte intet og glemte intet, og så vendte de sig fra revolutionære til reaktionære inden for omkring en halv snes år. De kunne godt lide at spøge med, at personlige computere hørte til i garagen - en forladt garage, selvfølgelig. Det er helt åbenlyst, at de blev ødelagt af mere fleksible virksomheder. Da det stod klart, at virksomheden var i problemer, ringede jeg til en af mine venner i Brown, som ligger cirka en time uden for Boston. Jeg ønskede ikke at forlade Boston på det tidspunkt, fordi der ikke var mange åbninger på andre universiteter. Det var en tid, hvor der ikke var så mange job inden for datalogi, som der er nu. Og Brown havde en åbning, jeg behøvede ikke at flytte mit hjem, jeg behøvede ikke at flytte min familie, og jeg elsker virkelig at bo i Boston! Det var sådan jeg besluttede at tage til Brown. Jeg kan lide det. Eleverne er vidunderlige, så jeg har aldrig prøvet at gå et andet sted hen. I løbet af mit sabbatår arbejdede jeg hos Microsoft i et år, tog til Technion i Haifa i et år, og nu skal jeg hos Algorand. Jeg har mange kolleger overalt, og derfor er den fysiske placering af vores klasseværelser ikke så vigtig. Men det vigtigste er eleverne, de er de bedste her. Jeg har aldrig prøvet at gå et andet sted hen, fordi jeg er ret glad her.
På trods af Browns berømmelse i USA er han overraskende ukendt i udlandet. Som du kan se, gør jeg nu alt for at rette op på denne situation.
Forskellen mellem forskning på et universitet og inden for en virksomhed
Vitaly: Okay, det næste spørgsmål handler om digitalt udstyr. Du var der som forsker. Hvad er forskellen mellem at arbejde i R&D-afdelingen i en stor virksomhed og at arbejde på et universitet? Hvad er fordele og ulemper?
Maurice: I tyve år arbejdede jeg hos Microsoft, arbejdede tæt sammen med medarbejdere i Sun Microsystems, Oracle, Facebook og nu Algorand. På baggrund af alt dette vil jeg sige, at det er muligt at drive førsteklasses forskning både i virksomheder og på universiteter. Den vigtige forskel er, at man i en virksomhed arbejder sammen med kolleger. Hvis jeg pludselig har en idé til et projekt, som endnu ikke eksisterer, skal jeg overbevise mine kammerater om, at det er en god idé. Hvis jeg er på Brown, så kan jeg fortælle mine elever: lad os arbejde på antigravitation! De vil enten tage afsted til en anden eller påtage sig et projekt. Ja, jeg skal finde finansiering, jeg skal skrive en ansøgning om tilskud og så videre. Under alle omstændigheder vil der altid være mange elever, og man vil kunne træffe beslutninger ensidigt. Men på universitetet vil du højst sandsynligt ikke arbejde med folk på dit niveau. I en verden af industriel forskning skal du først overbevise alle om, at dit projekt er værd at tage fat på. Jeg kan ikke bestille noget til nogen. Og begge disse måder at arbejde på er værdifulde, for hvis du arbejder på noget virkelig skørt, og dine kolleger er svære at overbevise, er det nemmere at overbevise kandidatstuderende – især hvis du betaler dem. Hvis du arbejder med noget, der kræver en masse erfaring og dyb ekspertise, så har du brug for kolleger, der kan sige "nej, det er bare sådan, at jeg forstår på dette område, og din idé er dårlig, den vil ikke fungere." Dette er meget nyttigt i forhold til at spilde tid. Også, hvis du i industrielle laboratorier bruger meget tid på at skrive rapporter, så bruger du denne tid på et universitet på at finde penge. Hvis jeg vil have eleverne til at kunne gå et sted hen, må jeg finde pengene til det et andet sted. Og jo vigtigere din stilling på universitetet er, jo mere tid skal du bruge på at skaffe penge. Så nu ved du, hvad jeg arbejder for - en professionel tigger! Som en af de munke, der går rundt med en offerplade. Generelt supplerer disse to aktiviteter hinanden. Derfor prøver jeg at leve og holde fødderne på jorden i begge verdener.
Vitaly: Det ser ud til, at det er sværere at overbevise en virksomhed end at overbevise andre videnskabsmænd.
Maurice: Sværere og meget mere. Desuden er det anderledes på forskellige områder: Nogle udfører fuldskalaforskning, mens andre fokuserer på deres emne. Hvis jeg gik til Microsoft eller Facebook og sagde: lad os lave anti-tyngdekraft, ville de næppe sætte pris på det. Men hvis jeg sagde præcis det samme til mine kandidatstuderende, ville de højst sandsynligt komme i gang med det samme, selvom jeg nu ville få problemer - jeg skal trods alt finde penge til det her. Men så længe du ønsker at lave noget, der stemmer overens med virksomhedens mål, kan den virksomhed være et rigtig godt sted at lave research.
Hydra og SPTDC
Vitaly: Mine spørgsmål er ved at være slut, så lad os tale lidt om den kommende tur til Rusland.
Maurice: Ja, jeg glæder mig til at vende tilbage til St. Petersborg.
Alexey: Jeg er beæret over at have dig hos os i år. Det er din anden gang i St. Petersborg, ikke?
Maurice: Allerede den tredje!
Alexey: Jeg forstår det, men – helt klart den anden. Sidste gang blev skolen kaldt , har vi nu ændret ét bogstav (C til D, samtidig til distribueret) for at understrege, at der er flere områder, der specifikt er relateret til distribueret databehandling i år. Kan du sige et par ord om dine rapporter på Skolen og ?
Maurice: På skolen vil jeg tale om det grundlæggende i blockchain, og hvad du kan gøre med det. Jeg vil gerne vise, at blockchains minder meget om den flertrådede programmering, vi kender, men med deres egne nuancer, og disse forskelle er vigtige at forstå. Hvis du laver en fejl i en almindelig webapplikation, er det bare irriterende. Hvis du skriver buggy-kode i en finansiel applikation, vil nogen helt sikkert stjæle alle dine penge. Det er helt forskellige niveauer af ansvar og konsekvenser. Jeg vil tale lidt om proof-of-work, om smarte kontrakter, om transaktioner mellem forskellige blockchains.
Der vil være andre talere, der arbejder ved siden af mig, som også har noget at sige om blockchain, og vi blev enige om at koordinere med hinanden, så vores historier passer godt sammen. Men til ingeniørrapporten vil jeg fortælle et bredt publikum en forståelig forklaring på, hvorfor man ikke skal tro på alt, hvad man hører om blockchains, hvorfor blockchains er et fantastisk felt, hvordan det passer ind med andre kendte ideer, og hvorfor vi modigt bør se til fremtiden.
Alexey: Derudover vil jeg sige, at dette ikke vil finde sted i formatet af et møde eller en brugergruppe, som det var for to år siden. Vi besluttede at holde en lille konference i nærheden af skolen. Årsagen er, at efter at have kommunikeret med Peter Kuznetsov, indså vi, at skolen er begrænset til kun hundrede, måske 120 personer. Samtidig er der rigtig mange ingeniører, der gerne vil kommunikere med dig, deltage i oplæg og generelt interesserer sig for emnet. Derfor har vi lavet en ny konference . Forresten, nogen ideer til hvorfor Hydra?
Maurice: Fordi der vil være syv talere? Og deres hoveder kan skæres af, og nye højttalere vil vokse i deres sted?
Alexey: God idé til at dyrke nye højttalere. Men faktisk er der en historie her. Husk legenden om Odysseus, hvor han skulle sejle imellem ? Hydra er noget som Charybdis. Historien er, at jeg engang talte til en konference og talte om multithreading. Der var kun to spor på denne konference. I begyndelsen af rapporten fortalte jeg tilhørerne i salen, at de nu har et valg mellem Scylla og Charybdis. Mit åndedyr er Charybdis, fordi Charybdis har mange hoveder, og mit tema er multi-threading. Sådan vises navnene på konferencer.
Vi er i hvert fald løbet tør for spørgsmål og tid. Så tak, venner, for et godt interview, og vi ses til SPTDC Skole og Hydra 2019!
Du kan fortsætte din samtale med Maurice 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