- proprietar a doi. Primul este pentru lucru (Brown University) și al doilea, mai recent, - (Universitatea Tehnică din Virginia). Premiul Dijkstra este acordat pentru lucrări a căror semnificație și influență sunt vizibile de cel puțin zece ani și Maurice este, evident, unul dintre cei mai cunoscuți specialiști în domeniu. În prezent lucrează ca profesor la Universitatea Brown și are numeroase realizări care sunt lungi de un paragraf. În prezent, cercetează blockchain-ul în contextul calculului distribuit clasic.
Anterior, Maurice venise deja în Rusia pentru SPTCC () și a făcut o întâlnire excelentă a comunității de dezvoltatori Java JUG.ru din Sankt Petersburg ().
Acest habrapost este un interviu grozav cu Maurice Herlihy. Se discută următoarele subiecte:
- Interacțiunea dintre mediul academic și industrie;
- Fundația pentru Cercetare Blockchain;
- De unde vin ideile inovatoare? Influența popularității;
- doctorat sub supravegherea Barbara Liskov;
- Lumea așteaptă multi-core;
- O lume nouă aduce noi probleme. Hacking NVM, NUMA și arhitectură;
- Compilatoare vs procesoare, RISC vs CISC, memorie partajată vs transmitere de mesaje;
- Arta de a scrie cod fragil multi-threaded;
- Cum să-i înveți pe elevi să scrie cod complex cu mai multe fire;
- Noua ediție a cărții „The Art of Multiprocessor Programming”;
- Cum a fost inventată memoria tranzacțională;
- De ce merită să faceți cercetări în domeniul calculului distribuit;
- S-a oprit dezvoltarea algoritmilor și cum să mergi mai departe;
- Lucrează la Universitatea Brown;
- Diferența dintre cercetarea la o universitate și în cadrul unei corporații;
- Hidra și SPTDC.
Interviul este condus de:
Vitali Aksenov — în prezent, post-doctorat la IST Austria și angajat al Departamentului de Tehnologii Calculatoare a Universității ITMO. Efectuează cercetări în domeniul teoriei și practicii structurilor de date competitive. Înainte de a lucra la IST, și-a luat doctoratul de la Universitatea Paris Diderot și Universitatea ITMO sub supravegherea profesorului Peter Kuznetsov.
Alexei Fedorov - Producator la JUG Ru Group, companie ruseasca care organizeaza conferinte pentru dezvoltatori. Alexey a participat la pregătirea a peste 50 de conferințe, iar CV-ul său include totul, de la poziția de inginer de dezvoltare la Oracle (JCK, Java Platform Group) până la poziția de dezvoltator la Odnoklassniki.
Vladimir Sitnikov - Inginer la Netcracker. Zece ani de lucru pe performanța și scalabilitatea sistemului de operare NetCracker, software folosit de operatorii de telecomunicații pentru a automatiza procesele de gestionare a rețelei și a echipamentelor de rețea. Interesat de problemele de performanță Java și Oracle Database. Autor a mai mult de o duzină de îmbunătățiri ale performanței driverului oficial PostgreSQL JDBC.
Interacțiunea dintre mediul academic și industrie
Alexey: Maurice, ai lucrat foarte mult timp într-un mediu academic și prima întrebare este interacțiunea dintre sfera academică și cea industrială. Ați putea vorbi despre modul în care interacțiunile dintre ei s-au schimbat recent? Ce s-a întâmplat acum 20-30 de ani și ce se întâmplă acum?
Maurice: Am încercat întotdeauna să lucrez îndeaproape cu companii comerciale pentru că au probleme interesante. Ei, de regulă, nu sunt foarte interesați nici de publicarea rezultatelor lor, nici de explicații detaliate ale problemelor lor către comunitatea mondială. Ei sunt interesați doar să rezolve aceste probleme. Am lucrat pentru astfel de companii de ceva vreme. Am petrecut cinci ani lucrând cu normă întreagă într-un laborator de cercetare la Digital Equipment Corporation, care era o companie mare de calculatoare. Am lucrat o zi pe săptămână la Sun, la Microsoft, la Oracle și am lucrat puțin la Facebook. Acum voi pleca într-un concediu sabatic (un profesor de la o universitate americană are voie să ia un astfel de concediu timp de un an aproximativ o dată la șase ani) și voi lucra în , aceasta este o companie de criptomonede din Boston. Lucrul îndeaproape cu companiile a fost întotdeauna o plăcere pentru că așa înveți despre lucruri noi și interesante. S-ar putea să fii chiar prima sau a doua persoană care publică un articol pe un subiect ales, mai degrabă decât să lucrezi la îmbunătățirea treptată a soluțiilor la probleme la care toți ceilalți lucrează deja.
Alexey: Ne poți spune mai detaliat cum se întâmplă asta?
Maurice: Desigur. Știi, când lucram la Digital Equipment Corporation, eu și Elliot Moss, am inventat memoria tranzacțională. A fost o perioadă foarte fructuoasă când toată lumea a început să fie interesată de tehnologia informației. Paralelism, inclusiv, deși sistemele multi-core nu existau încă. În zilele Sun și Oracle, am lucrat mult la structuri de date paralele. La Facebook am lucrat la proiectul lor blockchain, despre care nu pot vorbi, dar sper să devină public în curând. Anul viitor, la Algorand, voi lucra într-un grup de cercetare care studiază contractele inteligente.
Alexey: Blockchain a devenit un subiect foarte popular în ultimii ani. Vă va ajuta acest lucru cercetarea? Poate că va facilita obținerea de granturi sau oferirea accesului la resurse de la companiile care operează în industrie?
Maurice: Am primit deja un mic grant de la Fundația Ethereum. Popularitatea blockchain-ului este foarte utilă pentru a inspira studenții să lucreze în acest domeniu. Sunt foarte interesați de asta și sunt încântați să se implice, dar uneori nu își dau seama că cercetarea care sună incitantă în exterior se dovedește a presupune o muncă foarte grea. Cu toate acestea, sunt foarte încântat să folosesc toată această mistică în jurul blockchain-ului pentru a ajuta la atragerea studenților.
Dar asta nu este tot. Sunt în consiliul consultativ al mai multor startup-uri blockchain. Unii dintre ei pot reuși, alții nu, dar întotdeauna este foarte interesant să le vezi ideile, să le studiezi și să sfătuiești oamenii. Cel mai interesant lucru este atunci când îi avertizezi pe oameni să nu facă ceva. Multe lucruri par a fi o idee bună la început, dar sunt cu adevărat?
Fundația pentru cercetarea blockchain
Vitaly: Unii oameni cred că viitorul stă în blockchain și algoritmii săi. Și alții spun că este doar o altă bulă. Puteți să vă împărtășiți părerea despre această chestiune?
Maurice: Multe din ceea ce se întâmplă în lumea blockchain sunt greșite, unele sunt doar o înșelătorie, multe sunt supraevaluate. Cu toate acestea, cred că există o bază științifică solidă pentru aceste studii. Faptul că lumea blockchain este plină de diferențe ideologice arată nivelul de entuziasm și dăruire. Pe de altă parte, acest lucru nu este deosebit de benefic pentru cercetarea științifică. Acum, dacă publicați un articol care vorbește despre deficiențele unui anumit algoritm, reacția rezultată nu este întotdeauna pe deplin științifică. De multe ori oamenii își aruncă emoțiile. Cred că acest tip de entuziasm în acest domeniu poate părea atractiv pentru unii, dar la sfârșitul zilei, există probleme științifice și de inginerie reale care trebuie abordate. Există multă informatică aici.
Vitaly: Deci încerci să pui bazele cercetării blockchain, nu?
Maurice: Încerc să pun bazele pentru o disciplină solidă, solidă din punct de vedere științific și matematic. Și o parte a problemei este că uneori trebuie să contraziceți unele dintre pozițiile prea dure ale altor oameni și să le ignorați. Uneori oamenii mă întreabă de ce lucrez într-o zonă în care sunt interesați doar teroriștii și traficanții de droguri. O astfel de reacție este la fel de lipsită de sens ca și comportamentul adepților care îți repetă orbește cuvintele. Cred că adevărul este undeva la mijloc. Blockchain-ul va avea un impact profund asupra societății și economiei globale. Dar probabil că acest lucru nu se va întâmpla datorită tehnologiei moderne. Tehnologiile moderne se vor dezvolta și ceea ce se va numi blockchain în viitor va deveni foarte important. S-ar putea să nu arate ca blocurile moderne, aceasta este o întrebare deschisă.
Dacă oamenii inventează noi tehnologii, vor continua să le numească blockchain. Adică, așa cum Fortranul de astăzi nu are nimic de-a face cu limba Fortran din anii 1960, dar toată lumea o numește Fortran. Același lucru pentru UNIX. Ceea ce se numește „blockchain” va face în continuare revoluție. Dar mă îndoiesc că acest nou blockchain va fi ceva asemănător cu ceea ce toată lumea îi place să folosească astăzi.
De unde vin ideile inovatoare? Impactul popularității
Alexey: A dus popularitatea blockchain-ului la noi rezultate din punct de vedere științific? Mai multă interacțiune, mai mulți studenți, mai multe companii în zonă. Există deja rezultate din această creștere a popularității?
Maurice: Am devenit interesat de asta când cineva mi-a înmânat un fluturaș oficial pentru o companie care tocmai strânsese destul de mulți bani. S-a scris despre , cu care sunt mai mult decât familiarizat. Ceea ce era scris în prospect era în mod clar incorect din punct de vedere tehnic. Oamenii care au scris toate astea nu prea au înțeles modelul din spatele problemei... și totuși această companie a strâns mulți bani. Ulterior, compania a înlocuit în liniște acest prospect cu o versiune mult mai corectă - și nu voi spune care era numele acestei companii. Sunt încă prin preajmă și se descurcă foarte bine. Acest incident m-a convins că, în primul rând, blockchain-ul este pur și simplu o formă de calcul distribuit. În al doilea rând, pragul de intrare (cel puțin atunci, acum patru ani) era destul de scăzut. Oamenii care lucrau în acest domeniu erau foarte energici și inteligenți, dar nu citeau lucrări științifice. Au încercat să reinventeze lucruri cunoscute și au greșit. Astăzi drama s-a diminuat.
Alexey: Este foarte interesant, pentru că acum câțiva ani aveam un alt trend. Este un pic ca dezvoltarea front-end, când dezvoltatorii front-end bazați pe browser au reinventat tehnologii întregi care erau deja populare în back-end: sisteme de construcție, integrare continuă, lucruri de genul ăsta.
Maurice: Sunt de acord. Dar acest lucru nu este surprinzător, deoarece ideile cu adevărat inovatoare vin întotdeauna din afara comunității stabilite. Cercetătorii consacrați, în special academicienii consacrați, este puțin probabil să facă ceva cu adevărat inovator. Este ușor să scrii o lucrare pentru următoarea conferință despre cum ai îmbunătățit ușor rezultatele muncii tale anterioare. Mergeți la o conferință, întâlniți-vă cu prietenii, vorbiți despre aceleași lucruri. Iar oamenii care au izbucnit cu idei inovatoare provin aproape întotdeauna din afară. Ei nu știu regulile, nu știu limba, dar totuși... Dacă te afli într-o comunitate consacrată, te sfătuiesc să fii atent la lucruri noi, la ceva care nu se încadrează în imaginea de ansamblu. Într-un fel, se poate încerca combinarea dezvoltărilor externe, mai fluide, cu metode pe care le înțelegem deja. În primul pas, încercați să stabiliți o bază științifică și apoi să o schimbați astfel încât să poată fi aplicată la idei noi inovatoare. Cred că blockchain-ul este grozav pentru a fi o idee proaspătă, disruptivă.
Alexey: De ce crezi că se întâmplă asta? Pentru că oamenii „din afară” nu au bariere specifice inerente comunității?
Maurice: Există un model care se întâmplă aici. Dacă citiți istoria impresioniștilor în pictură și în artă în general, atunci cândva artiști celebri au respins impresionismul. Au spus că a fost un fel de copilăresc. O generație mai târziu, această formă de artă respinsă anterior a devenit standardul. Ce văd în domeniul meu: inventatorii blockchain-ului nu erau interesați de putere, de creșterea publicațiilor și a indicelui de citare, au vrut doar să facă ceva bun. Și așa s-au așezat și au început să o facă. Le lipsea o anumită profunzime tehnică, dar asta se poate repara. Este mult mai dificil să vii cu idei creative noi decât să le corectezi și să le întărești pe cele insuficient mature. Datorită acestor inventatori, acum am ceva de făcut!
Alexey: Aceasta este similară cu diferența dintre startup-uri și proiectele moștenite. Moștenim multe limitări ale gândirii, bariere, cerințe speciale și așa mai departe.
Maurice: O analogie bună este calculul distribuit. Gândiți-vă la blockchain ca și cum ar fi un startup și calculatoare distribuită ca o companie mare, consacrată. Calculul distribuit este în curs de a fi achiziționat și fuzionat cu blockchain.
doctorat sub supravegherea Barbara Liskov
Vitaly: Mai avem multe întrebări! Ne-am uitat în trecutul tău și am găsit un fapt interesant despre doctoratul tău. Da, asta a fost cu mult timp în urmă, dar pare a fi un subiect important. Ți-ai primit doctoratul sub îndrumarea ta ! Barbara este foarte cunoscută în comunitatea limbajului de programare și o persoană foarte cunoscută în general. Este logic că cercetarea dumneavoastră a fost în domeniul limbajelor de programare. Cum ai trecut la calculul paralel? De ce ai decis să schimbi subiectul?
Maurice: La acea vreme, Barbara și grupul ei se uitau doar la calculul distribuit, care era o idee foarte nouă. Au fost și cei care au spus că calcularea distribuită este o prostie și că computerele care comunică între ele sunt inutile. Una dintre problemele abordate în calculul distribuit care îl deosebește de calculul centralizat este toleranța la erori. După multe cercetări, am decis că un limbaj de programare de calcul distribuit trebuie să aibă ceva de genul tranzacțiilor atomice, deoarece nu poți fi niciodată sigur că un apel la distanță va reuși. Odată ce ai tranzacții, apare problema managementului concurenței. Apoi a fost mult de lucru pentru obținerea unor structuri de date tranzacționale extrem de paralele. Apoi, când am absolvit, m-am dus la și a început să caute un subiect pe care să lucreze. Mi-a trecut prin minte că computerele s-au mutat de la calculatoare individuale la rețele de calculatoare. Multiprocesoarele ar fi o continuare firească a progresului - cuvântul „multi-core” nu exista încă. M-am gândit: care este echivalentul tranzacțiilor atomice pentru un sistem multi-core? Cu siguranță nu tranzacții obișnuite pentru că sunt prea mari și grele. Și așa mi-a venit ideea și așa am venit cu toată sincronizarea fără așteptare. Aceasta a fost o încercare de a răspunde la întrebarea care este analogul tranzacțiilor atomice pentru un sistem multiprocesor cu memorie partajată. La prima vedere, această lucrare poate părea complet diferită, dar de fapt este o continuare a aceleiași teme.
Lumea așteaptă multi-core
Vitaly: Ai menționat că la vremea aceea erau foarte puține computere multi-core, nu?
Maurice: Pur și simplu nu erau acolo. Existau mai multe așa-numite multiprocesoare simetrice, care practic erau conectate la aceeași magistrală. Acest lucru nu a funcționat foarte bine pentru că de fiecare dată când o nouă companie crea ceva similar, Intel lansa un singur procesor care era superior multiprocesorului.
Alexey: Asta nu înseamnă că în acele vremuri străvechi era mai degrabă un studiu teoretic?
Maurice: Nu a fost un studiu teoretic, ci mai degrabă un studiu speculativ. Toate acestea nu au fost despre lucrul cu multe teoreme, ci mai degrabă am înaintat ipoteze despre o arhitectură care nu exista la acea vreme. Pentru asta este cercetarea! Nicio companie nu ar fi făcut așa ceva; totul era ceva din viitorul îndepărtat. De fapt, așa a fost până în 2004, când au apărut adevărate procesoare multi-core. Deoarece procesoarele se supraîncălzi, puteți face procesorul și mai mic, dar nu îl puteți face mai rapid. Din acest motiv, a existat o tranziție la arhitecturi multi-core. Și apoi asta a însemnat că dintr-o dată a existat o utilizare pentru toate conceptele pe care le dezvoltasem în trecut.
Alexey: De ce crezi că procesoarele multi-core au apărut abia în anii XNUMX? Deci de ce este atât de târziu?
Maurice: Acest lucru se datorează limitărilor hardware. Intel, AMD și alte companii sunt foarte bune la creșterea vitezei procesorului. Când la un moment dat procesoarele au devenit suficient de mici încât să nu mai poată crește viteza de ceas pentru că procesoarele ar începe să se consume. Le poți face mai mici, dar nu mai repede. Ce stă în puterea lor - în loc de un procesor foarte mic, pot încăpea opt, șaisprezece sau treizeci și două de procesoare în același volum al carcasei, unde înainte doar unul putea încăpea. Acum aveți multithreading și comunicare rapidă între ei, deoarece partajează memoria cache. Dar nu îi poți forța să alerge mai repede - există o limită de viteză foarte specifică. Continuă să se îmbunătățească încetul cu încetul, dar nu mai mult. Legile fizicii au stat în calea îmbunătățirilor.
O lume nouă aduce noi probleme. NUMA, NVM și hacking de arhitectură
Alexey: Sună foarte rezonabil. Odată cu noile procesoare multi-core au apărut noi probleme. Tu și colegii tăi te așteptai la aceste probleme? Poate le-ai studiat dinainte? În studiile teoretice, adesea nu este foarte ușor să prezici astfel de lucruri. Când au apărut probleme, cum au îndeplinit așteptările dvs. și ale colegilor dvs.? Sau erau complet noi, iar tu și colegii tăi a trebuit să petreci mult timp rezolvând probleme pe măsură ce au apărut?
Vitaly: Voi adăuga la întrebarea lui Alexey: ai prezis corect arhitectura procesorului în timp ce studiai teoria?
Maurice: Nu 100%. Dar cred că eu și colegii mei am făcut o treabă bună predicând mai multe nuclee cu memorie partajată. Cred că am prezis corect dificultățile în dezvoltarea structurilor de date paralele care funcționează fără blocări. Astfel de structuri de date au fost importante pentru multe aplicații, deși nu pentru toate, dar adesea ceea ce aveți nevoie este o structură de date fără blocare. Când le-am inventat, mulți au susținut că asta a fost o prostie, că totul merge bine cu încuietori. Am prezis destul de bine că vor exista soluții gata făcute pentru multe probleme de programare și probleme de structura datelor. Au fost și probleme mai complexe, cum ar fi – acces neuniform la memorie. De fapt, ele nici măcar nu au fost luate în considerare până când au fost inventate procesoarele multi-core pentru că erau prea specifice. Comunitatea de cercetare lucra la întrebări care erau în general previzibile. Unele probleme hardware asociate cu arhitecturi specifice au trebuit să aștepte în aripi - de fapt, apariția acestor arhitecturi. De exemplu, nimeni nu a lucrat cu adevărat la structurile de date specifice GPU-urilor, deoarece GPU-urile nu existau atunci. Deși s-a lucrat mult , acești algoritmi au fost gata de utilizare de îndată ce hardware-ul adecvat a devenit disponibil. Cu toate acestea, este imposibil să prevăd totul.
Alexey: Dacă am înțeles bine, NUMA este un fel de compromis între cost, performanță și alte lucruri. Aveți idee de ce a apărut NUMA atât de târziu?
Maurice: Cred că NUMA există din cauza unor probleme cu hardware-ul folosit pentru a produce memorie: cu cât componentele sunt mai îndepărtate, cu atât este mai lent să le accesezi. Pe de altă parte, a doua valoare a acestei abstractizări este uniformitatea memoriei. Deci, una dintre caracteristicile calculului paralel este că toate abstracțiile sunt ușor sparte. Dacă accesul ar fi perfect uniform, toată memoria ar fi echidistantă, dar acest lucru este imposibil din punct de vedere economic și poate chiar fizic. Prin urmare, apare acest conflict. Dacă scrieți programul ca și cum memoria ar fi uniformă, atunci cel mai probabil va fi corect. În sensul că nu va da răspunsuri greșite. Dar nici spectacolul ei nu va prinde stelele de pe cer. La fel, dacă scrii Fără a înțelege ierarhia cache-ului, blocarea în sine va fi corectă, dar puteți uita de performanță. Într-un fel, trebuie să scrii programe care trăiesc pe deasupra unei abstracții foarte simple, dar trebuie să depășești oamenii care ți-au dat acea abstracție: trebuie să știi că sub abstracție există o ierarhie a memoriei, că există un autobuz între tine și această amintire și așa mai departe. Astfel, există un anumit conflict între abstracțiile utile individual, ceea ce ne duce la probleme foarte concrete și pragmatice.
Vitaly: Dar viitorul? Puteți prezice cum se vor dezvolta procesoarele în continuare? Există ideea că unul dintre răspunsuri este memoria tranzacțională. Probabil mai ai ceva in stoc.
Maurice: Urmează câteva provocări majore. Una este că memoria coerentă este o abstractizare minunată, dar începe să se destrame în cazuri speciale. Deci, de exemplu, NUMA este un exemplu viu de ceva în care puteți continua să pretindeți că există o memorie uniformă. De fapt nu, productivitatea te va face să plângi. La un moment dat, arhitecții vor trebui să abandoneze ideea unei arhitecturi de memorie unică; nu te poți preface pentru totdeauna. Vor fi necesare noi modele de programare care să fie suficient de ușor de utilizat și suficient de puternice pentru a eficientiza hardware-ul de bază. Acesta este un compromis foarte dificil, deoarece dacă le arătați programatorilor arhitectura care este de fapt folosită în hardware, ei vor înnebuni. Este prea complicat și nu este portabil. Dacă prezentați o interfață prea simplă, performanța va fi slabă. Astfel, vor trebui făcute multe compromisuri foarte dificile pentru a oferi modele de programare utile aplicabile procesoarelor cu mai multe nuclee cu adevărat mari. Nu sunt sigur că altcineva decât un specialist este capabil să programeze pe un computer cu 2000 de nuclee. Și dacă nu faci calcule foarte specializate sau științifice sau criptografie sau ceva de genul - încă nu este deloc clar cum să o faci corect.
Un alt domeniu similar este arhitecturile specializate. Acceleratoarele grafice există de mult timp, dar au devenit un exemplu clasic al modului în care puteți lua un tip specializat de calcul și îl puteți rula pe un cip dedicat. Acest lucru adaugă propriile provocări: cum comunicați cu un astfel de dispozitiv, cum îl programați. Am lucrat recent la problemele din zonă . Luați un procesor mic și îl lipiți pe o bucată imensă de memorie, astfel încât memoria să ruleze la viteza cache-ului L1 și apoi să comunice cu un dispozitiv precum – procesorul este ocupat să încarce sarcini noi în nucleul de memorie. Proiectarea structurilor de date și a protocoalelor de comunicare pentru acest tip de lucru este un alt exemplu interesant. Deci, procesoarele și hardware-ul personalizate vor continua să vadă îmbunătățiri pentru o perioadă de timp.
Alexey: Ce zici de memoria nevolatilă ()?
Maurice: Oh, acesta este un alt exemplu grozav! NVM va schimba foarte mult modul în care privim lucruri precum structurile de date. Memoria nevolatilă, într-un fel, promite să accelereze cu adevărat lucrurile. Dar nu va ușura viața, deoarece majoritatea procesoarelor, cache-urilor și registrelor sunt încă volatile. Când porniți după un accident, starea dvs. și starea memoriei dvs. nu vor fi exact aceleași ca înainte de accident. Sunt foarte recunoscător oamenilor care lucrează la NVM - vor fi multe de făcut cercetători pentru o lungă perioadă de timp încercând să descopere condițiile de corectitudine. Calculele sunt corecte dacă pot supraviețui unui accident în care conținutul cache-urilor și registrelor sunt pierdute, dar memoria principală rămâne intactă.
Compilatoare vs procesoare, RISC vs CISC, memorie partajată vs transmiterea mesajelor
Vladimir: Ce părere aveți despre dilema „compilatoare vs. procesoare” din punct de vedere al setului de instrucțiuni? Permiteți-mi să explic pentru cei care nu știu: dacă mergem la memorie distorsionată sau ceva asemănător, am putea folosi un set foarte simplu de comenzi și am putea cere compilatorului să genereze cod complex care poate profita de noile avantaje. Sau putem merge invers: implementăm instrucțiuni complexe și cere procesorului să reordoneze instrucțiunile și să facă alte manipulări cu ele. Ce crezi despre asta?
Maurice: Nu prea am un răspuns la această întrebare. Această dezbatere durează de patru decenii. A fost o vreme când între un set de comenzi şi războaiele civile au fost purtate de un set de comenzi. Pentru o vreme, oamenii RISC au câștigat, dar apoi Intel și-a reconstruit motoarele astfel încât un set redus de instrucțiuni a fost folosit intern, iar setul complet a fost exportat extern. Acesta este probabil un subiect în care fiecare nouă generație trebuie să-și găsească propriile compromisuri și să ia propriile decizii. Este foarte greu de prezis care dintre aceste lucruri va fi mai bun. Deci orice predicție pe care o fac va fi adevărată pentru o anumită perioadă de timp, apoi din nou falsă pentru un timp, și apoi din nou adevărată.
Alexey: Cât de comun este pentru industrie ca unele idei să câștige câteva decenii și să piardă în următoarele? Există și alte exemple de astfel de schimbări periodice?
Maurice: Pe tema calculului distribuit, există oameni care cred în și oameni care cred în . Inițial, în calculul distribuit, calculul paralel înseamnă transmiterea de mesaje. Apoi cineva a descoperit că era mult mai ușor de programat cu memoria partajată. Partea opusă a spus că memoria partajată este prea complicată, deoarece necesită blocări și altele asemenea, așa că merită să trecem la limbi în care nu există decât transmiterea de mesaje. Cineva s-a uitat la ce a ieșit din asta și a spus: „wow, această implementare de mesagerie seamănă mult cu memoria partajată, pentru că creezi o mulțime de aceste module mici, își trimit mesaje unul altuia și toate „Să facem o bază de date cu memorie partajată mai bună!” Toate acestea se repetă iar și iar și este imposibil de spus că una dintre părți are cu siguranță dreptate. Una dintre părți va domina întotdeauna pentru că, de îndată ce una dintre ele aproape câștigă, oamenii inventează din nou și din nou modalități de a-l îmbunătăți pe celălalt.
Arta de a scrie un cod fragil cu mai multe fire
Alexey: Este foarte interesant. De exemplu, atunci când scriem cod, indiferent de limbajul de programare, de obicei trebuie să creăm abstracții precum celulele care pot fi citite și scrise. Dar, de fapt, la un anumit nivel fizic, acest lucru poate arăta ca trimiterea unui mesaj printr-o magistrală hardware între diferite computere și alte dispozitive. Se pare că munca are loc la ambele niveluri de abstractizare simultan.
Maurice: Este absolut adevărat că memoria partajată se bazează pe transmiterea mesajelor - autobuze, cache și așa mai departe. Dar este greu să scrii programe folosind transmiterea de mesaje, așa că hardware-ul minte în mod deliberat, pretinzând că ai un fel de memorie uniformă. Acest lucru vă va face mai ușor să scrieți programe simple și corecte înainte ca performanța să înceapă să se deterioreze. Apoi vei spune: se pare că este timpul să te împrietenești cu cache-ul. Și apoi începi să-ți faci griji cu privire la locația cache-ului și de acolo merge. Într-un fel, piratați abstracția: știți că nu este doar o memorie plată și uniformă și veți folosi aceste cunoștințe pentru a scrie programe prietenoase cu memoria cache. Aceasta este ceea ce va trebui să faci în problemele reale. Acest conflict între abstractizarea dulce, simplă și plăcută care ți-a fost oferită și implementarea oribil de complexă a hardware-ului de bază este locul în care fiecare își va face propriul compromis. Am o carte despre multiprocesoare și sincronizare, iar la un moment dat aveam de gând să scriu un capitol despre structurile de date în java.util.concurrent. Dacă te uiți la ei, lucruri de genul Acestea sunt opere de artă uimitoare. (Nota editorului: cei familiarizați cu limbajul Java ar trebui cel puțin să arunce o privire asupra implementării ConcurrentSkipListMap, te poti uita la link-urile la и ). Dar din punctul meu de vedere, ar fi iresponsabil să le arăt studenților, pentru că o astfel de structură de date este un fel ca un tip dintr-un circ care alergă pe o frânghie peste o groapă pentru ursi. Dacă modificați chiar și un mic detaliu, întreaga structură se va prăbuși. Acest cod este foarte rapid și elegant doar pentru că este scris perfect, dar cea mai mică modificare va duce la eșec complet. Dacă dau acest cod ca exemplu studenților, ei vor spune imediat: și eu pot face asta! Și apoi un avion se va prăbuși sau un reactor nuclear va exploda și voi fi vinovat că le-am dat prea multe informații la momentul nepotrivit.
Alexey: Când eram puțin mai tânăr, de multe ori am încercat să studiez codul sursă al lui Doug Lee, de exemplu, java.util.concurrent, deoarece este open source, este foarte ușor să găsiți și să încercați să înțelegeți ce se întâmplă acolo. Nu a ieșit foarte bine: de multe ori, este complet neclar de ce Doug a decis să facă ceva în acest fel când toți ceilalți o fac diferit. Cum explicați aceste lucruri studenților dvs.? Există o modalitate corectă anume de a descrie detaliile specifice ale unui algoritm hardcore, de exemplu? Cum faci acest lucru?
Maurice: Profesorii de desen au un clișeu pe care și-l amintesc mai întâi: dacă vrei să desenezi ca Picasso, mai întâi trebuie să înveți cum să desenezi imagini simple realiste și doar când știi regulile poți începe să le încalci. Dacă începi prin a încălca regulile imediat, ajungi în mizerie. În primul rând, îi învăț pe elevi cum să scrie cod simplu și corect, fără a-ți face griji cu privire la performanță. Ceea ce spun este că există probleme complexe de sincronizare care pândesc aici, așa că nu vă faceți griji pentru cache, nu vă faceți griji pentru modelele de memorie, asigurați-vă doar că totul funcționează corect. Acest lucru este deja destul de dificil: programarea modernă nu este ușoară în sine, mai ales pentru studenții noi. Și când au o intuiție despre cum să scrie programele potrivite, spun: uitați-vă la aceste două implementări spinlock: una este foarte lentă, iar a doua nu este, de asemenea, foarte, dar mai bună. Cu toate acestea, din punct de vedere matematic, cei doi algoritmi sunt aceiași. De fapt, unul dintre ele folosește localitatea cache. Unul dintre ele rulează pe date stocate local în cache, iar celălalt efectuează în mod repetat operațiuni pe magistrală. Nu poți scrie cod eficient dacă nu înțelegi ce este și nu știi cum să spargi abstracția și să te uiți la structura de bază. Dar nu vei putea începe să faci asta imediat. Sunt oameni care încep să facă asta imediat și cred în propriul geniu, de obicei se termină prost pentru că nu înțeleg principiile. Nimeni nu desenează ca Picasso sau nu scrie programe precum Doug Lee proaspăt ieșit din facultate în prima sa săptămână. Este nevoie de ani pentru a atinge acest nivel de cunoștințe.
Alexey: Se pare că împărțiți problema în două părți: prima este corectitudinea, a doua este performanța?
Maurice: Exact. Și, exact în această ordine. O parte a problemei este că studenții noi nu înțeleg că corectitudinea este dificil de obținut. La prima vedere ei spun: acest lucru este în mod evident corect, tot ce rămâne este să o accelerăm. Așa că uneori le spun despre un algoritm inițial incorect de parcă ar fi corect.
Cum să-i înveți pe elevi să scrie cod complex cu mai multe fire
Alexey: Doar ca să văd dacă simt prinda?
Maurice: Întotdeauna avertizez dinainte că uneori voi propune algoritmi incorecți. Nu ar trebui să înșeli oamenii. Le sugerez să ia informațiile cu un sâmbure de sare. Dacă spun ceva și spun: „Uite, acest lucru este evident corect” - acesta este un semnal că undeva încearcă să te înșele și ar trebui să începi să pui întrebări. În continuare, încerc să încurajez elevii să pună în continuare întrebări, apoi sugerez: „Ce se va întâmpla dacă lăsăm lucrurile așa cum sunt?” Și ei văd imediat greșeala. Dar a convinge elevii că trebuie să-și facă griji cu privire la corectitudine este mult mai dificil decât pare la prima vedere. Mulți dintre acești elevi vin cu experiență în programare în liceu, unii și-au găsit locuri de muncă și au făcut programare acolo și toți sunt plini de încredere. Este ceva asemănător cu armata: mai întâi trebuie să le schimbi starea de spirit pentru a-i convinge să abordeze cu răbdare rezolvarea problemelor care apar. Sau poate este ca și călugării budiști: mai întâi învață să raționeze despre corectitudine și, odată ce înțeleg modalitățile de raționament despre corectitudine, li se permite să treacă la nivelul următor și să înceapă să-și facă griji pentru performanță.
Alexey: Adică, uneori le arăți elevilor exemple nefuncționale, datorită cărora primești feedback care arată dacă înțeleg esența problemei, dacă pot găsi codul greșit și rezultatul greșit. Deci, studenții te fac de obicei fericit sau trist?
Maurice: Studenții aproape întotdeauna găsesc greșeala în cele din urmă. Dacă caută prea încet, pun întrebări conducătoare și aici este important să înțelegi că, dacă nu-i înșeli niciodată, ei vor începe să perceapă fără minte cuvintele tale ca fiind adevărul suprem. Apoi se vor plictisi și vor începe să adoarmă în timp ce citesc Facebook pe laptop în timpul orei. Dar când le spui dinainte că vor fi păcăliți și vor părea proști dacă nu simt vreun truc, devin mult mai vigilenți. Acest lucru este bun în diferite moduri. Aș dori ca elevii să nu doar pună la îndoială înțelegerea lor asupra problemei, ci și să pună la îndoială autoritatea profesorului. Ideea este că un student poate ridica mâna în orice moment și poate spune: Cred că ceea ce tocmai ai spus este greșit. Este un instrument important de învățare. Nu vreau ca niciunul dintre studenți să stea și să se gândească în tăcere: toate acestea par o prostie completă, dar ridicarea mâinii este prea înfricoșătoare și, oricum, el este profesor, așa că tot ceea ce spune este adevărul. Prin urmare, dacă sunt avertizați în prealabil că nu tot ce s-a spus este neapărat adevărat, ei au un stimulent să acorde mai multă atenție materialului. Îți explic că este în regulă să ridici mâna și să pui întrebări. Întrebarea ta poate suna stupidă sau naivă, dar deseori așa apar cele mai bune întrebări.
Alexey: Foarte interesant. De obicei oamenii au un fel de barieră psihologică care nu le permite să pună o întrebare unui profesor. Mai ales dacă sunt mulți oameni în cameră și toată lumea se teme că a discuta despre întrebarea ta stupidă le va lua tot timpul acestor oameni. Există trucuri pentru a face față asta?
Maurice: Mă opresc adesea și pun întrebări clasice. Dacă o afirmație ar fi corectă sau cum ar rezolva problema discutată. Aceasta este o acțiune cheie, mai ales la începutul unei lecții când oamenii sunt jenați să spună chiar și cel mai mic lucru. Le pui o întrebare elevilor și nu mai spui nimic. Este tăcere, toată lumea devine puțin tensionată, tensiunea crește, apoi deodată cineva nu mai suportă, se dărâmă și spune răspunsul. Așa întoarceți situația: a continua să tăceți devine mai dificil și mai incomod decât a răspunde! Acesta este un truc pedagogic standard. Fiecare profesor din lume ar trebui să știe cum să facă asta.
Alexey: Acum avem un titlu excelent pentru acest interviu: „Este mai ușor să răspunzi decât să taci.”
Vitaly: Lasă-mă să întreb din nou. Lucrezi la dovezi topologice. Cum te-ai implicat în asta, pentru că calculul distribuit și topologia sunt lucruri complet diferite!
Maurice: Există o legătură ascunsă acolo. Când eram student la matematică, am studiat matematica pură. Nu am avut un interes real pentru calculatoare până când studiile mele s-au încheiat și m-am trezit confruntat cu nevoia stringentă de a-mi căuta un loc de muncă. Ca student am studiat topologia algebrică. Mulți ani mai târziu, în timp ce lucram la o problemă numită , am folosit grafice pentru a modela problema și, după cum părea atunci, am găsit o soluție. Trebuia doar să te așezi și să faci ocolul numărătorului. Încercați să găsiți un răspuns potrivit pe acest grafic. Dar algoritmul meu nu a funcționat: s-a dovedit că va alerga în cerc pentru totdeauna. Din păcate, toate acestea nu au putut fi explicate în limbajul formal al teoriei grafurilor - cel pe care îl cunosc toți informaticienii. Și apoi mi-am amintit că în urmă cu mulți ani, înapoi la cursurile de topologie, am folosit conceptul , care este o generalizare a graficelor la dimensiuni mai mari. Apoi m-am întrebat: ce s-ar întâmpla dacă am reformula problema în termeni de complexe simpliste? Acesta a devenit momentul cheie. Folosind un formalism mai puternic, problema devine brusc mult mai simplă. Oamenii au luptat împotriva ei mult timp, folosind grafice, dar nu au putut face nimic. Și nici acum nu pot - răspunsul corect s-a dovedit a fi nu un algoritm, ci o dovadă a imposibilității de a rezolva problema. Adică, un astfel de algoritm pur și simplu nu există. Dar bazat fie pe complexe simpliale, fie pe lucruri pe care oamenii s-au prefăcut că nu le consideră complexe simple. Doar pentru că numești ceva nou, acesta nu își pierde esența.
Vitaly: Se pare că ai fost doar norocos?
Maurice: Pe lângă noroc, este și promptitudine. Asta înseamnă că nu trebuie să uiți lucrurile „inutile” pe care le-ai învățat mai devreme. Cu cât înveți mai multe lucruri inutile, cu atât poți extrage mai multe idei atunci când te confrunți cu o nouă problemă. Acest tip de potrivire intuitivă a modelelor este important pentru că... Să facem asta, acesta este un lanț: la început am descoperit că graficele nu au funcționat deloc sau nu au funcționat deloc, mi-a amintit de ceva din evenimentele de la opt cu ani în urmă și anii mei de studenție, când am studiat toate aceste complexe simple. Acest lucru mi-a permis, la rândul său, să găsesc vechiul meu manual de topologie și să-l încarc înapoi în capul meu. Dar dacă nu ar fi fost acele vechi cunoștințe, nu aș fi făcut niciodată niciun progres în rezolvarea problemei inițiale.
Noua ediție a cărții „Arta programării multiprocesor”
Alexey: Ai spus câteva cuvinte despre cartea ta. Probabil că nu este cel mai rău secret că ai scris cea mai faimoasă carte din lume despre multithreading, . Are deja vreo 11 ani și de atunci a fost lansat doar . Va exista o a doua ediție?
Maurice: E bine că ai întrebat! Va fi foarte curând, peste trei luni și ceva. Mai sunt doi autori, am adăugat mult mai mult material, am îmbunătățit secțiunea despre paralelismul fork/join, am scris o secțiune pe MapReduce, am adăugat o mulțime de lucruri noi și am aruncat lucruri inutile - ceva care era foarte interesant la momentul scrierii. prima ediție, dar nu mai există astăzi. Rezultatul a fost o carte revizuită foarte serios.
Alexey: Totul a fost deja făcut, tot ce rămâne este să-l eliberăm?
Maurice: Câteva capitole mai necesită ceva lucru. Editorul nostru (care cred că deja ne urăște) încă încearcă să transmită mesajul că ar trebui să lucrăm mai repede. Suntem cu mult în urmă programului. Teoretic, am fi putut face această carte cu câțiva ani mai devreme.
Alexey: Vreo șansă de a obține o nouă versiune a cărții înainte de Crăciun?
Maurice: Acesta este scopul nostru! Dar am prezis victoria de atâtea ori încât nimeni nu mă mai crede. Probabil că nici în această chestiune nu ar trebui să ai prea multă încredere în mine.
Alexey: În orice caz, aceasta este o veste fantastică. Mi-a plăcut foarte mult prima ediție a cărții. Ai putea spune că sunt fan.
Maurice: Sper că noua ediție va fi demnă de entuziasmul tău fierbinte, mulțumesc!
Cum a fost inventată memoria tranzacțională
Vitaly: Următoarea întrebare este despre memoria tranzacțională. Din câte am înțeles, ești un pionier în acest domeniu, ai inventat-o într-un moment în care nimeni nu se gândea la astfel de lucruri. De ce ai decis să te muți în acest domeniu? De ce vi s-au părut importante tranzacțiile? Te-ai gândit că într-o zi vor fi implementate în hardware?
Maurice: Știu despre tranzacții din zilele mele de cercetare absolventă.
Vitaly: Da, dar acestea sunt tranzacții diferite!
Maurice: Am lucrat cu Elliott Moss la colectarea de gunoi fără blocare. Problema noastră era că am vrut să schimbăm atomic câteva cuvinte din memorie și apoi algoritmii vor deveni foarte simpli, iar măcar unii dintre ei vor deveni mai eficienți. Folosind pentru asigurată de arhitectura paralelă, se poate face ceva, dar este foarte ineficient și urât pentru că ai avea de a face cu straturi de indirectă. Vreau să schimb cuvintele de memorie și trebuie să schimb pentru că pot schimba doar un indicator, așa că trebuie să indice către un fel de structură asemănătoare directorului. Am vorbit despre cât de grozav ar fi dacă am putea schimba hardware-ul astfel încât să poată face înregistrarea simultană. Elliott pare să fi observat acest lucru: dacă te uiți la protocoalele de coerență a memoriei cache, acestea oferă deja cea mai mare parte a funcționalității necesare. Într-o tranzacție optimistă, protocolul de coerență a cache-ului va observa că există un conflict de timp și cache-ul va deveni . Ce se întâmplă dacă executați în mod speculativ o tranzacție în memoria cache și utilizați mecanismele protocolului de coerență pentru a detecta conflictele? Arhitectura hardware speculativă a fost ușor de proiectat. Așa că am scris-o pe aia despre memoria tranzacțională. În același timp, compania la care lucram, Digital Equipment Corporation, crea un nou procesor pe 64 de biți numit Alpha. Așa că m-am dus și am făcut o prezentare grupului de dezvoltare Alpha despre uimitoarea noastră memorie tranzacțională și ei au întrebat: Cât de mult venituri suplimentare ar obține compania noastră dacă am adăuga toate acestea direct la procesor? Și nu am avut absolut niciun răspuns la asta, pentru că sunt tehnolog, nu sunt specialist în marketing. Chiar nu am avut ce să răspund. Nu au fost foarte impresionați că nu știu nimic.
Vitaly: Miliarde! Spune doar miliarde!
Maurice: Da, asta ar fi trebuit să spun. Acum, în epoca startup-urilor și a altora, știu să scriu un plan de afaceri. Că poți minți puțin despre mărimea profitului tău potențial. Dar în acele zile părea naiv, așa că am spus doar: „Nu știu”. Dacă te uiți la istoria publicației despre memoria tranzacțională, vei observa că după un an au existat mai multe referințe la aceasta, iar apoi timp de aproximativ zece ani nimeni nu a citat deloc această lucrare. Citatele au apărut în jurul anului 2004, când au apărut adevărate multi-core. Când oamenii au descoperit că scrierea codului paralel poate face bani, au început noi cercetări. Ravi Rajwar , care a introdus într-un fel conceptul de memorie tranzacțională în mainstream. (Nota editorului: există o a doua versiune a acestui articol, lansată în 2010 și disponibilă gratuit ). Deodată oamenii și-au dat seama exact cum ar putea fi folosite toate acestea, cum ar putea fi accelerați algoritmii tradiționali cu încuietori. Un bun exemplu de ceva care în trecut părea doar o problemă academică interesantă. Și da, dacă m-ai fi întrebat în acel moment dacă mă gândesc că toate acestea vor fi importante în viitor, aș fi spus: desigur, dar când exact nu este clar. Poate peste 50 de ani? În practică, acesta s-a dovedit a fi doar un deceniu. E foarte frumos când faci ceva și după doar zece ani oamenii îl observă.
De ce merită să faceți cercetări în domeniul calculului distribuit
Vitaly: Dacă vorbim despre noi cercetări, ce ați sfătui cititorii - calcul distribuit sau multi-core și de ce?
Maurice: În zilele noastre este ușor să obțineți un procesor multi-core, dar este mai greu să configurați un sistem adevărat distribuit. Am început să lucrez la ele pentru că am vrut să fac ceva diferit de teza mea de doctorat. Acesta este sfatul pe care îl dau mereu noilor studenți: nu scrie o continuare a tezei tale - încearcă să mergi într-o nouă direcție. Și, de asemenea, multithreading este ușor. Pot experimenta cu propria mea furcă care rulează pe laptop fără să mă ridic din pat. Dar dacă aș fi vrut dintr-o dată să creez un sistem real distribuit, ar trebui să fac multă muncă, să atrag studenți și așa mai departe. Sunt o persoană leneșă și prefer să lucrez la multi-core. Experimentarea pe sisteme multi-core este, de asemenea, mai ușoară decât a face experimente pe sisteme distribuite, deoarece chiar și într-un sistem distribuit stupid sunt prea mulți factori care trebuie controlați.
Vitaly: Ce faci acum, cercetând blockchain-ul? La ce articole ar trebui să fii atent mai întâi?
Maurice: A apărut recent , pe care l-am scris împreună cu elevul meu, Vikram Saraf, special pentru o conferință la la Paris acum trei săptămâni. Acesta este un articol despre sistemele practice distribuite, în care propunem să facem Ethereum multi-threaded. În prezent, contractele inteligente (codul care rulează pe blockchain) sunt executate secvenţial. Am scris mai devreme un articol care vorbea despre o modalitate de a folosi tranzacțiile speculative pentru a accelera procesul. Am luat o mulțime de idei din memoria tranzacțională software și am spus că dacă faceți aceste idei parte din mașina virtuală Etherium, atunci totul va funcționa mai repede. Dar pentru aceasta este necesar ca în contracte să nu existe conflicte de date. Și apoi am presupus că în viața reală nu există într-adevăr astfel de conflicte. Dar nu aveam cum să aflăm. Apoi ne-a trecut prin minte că aveam aproape un deceniu de istorie reală a contractelor în mână, așa că am renunțat la blockchain-ul Ethereum și ne-am întrebat: ce s-ar întâmpla dacă aceste înregistrări istorice ar fi executate în paralel? Am constatat o creștere semnificativă a vitezei. În primele zile ale Ethereum, viteza a crescut foarte mult, dar astăzi totul este ceva mai complicat, pentru că sunt mai puține contracte și probabilitatea conflictelor asupra datelor care necesită serializare a devenit mai mare. Dar toate acestea sunt lucrări experimentale cu date istorice reale. Lucrul frumos despre blockchain este că își amintește totul pentru totdeauna, astfel încât să ne întoarcem în timp și să studiem ce s-ar fi întâmplat dacă am fi folosit diferiți algoritmi pentru a rula codul. Cum le-ar fi plăcut oamenilor din trecut noua noastră idee? O astfel de cercetare este mult mai ușor și mai plăcut de făcut, pentru că există un lucru care monitorizează totul și înregistrează totul. Acesta este deja ceva mai asemănător cu sociologia decât cu dezvoltarea algoritmilor.
S-a oprit dezvoltarea algoritmilor și cum să mergem mai departe?
Vitaly: E timpul pentru ultima întrebare teoretică! Se pare că progresul în structurile de date competitive scade în fiecare an? Crezi că am atins un platou în înțelegerea structurilor de date sau vor exista unele îmbunătățiri majore? Poate că există câteva idei inteligente care pot schimba complet totul?
Maurice: S-ar putea să fi atins un platou în structurile de date pentru arhitecturile tradiționale. Dar structurile de date pentru noile arhitecturi sunt încă un domeniu foarte promițător. Dacă doriți să creați structuri de date pentru, de exemplu, acceleratoare hardware, atunci structurile de date pentru un GPU sunt foarte diferite de structurile de date pentru un procesor. Când dezvoltați structuri de date pentru blockchains, trebuie să analizați fragmente de date și apoi să le puneți în ceva de genul , pentru a preveni contrafacerea. A existat o creștere a activității în acest domeniu în ultima vreme, mulți făcând o treabă foarte bună. Dar cred că ceea ce se va întâmpla este că noi arhitecturi și noi aplicații vor duce la noi structuri de date. Aplicații vechi și arhitectură tradițională - s-ar putea să nu mai fie mult loc de explorare. Dar dacă ieși din calea bătută și te uiți dincolo de margini, vei vedea lucruri nebunești pe care mainstreamul nu le ia în serios - acolo se întâmplă cu adevărat toate lucrurile interesante.
Vitaly: Prin urmare, pentru a fi un cercetător foarte celebru, a trebuit să-mi inventez propria arhitectură :)
Maurice: Poți „fura” noua arhitectură a altcuiva - pare mult mai ușor!
Lucrează la Universitatea Brown
Vitaly: Ne poți spune mai multe despre unde lucrați? Nu se știu multe despre el în contextul tehnologiei informației. Mai puțin decât despre MIT, de exemplu.
Maurice: Universitatea Brown este una dintre cele mai vechi universități din Statele Unite. Cred că doar Harvard este puțin mai în vârstă. Brown face parte din așa-numitul , care este o colecție de opt cele mai vechi universități. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Este un fel de universitate veche, mică și puțin aristocratică. Accentul principal este pe educația în arte liberale. Nu încearcă să fie ca MIT, MIT este foarte specializat și tehnic. Brown este un loc minunat pentru a studia literatura rusă sau greacă clasică și, desigur, informatica. Se concentrează pe educația cuprinzătoare. Majoritatea studenților noștri merg la Facebook, Apple, Google - așa că cred că studenții noștri nu au probleme în a găsi un loc de muncă în industrie. Am mers să lucrez la Brown pentru că anterior lucrasem la Digital Equipment Corporation din Boston. Aceasta a fost o companie care a inventat multe lucruri interesante, dar a negat importanța computerelor personale. O companie cu o soartă grea, ai cărei fondatori au fost cândva tineri revoluționari, nu au învățat nimic și nu au uitat nimic, așa că s-au transformat de la revoluționari la recționari în aproximativ o duzină de ani. Le plăcea să glumească că computerele personale aparțin unui garaj — un garaj abandonat, desigur. Este destul de evident că au fost distruse de companii mai flexibile. Când a devenit clar că compania are probleme, am sunat un prieten de-al meu din Brown, care se află la aproximativ o oră în afara Bostonului. Nu am vrut să plec la vremea aceea din Boston pentru că nu erau prea multe locuri de muncă la alte universități. Acesta a fost o perioadă în care nu erau atât de multe locuri de muncă în informatică ca acum. Și Brown a avut o deschidere, nu trebuia să-mi mut casa, nu trebuia să-mi mut familia și chiar îmi place să trăiesc în Boston! Așa am decis să merg la Brown. Imi place. Studenții sunt minunați, așa că nici măcar nu am încercat să merg altundeva. În timpul meu sabatic, am lucrat la Microsoft timp de un an, am fost la Technion din Haifa timp de un an, iar acum voi fi la Algorand. Am mulți colegi peste tot și, prin urmare, locația fizică a sălilor noastre de clasă nu este atât de importantă. Dar cel mai important lucru sunt studenții, ei sunt cei mai buni aici. Nu am încercat niciodată să merg altundeva pentru că sunt destul de fericit aici.
Cu toate acestea, în ciuda faimei lui Brown în Statele Unite, el este surprinzător de necunoscut în străinătate. După cum puteți vedea, acum fac tot posibilul pentru a corecta această stare de lucruri.
Diferența dintre cercetarea la o universitate și în cadrul unei corporații
Vitaly: Bine, următoarea întrebare este despre echipamente digitale. Ai fost acolo ca cercetător. Care este diferența dintre a lucra în departamentul de cercetare și dezvoltare al unei companii mari și a lucra la o universitate? Care sunt avantajele și dezavantajele?
Maurice: Timp de douăzeci de ani am lucrat la Microsoft, am lucrat îndeaproape cu angajații Sun Microsystems, Oracle, Facebook și acum Algorand. Pe baza tuturor acestor lucruri, vreau să spun că este posibil să se efectueze cercetări de primă clasă atât în companii, cât și în universități. Diferența importantă este că într-o companie lucrezi cu colegii. Dacă îmi vine brusc o idee pentru un proiect care nu există încă, trebuie să-mi conving colegii că aceasta este o idee bună. Dacă sunt la Brown, atunci le pot spune elevilor mei: să lucrăm la antigravitație! Fie vor pleca pentru altcineva, fie vor prelua un proiect. Da, va trebui să găsesc finanțare, va trebui să scriu o cerere de grant și așa mai departe. În orice caz, întotdeauna vor fi mulți studenți, iar tu vei putea lua decizii unilateral. Dar la universitate cel mai probabil nu vei lucra cu oameni de nivelul tău. În lumea cercetării industriale, mai întâi trebuie să-i convingi pe toți că proiectul tău merită preluat. Nu pot comanda nimic nimănui. Și ambele moduri de lucru sunt valoroase, pentru că dacă lucrezi la ceva cu adevărat nebunesc și colegii tăi sunt greu de convins, este mai ușor să convingi studenții absolvenți – mai ales dacă îi plătești. Dacă lucrezi la ceva care necesită multă experiență și expertiză profundă, atunci ai nevoie de colegi care să spună „nu, se întâmplă că înțeleg în acest domeniu și ideea ta este proastă, nu va funcționa”. Acest lucru este foarte util în ceea ce privește pierderea timpului. De asemenea, dacă în laboratoarele industriale petreci mult timp scriind rapoarte, atunci într-o universitate petreci acest timp încercând să găsești bani. Dacă vreau ca studenții să poată merge undeva, trebuie să găsesc bani pentru asta în altă parte. Și cu cât este mai importantă poziția ta la universitate, cu atât mai mult timp ai de petrecut strângând bani. Deci acum știi pentru ce lucrez - un cerșetor profesionist! Ca unul dintre acei călugări care se plimbă cu o farfurie cu ofrande. În general, aceste două activități se completează reciproc. De aceea încerc să trăiesc și să-mi țin picioarele pe pământ în ambele lumi.
Vitaly: Se pare că a convinge o companie este mai dificil decât a convinge alți oameni de știință.
Maurice: Mai dificil și mult mai mult. Mai mult, în diferite domenii este diferit: unii efectuează cercetări la scară largă, în timp ce alții se concentrează pe tema lor. Dacă m-aș duce la Microsoft sau Facebook și aș spune: să facem antigravitație, cu greu ar aprecia. Dar dacă le-aș spune exact același lucru studenților mei absolvenți, cel mai probabil s-ar apuca instantaneu de lucru, deși acum aș avea probleme - la urma urmei, trebuie să găsesc bani pentru asta. Dar atâta timp cât vrei să faci ceva care se aliniază cu obiectivele companiei, acea companie poate fi un loc foarte bun pentru a face cercetări.
Hidra și SPTDC
Vitaly: Întrebările mele se apropie de sfârșit, așa că hai să vorbim puțin despre viitoarea călătorie în Rusia.
Maurice: Da, abia aștept să mă întorc la Sankt Petersburg.
Alexey: Sunt onorat să te am alături de noi anul acesta. Este a doua oară când mergi în Sankt Petersburg, nu?
Maurice: Deja al treilea!
Alexey: Înțeleg, dar – cu siguranță al doilea. Ultima dată a fost sunat la școală , am schimbat acum o literă (C în D, Concomitent cu Distribuit) pentru a sublinia faptul că în acest an există mai multe domenii legate în mod specific de calculul distribuit. Poți spune câteva cuvinte despre rapoartele tale de la școală și ?
Maurice: La școală vreau să vorbesc despre elementele de bază ale blockchain-ului și despre ce poți face cu el. Aș dori să arăt că blockchain-urile sunt foarte asemănătoare cu programarea multi-threaded cu care suntem familiarizați, dar cu propriile nuanțe, iar aceste diferențe sunt importante de înțeles. Dacă faci o greșeală într-o aplicație web obișnuită, este doar enervant. Dacă scrieți cod bug într-o aplicație financiară, cineva vă va fura cu siguranță toți banii. Acestea sunt niveluri complet diferite de responsabilitate și consecințe. Voi vorbi puțin despre proof-of-work, despre smart contracts, despre tranzacții între diferite blockchain-uri.
Lângă mine vor lucra și alți vorbitori care au ceva de spus despre blockchain și am convenit să ne coordonăm, astfel încât poveștile noastre să se potrivească bine. Dar, pentru raportul de inginerie, vreau să ofer unui public larg o explicație înțeleasă despre de ce nu ar trebui să crezi tot ce auziți despre blockchains, de ce blockchains-urile sunt un domeniu grozav, cum se potrivește cu alte idei cunoscute și de ce ar trebui să ne uităm cu îndrăzneală. in viitor.
Alexey: În plus, vreau să spun că acest lucru nu va avea loc în formatul unei întâlniri sau al unui grup de utilizatori, așa cum a fost acum doi ani. Am decis să ținem o mică conferință lângă școală. Motivul este că, după ce am comunicat cu Peter Kuznetsov, ne-am dat seama că școala este limitată la doar o sută, poate 120 de persoane. În același timp, există o mulțime de ingineri care doresc să comunice cu tine, să participe la prezentări și, în general, sunt interesați de subiect. Din acest motiv am creat o nouă conferință . Apropo, vreo idee de ce Hydra?
Maurice: Pentru că vor fi șapte vorbitori? Și capetele lor pot fi tăiate, iar noi difuzoare vor crește în locul lor?
Alexey: O idee grozavă pentru a dezvolta noi difuzoare. Dar, de fapt, există o poveste aici. Amintiți-vă de legenda lui Ulise, unde a trebuit să navigheze între ele ? Hydra este ceva ca Charybdis. Povestea este că odată am vorbit la o conferință și am vorbit despre multithreading. Au fost doar două piese la această conferință. La începutul reportajului, le-am spus publicului din sală că acum au de ales între Scylla și Charybdis. Animalul meu spiritual este Charybdis pentru că Charybdis are multe capete și tema mea este multi-threading. Așa apar denumirile conferințelor.
În orice caz, am rămas fără întrebări și fără timp. Deci, vă mulțumesc, prieteni, pentru un interviu grozav și ne vedem la SPTDC School and Hydra 2019!
Puteți continua conversația cu Maurice la conferința Hydra 2019, care va avea loc în perioada 11-12 iulie 2019 la Sankt Petersburg. Va veni cu un raport . Biletele pot fi achiziționate .
Sursa: www.habr.com