Maurice Herlihy - eier av to Dijkstra-priser. Den første er for arbeid med "Ventefri synkronisering" (Brown University) og den andre, nyere, - "Transaksjonsminne: Arkitektonisk støtte for låsefrie datastrukturer" (Virginia Tech University). Dijkstra-prisen gis for arbeid hvis betydning og innflytelse har vært synlig i minst ti år og Maurice er åpenbart en av de mest kjente spesialistene på feltet. Han jobber for tiden som professor ved Brown University og har en rekke prestasjoner som er et avsnitt langt. Han forsker for tiden på blokkjede i sammenheng med klassisk distribuert databehandling.

Tidligere hadde Maurice allerede kommet til Russland for SPTCC (videoopptak) og gjorde et utmerket møte med JUG.ru Java-utviklerfellesskapet i St. Petersburg (videoopptak).

Denne habraposten er et flott intervju med Maurice Herlihy. Den diskuterer følgende emner:

• Samspill mellom akademia og industri;
• Foundation for Blockchain Research;
• Hvor kommer banebrytende ideer fra? Påvirkning av popularitet;
• PhD under veiledning av Barbara Liskov;
• Verden venter på multi-core;
• En ny verden gir nye problemer. NVM, NUMA og arkitekturhacking;
• Kompilatorer vs prosessorer, RISC vs CISC, delt minne vs meldingsoverføring;
• Kunsten å skrive skjør flertrådskode;
• Hvordan lære elevene å skrive kompleks flertrådskode;
• Ny utgave av boken «The Art of Multiprocessor Programming»;
• Hvordan transaksjonsminne ble oppfunnet;   
• Hvorfor det er verdt å forske innen distribuert databehandling;
• Har utviklingen av algoritmer stoppet, og hvordan gå videre;
• Jobber ved Brown University;
• Forskjellen mellom forskning ved et universitet og innenfor et selskap;
• Hydra og SPTDC.

Intervjuet er utført av:

Vitaly Aksenov — for tiden post-doc ved IST Østerrike og ansatt ved Institutt for datateknologi ved ITMO University. Utfører forskning innen teori og praksis av konkurrerende datastrukturer. Før han jobbet ved IST, mottok han sin doktorgrad fra Paris Diderot University og ITMO University under veiledning av professor Peter Kuznetsov.

Alexey Fedorov - Produsent ved JUG Ru Group, et russisk selskap som arrangerer konferanser for utviklere. Alexey deltok i utarbeidelsen av mer enn 50 konferanser, og CV-en hans inkluderer alt fra stillingen som utviklingsingeniør hos Oracle (JCK, Java Platform Group) til stillingen som utvikler hos Odnoklassniki.

Vladimir Sitnikov - Ingeniør hos Netcracker. Ti års arbeid med ytelsen og skalerbarheten til NetCracker OS, programvare som brukes av telekomoperatører for å automatisere administrasjonsprosesser for nettverk og nettverksutstyr. Interessert i ytelsesproblemer i Java og Oracle Database. Forfatter av mer enn et dusin ytelsesforbedringer i den offisielle PostgreSQL JDBC-driveren.

Samspill mellom akademia og industri

Alexey: Maurice, du har jobbet i et akademisk miljø i veldig lang tid, og det første spørsmålet er samspillet mellom den akademiske og industrielle sfæren. Kan du snakke om hvordan interaksjonene mellom dem har endret seg i det siste? Hva skjedde for 20-30 år siden og hva skjer nå? 

Maurice: Jeg har alltid prøvd å jobbe tett med kommersielle selskaper fordi de har interessante problemer. De er som regel ikke særlig interessert verken i å publisere resultatene sine eller i detaljerte forklaringer av problemene deres til verdenssamfunnet. De er bare interessert i å løse disse problemene. Jeg jobbet for slike selskaper en stund. Jeg brukte fem år på fulltid i et forskningslaboratorium hos Digital Equipment Corporation, som pleide å være et stort dataselskap. Jeg jobbet en dag i uken hos Sun, hos Microsoft, hos Oracle, og jobbet litt på Facebook. Nå skal jeg ut på sabbatspermisjon (en professor ved et amerikansk universitet har lov til å ta en slik permisjon i ett år omtrent en gang hvert sjette år) og jobbe i Algorand, dette er et kryptovalutaselskap i Boston. Å jobbe tett med bedrifter har alltid vært en fornøyelse fordi det er slik man lærer om nye og interessante ting. Du kan til og med være den første eller andre personen som publiserer en artikkel om et valgt emne, i stedet for å jobbe med gradvis å forbedre løsninger på problemer som alle andre allerede jobber med.

Alexey: Kan du fortelle oss mer detaljert hvordan dette skjer?

Maurice: Selvfølgelig. Du vet, da jeg jobbet i Digital Equipment Corporation, jeg og Elliot Moss, oppfant vi transaksjonsminne. Det var en veldig fruktbar periode da alle begynte å interessere seg for informasjonsteknologi. Parallellisme, inkludert, selv om flerkjernesystemer ennå ikke eksisterte. I løpet av Sun- og Oracle-dagene jobbet jeg mye med parallelle datastrukturer. På Facebook jobbet jeg med blokkjedeprosjektet deres, som jeg ikke kan snakke om, men jeg håper det blir offentlig snart. Neste år, på Algorand, skal jeg jobbe i en forskningsgruppe som studerer smarte kontrakter.

Alexey: Blockchain har blitt et veldig populært tema de siste årene. Vil dette hjelpe forskningen din? Kanskje vil det gjøre det lettere å få tilskudd eller gi tilgang til ressurser fra bedrifter som opererer i bransjen?

Maurice: Jeg har allerede mottatt et lite stipend fra Ethereum Foundation. Populariteten til blockchain er svært nyttig for å inspirere studenter til å jobbe med dette feltet. De er veldig interessert i det og er spente på å engasjere seg, men noen ganger skjønner de ikke at forskningen som høres spennende ut på utsiden viser seg å involvere hardt arbeid. Jeg er imidlertid veldig spent på å bruke all denne mystikken rundt blockchain for å tiltrekke studenter. 

Men det er ikke alt. Jeg sitter i advisory board for flere blockchain-oppstart. Noen av dem kan lykkes, noen av dem kanskje ikke, men det er alltid veldig interessant å se ideene deres, studere dem og gi råd til folk. Det mest spennende er når du advarer folk mot å gjøre noe. Mange ting virker som en god idé i begynnelsen, men er de virkelig?

Foundation for Blockchain Research

Vitaly: Noen tror at fremtiden ligger hos blokkjeden og dens algoritmer. Og andre sier at det bare er en ny boble. Kan du dele din mening om denne saken?

Maurice: Mye av det som skjer i blokkjedeverdenen er feil, noe er bare svindel, mye er overvurdert. Jeg tror imidlertid det er et solid vitenskapelig grunnlag for disse studiene. Det faktum at blockchain-verdenen er full av ideologiske forskjeller viser nivået av spenning og dedikasjon. På den annen side er ikke dette spesielt gunstig for vitenskapelig forskning. Nå, hvis du publiserer en artikkel som snakker om manglene til en bestemt algoritme, er den resulterende reaksjonen ikke alltid fullstendig vitenskapelig. Ofte kaster folk ut følelsene sine. Jeg tror at denne typen spenning i dette området kan virke attraktiv for noen, men til syvende og sist er det virkelige vitenskapelige og tekniske problemer som må tas opp. Det er mye informatikk her.

Vitaly: Så du prøver å legge grunnlaget for blockchain-forskning, ikke sant?

Maurice: Jeg prøver å legge grunnlaget for en solid, vitenskapelig og matematisk forsvarlig disiplin. Og en del av problemet er at noen ganger må du motsi noen av de altfor harde posisjonene til andre mennesker og ignorere dem. Noen ganger spør folk hvorfor jeg jobber i et område der bare terrorister og narkotikasmuglere er interessert. En slik reaksjon er like meningsløs som oppførselen til følgere som blindt gjentar ordene dine. Jeg tror sannheten ligger et sted i midten. Blockchain vil ha en dyp innvirkning på samfunnet og den globale økonomien. Men dette vil sannsynligvis ikke skje takket være moderne teknologi. Moderne teknologier vil utvikle seg og det som vil bli kalt blockchain i fremtiden vil bli svært viktig. Det ser kanskje ikke engang ut som moderne blokkjeder, det er et åpent spørsmål.

Hvis folk finner opp nye teknologier, vil de fortsette å kalle det blockchain. Jeg mener, akkurat som dagens Fortran ikke har noe med Fortran-språket fra 1960-tallet å gjøre, men alle fortsetter å kalle det Fortran. Samme for UNIX. Det som kalles "blockchain" vil fortsatt gjøre sin revolusjon. Men jeg tviler på at denne nye blokkjeden vil være noe som alle liker å bruke i dag.

Hvor kommer banebrytende ideer fra? Påvirkning av popularitet

Alexey: Har populariteten til blockchain ført til nye resultater fra et vitenskapelig synspunkt? Mer samhandling, flere studenter, flere bedrifter i området. Er det allerede noen resultater fra denne økningen i popularitet?

Maurice: Jeg ble interessert i dette da noen ga meg en offisiell flyer for et selskap som nettopp hadde samlet inn ganske mye penger. Den skrev om oppgaven til de bysantinske generalene, som jeg er mer enn kjent med. Det som sto i brosjyren var tydeligvis teknisk feil. De som skrev alt dette forsto egentlig ikke modellen bak problemet... og likevel samlet dette selskapet inn mye penger. Deretter byttet selskapet i det stille ut denne brosjyren med en mye mer korrekt versjon - og jeg vil ikke si hva navnet på dette selskapet var. De er fortsatt rundt og har det veldig bra. Denne hendelsen overbeviste meg om at for det første er blockchain ganske enkelt en form for distribuert databehandling. For det andre var inngangsterskelen (i hvert fall for fire år siden) ganske lav. Menneskene som jobbet i dette feltet var veldig energiske og intelligente, men de leste ikke vitenskapelige artikler. De prøvde å gjenoppfinne kjente ting og gjorde det feil. I dag har dramatikken blitt mindre.

Alexey: Dette er veldig interessant, for for noen år siden hadde vi en annen trend. Det er litt som frontend-utvikling, da nettleserbaserte frontend-utviklere gjenoppfant hele teknologier som allerede var populære i back-end: bygge systemer, kontinuerlig integrasjon, slike ting. 

Maurice: Jeg er enig. Men dette er ikke overraskende, for virkelig banebrytende ideer kommer alltid utenfor det etablerte samfunnet. Etablerte forskere, spesielt etablerte akademikere, vil neppe gjøre noe virkelig banebrytende. Det er lett å skrive en artikkel til neste konferanse om hvordan du forbedret resultatene av tidligere arbeid litt. Gå på en konferanse, kom sammen med venner, snakk om de samme tingene. Og menneskene som bryter inn med banebrytende ideer kommer nesten alltid utenfra. De kan ikke reglene, de kan ikke språket, men likevel... Hvis du er innenfor et etablert fellesskap, råder jeg deg til å ta hensyn til nye ting, til noe som ikke passer inn i helhetsbildet. På en måte kan man forsøke å kombinere eksterne, mer flytende utviklinger med metoder som vi allerede forstår. Som et første skritt, prøv å etablere et vitenskapelig grunnlag, og endre det så slik at det kan brukes på nye gjennombruddsideer. Jeg tror at blockchain er flott for å være en frisk, forstyrrende idé.

Alexey: Hvorfor tror du dette skjer? Fordi folk "utenfor" ikke har noen spesifikke barrierer iboende i samfunnet?

Maurice: Det er et mønster på gang her. Hvis du leser historien til impresjonistene innen maleri og kunst generelt, så avviste kjente kunstnere en gang impresjonismen. De sa det var litt barnslig. En generasjon senere ble denne tidligere avviste kunstformen standarden. Det jeg ser i mitt felt: oppfinnerne av blockchain var ikke interessert i makt, i økende publikasjoner og sitasjonsindeks, de ville bare gjøre noe bra. Så de satte seg ned og begynte å gjøre det. De manglet en viss mengde teknisk dybde, men det kan fikses. Det er mye vanskeligere å komme opp med nye kreative ideer enn å korrigere og styrke utilstrekkelig modne. Takket være disse oppfinnerne har jeg nå noe å gjøre!

Alexey: Dette ligner på forskjellen mellom startups og eldre prosjekter. Vi arver mange begrensninger for tenkning, barrierer, spesielle krav og så videre.

Maurice: En god analogi er distribuert databehandling. Tenk på blockchain som om det var en oppstart og distribuert databehandling som et stort, etablert selskap. Distribuert databehandling er i ferd med å bli anskaffet og slått sammen med blockchain.

PhD under veiledning av Barbara Liskov

Vitaly: Vi har fortsatt mange spørsmål! Vi undersøkte bakgrunnen din og kom over et interessant faktum om doktorgraden din. Ja, dette var lenge siden, men det ser ut til å være et viktig tema. Du mottok doktorgraden din under veiledning av deg selv Barbara Liskov! Barbara er veldig godt kjent i programmeringsspråkmiljøet, og en veldig kjent person generelt. Det er logisk at forskningen din var innen programmeringsspråk. Hvordan byttet du til parallell databehandling? Hvorfor bestemte du deg for å endre tema?

Maurice: På den tiden så Barbara og gruppen hennes bare på distribuert databehandling, som var en veldig ny idé. Det var også de som sa at distribuert databehandling var tull og at datamaskiner som kommuniserte med hverandre var meningsløst. Et av problemene som tas opp i distribuert databehandling som skiller det fra sentralisert databehandling er feiltoleranse. Etter mye forskning bestemte vi oss for at et distribuert programmeringsspråk for databehandling måtte ha noe som atomtransaksjoner fordi du aldri kan være sikker på at en ekstern samtale vil lykkes. Når du har transaksjoner, oppstår problemet med samtidighetshåndtering. Deretter var det mye arbeid med å skaffe svært parallelle transaksjonelle datastrukturer. Så, da jeg ble uteksaminert, dro jeg til Carnegie Mellon og begynte å lete etter et emne å jobbe med. Det gikk opp for meg at databehandling har flyttet fra individuelle datamaskiner til nettverk av datamaskiner. Multiprosessorer ville være en naturlig fortsettelse av fremgangen - ordet "multi-core" eksisterte ennå ikke. Jeg tenkte: hva tilsvarer atomtransaksjoner for et flerkjernesystem? Definitivt ikke vanlige transaksjoner fordi de er for store og tunge. Og det var slik jeg kom på ideen lineariserbarhet og det var slik jeg kom opp med hele den ventefrie synkroniseringen. Dette var et forsøk på å svare på spørsmålet om hva som er analogen til atomtransaksjoner for et multiprosessorsystem med delt minne. Ved første øyekast kan dette verket se helt annerledes ut, men faktisk er det en fortsettelse av samme tema.

Verden venter på multi-core

Vitaly: Du nevnte at det på den tiden var veldig få multi-core datamaskiner, ikke sant?

Maurice: De var bare ikke der. Det var flere såkalte symmetriske multiprosessorer, som i utgangspunktet var koblet til samme buss. Dette fungerte ikke veldig bra fordi hver gang et nytt selskap opprettet noe lignende, ville Intel gi ut en enkelt prosessor som var overlegen multiprosessoren.

Alexey: Betyr ikke dette at det i de gamle tider var mer et teoretisk studium?

Maurice: Det var ikke en teoretisk studie, men snarere en spekulativ studie. Alt dette handlet ikke om å jobbe med mange teoremer; snarere la vi frem hypoteser om en arkitektur som ikke eksisterte på den tiden. Det er dette forskning er til for! Ingen bedrift ville ha gjort noe slikt; det hele var noe fra en fjern fremtid. Faktisk var dette tilfellet frem til 2004, da ekte flerkjerneprosessorer dukket opp. Fordi prosessorer overopphetes, kan du gjøre prosessoren enda mindre, men du kan ikke gjøre den raskere. På grunn av dette var det en overgang til flerkjernearkitekturer. Og så betydde det at det plutselig var bruk for alle konseptene vi hadde utviklet tidligere.

Alexey: Hvorfor tror du flerkjerneprosessorer dukket opp først på XNUMX-tallet? Så hvorfor er det så sent?

Maurice: Dette skyldes maskinvarebegrensninger. Intel, AMD og andre selskaper er veldig flinke til å øke prosessorhastigheten. Når prosessorene på et tidspunkt ble små nok til at de ikke lenger kunne øke klokkehastigheten fordi prosessorene ville begynne å brenne ut. Du kan gjøre dem mindre, men ikke raskere. Hva er i deres makt - i stedet for en veldig liten prosessor, kan de få plass til åtte, seksten eller trettito prosessorer i samme volum av kabinettet, der tidligere bare én kunne passe. Nå har du multithreading og rask kommunikasjon mellom dem fordi de deler cacher. Men du kan ikke tvinge dem til å løpe fortere – det er en helt bestemt fartsgrense. De fortsetter å forbedre seg litt etter litt, men ikke så mye lenger. Fysikkens lover sto i veien for forbedringer.

En ny verden gir nye problemer. NUMA, NVM og arkitekturhacking

Alexey: Høres veldig fornuftig ut. Med nye multi-core prosessorer kom nye problemer. Forventet du og kollegene dine disse problemene? Kanskje du studerte dem på forhånd? I teoretiske studier er det ofte ikke så lett å forutsi slike ting. Når problemer oppsto, hvordan oppfylte de forventningene dine og kollegene dine? Eller var de helt nye, og du og kollegene dine måtte bruke mye tid på å løse problemer slik de dukket opp?

Vitaly: Jeg vil legge til Alexeys spørsmål: spådde du prosessorarkitekturen riktig mens du studerte teorien?

Maurice: Ikke 100 %. Men jeg synes kollegene mine og jeg har gjort en god jobb med å forutsi multikjerner med delt minne. Jeg tror vi riktig forutså vanskelighetene med å utvikle parallelle datastrukturer som opererer uten låser. Slike datastrukturer har vært viktige for mange applikasjoner, selv om ikke alle, men ofte er det man egentlig trenger en ikke-låsende datastruktur. Da vi fant opp dem var det mange som hevdet at dette var tull, at alt fungerte bra med låser. Vi spådde ganske godt at det ville være ferdige løsninger for mange programmeringsproblemer og datastrukturproblemer. Det var også mer komplekse problemer, som f.eks NUMA – ujevn tilgang til minne. Faktisk ble de ikke engang vurdert før flerkjerneprosessorer ble oppfunnet fordi de var for spesifikke. Forskermiljøet jobbet med spørsmål som generelt var forutsigbare. Noen maskinvareproblemer knyttet til spesifikke arkitekturer måtte vente i kulissene - faktisk utseendet til disse arkitekturene. For eksempel jobbet ingen egentlig med GPU-spesifikke datastrukturer fordi GPUer ikke eksisterte den gang. Selv om det er gjort mye arbeid med SIMD, var disse algoritmene klare til bruk så snart passende maskinvare ble tilgjengelig. Det er imidlertid umulig å forutse alt.

Alexey: Hvis jeg forstår det riktig, er NUMA et slags kompromiss mellom kostnader, ytelse og noen andre ting. Noen ideer om hvorfor NUMA kom ut så sent?

Maurice: Jeg tror at NUMA eksisterer på grunn av problemer med maskinvaren som brukes til å produsere minne: jo lenger unna komponentene er, jo tregere er det å få tilgang til dem. På den annen side er den andre verdien av denne abstraksjonen minneensartethet. Så en av egenskapene til parallell databehandling er at alle abstraksjonene er litt ødelagte. Hvis tilgangen var helt ensartet, ville all hukommelse vært like langt, men dette er økonomisk, og kanskje til og med fysisk, umulig. Derfor oppstår denne konflikten. Hvis du skriver programmet ditt som om minnet var ensartet, vil det mest sannsynlig være riktig. I den forstand at det ikke vil gi feil svar. Men opptredenen hennes vil heller ikke fange stjernene fra himmelen. På samme måte hvis du skriver spinlocks Uten å forstå cachehierarkiet vil selve blokkeringen være riktig, men du kan glemme ytelsen. På en måte må du skrive programmer som lever på toppen av en veldig enkel abstraksjon, men du må overliste menneskene som ga deg den abstraksjonen: du må vite at under abstraksjonen er det et eller annet hierarki av minne, at det er en buss mellom deg og dette minnet, og så videre. Dermed er det en viss konflikt mellom individuelt nyttige abstraksjoner, noe som fører oss til veldig konkrete og pragmatiske problemer.

Vitaly: Hva med fremtiden? Kan du forutsi hvordan prosessorer vil utvikle seg neste gang? Det er en ide om at et av svarene er transaksjonsminne. Du har sikkert noe annet på lager.

Maurice: Det er et par store utfordringer fremover. Den ene er at sammenhengende hukommelse er en fantastisk abstraksjon, men den begynner å bryte sammen i spesielle tilfeller. Så, for eksempel, er NUMA et levende eksempel på noe der du kan fortsette å late som om det eksisterer enhetlig hukommelse. Egentlig nei, produktivitet vil få deg til å gråte. På et tidspunkt vil arkitekter måtte forlate ideen om en enkelt minnearkitektur; du kan ikke late som for alltid. Det vil være behov for nye programmeringsmodeller som er enkle nok å bruke og kraftige nok til å gjøre den underliggende maskinvaren effektiv. Dette er et veldig vanskelig kompromiss, for hvis du viser programmerere arkitekturen som faktisk brukes i maskinvaren, blir de gale. Det er for komplisert og ikke bærbart. Hvis du presenterer et grensesnitt som er for enkelt, blir ytelsen dårlig. Derfor vil mange svært vanskelige avveininger måtte gjøres for å gi nyttige programmeringsmodeller som kan brukes for virkelig store flerkjerneprosessorer. Jeg er ikke sikker på at andre enn en spesialist er i stand til å programmere på en 2000-kjerners datamaskin. Og med mindre du driver med veldig spesialisert eller vitenskapelig databehandling eller kryptografi eller noe sånt - er det fortsatt ikke helt klart hvordan du gjør det riktig. 

Et annet lignende område er spesialiserte arkitekturer. Grafikkakseleratorer har eksistert lenge, men de har blitt noe av et klassisk eksempel på hvordan du kan ta en spesialisert type databehandling og kjøre den på en dedikert brikke. Dette gir sine egne utfordringer: hvordan du kommuniserer med en slik enhet, hvordan du programmerer den. Jeg har nylig jobbet med problemer i området nær minnedatabehandling. Du tar en liten prosessor og limer den til en stor del av minnet slik at minnet kjører med L1 cache-hastighet og deretter kommuniserer med en enhet som f.eks. TPU – prosessoren er opptatt med å laste nye oppgaver inn i minnekjernen din. Å designe datastrukturer og kommunikasjonsprotokoller for denne typen ting er et annet interessant eksempel. Så tilpassede prosessorer og maskinvare vil fortsette å se forbedringer i en stund.

Alexey: Hva med ikke-flyktig minne (ikke-flyktig minne)?

Maurice: Å, det er nok et godt eksempel! NVM vil i stor grad endre måten vi ser på ting som datastrukturer. Ikke-flyktig minne, på en måte, lover å virkelig få fart på ting. Men det vil ikke gjøre livet enklere fordi de fleste prosessorer, cacher og registre fortsatt er flyktige. Når du starter etter en krasj, vil ikke tilstanden og minnetilstanden din være nøyaktig den samme som før krasj. Jeg er veldig takknemlig for de som jobber på NVM - det vil være mye for forskere å gjøre i lang tid for å finne ut riktighetsforhold. Beregninger er korrekte hvis de kan overleve et krasj der innholdet i cacher og registre går tapt, men hovedminnet forblir intakt.

Kompilatorer vs prosessorer, RISC vs CISC, delt minne vs meldingsoverføring

Vladimir: Hva synes du om "kompilatorer vs. prosessorer"-dilemmaet fra et instruksjonssett synspunkt? La meg forklare for de som ikke vet: Hvis vi går til skjevt minne eller noe lignende, kan vi bruke et veldig enkelt sett med kommandoer og be kompilatoren generere kompleks kode som kan dra nytte av de nye fordelene. Eller vi kan gå den andre veien: implementere komplekse instruksjoner og be prosessoren om å omorganisere instruksjonene og gjøre andre manipulasjoner med dem. Hva synes du om det?

Maurice: Jeg har egentlig ikke noe svar på det spørsmålet. Denne debatten har pågått i fire tiår. Det var en tid da mellom forkortet et sett med kommandoer og komplisert borgerkriger ble utkjempet av et sett med kommandoer. En stund vant RISC-folket, men så bygget Intel om motorene sine slik at et redusert sett med instruksjoner ble brukt internt, og hele settet ble eksportert eksternt. Dette er sannsynligvis et tema der hver ny generasjon må finne sine egne kompromisser og ta sine egne beslutninger. Det er veldig vanskelig å forutsi hvilke av disse tingene som vil bli bedre. Så enhver spådom jeg kommer med vil være sann i en viss tid, og deretter falsk igjen en stund, og så sann igjen.

Alexey: Hvor vanlig er det for industrien at noen ideer vinner i flere tiår og taper i de neste? Finnes det andre eksempler på slike periodiske endringer?

Maurice: På temaet distribuert databehandling er det folk som tror på delt minne og folk som tror på meldinger. Til å begynne med, i distribuert databehandling, betyr parallell databehandling at meldinger sendes. Så oppdaget noen at det var mye lettere å programmere med delt minne. Den motsatte siden sa at delt minne er for komplisert, fordi det krever låser og lignende, så det er verdt å flytte til språk der ingenting annet enn meldingsoverføring bare eksisterer. Noen så på hva som kom ut av dette og sa, "wow, denne meldingsimplementeringen ser mye ut som delt minne, fordi du lager mange og mange av disse små modulene, de sender meldinger til hverandre, og de alle forrigling"La oss lage en bedre database for delt minne!" Alt dette gjentas om og om igjen, og det er umulig å si at en av partene definitivt har rett. En av sidene vil alltid dominere fordi så snart en av dem nesten vinner, finner folk opp igjen og igjen måter å forbedre den andre på.

Kunsten å skrive sprø flertrådskode

Alexey: Dette er veldig interessant. For eksempel, når vi skriver kode, uansett hvilket programmeringsspråk, må vi vanligvis lage abstraksjoner som celler som kan leses og skrives. Men faktisk, på et fysisk nivå, kan dette se ut som å sende en melding over en maskinvarebuss mellom forskjellige datamaskiner og andre enheter. Det viser seg at arbeid skjer på begge abstraksjonsnivåer samtidig.

Maurice: Det er helt sant at delt minne er bygget på meldingsoverføring – busser, cacher og så videre. Men det er vanskelig å skrive programmer ved å bruke meldingsoverføring, så maskinvaren lyver bevisst og later som om du har en slags enhetlig hukommelse. Dette vil gjøre det lettere for deg å skrive enkle, riktige programmer før ytelsen begynner å bli dårligere. Da vil du si: det ser ut som det er på tide å bli venner med cachen. Og så begynner du å bekymre deg for plasseringen av cachen, og derfra går det. På en måte hacker du abstraksjonen: du vet at det ikke bare er flatt, enhetlig minne, og du kommer til å bruke den kunnskapen til å skrive cache-vennlige programmer. Dette er hva du må gjøre i reelle problemer. Denne konflikten mellom den søte, enkle, fine abstraksjonen du har fått og den fryktelig komplekse implementeringen av den underliggende maskinvaren er der alle vil inngå sitt eget kompromiss. Jeg har en bok om multiprosessorer og synkronisering, og på et tidspunkt skulle jeg skrive et kapittel om datastrukturer i java.util.samtidig. Hvis du ser på dem, f.eks lister med mangler Dette er fantastiske kunstverk. (Redaktørens merknad: De som er kjent med Java-språket bør i det minste ta en titt på implementeringen Concurrent SkipListMap, du kan se på lenkene på API и kildekode). Men fra mitt ståsted ville det vært uansvarlig å vise dem til studenter, for en slik datastruktur er på en måte som en fyr i et sirkus som løper på stram tau over en bjørnegrop. Hvis du endrer bare en liten detalj, vil hele strukturen kollapse. Denne koden er veldig rask og elegant bare fordi den er skrevet perfekt, men den minste endringen vil føre til fullstendig feil. Hvis jeg gir denne koden som eksempel til studenter, vil de umiddelbart si: Det kan jeg også! Og så vil et fly havarere eller en atomreaktor eksplodere, og jeg vil være skyldig i å gi dem for mye informasjon til feil tid.

Alexey: Da jeg var litt yngre, prøvde jeg mange ganger å studere Doug Lees kildekode, for eksempel, java.util.samtidig, fordi det er åpen kildekode, er det veldig enkelt å finne og prøve å forstå hva som skjer der. Det viste seg ikke veldig bra: ofte er det helt uklart hvorfor Doug bestemte seg for å gjøre noe på denne måten når alle andre gjør det annerledes. Hvordan forklarer du disse tingene til elevene dine? Er det en spesiell korrekt måte å beskrive spesifikke detaljer om en hardcore-algoritme, for eksempel? Hvordan gjør du dette?

Maurice: Tegnelærere har en klisjé som de husker først: Hvis du vil tegne som Picasso, må du først lære å tegne enkle realistiske bilder, og først når du kjenner reglene kan du begynne å bryte dem. Begynner du med å bryte reglene med en gang, havner du i et rot. Først lærer jeg elevene hvordan de skriver enkel, riktig kode uten å bekymre seg for ytelsen. Det jeg sier er at det er komplekse tidsproblemer som lurer her, så ikke bekymre deg for cacher, ikke bekymre deg for minnemodeller, bare sørg for at alt fungerer som det skal. Dette er allerede vanskelig nok: moderne programmering er ikke lett i seg selv, spesielt for nye studenter. Og når de har en intuisjon om hvordan de skal skrive de riktige programmene, sier jeg: se på disse to spinlock-implementeringene: den ene er veldig treg, og den andre er heller ikke veldig, men bedre. Matematisk er imidlertid de to algoritmene de samme. Faktisk bruker en av dem cache-lokalitet. En av dem kjører på lokalt bufrede data, og den andre utfører gjentatte ganger operasjoner på tvers av bussen. Du kan ikke skrive effektiv kode hvis du ikke forstår hva det er, og ikke vet hvordan du skal bryte abstraksjonen og se på den underliggende strukturen. Men du vil ikke kunne begynne å gjøre dette med en gang. Det er folk som begynner å gjøre dette med en gang og tror på sitt eget geni, vanligvis ender det dårlig fordi de ikke forstår prinsippene. Ingen tegner som Picasso eller skriver programmer som Doug Lee som er fersk fra college den første uken. Det tar år å nå dette kunnskapsnivået.

Alexey: Det viser seg at du deler problemet i to deler: den første er korrekthet, den andre er ytelse?

Maurice: Akkurat. Og akkurat i den rekkefølgen. Noe av problemet er at nye elever ikke forstår at korrekthet er vanskelig å oppnå. Ved første øyekast sier de: dette er åpenbart riktig, det gjenstår bare å få fart på det. Så noen ganger forteller jeg dem om en opprinnelig feil algoritme som om den var riktig.

Hvordan lære elevene å skrive kompleks flertrådskode

Alexey: Bare for å se om de kan fornemme fangsten?

Maurice: Jeg advarer alltid på forhånd om at noen ganger vil jeg foreslå feil algoritmer. Du bør ikke lure folk. Jeg foreslår at de tar informasjonen med en klype salt. Hvis jeg forteller noe og sier: "se, dette er åpenbart riktig" - dette er et signal om at et sted prøver de å lure deg, og du bør begynne å stille spørsmål. Deretter prøver jeg å oppmuntre elevene til å fortsette å stille spørsmål, og så foreslår jeg: «Hva vil skje hvis vi lar ting være som de er?» Og de ser umiddelbart feilen. Men å overbevise elevene om at de trenger å bekymre seg for riktigheten er mye vanskeligere enn det ser ut ved første øyekast. Mange av disse elevene kommer med programmeringserfaring på videregående, noen har fått jobb og har drevet med programmering der, og de er alle fulle av selvtillit. Dette er noe sånt som hæren: du må først endre humøret deres for å overbevise dem om å tålmodig nærme seg å løse problemer som oppstår. Eller kanskje det er som buddhistiske munker: først lærer de å resonnere om korrekthet, og når de først forstår måtene å resonnere om korrekthet på, får de lov til å gå videre til neste nivå og begynne å bekymre seg for ytelse.

Alexey: Det vil si at noen ganger viser du studenter eksempler som ikke fungerer, takket være at du får tilbakemelding som viser om de forstår essensen av problemet, om de kan finne feil kode og feil resultat. Så gjør studenter deg vanligvis glad eller trist?

Maurice: Studenter finner nesten alltid feilen til slutt. Hvis de søker for sakte, stiller jeg ledende spørsmål, og her er det viktig å forstå at hvis du aldri lurer dem, vil de begynne å tankeløst oppfatte ordene dine som den ultimate sannheten. Da vil de kjede seg og begynne å sovne mens de leser Facebook på den bærbare datamaskinen i timen. Men når du forteller dem på forhånd at de vil bli lurt, og de vil se dumme ut hvis de ikke aner et triks, blir de mye mer årvåkne. Dette er bra på forskjellige måter. Jeg vil gjerne at elevene ikke bare stiller spørsmål ved deres forståelse av problemstillingen, men også stiller spørsmål ved lærerens autoritet. Tanken er at en elev når som helst kan rekke opp hånden og si: Jeg synes det du nettopp sa er feil. Det er et viktig læringsverktøy. Jeg vil ikke at noen av studentene skal sitte og tenke stille for seg selv: alt dette virker fullstendig tull, men å rekke opp hånden er for skummelt, og uansett er han professor, så alt han sier er sannheten. Derfor, hvis de på forhånd blir advart om at ikke alt som fortelles nødvendigvis er sant, har de et insentiv til å være mer oppmerksom på materialet. Jeg gjør det klart at det er greit å rekke opp hånden og stille spørsmål. Spørsmålet ditt kan høres dumt eller naivt ut, men det er ofte slik de beste spørsmålene oppstår.

Alexey: Veldig interessant. Vanligvis har folk en slags psykologisk barriere som ikke tillater dem å stille et spørsmål til en professor. Spesielt hvis det er mange mennesker i rommet, og alle er redde for at det å diskutere det dumme spørsmålet ditt vil ta all tid til disse menneskene. Finnes det noen triks for å takle dette?

Maurice: Jeg stopper ofte opp og stiller klassiske spørsmål. Om en påstand ville være riktig, eller hvordan de ville løse problemet som diskuteres. Dette er en nøkkelhandling, spesielt i begynnelsen av en leksjon når folk er flaue over å si selv den minste ting. Du stiller elevene et spørsmål og sier ikke noe mer. Det er stillhet, alle blir litt anspente, spenningen vokser, så er det plutselig noen som ikke tåler det, bryter sammen og sier svaret. Slik snur du situasjonen: Å fortsette å tie blir vanskeligere og upraktisk enn å svare! Dette er et standard pedagogisk triks. Hver lærer i verden bør vite hvordan dette skal gjøres.

Alexey: Nå har vi en utmerket tittel for dette intervjuet: "det er lettere å svare enn å tie."

Vitaly: La meg spørre igjen. Du jobber med topologiske bevis. Hvordan ble du i det hele tatt involvert i dette, for distribuert databehandling og topologi er helt forskjellige ting!

Maurice: Det er en skjult forbindelse der. Da jeg var student og studerte matematikk, studerte jeg ren matematikk. Jeg hadde ingen reell interesse for datamaskiner før studiene tok slutt, og jeg ble møtt med det presserende behovet for å søke jobb. Som student studerte jeg algebraisk topologi. Mange år senere, mens du arbeider med et problem kalt "k-Set-avtaleproblem", brukte jeg grafer for å modellere problemet, og som det så ut på den tiden, hadde jeg funnet en løsning. Du måtte bare sette deg ned og gå rundt tellingen. Prøv å finne et passende svar på denne grafen. Men algoritmen min fungerte ikke: det viste seg at han ville løpe i sirkler for alltid. Dessverre kunne ikke alt dette forklares på grafteoriens formelle språk – det som alle dataforskere kjenner. Og så husket jeg at for mange år siden, tilbake i topologitimer, brukte vi konseptet "enkelt kompleks", som er en generalisering av grafer til høyere dimensjoner. Så spurte jeg meg selv: hva ville skje hvis vi omformulerte problemet i form av enkle komplekser? Dette ble nøkkeløyeblikket. Ved å bruke en kraftigere formalisme blir problemet plutselig mye enklere. Folk kjempet mot det i lang tid ved å bruke grafer, men de kunne ikke gjøre noe. Og selv nå kan de ikke - det riktige svaret viste seg å ikke være en algoritme, men et bevis på umuligheten av å løse problemet. Det vil si at en slik algoritme rett og slett ikke eksisterer. Men ethvert bevis på umulighet basert enten på enkle komplekser eller på ting som folk lot som om de ikke betraktet enkle komplekser. Bare fordi du kaller noe et nytt navn, mister det ikke essensen.

Vitaly: Det viser seg at du bare var heldig?

Maurice: Foruten flaks, er det det også beredskap. Dette betyr at du ikke bør glemme de "unyttige" tingene du har lært tidligere. Jo flere unyttige ting du lærer, jo flere ideer kan du trekke ut når du står overfor et nytt problem. Denne typen intuitiv mønstertilpasning er viktig fordi... La oss gjøre dette, dette er en kjede: først oppdaget jeg at grafene ikke fungerte i det hele tatt eller ikke fungerte i det hele tatt, det minnet meg om noe fra hendelsene i åtte år siden og mine studentår, da vi studerte alle disse enkle kompleksene. Dette tillot meg igjen å finne min gamle topologi-lærebok og laste den inn i hodet mitt igjen. Men hvis det ikke var for den gamle kunnskapen, ville jeg aldri ha gjort noen fremskritt i å løse det opprinnelige problemet.

Ny utgave av boken "The Art of Multiprocessor Programming"

Alexey: Du sa noen ord om boken din. Det er sannsynligvis ikke den verste hemmeligheten at du skrev verdens mest kjente bok om multithreading, "Kunsten å programmere flere prosessorer". Den er allerede rundt 11 år gammel og siden den gang har den bare blitt utgitt  revidert opptrykk. Kommer det en andre utgave?

Maurice: Det er bra du spurte! Det vil være veldig snart, om tre måneder eller så. Det er to forfattere til, vi la til mye mer materiale, forbedret avsnittet om gaffel/skjøteparallellisme, skrev et avsnitt om MapReduce, la til mye nytt og kastet ut unødvendige ting – noe som var veldig interessant i skrivende stund den første utgaven, men finnes ikke lenger i dag. Resultatet ble en svært seriøst revidert bok.

Alexey: Alt er allerede gjort, alt som gjenstår er å gi det ut?

Maurice: Et par kapitler trenger fortsatt litt arbeid. Utgiveren vår (som jeg tror allerede hater oss) prøver fortsatt å få frem budskapet om at vi bør jobbe raskere. Vi ligger langt bak skjema. Teoretisk sett kunne vi ha gjort denne boken et par år tidligere.

Alexey: Noen sjanse til å få en ny versjon av boken før jul?

Maurice: Dette er målet vårt! Men jeg har spådd seier så mange ganger at ingen tror meg lenger. Du bør nok ikke stole for mye på meg i denne saken heller.

Alexey: I alle fall er dette fantastiske nyheter. Jeg likte den første utgaven av boken veldig godt. Du kan si at jeg er en fan.

Maurice: Jeg håper den nye utgaven vil være verdig din inderlige entusiasme, takk!

Hvordan transaksjonsminne ble oppfunnet

Vitaly: Det neste spørsmålet handler om transaksjonsminne. Så vidt jeg forstår er du en pioner på dette feltet, du fant det opp i en tid da ingen tenkte på slike ting. Hvorfor bestemte du deg for å flytte inn på dette feltet? Hvorfor virket transaksjoner viktige for deg? Trodde du at de en dag ville bli implementert i maskinvare?

Maurice: Jeg har visst om transaksjoner siden studiedagene mine.

Vitaly: Ja, men dette er forskjellige transaksjoner!

Maurice: Jeg jobbet med Elliott Moss om ikke-blokkerende søppelinnsamling. Problemet vårt var at vi ønsket å atomisk endre noen få ord i minnet, og da ville algoritmene bli veldig enkle, og i det minste noen av dem ville bli mer effektive. Ved hjelp av sammenlign og bytt for load-link/store-conditionalgitt av den parallelle arkitekturen, er det mulig å gjøre noe, men det er veldig ineffektivt og stygt fordi du må forholde deg til lag med indirekte. Jeg vil endre minneord og jeg må bytte fordi jeg bare kan endre én peker, så de må peke på en slags kataloglignende struktur. Vi snakket om hvor flott det ville være om vi kunne endre maskinvaren slik at den kunne gjøre samtidige opptak. Elliott ser ut til å ha lagt merke til dette: Hvis du ser på protokoller for cache-koherens, gir de allerede det meste av den nødvendige funksjonaliteten. I en optimistisk transaksjon vil cache-koherensprotokollen legge merke til at det er en tidskonflikt og cachen vil bli ugyldig. Hva skjer hvis du spekulativt kjører en transaksjon på hurtigbufferen din og bruker koherensprotokollmekanismene for å oppdage konflikter? Spekulativ maskinvarearkitektur var enkel å designe. Så vi skrev den den aller første utgivelsen om transaksjonsminne. Samtidig laget selskapet jeg jobbet for, Digital Equipment Corporation, en ny 64-bits prosessor kalt Alpha. Så jeg gikk og holdt en presentasjon for Alpha-utviklingsgruppen om vårt fantastiske transaksjonsminne, og de spurte: Hvor mye ekstra inntekt ville selskapet vårt få hvis vi la alt dette direkte til prosessoren? Og jeg hadde absolutt ikke noe svar på dette, fordi jeg er teknolog, jeg er ingen markedsføringsspesialist. Jeg hadde egentlig ingenting å svare på. De var ikke veldig imponert over at jeg ikke visste noe.

Vitaly: Milliarder! Bare si milliarder!

Maurice: Ja, det er det jeg burde ha sagt. Nå, i en tid med startups og alt mulig, vet jeg hvordan jeg skal skrive en forretningsplan. At du kan lyve litt om størrelsen på din potensielle fortjeneste. Men på den tiden virket det naivt, så jeg sa bare: "Jeg vet ikke." Hvis du ser på historien til publikasjonen om transaksjonsminne, vil du legge merke til at det etter et år var flere referanser til den, og i omtrent ti år var det ingen som siterte denne artikkelen i det hele tatt. Sitatene dukket opp rundt 2004, da ekte multikjerner dukket opp. Da folk oppdaget at det å skrive parallell kode kunne tjene penger, begynte ny forskning. Ravi Rajwar skrev en artikkel, som på en eller annen måte introduserte konseptet transaksjonsminne til mainstream. (Redaktørens merknad: Det er en andre versjon av denne artikkelen, utgitt i 2010 og fritt tilgjengelig som PDF). Plutselig innså folk nøyaktig hvordan alt dette kunne brukes, hvordan tradisjonelle algoritmer med låser kunne akselereres. Et godt eksempel på noe som tidligere virket som et interessant akademisk problem. Og ja, hvis du hadde spurt meg på det tidspunktet om jeg trodde at alt dette ville bli viktig i fremtiden, ville jeg ha sagt: selvfølgelig, men nøyaktig når er ikke klart. Kanskje om 50 år? I praksis viste dette seg å være bare et tiår. Det er veldig hyggelig når man gjør noe og etter bare ti år legger folk merke til det.

Hvorfor det er verdt å forske innen distribuert databehandling

Vitaly: Hvis vi snakker om ny forskning, hva vil du råde leserne til – distribuert databehandling eller multi-core og hvorfor? 

Maurice: I disse dager er det enkelt å få en flerkjerneprosessor, men det er vanskeligere å sette opp et ekte distribuert system. Jeg begynte å jobbe med dem fordi jeg ønsket å gjøre noe annet enn doktorgradsavhandlingen min. Dette er rådet jeg alltid gir til nye studenter: ikke skriv en fortsettelse av avhandlingen din – prøv å gå i en ny retning. Og multithreading er også enkelt. Jeg kan eksperimentere med min egen gaffel som kjører på den bærbare datamaskinen uten å komme meg ut av sengen. Men hvis jeg plutselig ville lage et reelt distribuert system, måtte jeg gjøre mye arbeid, tiltrekke meg studenter og så videre. Jeg er en lat person og vil heller jobbe med multi-core. Eksperimentering på flerkjernesystemer er også enklere enn å gjøre eksperimenter på distribuerte systemer, fordi selv i et dumt distribuert system er det for mange faktorer som må kontrolleres.

Vitaly: Hva gjør du nå, forsker på blockchain? Hvilke artikler bør du være oppmerksom på først?

Maurice: Dukket nylig opp veldig bra artikkel, som jeg skrev sammen med min elev, Vikram Saraf, spesielt for en samtale kl Tokenomcs-konferanse i Paris for tre uker siden. Dette er en artikkel om praktiske distribuerte systemer, der vi foreslår å gjøre Ethereum flertrådet. For tiden utføres smarte kontrakter (kode som kjører på blokkjeden) sekvensielt. Vi skrev en artikkel tidligere som snakket om en måte å bruke spekulative transaksjoner for å fremskynde prosessen. Vi tok mange ideer fra programvaretransaksjonsminnet og sa at hvis du gjør disse ideene til en del av den virtuelle Etherium-maskinen, vil alt fungere raskere. Men for dette er det nødvendig at det ikke er datakonflikter i kontraktene. Og så antok vi at i det virkelige liv er det egentlig ingen slike konflikter. Men vi hadde ingen måte å finne ut av det. Så gikk det opp for oss at vi hadde nesten et tiår med ekte kontraktshistorie på hendene, så vi dumpet Ethereum-blokkjeden og spurte oss selv: hva ville skje hvis disse historiske postene ble utført parallelt? Vi fant en betydelig hastighetsøkning. I de tidlige dagene av Ethereum økte hastigheten veldig mye, men i dag er alt noe mer komplisert, fordi det er færre kontrakter og sannsynligheten for konflikter om data som krever serialisering har blitt høyere. Men alt dette er eksperimentelt arbeid med ekte historiske data. Det fine med blokkjeden er at den husker alt for alltid, slik at vi kan gå tilbake i tid og studere hva som ville ha skjedd hvis vi hadde brukt forskjellige algoritmer for å kjøre koden. Hvordan ville folk tidligere ha likt vår nye idé? Slik forskning er mye enklere og morsommere å gjøre, fordi det er en ting som overvåker alt og registrerer alt. Dette ligner allerede noe mer på sosiologi enn på utvikling av algoritmer.

Har utviklingen av algoritmer stoppet og hvordan gå videre?

Vitaly: Tid for det siste teoretiske spørsmålet! Føles det som om fremgangen i konkurrerende datastrukturer avtar hvert år? Tror du vi har nådd et platå i vår forståelse av datastrukturer eller vil det bli noen store forbedringer? Kanskje det er noen smarte ideer som kan endre alt fullstendig?

Maurice: Vi kan ha nådd et platå i datastrukturer for tradisjonelle arkitekturer. Men datastrukturer for nye arkitekturer er fortsatt et svært lovende område. Hvis du vil lage datastrukturer for for eksempel maskinvareakseleratorer, så er datastrukturene for en GPU svært forskjellige fra datastrukturene for en CPU. Når du utvikler datastrukturer for blokkjeder, må du hash biter av data og deretter sette dem inn i noe som Merkle tre, for å forhindre forfalskning. Det har vært en bølge av aktivitet på dette området i det siste, med mange som har gjort veldig godt arbeid. Men jeg tror det som vil skje er at nye arkitekturer og nye applikasjoner vil føre til nye datastrukturer. Eldre applikasjoner og tradisjonell arkitektur - det er kanskje ikke mye rom for utforskning lenger. Men hvis du går utenfor allfarvei og ser utover kantene, vil du se sprø ting som mainstream ikke tar på alvor – det er der alle de spennende tingene virkelig skjer.

Vitaly: Derfor, for å være en veldig kjent forsker, måtte jeg finne opp min egen arkitektur :)

Maurice: Du kan "stjele" andres nye arkitektur - det virker mye enklere!

Jobber ved Brown University

Vitaly: Kan du fortelle oss mer om Brown Universityhvor jobber du? Ikke mye er kjent om ham i sammenheng med informasjonsteknologi. Mindre enn om MIT, for eksempel.

Maurice: Brown University er et av de eldste universitetene i USA. Jeg tror bare Harvard er litt eldre. Brown er en del av den såkalte Ivy League, som er en samling av åtte eldste universiteter. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Det er liksom et gammelt, lite og litt aristokratisk universitet. Hovedfokuset er på liberal kunstutdanning. Det prøver ikke å være som MIT, MIT er veldig spesialisert og teknisk. Brown er et flott sted å studere russisk litteratur eller klassisk gresk, og selvfølgelig informatikk. Den fokuserer på omfattende utdanning. De fleste av studentene våre går til Facebook, Apple, Google – så jeg tror studentene våre ikke har noen problemer med å finne en jobb i bransjen. Jeg gikk på jobb hos Brown fordi jeg tidligere hadde jobbet i Digital Equipment Corporation i Boston. Dette var et selskap som fant opp mange interessante ting, men benektet viktigheten av personlige datamaskiner. Et selskap med en vanskelig skjebne, hvis grunnleggere en gang var unge revolusjonære, de lærte ingenting og glemte ingenting, og så gikk de fra revolusjonære til reaksjonære i løpet av et dusin år. De likte å spøke med at personlige datamaskiner hørte hjemme i garasjen - en forlatt garasje, selvfølgelig. Det er helt åpenbart at de ble ødelagt av mer fleksible selskaper. Da det ble klart at selskapet var i trøbbel, ringte jeg en venn av meg i Brown, som ligger omtrent en time utenfor Boston. Jeg ønsket ikke å forlate Boston på den tiden fordi det ikke var mange åpninger ved andre universiteter. Dette var en tid da det ikke var så mange jobber innen informatikk som det er nå. Og Brown hadde en åpning, jeg trengte ikke å flytte hjem, jeg trengte ikke å flytte familien min, og jeg elsker virkelig å bo i Boston! Det var slik jeg bestemte meg for å gå til Brown. Jeg liker det. Elevene er fantastiske, så jeg har aldri prøvd å gå et annet sted. I løpet av sabbatsperioden jobbet jeg i Microsoft i ett år, gikk på Technion i Haifa i et år, og nå skal jeg være i Algorand. Jeg har mange kolleger overalt og derfor er ikke den fysiske plasseringen av klasserommene våre så viktig. Men det viktigste er elevene, de er best her. Jeg har aldri prøvd å gå et annet sted fordi jeg er ganske fornøyd her.

Til tross for Browns berømmelse i USA, er han overraskende ukjent i utlandet. Som du kan se, gjør jeg nå alt jeg kan for å rette opp denne tilstanden.

Forskjellen mellom forskning ved et universitet og innenfor et selskap

Vitaly: Ok, neste spørsmål er om digitalt utstyr. Du var der som forsker. Hva er forskjellen mellom å jobbe i FoU-avdelingen i et stort selskap og å jobbe ved et universitet? Hva er fordelene og ulempene?

Maurice: I tjue år jobbet jeg i Microsoft, jobbet tett med ansatte i Sun Microsystems, Oracle, Facebook og nå Algorand. På bakgrunn av alt dette vil jeg si at det er mulig å drive førsteklasses forskning både i bedrifter og ved universiteter. Den viktige forskjellen er at man i en bedrift jobber med kollegaer. Hvis jeg plutselig har en idé til et prosjekt som ennå ikke eksisterer, må jeg overbevise mine jevnaldrende om at dette er en god idé. Hvis jeg er på Brown, kan jeg fortelle elevene mine: la oss jobbe med antigravitasjon! De vil enten reise til noen andre eller ta på seg et prosjekt. Ja, jeg må finne finansiering, jeg må skrive en stipendsøknad og så videre. Uansett vil det alltid være mange studenter, og man vil kunne ta avgjørelser ensidig. Men på universitetet vil du mest sannsynlig ikke jobbe med folk på ditt nivå. I en verden av industriell forskning må du først overbevise alle om at prosjektet ditt er verdt å ta fatt på. Jeg kan ikke bestille noe til noen. Og begge disse måtene å jobbe på er verdifulle, for hvis du jobber med noe virkelig sprøtt og kollegene dine er vanskelige å overbevise, er det lettere å overbevise avgangsstudenter – spesielt hvis du betaler dem. Hvis du jobber med noe som krever mye erfaring og dyp ekspertise, så trenger du kollegaer som kan si «nei, det hender at jeg forstår på dette området og ideen din er dårlig, den vil ikke fungere.» Dette er veldig nyttig med tanke på å kaste bort tid. Dessuten, hvis du i industrielle laboratorier bruker mye tid på å skrive rapporter, bruker du denne tiden på et universitet på å finne penger. Hvis jeg vil at studenter skal kunne gå et sted, må jeg finne pengene til det et annet sted. Og jo viktigere posisjonen din ved universitetet er, jo mer tid må du bruke på å samle inn penger. Så nå vet du hva jeg jobber for - en profesjonell tigger! Som en av de munkene som går rundt med en offerplate. Generelt utfyller disse to aktivitetene hverandre. Det er derfor jeg prøver å leve og holde føttene på bakken i begge verdener.

Vitaly: Det ser ut til at det er vanskeligere å overbevise et selskap enn å overbevise andre forskere.

Maurice: Vanskeligere, og mye mer. Dessuten er det forskjellig på forskjellige områder: noen driver fullskala forskning, mens andre fokuserer på emnet sitt. Hvis jeg gikk til Microsoft eller Facebook og sa: la oss lage antigravitasjon, ville de neppe satt pris på det. Men hvis jeg sa nøyaktig det samme til avgangsstudentene mine, ville de mest sannsynlig komme i jobb med en gang, selv om jeg nå ville få problemer - jeg må tross alt finne penger til dette. Men så lenge du ønsker å gjøre noe som er i tråd med selskapets mål, kan det selskapet være et veldig bra sted å forske.

Hydra og SPTDC

Vitaly: Spørsmålene mine nærmer seg slutten, så la oss snakke litt om den kommende turen til Russland.

Maurice: Ja, jeg gleder meg til å reise tilbake til St. Petersburg.

Alexey: Jeg er beæret over å ha deg med oss ​​i år. Dette er andre gang du er i St. Petersburg, ikke sant?

Maurice: Allerede den tredje!

Alexey: Jeg forstår, men SPTDC – definitivt den andre. Sist gang ble skolen ringt SPTCC, har vi nå endret én bokstav (C til D, Concurrent to Distributed) for å understreke at det er flere områder spesielt knyttet til distribuert databehandling i år. Kan du si noen ord om rapportene dine på skolen og Hydra konferanse?

Maurice: På skolen vil jeg snakke om det grunnleggende om blokkjede og hva du kan gjøre med det. Jeg vil gjerne vise at blokkjeder ligner veldig på den flertrådede programmeringen vi er kjent med, men med sine egne nyanser, og disse forskjellene er viktige å forstå. Hvis du gjør en feil i en vanlig nettapplikasjon, er det bare irriterende. Hvis du skriver buggy-kode i en finansapplikasjon, vil noen definitivt stjele alle pengene dine. Dette er helt forskjellige nivåer av ansvar og konsekvenser. Jeg skal snakke litt om proof-of-work, om smarte kontrakter, om transaksjoner mellom ulike blokkjeder.

Det vil være andre foredragsholdere som jobber ved siden av meg som også har noe å si om blockchain, og vi ble enige om å koordinere med hverandre slik at historiene våre passer godt sammen. Men for ingeniørrapporten vil jeg fortelle et bredt publikum en forståelig forklaring på hvorfor du ikke skal tro alt du hører om blokkjeder, hvorfor blokkjeder er et flott felt, hvordan det passer inn med andre kjente ideer, og hvorfor vi frimodig bør se til fremtiden.

Alexey: I tillegg vil jeg si at dette ikke vil finne sted i formatet til en treff- eller brukergruppe, slik det var for to år siden. Vi bestemte oss for å holde en liten konferanse i nærheten av skolen. Årsaken er at etter å ha kommunisert med Peter Kuznetsov, innså vi at skolen er begrenset til bare hundre, kanskje 120 personer. Samtidig er det mange ingeniører som ønsker å kommunisere med deg, delta på presentasjoner og generelt er interessert i temaet. Derfor har vi opprettet en ny konferanse kalt Hydra. Forresten, noen ideer om hvorfor Hydra?

Maurice: Fordi det blir syv foredragsholdere? Og hodene deres kan kuttes av, og nye høyttalere vil vokse i stedet for dem?

Alexey: Flott idé for å utvikle nye høyttalere. Men faktisk er det en historie her. Husk legenden om Odyssevs, hvor han måtte seile mellom Scylla og Charybdis? Hydra er noe sånt som Charybdis. Historien er at jeg en gang snakket på en konferanse og snakket om multithreading. Det var bare to spor på denne konferansen. I begynnelsen av reportasjen fortalte jeg publikum i salen at de nå har et valg mellom Scylla og Charybdis. Åndedyret mitt er Charybdis fordi Charybdis har mange hoder og temaet mitt er flertråding. Slik vises navn på konferanser.

Vi har uansett gått tom for spørsmål og tid. Så takk, venner, for et flott intervju, og vi sees på SPTDC School og Hydra 2019!

Du kan fortsette samtalen med Maurice på Hydra 2019-konferansen, som avholdes 11.-12. juli 2019 i St. Petersburg. Han kommer med en rapport "Blokkjeder og fremtiden for distribuert databehandling". Billetter kan kjøpes på den offisielle hjemmesiden.

Kilde: www.habr.com