- eienaar van twee. Die eerste een is vir werk aan (Brown University) en die tweede, meer onlangse, - (Virginia Tech University). Die Dijkstra-prys word gegee vir werk waarvan die betekenis en invloed reeds vir minstens tien jaar sigbaar is en Maurice is uiteraard een van die bekendste spesialiste op die gebied. Hy werk tans as professor by Brown Universiteit en het talle prestasies wat 'n paragraaf lank is. Hy doen tans navorsing oor blokketting in die konteks van klassieke verspreide rekenaars.
Voorheen het Maurice reeds na Rusland gekom vir SPTCC () en het 'n uitstekende vergadering van die JUG.ru Java-ontwikkelaargemeenskap in St. Petersburg ().
Hierdie habrapost is 'n wonderlike onderhoud met Maurice Herlihy. Dit bespreek die volgende onderwerpe:
- Interaksie tussen akademie en industrie;
- Stigting vir Blockchain Navorsing;
- Waar kom deurbraak idees vandaan? Die invloed van gewildheid;
- PhD onder leiding van Barbara Liskov;
- Die wêreld wag vir multi-kern;
- ’n Nuwe wêreld bring nuwe probleme. NVM, NUMA en argitektuur inbraak;
- Samestellers vs verwerkers, RISC vs CISC, gedeelde geheue vs boodskapoordrag;
- Die kuns om brose multi-threaded kode te skryf;
- Hoe om studente te leer om komplekse multi-draad kode te skryf;
- Nuwe uitgawe van die boek "The Art of Multiprocessor Programming";
- Hoe transaksionele geheue uitgevind is;
- Waarom dit die moeite werd is om navorsing op die gebied van verspreide rekenaars te doen;
- Het die ontwikkeling van algoritmes gestop, en hoe om voort te gaan;
- Werk by Brown Universiteit;
- Die verskil tussen navorsing by 'n universiteit en binne 'n korporasie;
- Hydra en SPTDC.
Die onderhoud word gevoer deur:
Vitaly Aksenov - tans, na-doktor by IST Oostenryk en werknemer van die Departement Rekenaartegnologie aan ITMO Universiteit. Doen navorsing in die veld van teorie en praktyk van mededingende datastrukture. Voordat hy by IST gewerk het, het hy sy PhD van Parys Diderot Universiteit en ITMO Universiteit ontvang onder leiding van professor Peter Kuznetsov.
Alexey Fedorov - Vervaardiger by JUG Ru Group, 'n Russiese maatskappy wat konferensies vir ontwikkelaars reël. Alexey het deelgeneem aan die voorbereiding van meer as 50 konferensies, en sy CV bevat alles van die posisie van 'n ontwikkelingsingenieur by Oracle (JCK, Java Platform Group) tot die posisie van 'n ontwikkelaar by Odnoklassniki.
Vladimir Sitnikov - Ingenieur by Netcracker. Tien jaar se werk aan die werkverrigting en skaalbaarheid van NetCracker OS, sagteware wat deur telekommunikasie-operateurs gebruik word om netwerk- en netwerktoerustingbestuursprosesse te outomatiseer. Stel belang in Java en Oracle Database prestasie kwessies. Skrywer van meer as 'n dosyn prestasieverbeterings in die amptelike PostgreSQL JDBC-bestuurder.
Interaksie tussen akademie en industrie
Alexey: Maurice, jy werk al baie lank in 'n akademiese omgewing en die eerste vraag is die interaksie tussen die akademiese en industriële sfere. Kan jy praat oor hoe interaksies tussen hulle onlangs verander het? Wat het 20-30 jaar gelede gebeur en wat gebeur nou?
Maurice: Ek het nog altyd probeer om nou saam met kommersiële maatskappye te werk omdat hulle interessante probleme het. Hulle stel as 'n reël nie baie belang in die publikasie van hul resultate of in gedetailleerde verduidelikings van hul probleme aan die wêreldgemeenskap nie. Hulle stel net daarin belang om hierdie probleme op te los. Ek het vir 'n geruime tyd vir sulke maatskappye gewerk. Ek het vyf jaar voltyds in 'n navorsingslaboratorium by Digital Equipment Corporation gewerk, wat vroeër 'n groot rekenaarmaatskappy was. Ek het een dag per week by Sun, by Microsoft, by Oracle gewerk, en 'n bietjie werk by Facebook gedoen. Nou gaan ek op 'n sabbatsverlof ('n professor by 'n Amerikaanse universiteit mag so 'n jaar lank so 'n verlof neem so een keer elke ses jaar) en werk in , dit is 'n cryptocurrency-maatskappy in Boston. Om nou met maatskappye saam te werk was nog altyd 'n plesier, want dit is hoe jy leer oor nuwe en interessante dinge. Jy kan selfs die eerste of tweede persoon wees wat 'n artikel oor 'n gekose onderwerp publiseer, eerder as om te werk aan die inkrementele verbetering van oplossings vir probleme waaraan almal reeds werk.
Alexey: Kan jy ons in meer besonderhede vertel hoe dit gebeur?
Maurice: Natuurlik. Jy weet, toe ek by die Digital Equipment Corporation gewerk het, ek en Elliot Moss, het ons transaksionele geheue uitgevind. Dit was 'n baie vrugbare tydperk toe almal in inligtingstegnologie begin belangstel het. Parallelisme, insluitend, hoewel meerkernstelsels nog nie bestaan het nie. Tydens die Son- en Oracle-dae het ek baie aan parallelle datastrukture gewerk. By Facebook het ek aan hul blokkettingprojek gewerk, waaroor ek nie kan praat nie, maar ek hoop dit word binnekort openbaar. Volgende jaar, by Algorand, sal ek in 'n navorsingsgroep werk wat slim kontrakte bestudeer.
Alexey: Blockchain het die afgelope paar jaar 'n baie gewilde onderwerp geword. Sal dit jou navorsing help? Miskien sal dit dit makliker maak om toelaes te verkry of toegang tot hulpbronne te verskaf van maatskappye wat in die bedryf werksaam is?
Maurice: Ek het reeds 'n klein toekenning van die Ethereum Foundation ontvang. Die gewildheid van blockchain is baie nuttig om studente te inspireer om in hierdie veld te werk. Hulle stel baie daarin belang en is opgewonde om betrokke te raak, maar soms besef hulle nie dat die navorsing wat na buite opwindend klink, werklik harde werk behels nie. Ek is egter baie opgewonde om al hierdie mistiek rondom blokketting te gebruik om studente te help lok.
Maar dit is nie al nie. Ek is op die adviesraad van verskeie blockchain-opstarters. Sommige van hulle sal dalk slaag, sommige van hulle dalk nie, maar dit is altyd baie interessant om hul idees te sien, dit te bestudeer en mense te adviseer. Die opwindendste ding is wanneer jy mense waarsku om nie iets te doen nie. Baie dinge lyk aanvanklik na 'n goeie idee, maar is dit regtig?
Stigting vir Blockchain Navorsing
Vitaly: Sommige mense dink dat die toekoms by die blokketting en sy algoritmes lê. En ander mense sê dit is net nog 'n borrel. Kan jy jou mening oor hierdie saak deel?
Maurice: Baie van wat in die blokkettingwêreld aangaan, is verkeerd, sommige is net 'n bedrogspul, baie is oorskat. Ek dink egter daar is 'n stewige wetenskaplike basis vir hierdie studies. Die feit dat die blokkettingwêreld vol ideologiese verskille is, wys die vlak van opgewondenheid en toewyding. Aan die ander kant is dit nie besonder voordelig vir wetenskaplike navorsing nie. Nou, as jy 'n artikel publiseer wat oor die tekortkominge van 'n bepaalde algoritme praat, is die gevolglike reaksie nie altyd ten volle wetenskaplik nie. Dikwels gooi mense hul emosies uit. Ek dink dat hierdie soort opwinding in hierdie gebied vir sommige aantreklik mag lyk, maar op die ou end is daar werklike wetenskaplike en ingenieurskwessies wat aangespreek moet word. Daar is baie rekenaarwetenskap hier.
Vitaly: So jy probeer die grondslag lê vir blokkettingnavorsing, nie waar nie?
Maurice: Ek probeer die grondslag lê vir 'n stewige, wetenskaplik en wiskundig verantwoorde dissipline. En deel van die probleem is dat jy soms sommige van die te harde standpunte van ander mense moet weerspreek en dit ignoreer. Soms vra mense hoekom ek in ’n gebied werk waar net terroriste en dwelmsmokkelaars belangstel. So 'n reaksie is so betekenisloos soos die gedrag van volgelinge wat blindelings jou woorde herhaal. Ek dink die waarheid is iewers in die middel. Blockchain sal 'n groot impak op die samelewing en die globale ekonomie hê. Maar dit sal waarskynlik nie gebeur danksy moderne tegnologie nie. Moderne tegnologieë sal ontwikkel en wat in die toekoms blokketting genoem sal word, sal baie belangrik word. Dit lyk dalk nie eens soos moderne blokkettings nie, dit is 'n ope vraag.
As mense nuwe tegnologie uitvind, sal hulle voortgaan om dit blokketting te noem. Ek bedoel, net soos vandag se Fortran niks te doen het met die Fortran-taal uit die 1960's nie, maar almal bly dit Fortran noem. Dieselfde vir UNIX. Wat "blockchain" genoem word, sal steeds sy revolusie maak. Maar ek twyfel of hierdie nuwe blokketting iets sal wees soos wat almal vandag geniet om te gebruik.
Waar kom deurbraak idees vandaan? Impak van gewildheid
Alexey: Het die gewildheid van blockchain gelei tot nuwe resultate vanuit 'n wetenskaplike oogpunt? Meer interaksie, meer studente, meer maatskappye in die omgewing. Is daar reeds enige resultate van hierdie toename in gewildheid?
Maurice: Ek het hierin belang gestel toe iemand vir my 'n amptelike strooibiljet oorhandig het vir 'n maatskappy wat pas nogal baie geld ingesamel het. Dit het geskryf oor , waarmee ek meer as vertroud is. Wat in die pamflet geskryf is, was duidelik tegnies verkeerd. Die mense wat dit alles geskryf het, het nie regtig die model agter die probleem verstaan nie... en tog het hierdie maatskappy baie geld ingesamel. Daarna het die maatskappy stilweg hierdie pamflet vervang met 'n baie meer korrekte weergawe - en ek sal nie sê wat die naam van hierdie maatskappy was nie. Hulle is nog steeds rond en doen baie goed. Hierdie voorval het my oortuig dat, eerstens, blockchain bloot 'n vorm van verspreide rekenaar is. Tweedens was die toegangsdrempel (ten minste toe, vier jaar gelede) redelik laag. Die mense wat in hierdie veld gewerk het, was baie energiek en intelligent, maar hulle het nie wetenskaplike referate gelees nie. Hulle het probeer om bekende dinge te herontdek en het dit verkeerd gedoen. Vandag het die drama minder geword.
Alexey: Dit is baie interessant, want 'n paar jaar gelede het ons 'n ander neiging gehad. Dit is 'n bietjie soos front-end-ontwikkeling, toe blaaier-gebaseerde front-end-ontwikkelaars hele tegnologieë herontdek het wat reeds gewild was in die back-end: bou stelsels, deurlopende integrasie, dinge soos dit.
Maurice: Ek stem saam. Maar dit is nie verbasend nie, want werklik deurbraak-idees kom altyd van buite die gevestigde gemeenskap. Gevestigde navorsers, veral gevestigde akademici, sal waarskynlik nie iets werklik baanbrekend doen nie. Dit is maklik om 'n referaat vir die volgende konferensie te skryf oor hoe jy die resultate van jou vorige werk effens verbeter het. Gaan na 'n konferensie, kom saam met vriende, praat oor dieselfde dinge. En die mense wat met deurbraak-idees ingebars het, kom byna altyd van buite. Hulle ken nie die reëls nie, hulle ken nie die taal nie, maar nietemin ... As jy binne 'n gevestigde gemeenskap is, raai ek jou aan om aandag te gee aan nuwe dinge, aan iets wat nie in die geheelbeeld pas nie. In 'n sekere sin kan 'n poging aangewend word om eksterne, meer vloeiende ontwikkelings te kombineer met metodes wat ons reeds verstaan. As 'n eerste stap, probeer om 'n wetenskaplike basis te vestig, en verander dit dan sodat dit toegepas kan word op nuwe deurbraak idees. Ek dink dat blockchain ideaal is om 'n vars, ontwrigtende idee te wees.
Alexey: Hoekom dink jy gebeur dit? Omdat mense "buite" geen spesifieke hindernisse inherent in die gemeenskap het nie?
Maurice: Hier is 'n patroon aan die gang. As jy die geskiedenis van die impressioniste in skilderkuns en kuns in die algemeen lees, dan het bekende kunstenaars op 'n tyd impressionisme verwerp. Hulle het gesê dit was nogal kinderagtig. 'n Generasie later het hierdie voorheen verwerpte kunsvorm die standaard geword. Wat ek in my veld sien: die uitvinders van blockchain was nie geïnteresseerd in mag nie, in die verhoging van publikasies en aanhalingsindeks, hulle wou net iets goeds doen. En so het hulle gaan sit en dit begin doen. Hulle het nie 'n sekere hoeveelheid tegniese diepte gehad nie, maar dit is reg te stel. Dit is baie moeiliker om met nuwe kreatiewe idees vorendag te kom as om onvoldoende volwasse idees reg te stel en te versterk. Danksy hierdie uitvinders het ek nou iets om te doen!
Alexey: Dit is soortgelyk aan die verskil tussen opstart- en nalatenskapprojekte. Ons erf baie beperkings van denke, hindernisse, spesiale vereistes, ensovoorts.
Maurice: 'n Goeie analogie is verspreide rekenaars. Dink aan blockchain asof dit 'n begin en verspreide rekenaars is as 'n groot, gevestigde maatskappy. Verspreide rekenaars is in die proses om verkry en saamgevoeg te word met blockchain.
PhD onder leiding van Barbara Liskov
Vitaly: Ons het nog baie vrae! Ons het na jou agtergrond gekyk en op 'n interessante feit oor jou doktorsgraad afgekom. Ja, dit was lank gelede, maar dit blyk 'n belangrike onderwerp te wees. Jy het jou PhD onder leiding van jouself ontvang ! Barbara is baie bekend in die programmeertaalgemeenskap, en 'n baie bekende persoon in die algemeen. Dit is logies dat jou navorsing op die gebied van programmeertale was. Hoe het jy oorgeskakel na parallelle rekenaars? Hoekom het jy besluit om die onderwerp te verander?
Maurice: Destyds het Barbara en haar groep net na verspreide rekenaars gekyk, wat 'n baie nuwe idee was. Daar was ook diegene wat gesê het dat verspreide rekenaars onsin is en dat rekenaars wat met mekaar kommunikeer, nutteloos is. Een van die kwessies wat aangespreek word in verspreide rekenaars wat dit onderskei van gesentraliseerde rekenaars is fouttoleransie. Na baie navorsing het ons besluit dat 'n verspreide rekenaarprogrammeertaal iets soos atoomtransaksies moet hê, want jy kan nooit seker wees dat 'n afstandoproep sal slaag nie. Sodra jy transaksies het, ontstaan die probleem van gelyktydigheidsbestuur. Toe was daar baie werk om hoogs parallelle transaksionele datastrukture te verkry. Toe, toe ek gegradueer het, het ek na en begin soek na 'n onderwerp om aan te werk. Dit het by my opgekom dat rekenaars van individuele rekenaars na netwerke van rekenaars verskuif het. Multiverwerkers sou 'n natuurlike voortsetting van vooruitgang wees - die woord "multi-kern" het nog nie bestaan nie. Ek het gedink: wat is die ekwivalent van atoomtransaksies vir 'n meerkernstelsel? Beslis nie gereelde transaksies nie, want dit is te groot en swaar. En dis hoe ek op die idee gekom het en dis hoe ek met die hele wagvrye sinchronisasie vorendag gekom het. Dit was 'n poging om die vraag te beantwoord wat die analoog is van atoomtransaksies vir 'n multiverwerkerstelsel met gedeelde geheue. Met die eerste oogopslag kan hierdie werk heeltemal anders lyk, maar eintlik is dit 'n voortsetting van dieselfde tema.
Die wêreld wag vir multi-kern
Vitaly: Jy het genoem dat daar destyds baie min multi-kern rekenaars was, nie waar nie?
Maurice: Hulle was net nie daar nie. Daar was verskeie sogenaamde simmetriese multiverwerkers, wat basies aan dieselfde bus gekoppel was. Dit het nie baie goed gewerk nie, want elke keer as 'n nuwe maatskappy iets soortgelyks geskep het, sou Intel 'n enkele verwerker vrystel wat beter is as die multiverwerker.
Alexey: Beteken dit nie dat dit in daardie antieke tye meer 'n teoretiese studie was nie?
Maurice: Dit was nie 'n teoretiese studie nie, maar eerder 'n spekulatiewe studie. Dit alles het nie gegaan oor die werk met baie stellings nie; ons het eerder hipoteses oor 'n argitektuur wat nie op daardie tydstip bestaan het nie. Dit is waarvoor navorsing is! Geen maatskappy sou so iets gedoen het nie; dit was alles iets uit die verre toekoms. Trouens, dit was die geval tot 2004, toe regte multi-kern verwerkers verskyn het. Omdat verwerkers oorverhit, kan jy die verwerker selfs kleiner maak, maar jy kan dit nie vinniger maak nie. As gevolg hiervan was daar 'n oorgang na multi-kern argitekture. En toe beteken dit dat daar skielik 'n nut was vir al die konsepte wat ons in die verlede ontwikkel het.
Alexey: Hoekom dink jy het multi-kern verwerkers eers in die XNUMX's verskyn? So hoekom is dit so laat?
Maurice: Dit is as gevolg van hardeware beperkings. Intel, AMD en ander maatskappye is baie goed om verwerkerspoed te verhoog. Toe die verwerkers op 'n stadium klein genoeg geword het dat hulle nie meer die klokspoed kon verhoog nie omdat die verwerkers sou begin uitbrand. Jy kan hulle kleiner maak, maar nie vinniger nie. Wat in hul vermoë is - in plaas van 'n baie klein verwerker, kan hulle agt, sestien of twee en dertig verwerkers in dieselfde volume van die houer pas, waar voorheen net een kon pas. Nou het jy multithreading en vinnige kommunikasie tussen hulle, want hulle deel kas. Maar jy kan hulle nie dwing om vinniger te hardloop nie – daar is ’n baie spesifieke spoedgrens. Hulle verbeter bietjie vir bietjie, maar nie meer so baie nie. Die wette van fisika het in die pad van verbeterings gestaan.
’n Nuwe wêreld bring nuwe probleme. NUMA, NVM en argitektuur inbraak
Alexey: Klink baie redelik. Met nuwe multi-kern verwerkers het nuwe probleme gekom. Het jy en jou kollegas hierdie probleme verwag? Miskien het jy hulle vooraf bestudeer? In teoretiese studies is dit dikwels nie baie maklik om sulke dinge te voorspel nie. Wanneer probleme wel voorgekom het, hoe het dit aan jou en jou kollegas se verwagtinge voldoen? Of was hulle heeltemal nuut, en jy en jou kollegas moes baie tyd spandeer om probleme op te los soos dit verskyn het?
Vitaly: Ek sal by Alexey se vraag voeg: het jy die verwerker-argitektuur korrek voorspel terwyl jy die teorie bestudeer het?
Maurice: Nie 100%. Maar ek dink ek en my kollegas het 'n goeie werk gedoen om multi-kerns met gedeelde geheue te voorspel. Ek dink ons het die probleme met die ontwikkeling van parallelle datastrukture wat sonder slotte werk, korrek voorspel. Sulke datastrukture was belangrik vir baie toepassings, hoewel nie almal nie, maar dikwels is wat jy regtig nodig het 'n nie-sluitende datastruktuur. Toe ons hulle uitgevind het, het baie aangevoer dat dit nonsens is, dat alles goed werk met slotte. Ons het redelik goed voorspel dat daar klaargemaakte oplossings vir baie programmeringsprobleme en datastruktuurprobleme sou wees. Daar was ook meer komplekse probleme, soos - ongelyke toegang tot geheue. Trouens, hulle is nie eers oorweeg tot die uitvinding van multi-kern verwerkers omdat hulle te spesifiek was. Die navorsingsgemeenskap het gewerk aan vrae wat oor die algemeen voorspelbaar was. Sommige hardewareprobleme wat met spesifieke argitekture geassosieer word, moes in die vleuels wag - trouens die voorkoms van hierdie argitekture. Niemand het byvoorbeeld regtig aan GPU-spesifieke datastrukture gewerk nie, want GPU's het toe nie bestaan nie. Alhoewel daar baie werk gedoen is aan , was hierdie algoritmes gereed vir gebruik sodra geskikte hardeware beskikbaar geword het. Dit is egter onmoontlik om alles te voorsien.
Alexey: As ek reg verstaan, is NUMA 'n soort kompromie tussen koste, prestasie en 'n paar ander dinge. Enige idees hoekom NUMA so laat uitgekom het?
Maurice: Ek dink dat NUMA bestaan as gevolg van probleme met die hardeware wat gebruik word om geheue te produseer: hoe verder die komponente is, hoe stadiger is dit om toegang daartoe te kry. Aan die ander kant is die tweede waarde van hierdie abstraksie geheue-uniformiteit. So een van die kenmerke van parallelle berekening is dat al die abstraksies effens gebreek is. As toegang heeltemal eenvormig was, sou alle geheue ewe ver wees, maar dit is ekonomies, en miskien selfs fisies, onmoontlik. Daarom ontstaan hierdie konflik. As jy jou program skryf asof geheue eenvormig is, dan sal dit heel waarskynlik korrek wees. In die sin dat dit nie verkeerde antwoorde sal gee nie. Maar haar vertoning sal ook nie die sterre uit die lug vang nie. Net so, as jy skryf Sonder om die kashiërargie te verstaan, sal die blokkering self korrek wees, maar jy kan van prestasie vergeet. In 'n sekere sin moet jy programme skryf wat bo-op 'n baie eenvoudige abstraksie leef, maar jy moet die mense wat jou daardie abstraksie gegee het uitoorlê: jy moet weet dat daar onder die abstraksie 'n hiërargie van geheue is, dat daar 'n bus tussen jou en hierdie herinnering, ensovoorts. Daar is dus 'n mate van konflik tussen individueel bruikbare abstraksies, wat ons tot baie konkrete en pragmatiese probleme lei.
Vitaly: Wat van die toekoms? Kan jy voorspel hoe verwerkers volgende sal ontwikkel? Daar is 'n idee dat een van die antwoorde transaksionele geheue is. Jy het waarskynlik nog iets in voorraad.
Maurice: Daar is 'n paar groot uitdagings wat voorlê. Een daarvan is dat koherente geheue 'n wonderlike abstraksie is, maar dit begin afbreek in spesiale gevalle. So, byvoorbeeld, NUMA is 'n lewende voorbeeld van iets waar jy kan aanhou voorgee dat eenvormige geheue bestaan. Eintlik nee, produktiwiteit sal jou laat huil. Op 'n stadium sal argitekte die idee van 'n enkele geheue-argitektuur moet laat vaar; jy kan nie vir ewig voorgee nie. Nuwe programmeringsmodelle sal nodig wees wat maklik genoeg is om te gebruik en kragtig genoeg is om die onderliggende hardeware doeltreffend te maak. Dit is 'n baie moeilike kompromie, want as jy aan programmeerders die argitektuur wys wat eintlik in die hardeware gebruik word, sal hulle mal word. Dit is te ingewikkeld en nie draagbaar nie. As jy 'n koppelvlak aanbied wat te eenvoudig is, sal die werkverrigting swak wees. Dus, baie baie moeilike afwegings sal gemaak moet word om nuttige programmeringsmodelle te verskaf wat van toepassing is op werklik groot multi-kern verwerkers. Ek is nie seker dat iemand anders as 'n spesialis in staat is om op 'n 2000-kern rekenaar te programmeer nie. En tensy jy baie gespesialiseerde of wetenskaplike rekenaars of kriptografie of iets dergeliks doen – is dit nog glad nie duidelik hoe om dit korrek te doen nie.
Nog 'n soortgelyke area is gespesialiseerde argitekture. Grafiese versnellers bestaan al lank, maar hulle het iets van 'n klassieke voorbeeld geword van hoe jy 'n gespesialiseerde tipe rekenaar kan neem en dit op 'n toegewyde skyfie kan laat loop. Dit voeg sy eie uitdagings by: hoe jy met so 'n toestel kommunikeer, hoe jy dit programmeer. Ek het onlangs aan probleme in die omgewing gewerk . Jy neem 'n klein verwerker en plak dit aan 'n groot stuk geheue vas sodat die geheue teen L1-kasspoed loop en dan met 'n toestel soos – die verwerker is besig om nuwe take in jou geheuekern te laai. Die ontwerp van datastrukture en kommunikasieprotokolle vir hierdie soort ding is nog 'n interessante voorbeeld. Dus sal pasgemaakte verwerkers en hardeware nog 'n geruime tyd verbeterings sien.
Alexey: Wat van nie-vlugtige geheue ()?
Maurice: O, dis nog 'n goeie voorbeeld! NVM sal die manier waarop ons na dinge soos datastrukture kyk, aansienlik verander. Nie-vlugtige geheue, in 'n sekere sin, beloof om dinge regtig te bespoedig. Maar dit sal die lewe nie makliker maak nie, want die meeste verwerkers, kas en registers is steeds wisselvallig. Wanneer jy na 'n ongeluk begin, sal jou toestand en die toestand van jou geheue nie presies dieselfde wees as voor die ongeluk nie. Ek is baie dankbaar vir die mense wat aan NVM werk - daar sal baie wees vir navorsers om vir 'n lang tyd te doen om korrektheidstoestande uit te vind. Berekeninge is korrek as hulle 'n ongeluk kan oorleef waarin die inhoud van kas en registers verlore gaan, maar die hoofgeheue ongeskonde bly.
Samestellers vs verwerkers, RISC vs CISC, gedeelde geheue vs boodskapversending
Vladimir: Wat dink jy van die "samestellers vs. verwerkers"-dilemma vanuit 'n instruksiestel-oogpunt? Laat ek verduidelik vir diegene wat nie op die hoogte is nie: as ons na skewe geheue of iets soortgelyks gaan, kan ons 'n baie eenvoudige stel opdragte gebruik en die samesteller vra om komplekse kode te genereer wat voordeel kan trek uit die ontdekte voordele. Of ons kan andersom gaan: implementeer komplekse instruksies en vra die verwerker om die instruksies te herrangskik en ander manipulasies daarmee te doen. Wat dink jy daarvan?
Maurice: Ek het nie regtig 'n antwoord op daardie vraag nie. Hierdie debat duur al vier dekades. Daar was 'n tyd wat tussen 'n stel opdragte en burgeroorloë is deur 'n stel bevele geveg. Vir 'n rukkie het die RISC-mense gewen, maar toe het Intel hul enjins herbou sodat 'n verminderde stel instruksies intern gebruik is, en die volle stel is ekstern uitgevoer. Dit is waarskynlik 'n onderwerp waarin elke nuwe generasie sy eie kompromieë moet vind en sy eie besluite moet neem. Dit is baie moeilik om te voorspel watter van hierdie dinge beter sal wees. So enige voorspelling wat ek maak sal waar wees vir 'n sekere tyd, en dan weer vir 'n rukkie vals, en dan weer waar.
Alexey: Hoe algemeen is dit vir die bedryf dat sommige idees vir 'n paar dekades wen en in die volgende verloor? Is daar ander voorbeelde van sulke periodieke veranderinge?
Maurice: Oor die onderwerp van verspreide rekenaars is daar mense wat in glo en mense wat in glo . Aanvanklik, in verspreide rekenaars, beteken parallelle berekening dat boodskap deurgee. Toe ontdek iemand dat dit baie makliker is om met gedeelde geheue te programmeer. Die teenoorgestelde kant het gesê dat gedeelde geheue te ingewikkeld is, want dit vereis slotte en dies meer, so dit is die moeite werd om na tale te beweeg waar niks anders as boodskap-oordrag eenvoudig bestaan nie. Iemand het gekyk na wat hieruit gekom het en gesê: "sjoe, hierdie boodskapimplementering lyk baie soos gedeelde geheue, want jy skep baie en baie van hierdie klein modules, hulle stuur boodskappe aan mekaar, en hulle almal "Kom ons maak 'n beter gedeelde geheue databasis!" Dit alles word oor en oor herhaal, en dit is onmoontlik om te sê dat een van die partye beslis reg is. Een van die kante sal altyd oorheers, want sodra een van hulle amper wen, vind mense keer op keer maniere uit om die ander te verbeter.
Die kuns om bros multithreaded-kode te skryf
Alexey: Dit is baie interessant. Byvoorbeeld, wanneer ons kode skryf, maak nie saak watter programmeertaal nie, ons moet gewoonlik abstraksies skep soos selle wat gelees en geskryf kan word. Maar om die waarheid te sê, op een of ander fisiese vlak kan dit lyk soos om 'n boodskap oor 'n hardewarebus tussen verskillende rekenaars en ander toestelle te stuur. Dit blyk dat werk op beide vlakke van abstraksie gelyktydig plaasvind.
Maurice: Dit is absoluut waar dat gedeelde geheue gebou word op boodskapversending – busse, kas, ensovoorts. Maar dit is moeilik om programme te skryf deur boodskap deur te gee, so die hardeware lieg doelbewus en maak asof jy 'n soort eenvormige geheue het. Dit sal dit vir jou makliker maak om eenvoudige, korrekte programme te skryf voordat prestasie begin verswak. Dan sal jy sê: dit lyk of dit tyd is om vriende te maak met die kas. En dan begin jy bekommerd wees oor die ligging van die kas, en van daar af gaan dit. In 'n sekere sin kap jy die abstraksie: jy weet dit is nie net plat, eenvormige geheue nie, en jy gaan daardie kennis gebruik om kasvriendelike programme te skryf. Dit is wat jy sal moet doen in werklike probleme. Hierdie konflik tussen die soet, eenvoudige, mooi abstraksie wat jy gegee is en die verskriklik komplekse implementering van die onderliggende hardeware is waar almal hul eie kompromie sal maak. Ek het 'n boek oor multiverwerkers en sinchronisasie, en op 'n stadium gaan ek 'n hoofstuk skryf oor datastrukture in java.util.samelopend. As jy na hulle kyk, dinge soos Dit is wonderlike kunswerke. (Redakteur se nota: Diegene wat vertroud is met die Java-taal moet ten minste na die implementering kyk ConcurrentSkipListMap, jy kan kyk na die skakels by и ). Maar uit my oogpunt sou dit onverantwoordelik wees om dit vir studente te wys, want so 'n datastruktuur is soort van soos 'n ou in 'n sirkus wat op 'n koord oor 'n beerput hardloop. As jy selfs een klein detail verander, sal die hele struktuur ineenstort. Hierdie kode is baie vinnig en elegant net omdat dit perfek geskryf is, maar die geringste verandering sal lei tot volledige mislukking. As ek hierdie kode as voorbeeld vir studente gee, sal hulle dadelik sê: Ek kan dit ook doen! En dan sal een of ander vliegtuig neerstort of 'n kernreaktor sal ontplof, en ek sal skuldig wees daaraan dat ek hulle te veel inligting op die verkeerde tyd gegee het.
Alexey: Toe ek 'n bietjie jonger was, het ek baie keer probeer om Doug Lee se bronkode te bestudeer, byvoorbeeld, java.util.samelopend, omdat dit oopbron is, is dit baie maklik om te vind en te probeer verstaan wat daar aangaan. Dit het nie baie goed uitgekom nie: dikwels is dit heeltemal onduidelik hoekom Doug besluit het om iets op hierdie manier te doen wanneer almal anders dit doen. Hoe verduidelik jy hierdie dinge aan jou studente? Is daar 'n spesifieke korrekte manier om spesifieke besonderhede van 'n hardekernalgoritme te beskryf, byvoorbeeld? Hoe doen jy dit?
Maurice: Tekenonderwysers het 'n cliché wat hulle eerste onthou: as jy soos Picasso wil teken, moet jy eers leer hoe om eenvoudige realistiese prente te teken, en eers as jy die reëls ken, kan jy dit begin oortree. As jy begin deur die reëls dadelik te oortree, beland jy in 'n gemors. Eerstens leer ek studente hoe om eenvoudige, korrekte kode te skryf sonder om bekommerd te wees oor prestasie. Wat ek sê is dat daar komplekse tydsberekeningskwessies hier skuil, so moenie bekommerd wees oor kas nie, moenie bekommerd wees oor geheuemodelle nie, maak net seker dat alles reg werk. Dit is reeds moeilik genoeg: moderne programmering is nie op sigself maklik nie, veral vir nuwe studente. En wanneer hulle 'n intuïsie het oor hoe om die regte programme te skryf, sê ek: kyk na hierdie twee spinlock-implementerings: een is baie stadig, en die tweede is ook nie baie nie, maar beter. Wiskundig is die twee algoritmes egter dieselfde. Trouens, een van hulle gebruik kaslokaliteit. Een van hulle loop op plaaslik gekas data, en die ander voer herhaaldelik bewerkings oor die bus uit. Jy kan nie doeltreffende kode skryf as jy nie verstaan wat dit is nie, en nie weet hoe om die abstraksie te breek en na die onderliggende struktuur te kyk nie. Maar jy sal nie dadelik kan begin om dit te doen nie. Daar is mense wat dit dadelik begin doen en in hul eie genialiteit glo, gewoonlik eindig dit sleg omdat hulle nie die beginsels verstaan nie. Niemand teken soos Picasso of skryf programme soos Doug Lee pas uit die universiteit in sy eerste week nie. Dit neem jare om hierdie vlak van kennis te bereik.
Alexey: Dit blyk dat jy die probleem in twee dele verdeel: die eerste is korrektheid, die tweede is prestasie?
Maurice: Presies. En presies in daardie volgorde. Deel van die probleem is dat nuwe studente nie verstaan dat korrektheid moeilik is om te bereik nie. Met die eerste oogopslag sê hulle: dit is natuurlik korrek, al wat oorbly is om dit te bespoedig. So soms vertel ek hulle van 'n aanvanklik verkeerde algoritme asof dit korrek is.
Hoe om studente te leer om komplekse multithreaded-kode te skryf
Alexey: Net om te sien of hulle die vangs kan aanvoel?
Maurice: Ek waarsku altyd vooraf dat ek soms verkeerde algoritmes sal voorstel. Jy moet nie mense mislei nie. Ek stel voor hulle neem die inligting met 'n greintjie sout. As ek iets vertel en sê: "kyk, dit is natuurlik korrek" - dit is 'n teken dat hulle iewers probeer om jou te mislei, en jy moet begin vrae vra. Vervolgens probeer ek studente aanmoedig om aan te hou vrae vra, en dan stel ek voor: "Wat sal gebeur as ons dinge laat soos dit is?" En hulle sien dadelik die fout. Maar om studente te oortuig dat hulle oor korrektheid moet bekommer, is baie moeiliker as wat dit met die eerste oogopslag lyk. Baie van hierdie studente kom met programmeringservaring op hoërskool, sommige het werk gekry en daar geprogrammeer, en hulle is almal vol selfvertroue. Dit is iets soos die weermag: jy moet eers hul bui verander om hulle te oortuig om geduldig te benader om probleme op te los wat opduik. Of dalk is dit soos Boeddhistiese monnike: eers leer hulle om oor korrektheid te redeneer, en sodra hulle die maniere verstaan om oor korrektheid te redeneer, word hulle toegelaat om na die volgende vlak te beweeg en oor prestasie te begin bekommer.
Alexey: Dit wil sê, jy wys soms vir studente nie-werkende voorbeelde, waardeur jy terugvoer kry wat wys of hulle die essensie van die probleem verstaan, of hulle die verkeerde kode en die verkeerde resultaat kan vind. So, maak studente jou gewoonlik gelukkig of hartseer?
Maurice: Studente vind amper altyd die fout uiteindelik. As hulle te stadig soek, vra ek leidende vrae, en hier is dit belangrik om te verstaan dat as jy hulle nooit mislei nie, hulle jou woorde onbedagsaam sal begin beskou as die uiteindelike waarheid. Dan sal hulle verveeld raak en begin aan die slaap raak terwyl hulle Facebook lees op hul skootrekenaar tydens die klas. Maar wanneer jy vooraf vir hulle sê dat hulle mislei sal word, en hulle sal dom lyk as hulle nie 'n truuk aanvoel nie, word hulle baie meer waaksaam. Dit is goed op verskillende maniere. Ek wil graag hê dat studente nie net hul begrip van die kwessie moet bevraagteken nie, maar ook die gesag van die onderwyser bevraagteken. Die idee is dat ’n student enige tyd hul hand kan opsteek en sê: Ek dink wat jy sopas gesê het is verkeerd. Dit is 'n belangrike leermiddel. Ek wil nie hê dat enige van die studente stilswyend by hulself moet sit en dink nie: dit lyk alles vol snert, maar om jou hand op te steek is te skrikwekkend, en in elk geval, hy is 'n professor, so alles wat hy sê is die waarheid. As hulle dus vooraf gewaarsku word dat nie alles wat vertel word noodwendig waar is nie, het hulle 'n aansporing om meer aandag aan die materiaal te gee. Ek maak dit duidelik dat dit goed is om jou hand op te steek en vrae te vra. Jou vraag klink dalk dom of naïef, maar dit is dikwels hoe die beste vrae ontstaan.
Alexey: Baie interessant. Gewoonlik het mense 'n soort sielkundige hindernis wat hulle nie toelaat om 'n vraag aan 'n professor te vra nie. Veral as daar baie mense in die vertrek is, en almal is bang dat die bespreking van jou dom vraag al hierdie mense se tyd sal in beslag neem. Is daar enige truuks om dit te hanteer?
Maurice: Ek stop gereeld en vra klassieke vrae. Of 'n stelling korrek sal wees, of hoe hulle die probleem wat bespreek word, sal oplos. Dit is 'n sleutelaksie, veral aan die begin van 'n les wanneer mense skaam is om selfs die kleinste ding te sê. Jy vra die studente 'n vraag en sê niks verder nie. Daar is stilte, almal raak bietjie gespanne, die spanning groei, dan skielik kan iemand dit nie verdra nie, breek af en sê die antwoord. Dit is hoe jy die situasie omdraai: om aan te hou stilbly word moeiliker en ongemakliker as om te antwoord! Dit is 'n standaard pedagogiese truuk. Elke onderwyser in die wêreld behoort te weet hoe om dit te doen.
Alexey: Nou het ons 'n uitstekende titel vir hierdie onderhoud: "dit is makliker om te antwoord as om stil te bly."
Vitaly: Laat ek weer vra. Jy werk aan topologiese bewyse. Hoe het jy selfs hierby betrokke geraak, want verspreide rekenaars en topologie is heeltemal verskillende dinge!
Maurice: Daar is 'n versteekte verband daar. Toe ek 'n student was wat wiskunde studeer het, het ek suiwer wiskunde studeer. Ek het geen werklike belangstelling in rekenaars gehad totdat my studies tot 'n einde gekom het nie en ek het gekonfronteer met die dringende behoefte om werk te soek. As student het ek algebraïese topologie bestudeer. Baie jare later, terwyl die werk aan 'n probleem genoem , Ek het grafieke gebruik om die probleem te modelleer en, soos dit destyds gelyk het, het ek 'n oplossing gevind. Jy moes net gaan sit en om die telling gaan. Probeer om 'n geskikte antwoord op hierdie grafiek te vind. Maar my algoritme het nie gewerk nie: dit het geblyk dat hy vir ewig in sirkels sou hardloop. Ongelukkig kon dit alles nie in die formele taal van grafiekteorie verduidelik word nie – die een wat alle rekenaarwetenskaplikes ken. En toe onthou ek dat ons baie jare gelede, terug in topologieklasse, die konsep gebruik het , wat 'n veralgemening van grafieke na hoër dimensies is. Toe vra ek myself af: wat sal gebeur as ons die probleem herformuleer in terme van eenvoudige komplekse? Dit het die sleuteloomblik geword. Deur 'n kragtiger formalisme te gebruik, word die probleem skielik baie eenvoudiger. Mense het lank daarteen geveg, met behulp van grafieke, maar hulle kon niks doen nie. En selfs nou kan hulle nie - die korrekte antwoord blyk nie 'n algoritme te wees nie, maar 'n bewys van die onmoontlikheid om die probleem op te los. Dit wil sê, so 'n algoritme bestaan eenvoudig nie. Maar gebaseer óf op eenvoudige komplekse óf op dinge wat mense gemaak het asof hulle nie eenvoudige komplekse beskou nie. Net omdat jy iets 'n nuwe naam noem, verloor dit nie sy wese nie.
Vitaly: Dit blyk dat jy net gelukkig was?
Maurice: Behalwe geluk, is dit ook bereidwilligheid. Dit beteken dat jy nie die "nuttelose" dinge wat jy vroeër geleer het, moet vergeet nie. Hoe meer nuttelose dinge jy leer, hoe meer idees kan jy onttrek wanneer jy voor 'n nuwe probleem te staan kom. Hierdie soort intuïtiewe patroonpassing is belangrik omdat... Kom ons doen dit, hierdie is 'n ketting: ek het eers ontdek dat die grafieke glad nie werk nie of glad nie werk nie, dit het my herinner aan iets uit die gebeure van agt jare gelede en my studentejare, toe ons al hierdie eenvoudige komplekse bestudeer het. Dit het my weer in staat gestel om my ou topologie-handboek te vind en dit weer in my kop te laai. Maar as dit nie vir daardie ou kennis was nie, sou ek nooit enige vordering gemaak het om die oorspronklike probleem op te los nie.
Nuwe uitgawe van die boek "The Art of Multiprocessor Programming"
Alexey: Jy het 'n paar woorde oor jou boek gesê. Dit is waarskynlik nie die ergste geheim dat jy die wêreld se bekendste boek oor multithreading geskryf het nie, . Dit is reeds sowat 11 jaar oud en sedertdien is dit nog net vrygestel . Gaan daar 'n tweede uitgawe wees?
Maurice: Dis goed dat jy gevra het! Dit sal binnekort wees, oor drie maande of so. Daar is nog twee skrywers, ons het baie meer materiaal bygevoeg, die afdeling oor vurk/voeg-parallelisme verbeter, 'n afdeling oor MapReduce geskryf, baie nuwe dinge bygevoeg en onnodige goed uitgegooi - iets wat baie interessant was met die skryf hiervan die eerste uitgawe, maar is vandag nie meer daar nie. Die resultaat was 'n baie ernstig hersiene boek.
Alexey: Alles is reeds gedoen, al wat oorbly is om dit vry te stel?
Maurice: 'n Paar hoofstukke kort nog werk. Ons uitgewer (wat ek dink ons al haat) probeer steeds die boodskap oordra dat ons vinniger moet werk. Ons is ver agter skedule. Teoreties kon ons hierdie boek 'n paar jaar vroeër gedoen het.
Alexey: Enige kans om 'n nuwe weergawe van die boek voor Kersfees te kry?
Maurice: Dit is ons doelwit! Maar ek het al soveel keer oorwinning voorspel dat niemand my meer glo nie. Jy moet my seker ook nie te veel vertrou in hierdie saak nie.
Alexey: In elk geval, dit is fantastiese nuus. Ek het baie van die eerste uitgawe van die boek gehou. Jy kan sê ek is 'n aanhanger.
Maurice: Ek hoop die nuwe uitgawe sal jou vurige entoesiasme waardig wees, dankie!
Hoe transaksiegeheue uitgevind is
Vitaly: Die volgende vraag gaan oor transaksionele geheue. Sover ek verstaan is jy 'n baanbreker op hierdie gebied, jy het dit uitgevind in 'n tyd toe niemand aan sulke goed gedink het nie. Hoekom het jy besluit om na hierdie veld te beweeg? Hoekom het transaksies vir jou belangrik gelyk? Het jy gedink dat hulle eendag in hardeware geïmplementeer sou word?
Maurice: Ek weet van transaksies sedert my nagraadse navorsingsdae.
Vitaly: Ja, maar dit is verskillende transaksies!
Maurice: Ek het saam met Elliott Moss gewerk aan vullisversameling wat nie blokkeer nie. Ons probleem was dat ons 'n paar woorde in die geheue atoom wou verander en dan sou die algoritmes baie eenvoudig word, en ten minste van hulle sou meer doeltreffend word. Met behulp van vir wat deur die parallelle argitektuur verskaf word, is dit moontlik om iets te doen, maar dit is baie ondoeltreffend en lelik omdat jy lae van indireksie sal moet hanteer. Ek wil geheuewoorde verander en ek moet oorskakel, want ek kan net een wyser verander, so hulle moet na 'n soort gidsagtige struktuur wys. Ons het gepraat oor hoe wonderlik dit sou wees as ons die hardeware kan verander sodat dit gelyktydige opnames kan doen. Dit lyk of Elliott dit opgemerk het: as jy na kaskoherensieprotokolle kyk, bied dit reeds die meeste van die vereiste funksionaliteit. In 'n optimistiese transaksie sal die kaskoherensieprotokol opmerk dat daar 'n tydsberekeningskonflik is en die kas sal word . Wat gebeur as jy spekulatief 'n transaksie op jou kas uitvoer en die koherensieprotokolmeganismes gebruik om konflikte op te spoor? Spekulatiewe hardeware-argitektuur was maklik om te ontwerp. So ons het daardie een geskryf oor transaksionele geheue. Terselfdertyd was die maatskappy vir wie ek gewerk het, Digital Equipment Corporation, besig om 'n nuwe 64-bis verwerker genaamd Alpha te skep. So ek het 'n aanbieding aan die Alpha-ontwikkelingsgroep oor ons wonderlike transaksiegeheue gegaan en hulle het gevra: Hoeveel bykomende inkomste sal ons maatskappy kry as ons dit alles direk by die verwerker voeg? En ek het absoluut geen antwoord hierop gehad nie, want ek is 'n tegnoloog, ek is nie 'n bemarkingspesialis nie. Ek het regtig niks gehad om te antwoord nie. Hulle was nie baie beïndruk dat ek niks weet nie.
Vitaly: Miljarde! Sê maar biljoene!
Maurice: Ja, dis wat ek moes gesê het. Nou, in die era van beginners en alles, weet ek hoe om 'n sakeplan te skryf. Dat jy 'n bietjie kan lieg oor die grootte van jou potensiële wins. Maar in daardie dae het dit naïef gelyk, so ek het net gesê: "Ek weet nie." As jy na die geskiedenis van die publikasie oor transaksiegeheue kyk, sal jy opmerk dat daar na 'n jaar verskeie verwysings daarna was, en toe het niemand hierdie artikel vir ongeveer tien jaar lank aangehaal nie. Die aanhalings het omstreeks 2004 verskyn, toe ware multi-cores verskyn het. Toe mense ontdek dat die skryf van parallelle kode geld kan maak, het nuwe navorsing begin. Ravi Rajwar , wat op een of ander manier die konsep van transaksionele geheue aan die hoofstroom bekend gestel het. (Redakteur se nota: Daar is 'n tweede weergawe van hierdie artikel, vrygestel in 2010 en vrylik beskikbaar ). Skielik het mense besef presies hoe dit alles gebruik kan word, hoe tradisionele algoritmes met slotte versnel kan word. 'n Goeie voorbeeld van iets wat in die verlede na net 'n interessante akademiese probleem gelyk het. En ja, as jy my destyds gevra het of ek dink dit alles gaan in die toekoms belangrik wees, sou ek gesê het: natuurlik, maar wanneer presies is nie duidelik nie. Miskien oor 50 jaar? In die praktyk blyk dit net 'n dekade te wees. Dis baie lekker as jy iets doen en ná net tien jaar kom mense dit agter.
Waarom dit die moeite werd is om navorsing op die gebied van verspreide rekenaars te doen
Vitaly: As ons oor nuwe navorsing praat, wat sal jy lesers adviseer – verspreide rekenaars of multi-kern en hoekom?
Maurice: Deesdae is dit maklik om 'n multi-kern verwerker te kry, maar dit is moeiliker om 'n ware verspreide stelsel op te stel. Ek het daaraan begin werk omdat ek iets anders as my PhD-tesis wou doen. Dit is die raad wat ek altyd aan nuwe studente gee: moenie 'n voortsetting van jou proefskrif skryf nie - probeer om 'n nuwe rigting in te gaan. En ook, multithreading is maklik. Ek kan eksperimenteer met my eie vurk wat op my skootrekenaar loop sonder om uit die bed te klim. Maar as ek skielik 'n werklike verspreide stelsel wou skep, sou ek baie werk moes doen, studente lok, ensovoorts. Ek is 'n lui mens en sal eerder op multi-core werk. Eksperimentering op multikernstelsels is ook makliker as om eksperimente op verspreide stelsels te doen, want selfs in 'n dom verspreide stelsel is daar te veel faktore wat beheer moet word.
Vitaly: Wat doen jy nou, ondersoek blockchain? Aan watter artikels moet jy eerste aandag gee?
Maurice: Onlangs verskyn , wat ek saam met my student, Vikram Saraf, spesiaal geskryf het vir 'n praatjie by drie weke gelede in Parys. Dit is 'n artikel oor praktiese verspreide stelsels, waarin ons voorstel om Ethereum multi-threaded te maak. Tans word slim kontrakte (kode wat op die blokketting loop) opeenvolgend uitgevoer. Ons het vroeër 'n artikel geskryf wat gepraat het oor 'n manier om spekulatiewe transaksies te gebruik om die proses te bespoedig. Ons het baie idees uit sagteware-transaksiegeheue geneem en gesê dat as jy hierdie idees deel maak van die Etherium virtuele masjien, dan sal alles vinniger werk. Maar hiervoor is dit nodig dat daar geen datakonflik in die kontrakte is nie. En toe het ons aangeneem dat daar in die werklike lewe regtig nie sulke konflikte is nie. Maar ons het geen manier gehad om uit te vind nie. Toe het dit by ons opgekom dat ons byna tien jaar van werklike kontrakgeskiedenis op ons hande gehad het, so ons het die Ethereum-blokketting gestort en onsself gevra: wat sou gebeur as hierdie historiese rekords parallel uitgevoer word? Ons het 'n aansienlike toename in spoed gevind. In die vroeë dae van Etherium het die spoed baie toegeneem, maar vandag is alles ietwat meer ingewikkeld, want daar is minder kontrakte en die waarskynlikheid van konflikte oor data wat serialisering vereis, het groter geword. Maar dit alles is eksperimentele werk met werklike historiese data. Die lekker ding van die blokketting is dat dit alles vir altyd onthou, sodat ons kan teruggaan in tyd en bestudeer wat sou gebeur het as ons verskillende algoritmes gebruik het om die kode uit te voer. Hoe sou mense in die verlede van ons nuwe idee gehou het? Sulke navorsing is baie makliker en lekkerder om te doen, want daar is 'n ding wat alles monitor en alles opteken. Dit is reeds iets wat meer soortgelyk is aan sosiologie as aan die ontwikkeling van algoritmes.
Het die ontwikkeling van algoritmes gestop en hoe om voort te gaan?
Vitaly: Tyd vir die laaste teoretiese vraag! Voel dit asof vordering in mededingende datastrukture elke jaar afneem? Dink jy ons het 'n plato bereik in ons begrip van datastrukture of sal daar 'n paar groot verbeterings wees? Miskien is daar 'n paar slim idees wat alles heeltemal kan verander?
Maurice: Ons het dalk 'n plato bereik in datastrukture vir tradisionele argitekture. Maar datastrukture vir nuwe argitekture is steeds 'n baie belowende area. As jy datastrukture wil skep vir byvoorbeeld hardewareversnellers, dan verskil die datastrukture vir 'n GPU baie van die datastrukture vir 'n SVE. Wanneer jy datastrukture vir blokkettings ontwikkel, moet jy stukke data hash en dit dan in iets soos , om vervalsing te voorkom. Daar was die afgelope tyd 'n oplewing van bedrywighede in hierdie gebied, met baie wat baie goeie werk gedoen het. Maar ek dink wat sal gebeur, is dat nuwe argitekture en nuwe toepassings tot nuwe datastrukture sal lei. Verouderde toepassings en tradisionele argitektuur - daar is dalk nie meer ruimte vir verkenning nie. Maar as jy van die gebaande pad af raak en verby die kante kyk, sal jy mal dinge sien wat die hoofstroom nie ernstig opneem nie – dis waar al die opwindende goed regtig gebeur.
Vitaly: Daarom, om 'n baie bekende navorser te wees, moes ek my eie argitektuur uitvind :)
Maurice: Jy kan iemand anders se nuwe argitektuur “steel” – dit lyk baie makliker!
Werk by Brown Universiteit
Vitaly: Kan jy ons meer vertel oor waar werk jy? Daar is nie veel oor hom bekend in die konteks van inligtingstegnologie nie. Minder as oor MIT, byvoorbeeld.
Maurice: Brown Universiteit is een van die oudste universiteite in die Verenigde State. Ek dink net Harvard is 'n bietjie ouer. Brown is deel van die sg , wat 'n versameling van agt oudste universiteite is. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Dit is soort van 'n ou, klein en 'n bietjie aristokratiese universiteit. Die hooffokus is op liberale kunste-onderwys. Dit probeer nie om soos MIT te wees nie, MIT is baie gespesialiseerd en tegnies. Brown is 'n wonderlike plek om Russiese letterkunde of Klassieke Grieks te studeer, en natuurlik Rekenaarwetenskap. Dit fokus op omvattende onderwys. Die meeste van ons studente gaan na Facebook, Apple, Google – so ek dink ons studente het geen probleme om werk in die bedryf te kry nie. Ek het by Brown gaan werk omdat ek voorheen by Digital Equipment Corporation in Boston gewerk het. Dit was 'n maatskappy wat baie interessante dinge uitgevind het, maar die belangrikheid van persoonlike rekenaars ontken het. 'n Maatskappy met 'n moeilike lot, wie se stigters eens jong revolusionêre was, hulle het niks geleer en niks vergeet nie, en so het hulle binne ongeveer 'n dosyn jaar van revolusionêre na reaksionêres verander. Hulle het graag gespot dat persoonlike rekenaars in die motorhuis hoort—natuurlik ’n verlate motorhuis. Dit is duidelik dat hulle deur meer buigsame maatskappye vernietig is. Toe dit duidelik word dat die maatskappy in die moeilikheid is, het ek 'n vriend van my in Brown, wat sowat 'n uur buite Boston is, gebel. Ek wou nie Boston op daardie stadium verlaat nie, want daar was nie baie openings by ander universiteite nie. Dit was 'n tyd toe daar nie soveel poste in Rekenaarwetenskap was soos nou nie. En Brown het 'n opening gehad, ek hoef nie my huis te skuif nie, ek hoef nie my gesin te skuif nie, en ek hou regtig daarvan om in Boston te woon! Dis hoe ek besluit het om Brown toe te gaan. Ek hou daarvan. Die studente is wonderlik, so ek het nooit eers probeer om iewers anders te gaan nie. Tydens my sabbatsverlof het ek vir 'n jaar by Microsoft gewerk, vir 'n jaar na Technion in Haifa gegaan, en nou sal ek by Algorand wees. Ek het oral baie kollegas en daarom is die fisiese ligging van ons klaskamers nie so belangrik nie. Maar die belangrikste is die studente, hulle is die beste hier. Ek het nog nooit probeer om iewers anders te gaan nie, want ek is baie gelukkig hier.
Ten spyte van Brown se roem in die Verenigde State, is hy verbasend onbekend in die buiteland. Soos u kan sien, doen ek nou alles moontlik om hierdie toedrag van sake reg te stel.
Verskil tussen navorsing by 'n universiteit en binne 'n korporasie
Vitaly: Goed, die volgende vraag gaan oor digitale toerusting. Jy was daar as navorser. Wat is die verskil tussen werk in die R&D-afdeling van 'n groot maatskappy en om by 'n universiteit te werk? Wat is die voordele en nadele?
Maurice: Ek het twintig jaar lank by Microsoft gewerk, nou saamgewerk met werknemers van Sun Microsystems, Oracle, Facebook, en nou Algorand. Op grond van dit alles wil ek sê dat dit moontlik is om eersteklas navorsing sowel in maatskappye as by universiteite te doen. Die belangrike verskil is dat jy in 'n maatskappy saam met kollegas werk. As ek skielik 'n idee het vir 'n projek wat nog nie bestaan nie, moet ek my maats oortuig dat dit 'n goeie idee is. As ek by Brown is, dan kan ek vir my studente sê: kom ons werk aan antiswaartekrag! Hulle sal óf na iemand anders vertrek óf 'n projek aanpak. Ja, ek sal befondsing moet kry, ek sal 'n toelaagaansoek moet skryf, ensovoorts. Daar sal in elk geval altyd baie studente wees, en jy sal eensydig besluite kan neem. Maar op universiteit sal jy heel waarskynlik nie met mense van jou vlak werk nie. In die wêreld van industriële navorsing moet jy eers almal oortuig dat jou projek die moeite werd is om aan te pak. Ek kan vir niemand iets bestel nie. En albei hierdie maniere van werk is waardevol, want as jy aan iets regtig gek werk en jou kollegas moeilik is om te oortuig, is dit makliker om afgestudeerde studente te oortuig – veral as jy hulle betaal. As jy aan iets werk wat baie ondervinding en diepgaande kundigheid verg, dan het jy kollegas nodig wat kan sê "nee, dit gebeur net so dat ek op hierdie gebied verstaan en jou idee is sleg, dit sal nie werk nie." Dit is baie nuttig in terme van tydmors. Ook, as jy in industriële laboratoriums baie tyd spandeer om verslae te skryf, dan spandeer jy hierdie tyd in 'n universiteit om geld te vind. As ek wil hê studente moet iewers heen kan gaan, moet ek die geld daarvoor iewers anders kry. En hoe belangriker jou posisie by die universiteit is, hoe meer tyd het jy om geld in te samel. So nou weet jy waarvoor ek werk - 'n professionele bedelaar! Soos een van daardie monnike wat met 'n offerbord rondloop. Oor die algemeen vul hierdie twee aktiwiteite mekaar aan. Daarom probeer ek leef en my voete op die grond hou in albei wêrelde.
Vitaly: Dit blyk dat dit moeiliker is om 'n maatskappy te oortuig as om ander wetenskaplikes te oortuig.
Maurice: Moeiliker, en baie meer. Boonop is dit op verskillende gebiede anders: sommige doen volskaalse navorsing, terwyl ander op hul onderwerp fokus. As ek na Microsoft of Facebook gaan en sê: kom ons maak anti-swaartekrag, sal hulle dit skaars waardeer. Maar as ek presies dieselfde vir my nagraadse studente sou sê, sou hulle heel waarskynlik dadelik aan die werk kom, hoewel ek nou probleme sou hê - ek moet immers geld kry hiervoor. Maar solank jy iets wil doen wat strook met die maatskappy se doelwitte, kan daardie maatskappy ’n baie goeie plek wees om navorsing te doen.
Hydra en SPTDC
Vitaly: My vrae kom tot 'n einde, so kom ons praat 'n bietjie oor die komende reis na Rusland.
Maurice: Ja, ek sien uit daarna om terug te keer na St. Petersburg.
Alexey: Ek is bevoorreg om jou vanjaar by ons te hê. Dit is jou tweede keer in St. Petersburg, reg?
Maurice: Reeds die derde!
Alexey: Ek verstaan, maar – beslis die tweede een. Laas is die skool ontbied , het ons nou een letter verander (C na D, Gelyktydig na Verspreid) om te beklemtoon dat daar meer areas is wat spesifiek verband hou met verspreide rekenaars hierdie jaar. Kan jy 'n paar woorde sê oor jou verslae by die Skool en ?
Maurice: By die Skool wil ek praat oor die basiese beginsels van blokketting en wat jy daarmee kan doen. Ek wil graag wys dat blokkettings baie soortgelyk is aan die multi-threaded programmering waarmee ons vertroud is, maar met hul eie nuanses, en hierdie verskille is belangrik om te verstaan. As jy 'n fout in 'n gewone webtoepassing maak, is dit net irriterend. As jy karretjie-kode in 'n finansiële toepassing skryf, sal iemand beslis al jou geld steel. Dit is heeltemal verskillende vlakke van verantwoordelikheid en gevolge. Ek sal 'n bietjie praat oor bewys-van-werk, oor slim kontrakte, oor transaksies tussen verskillende blokkettings.
Daar sal ander sprekers langs my werk wat ook iets oor blockchain te sê het, en ons het ooreengekom om met mekaar te koördineer sodat ons stories goed by mekaar pas. Maar vir die ingenieursverslag wil ek vir 'n breë gehoor verstaanbare verduideliking vertel van hoekom jy nie alles moet glo wat jy oor blokkettings hoor nie, hoekom blokkettings 'n wonderlike veld is, hoe dit by ander bekende idees inpas, en hoekom ons met vrymoedigheid moet kyk na die toekoms.
Alexey: Daarbenewens wil ek sê dat dit nie sal plaasvind in die formaat van 'n ontmoeting of gebruikersgroep, soos dit twee jaar gelede was nie. Ons het besluit om 'n klein konferensie naby die skool te hou. Die rede is dat ons, nadat ons met Peter Kuznetsov gekommunikeer het, besef het dat die skool tot net honderd, miskien 120 mense beperk is. Terselfdertyd is daar baie ingenieurs wat met jou wil kommunikeer, aanbiedings wil bywoon en oor die algemeen in die onderwerp belangstel. Om hierdie rede het ons 'n nuwe konferensie geskep . Terloops, enige idees hoekom Hydra?
Maurice: Omdat daar sewe sprekers sal wees? En hul koppe kan afgekap word, en nuwe sprekers sal in hul plek groei?
Alexey: Goeie idee om nuwe sprekers te laat groei. Maar eintlik is hier 'n storie. Onthou die legende van Odysseus, waar hy tussenin moes vaar ? Hydra is iets soos Charybdis. Die storie is dat ek eenkeer by 'n konferensie gepraat het en oor multithreading gepraat het. Daar was net twee snitte by hierdie konferensie. Aan die begin van die berig het ek vir die gehoor in die saal gesê hulle het nou ’n keuse tussen Scylla en Charybdis. My geesdier is Charybdis want Charybdis het baie koppe en my tema is multi-threading. Dit is hoe die name van konferensies verskyn.
Ons het in elk geval nie meer vrae en tyd nie. So, dankie, vriende, vir 'n wonderlike onderhoud, en sien julle by SPTDC Skool en Hydra 2019!
Jy kan jou gesprek met Maurice voortsit by die Hydra 2019-konferensie, wat op 11-12 Julie 2019 in St. Petersburg gehou word. Hy sal met 'n verslag kom . Kaartjies kan gekoop word .
Bron: will.com