- ca profesor de informatică la Universitatea din Rochester, iar la Universitatea sa natală din Wisconsin–Madison a fost decan timp de cinci ani. El cercetează și îi predă pe studenți despre programarea paralelă și distribuită și despre proiectarea limbajului.
Lumea îl cunoaște pe Michael din manual , ce zici de munca a primit Premiul Dijkstra ca fiind unul dintre cele mai cunoscute în domeniul calculului distribuit. S-ar putea să-l cunoști, de asemenea, drept autorul acelui algoritm .
Împreună cu Doug Lee, a dezvoltat algoritmii neblocatori și cozile sincrone care alimentează bibliotecile Java. Implementarea în JavaSE 6 a îmbunătățit performanța de 10 ori ThreadPoolExecutor.
Cuprins:
- Cariera timpurie, Universitatea din Rochester. Proiect Charlotte, limba Lynx;
- Interfață coerentă scalabilă IEEE, blocare MCS;
- Supraviețuire într-o lume în continuă schimbare;
- Studenții devin mai proști? Tendințe globale, internaționalizare;
- Lucru eficient cu elevii;
- Cum să ții pasul cu pregătirea de noi cursuri și cărți;
- Legături între mediul de afaceri și mediul academic;
- Implementarea practică a ideilor. MCS, MS, CLH, JSR 166, lucrând cu Doug Lee și multe altele;
- Memoria tranzacțională;
- Arhitecturi noi. Victoria memoriei tranzacționale este aproape;
- Memorie nevolatilă, DIMM Optane, dispozitive ultra-rapide;
- Următoarea mare tendință. Structuri de date duale. Hidra.
Interviul este condus de:
Vitali Aksenov — în prezent este postdoctorat la IST Austria și membru al Departamentului de Tehnologii Calculatoare de la Universitatea 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.
Cariera timpurie, Universitatea din Rochester. Proiectul Charlotte, limbajul Lynx.
Alexey: Pentru început, am vrut să vă spun că în Rusia cu toții ne place foarte mult Informatica, Știința datelor și algoritmii. Este de-a dreptul obscen. Am citit totul . Prin urmare, viitoarea conferință, școala și acest interviu în sine ar trebui să fie foarte populare. Am primit multe întrebări pentru acest interviu de la studenți, programatori și membri ai comunității, așa că suntem foarte recunoscători pentru această oportunitate. Informatica primeste aceeasi dragoste in SUA?
Michael: Domeniul nostru este atât de divers, are atât de multe direcții și afectează societatea în atât de multe moduri diferite încât îmi este greu să vă dau un răspuns definitiv. Dar adevărul este că a adus schimbări extraordinare în afaceri, industrie, artă și societate în general în ultimii 30 de ani.
Vitali: Să începem cu ceva îndepărtat. În multe universități există ceva de genul specializării într-un anumit domeniu. Pentru Universitatea Carnegie Mellon aceasta este calculul paralel, pentru MIT este criptografie, roboți și multithreading. Există o astfel de specializare la Universitatea din Rochester?
Michael: Sincer să fiu, aș spune că CMU și MIT sunt specializate în toate domeniile. Departamentul nostru a acordat întotdeauna cea mai mare atenție inteligenței artificiale. Jumătate dintre oamenii care lucrează pentru noi sunt implicați în AI sau interacțiunea om-calculator - această pondere este mai mare decât în alte departamente și a fost întotdeauna așa. Dar când eram la universitate, nu aveam cursuri de AI și nu am lucrat niciodată în acest domeniu. Deci departamentul meu este specializat într-o problemă cu care nu am nimic de-a face. Consolarea este că a doua cea mai importantă problemă pentru departamentul nostru este programarea paralelă și multi-threaded, adică specializarea mea.
Vitali: Ați început să lucrați în informatică atunci când domeniul programării multi-threaded tocmai a apărut. Lista publicațiilor dvs. arată că primele dvs. lucrări au tratat o gamă destul de largă de probleme: gestionarea memoriei în sisteme multi-threaded, sisteme de fișiere distribuite, sisteme de operare. De ce o asemenea versatilitate? Ați încercat să vă găsiți locul în comunitatea de cercetare?
Michael: Ca student, am participat la la Universitatea din Wisconsin, unde a fost dezvoltat unul dintre primele sisteme de operare distribuite. Acolo am lucrat împreună cu Rafael Finkel () și Marvin Solomon (). Teza mea a fost dedicată dezvoltării unui limbaj pentru software de sistem pentru sisteme distribuite - acum toată lumea a uitat de el și mulțumesc lui Dumnezeu. Am creat limbajul de programare Lynx, care a fost menit să faciliteze crearea de servere pentru un sistem de operare distribuit slab cuplat. Deoarece la acea vreme eram implicat în principal în sistemele de operare, am presupus că cariera mea va fi legată în principal de acestea. Dar Rochester era o universitate foarte mică și, din această cauză, diferitele grupuri de acolo au interacționat foarte strâns unele cu altele. Nu mai erau o duzină de oameni cu sisteme de operare cu care să vorbesc, așa că toate contactele mele erau cu oameni care lucrau în domenii complet diferite. Mi-a plăcut foarte mult, a fi un polivalent este un mare avantaj pentru mine. Dacă vorbim în mod specific despre structuri de date cu mai multe fire și algoritmi de sincronizare, atunci am început să lucrez la ele complet din întâmplare.
Interfață coerentă scalabilă IEEE, blocare MCS.
Vitali: Îmi poți spune ceva mai multe despre asta?
Michael: Aceasta este o poveste amuzantă pe care nu mă obosesc să o spun tuturor. S-a întâmplat la o conferință în Boston - asta a fost la sfârșitul anilor 80 sau începutul anilor 90. John Mellor-Crummey (), absolvent al facultăţii noastre. L-am cunoscut, dar nu făcusem cercetări comune înainte. Mary Vernon () din Wisconsin a ținut o discuție despre un sistem multiprocesor pe care îl dezvoltau în Wisconsin: . Acest Multicube avea un mecanism de sincronizare la nivel hardware numit Q on Sync Bit, iar mai târziu a fost redenumit Q pe Lock Bit pentru că suna ca brânză Colby, care era un joc de cuvinte. Dacă sunteți interesat de mecanismele multithreading, probabil știți că Colby a devenit în cele din urmă motorul de sincronizare pentru standardul IEEE Scalable Coherent Interface. Acesta a fost un mecanism de blocare care a creat indicatori de la un cache la altul la nivel hardware, astfel încât fiecare deținător de blocare să știe cui este rândul. Când John și cu mine am auzit despre asta, ne-am uitat unul la altul și am spus: de ce facem asta la nivel hardware? Nu se poate obține același lucru folosind compararea și schimbarea? Am luat unul dintre caietele aflate în clasă și am mâzgălit pe el , în timp ce Mary își continua raportul. Ulterior, am implementat-o, am experimentat, ideea s-a dovedit a fi de succes și am publicat articolul. La acea vreme, pentru mine, acest subiect mi s-a părut doar o distragere a distracției, după care am plănuit să revin la sistemele de operare. Dar apoi a apărut o altă problemă în același sens și, în cele din urmă, sincronizarea, multithreadingul și structurile de date au devenit specialitatea mea. După cum puteți vedea, totul s-a întâmplat întâmplător.
Vitali: Sunt familiarizat cu blocarea MCS de multă vreme, dar până acum nu știam că este munca dumneavoastră și nu înțelegeam că este un acronim pentru numele dumneavoastră de familie.
Cum să supraviețuiești într-o lume în continuă schimbare?
Alexey: Am o întrebare pe un subiect înrudit. Acum 30 sau 40 de ani era mai multă libertate în diferite specialități. Dacă vrei să începi o carieră în sisteme multithreading sau distribuite, ești binevenit, dacă vrei să intri în sistemele de operare, nicio problemă. În fiecare domeniu au fost multe întrebări deschise și puțini experți. Au apărut acum specializări înguste: nu există doar experți în sisteme de operare în general, există specialiști pe sisteme individuale. Este același lucru cu sistemele multithreading și distribuite. Dar problema este că viețile noastre nu sunt nesfârșite; toată lumea poate dedica doar câteva decenii cercetării. Cum să supraviețuiești în această lume nouă?
Michael: Nu suntem speciali în acest sens, același lucru s-a întâmplat cândva în alte zone. Am avut noroc că am început să lucrez în informatică când domeniul era în anii „adolescenței”. Niște baze fuseseră deja puse, dar totul era încă foarte imatur. Această oportunitate nu apare des. Ingineria electrică există de foarte mult timp, fizica și mai mult timp, matematica aproape de la începutul timpurilor. Dar asta nu înseamnă că nimeni nu mai face descoperiri interesante în matematică. Există încă multe probleme deschise, dar, în același timp, mai trebuie învățat. Ai dreptate să remarci că acum există mult mai multe specializări decât erau înainte, dar asta înseamnă doar că ne aflăm în aceeași situație ca majoritatea celorlalte domenii ale activității umane.
Alexey: Sunt interesat de aspectul mai practic al problemei de aici. Am o pregătire în matematică, iar în timpul studiilor am participat adesea la conferințe și am lucrat pe diverse teme științifice. Am descoperit că nimeni din audiență nu înțelegea relatările mele și, în același mod, rapoartele altor oameni erau de înțeles doar pentru ei înșiși. Nu este cazul subiectelor la nivel înalt, dar de îndată ce începi să aprofundezi în ceva, publicul nu mai poate ține pasul cu tine. Cum te descurci cu asta?
Michael: Nu întotdeauna de succes. Am pregătit recent un reportaj în care am intrat prea adânc în detalii tehnice. Pe măsură ce discuția a progresat, a devenit clar că majoritatea publicului nu mă înțelegea, așa că a trebuit să mă adaptez situației din mers. Diapozitivele nu au putut fi schimbate, așa că nu a ieșit foarte bine - așa că, în general, încerc să nu folosesc diapozitive. În general, sfatul meu este să luați în considerare publicul dvs. Trebuie să știi cu cine vorbești, care este nivelul lor de cunoștințe și ce trebuie să audă pentru a-ți aprecia munca.
Vitali: Ne puteți da un indiciu despre ce a fost această prelegere?
Michael: Sincer să fiu, aș prefera să nu extind acest subiect pentru a lăsa persoanele în cauză anonime. Ideea este că adesea intrăm prea adânc în complexitatea problemei la care lucrăm, așa că devine dificil pentru noi să explicăm la începutul discuției de ce problema este interesantă și importantă și cum se leagă de problemele pe care publicul știe deja. Conform observațiilor mele, studenții învață cel mai greu această abilitate. Și acesta a fost și punctul slab al raportului meu recent. Un raport bine structurat ar trebui, de la bun început, să găsească contactul cu publicul, să le explice care este problema exactă și cum se leagă ea de subiectele deja cunoscute de acesta. Cât de tehnică este această introducere depinde de public. Dacă este complet pestriț, atunci raportul poate fi în mai multe etape. Introducerea ar trebui să fie accesibilă pentru toată lumea și, până la sfârșit, piesa poate să nu poată ține pasul cu tine, dar oamenii relativ familiarizați cu domeniul tău vor putea să-și dea seama.
Studenții devin mai proști? Tendințe globale, internaționalizare.
Alexey: Observați studenții de câteva decenii. Studenții devin mai proști sau mai inteligenți de la un deceniu la altul sau de la an la an? În Rusia, profesorii se plâng în mod constant că studenții devin mai proști în fiecare an și chiar nu este clar ce să facă în privința asta.
Michael: Puteți auzi cu adevărat multă negativitate de la noi, bătrânii. În mod subconștient, avem tendința de a ne aștepta ca studenții să absoarbă toți cei 30 de ani de experiență pe care îi avem deja. Dacă am o înțelegere mai profundă decât am avut-o în 1985, de ce nu o au studenții? Probabil pentru că au 20 de ani, ce părere aveți? Cred că cele mai semnificative schimbări din ultimele decenii au fost în compoziția demografică: acum avem mult mai mulți studenți internaționali, cu excepția canadienilor. Au fost o mulțime de canadieni pentru că suntem foarte aproape de granița cu Canada și studenții de acolo pot călători acasă în weekend. Dar acum există multe universități bune în Canada, iar canadienii preferă să studieze aici; semnificativ mai puține dintre ele vin în SUA.
Alexey: Crezi că acesta este un trend local sau unul global?
Michael: Nu-mi amintesc exact cine, dar cineva a spus că lumea este plată. Domeniul nostru a devenit mult mai internațional. Anterior, se țineau exclusiv în Statele Unite, apoi s-au hotărât să le țină o dată la 4 ani în alte țări, iar acum se țin în toată lumea. Aceste schimbări au afectat și mai mult , deoarece a fost întotdeauna o organizație mai internațională decât ACM. Și există scaune de program din China, India, Rusia, Germania și multe alte țări, pentru că acum se întâmplă multe peste tot.
Alexey: Dar, probabil, există unele aspecte negative ale unei astfel de internaționalizări?
Michael: Aș spune că toate aspectele negative se referă nu la tehnologie, ci la politică. Pe vremuri, principala problemă era faptul că SUA fura cei mai deștepți și talentați oameni din țări din întreaga lume. Și acum principala problemă o reprezintă jocurile politice dintre diferite țări în jurul vizelor și imigrației.
Alexey: Adică bariere și lucruri de genul ăsta. Este clar.
Vladimir: Personal, sunt interesat de abordarea pe care o luați atunci când predați o materie nouă studenților. Există diferite opțiuni: poți încerca în primul rând să-i inspiri să încerce ceva nou, sau poți acorda mai multă atenție detaliilor cum funcționează o anumită tehnologie. Ce preferi?
Lucru eficient cu elevii
Alexey: Și cum să găsesc al naibii de echilibru între primul și al doilea?
Michael: Problema este că cursurile nu merg întotdeauna așa cum mi-aș dori. De obicei, le ofer studenților materiale de citit în avans, astfel încât să se aprofundeze în el, să le înțeleagă cât mai bine și să formuleze întrebări despre acele părți pe care nu le-au putut înțelege. Apoi, la clasă, vă puteți concentra pe cele mai dificile momente și le puteți explora împreună. Așa îmi place cel mai mult să predau cursuri. Dar, având în vedere încărcarea pe care acum o revin studenților, nu sunt întotdeauna capabil să mă asigur că se pregătesc din timp. Drept urmare, trebuie să dedicați mult mai mult timp repovestirii generale a materialului decât v-ați dori. În ciuda acestui fapt, încerc să mențin orele noastre interactive. În caz contrar, este mai ușor să înregistrați un videoclip odată pe care elevii îl pot viziona apoi acasă. Scopul orelor live este interacțiunea umană. La clasă, prefer să folosesc creta și o tablă mai degrabă decât diapozitive, cu excepția cazurilor în care o diagramă este prea complexă pentru a fi reprezentată pe tablă. Datorită acestui lucru, nu trebuie să mă țin de un plan rigid de lecție. Deoarece nu există o ordine strictă în care dau materialul, acest lucru îmi permite să-l adaptez publicului în funcție de întrebările pe care le primesc. În general, încerc să fac orele cât mai interactive, astfel încât materialul pe care îl prezint să depindă de întrebările care mi se pun.
Vladimir: E minunat. Din experiența mea, este destul de dificil să-i convin pe ascultători să pună întrebări. Chiar dacă cereți în avans să puneți orice întrebări, oricât de stupide sau deștepte, ei totuși tac. Cum te descurci cu asta?
Michael: O să râzi, dar dacă stai în tăcere suficient de mult, mai devreme sau mai târziu toată lumea va deveni inconfortabilă și cineva va pune o întrebare. Sau puteți pune o întrebare tehnică simplă cu un răspuns da sau nu pentru a determina dacă oamenii înțeleg ceea ce tocmai s-a spus. De exemplu, există o cursă de date în exemplul de mai sus? Cine crede așa? Cine crede că nu? Cine nu înțelege absolut nimic, pentru că în total doar jumătate din mâini au urcat?
Vitali: Și dacă ai răspuns greșit, ești dat afară din clasă :)
Michael: Dacă nu ați răspuns nimic, atunci ar trebui să puneți o întrebare. Trebuie să înțeleg exact ce trebuie să știe elevul pentru a răspunde la întrebarea pe care tocmai am pus-o. Am nevoie de ei să mă ajute să-i ajut. Sunt gata să mă adaptez la ei pentru ca ei să înțeleagă problema. Dar dacă nu știu ce se întâmplă în capul lor, nu o pot face. Și dacă nu le oferi studenților pace suficient de mult timp, uneori, până la urmă, ei pun întrebările potrivite, adică cele care îmi permit să văd ce se întâmplă exact în capul studenților.
Alexey: Aceste întrebări conduc uneori la idei la care nu te-ai gândit înainte? Sunt neașteptate? Vă permit să priviți o problemă într-o lumină nouă?
Michael: Există întrebări care deschid un nou mod de prezentare a materialului. Sunt adesea întrebări care duc la probleme interesante despre care nu am plănuit să vorbesc. Elevii îmi spun adesea că am tendința de a ieși în afara subiectului când se întâmplă acest lucru. Și, potrivit lor, de foarte multe ori aceasta este cea mai interesantă parte a lecției. Foarte rar, doar de câteva ori, studenții au pus întrebări care au determinat o nouă direcție în cercetare și au devenit un articol. Acest lucru se întâmplă mult mai des în conversațiile cu elevii, mai degrabă decât în timpul orelor, dar ocazional s-a întâmplat în timpul orelor.
Alexey: Deci studenții v-au pus întrebări pe baza cărora a fost apoi posibil să publicați un articol?
Michael: Da.
Vitali: Cât de des aveți aceste conversații cu studenții? Când vor să învețe mai mult decât ceea ce a fost tratat în timpul lecției?
Michael: Cu studenții mei absolvenți – tot timpul. Am vreo 5 sau 6 dintre ei și discutăm ceva cu ei tot timpul. Iar conversațiile de acest fel cu studenții care pur și simplu merg la cursurile mele nu sunt foarte frecvente. Deși mi-aș dori să se întâmple asta mai des. Bănuiesc că pur și simplu le este frică să vină la facultate în timpul orelor de serviciu. În fiecare semestru, unii studenți reușesc să depășească această barieră psihologică și este întotdeauna foarte interesant să vorbești cu ei după oră. Adevărat, dacă toți studenții ar fi la fel de curajoși, pur și simplu nu aș avea suficient timp. Deci poate totul funcționează așa cum ar trebui.
Vitali: Cum reușiți să găsiți timp pentru a comunica cu studenții? Din câte știu eu, în SUA profesorii au multă muncă – să aplice pentru granturi și altele asemenea.
Michael: Sincer, lucrul cu studenții este aspectul muncii mele care îmi place cel mai mult. Deci am destulă motivație pentru asta. Majoritatea timpului pe care îl petrec în biroul meu este petrecut în întâlniri de tot felul. Acum e vară, așa că programul meu este mai puțin încărcat, dar în timpul anului școlar, în fiecare zi de la 9 la 17 am totul împachetat. Lucrări de cercetare, recenzii, granturi - pentru toate acestea există doar seri și weekenduri.
Cum să ții pasul cu pregătirea de noi cursuri și cărți.
Alexey: În prezent, continuați să predați cursuri pe care le predați de mult timp? Ceva ca o introducere în informatică.
Michael: Primul lucru care îmi vine în minte aici este un curs de limbaje de programare.
Alexey: Cât de diferită este versiunea de astăzi a acestui curs de ceea ce era acum 10, 20, 30 de ani? Poate că ceea ce este mai interesant aici nu sunt detaliile unui anumit curs, ci tendințele generale.
Michael: Cursul meu despre limbaje de programare era oarecum neobișnuit la momentul în care l-am creat. Am început să-l citesc la sfârșitul anilor 1980, înlocuindu-l pe colegul meu, Doug Baldwin (). Tema cursului era legată doar tangenţial de specialitatea mea, dar când a plecat, eu eram cel mai bun candidat pentru a preda cursul. Nu mi-a plăcut niciunul dintre manualele care existau la acea vreme, așa că am ajuns să scriu singur manualul pentru acest curs. (Nota editorului: vorbim despre carte) Acum este folosit în peste 200 de universități din întreaga lume. Abordarea mea este neobișnuită prin faptul că amestecă în mod deliberat problemele de proiectare și implementare a limbajului și acordă o mare atenție interacțiunii dintre aceste aspecte în toate domeniile posibile. Abordarea de bază a rămas neschimbată, la fel ca și multe concepte de bază: abstracții, spații de nume, modularitate, tipuri. Dar setul de limbaje cu care sunt demonstrate aceste concepte s-a schimbat complet. Când cursul a fost creat pentru prima dată, erau multe exemple în Pascal, dar astăzi mulți dintre studenții mei nici măcar nu au auzit de această limbă. Dar ei știu Swift, Go, Rust, așa că trebuie să vorbesc despre limbile care sunt folosite astăzi. De asemenea, studenții sunt acum bine versați în limbaje de scripting, dar când am început să predau acest curs, era vorba despre limbaje compilate. Acum avem nevoie de mult material despre Python, Ruby și chiar Perl, pentru că acesta este codul scris în zilele noastre și se întâmplă o mulțime de lucruri interesante în aceste limbaje, inclusiv în domeniul designului limbajului.
Vitali: Atunci următoarea mea întrebare va fi legată de cea anterioară. Cum să țin pasul în acest domeniu? Bănuiesc că actualizarea unui astfel de curs necesită multă muncă - trebuie să înțelegeți limbi noi, să înțelegeți ideile principale. Cum faci acest lucru?
Michael: Nu mă pot lăuda că reușesc întotdeauna 100%. Dar de cele mai multe ori fac doar ceea ce fac toți ceilalți - citesc pe internet. Dacă vreau să înțeleg Rust, îl caut pe Google, merg pe pagina Mozilla și citesc manualul postat acolo. Aceasta face parte din lucrurile care se întâmplă în dezvoltarea comercială. Dacă vorbim despre știință, atunci trebuie să urmăriți rapoartele de la principalele conferințe.
Legătura dintre afaceri și mediul academic
Vitali: Să vorbim despre legătura dintre afaceri și cercetarea științifică. În lista dvs. de lucrări, am găsit mai multe articole despre coerența cache-ului. Înțeleg că algoritmii de consistență în cache erau instabili la momentul publicării? Sau nu este suficient de răspândit. Cât de comune au fost ideile tale în practică?
Michael: Nu sunt exact sigur despre ce publicații vorbiți. Am lucrat destul de mult cu elevii mei Bill Bolosky () și Leonidas Kontotanassis () la începutul anilor 1990 privind gestionarea memoriei mașinilor Neumann. La acel moment, afacerile nu înțelegeau încă cum să realizeze corect un sistem multiprocesor: merită să creați suport pentru accesarea memoriei de la distanță la nivel hardware, merită să distribuiți memoria, este posibil să încărcați memoria cache din memorie de la distanță, sau este necesar să mutați paginile din sistemul sălii de operație? Bill și Leonidas au lucrat ambii în acest domeniu și au explorat abordări fără încărcarea cache-ului de la distanță. Acest lucru nu a fost direct legat de coerența cache-ului, dar a fost încă munca la gestionarea memoriei NUMA și, ulterior, abordările moderne ale plasării paginilor în sistemele de operare moderne au crescut din aceasta. În general, Bill și Leonidas au făcut o muncă importantă, deși nu au fost cele mai influente în acest domeniu - erau mulți alți oameni care lucrau la același lucru în acel moment. Mai târziu, am lucrat la un subiect legat de coerența cache-ului în contextul memoriei tranzacționale hardware. Grupul cu care am lucrat la această problemă a ajuns să primească mai multe brevete. Există câteva idei destul de interesante în spatele lor, dar nu cred că vor ajunge să fie implementate în practică. Într-un fel sau altul, îmi este greu să judec profitabilitatea lor.
Alexey: În acest sens, o întrebare mai personală: cât de important este pentru tine ca ideile tale să fie puse în practică? Sau nu te gândești la asta?
Michael: Îmi place să pun această întrebare în interviurile cu alte persoane, candidați sau candidați care doresc să se alăture facultatii. Nu cred că există un răspuns corect la această întrebare. Oamenii care fac lucruri interesante pot avea motivații foarte diferite. Sunt atras de probleme pentru că personal le găsesc interesante, nu din cauza beneficiilor lor practice. Dar, pe de altă parte, când un lucru interesant încă își găsește aplicație, îmi place foarte mult. Deci nu este ușor aici. Dar la începutul lucrării mele, sunt încă condus nu de ideea unei utilizări finale în lume, ci de armonia ideii și dorința de a o explora și de a vedea ce rezultă din ea. Daca pana la urma da rezultate practice, grozav.
Alexey: Datorită educației și experienței tale, ești mai capabil decât majoritatea să judeci valoarea ideilor altora. Puteți să le comparați și să determinați care funcționează mai bine cu care. Sunt sigur că aveți o părere despre lucruri care sunt folosite în prezent în practică de mari producători precum Intel. Din punctul dumneavoastră de vedere, cât de corect este cursul pe care îl urmează aceste companii?
Michael: Practica se învârte întotdeauna în jurul a ceea ce poate avea succes comercial, adică să creeze profit, și mai bine întrebați pe altcineva despre asta. Munca mea are ca rezultat în mare parte publicații, iar în domeniul sistemelor de operare acestea sunt evaluate pe baza indicatorilor de performanță: viteza, consumul de energie, dimensiunea codului. Dar întotdeauna mi s-a părut că aceste rezultate empirice sunt adăugate articolelor doar pentru a putea fi publicate, iar motivele reale pentru muncă ale oamenilor sunt estetice. Cercetătorii evaluează soluțiile din perspectivă artistică, le pasă de cât de elegante sunt ideile și încearcă să creeze ceva mai bun decât abordările existente. Cercetătorii sunt conduși de motive personale, subiective, estetice. Dar nu puteți scrie despre asta în articolul în sine; aceste lucruri nu sunt argumente pentru comitetul de program. Din fericire, soluțiile elegante sunt adesea și rapide și ieftine. O duzină dintre colegii mei și cu mine am discutat despre acest subiect în urmă cu aproximativ 15 ani și am ajuns să scriem un articol despre el. Cred că încă îl poți găsi acum, se numește sau ceva de genul, are mai mult de o duzină de autori. Acesta este singurul articol în care sunt autor împreună , așa că dacă faci o căutare după numele ei în lista mea de publicații, vei găsi ceea ce ai nevoie. Vorbește despre evaluarea cercetării sistemelor și despre cât de importantă este eleganța.
Alexey: Deci există o diferență între standardul a ceea ce este considerat bun în știință și în afaceri. Știința evaluează performanța, consumul de energie, TDP, ușurința de implementare și multe altele. Ai ocazia să faci acest tip de cercetare la universitate? Aveți un laborator cu diferite mașini și diferite arhitecturi în care puteți efectua experimente?
Michael: Da, departamentul nostru are o mulțime de mașini interesante diferite. Cel mai adesea sunt mici, avem un cluster mic și multe sisteme multiprocesor cu acceleratoare diferite. În plus, campusul are un centru uriaș de calcul care deservește oameni de știință din câteva zeci de discipline diferite. Are aproximativ o mie de noduri și douăzeci de mii de nuclee, toate pe Linux. Dacă este nevoie, puteți cumpăra oricând niște AWS. Deci nu avem restricții semnificative cu hardware-ul.
Alexey: Cum a fost acum treizeci de ani? Au fost probleme atunci?
Michael: Atunci era puțin diferit. La mijlocul până la sfârșitul anilor 1980, știința era considerată lipsită de resurse de calcul. Pentru a remedia această situație, Fundația Națională de Știință ) a creat un program de cercetare experimentală coordonată (Coordinated Experimental Research, CER). Misiunea programului a fost de a oferi infrastructură de calcul pentru departamentele de informatică și a realizat schimbări semnificative. Cu banii pe care i-a oferit, noi, cei de la Universitatea din Rochester, am cumpărat un fluture BBN de 1984 de noduri în 128, asta a fost cu un an înainte să ajung eu acolo. La acea vreme era cel mai mare sistem multiprocesor din lume cu memorie partajată. Avea 128 de procesoare, fiecare pe o placă de bază separată și ocupa patru rafturi. Fiecare procesor avea un megaoctet de memorie, 128 de megaocteți de RAM era o cantitate de neimaginat la acea vreme. Pe această mașină am implementat pentru prima dată blocarea MCS.
Alexey: Deci, dacă vă înțeleg bine, atunci în momentul de față problema cu hardware-ul a fost rezolvată?
Michael: În general, da. Există câteva avertismente: în primul rând, dacă faci arhitectură de computer la nivel de cip, este greu de făcut într-un mediu academic, deoarece există instrumente mult mai bune pentru a face acest lucru în afaceri. Dacă aveți nevoie de ceva mai mic de 10 nanometri, va trebui să îl comandați de la altcineva. În acest domeniu este mult mai ușor să fii cercetător la Intel. Dacă lucrezi la comunicații optice pe cipuri sau pe memorie solid-state, vei găsi în afaceri tehnologii care nu sunt încă în știință, așa că trebuie să creezi alianțe. De exemplu, Stephen Swanson () creată pentru noile tehnologii de memorie. Această formă nu funcționează întotdeauna, dar în unele cazuri poate avea destul succes. În plus, dezvoltarea celor mai puternice sisteme de calcul din știință este mai dificilă. Cele mai mari proiecte de supercomputer în prezent în SUA, Japonia și China sunt toate axate pe afaceri.
Implementarea practică a ideilor. MCS, MS, CLH, JSR 166, lucrând cu Doug Lee și multe altele.
Vitali: Ați vorbit deja despre cum ați început să lucrați la algoritmii de sincronizare. Ai două articole foarte celebre despre и , care într-un fel au fost implementate în Java. (Nota editorului: toate publicațiile pot fi vizualizate ). Acolo această blocare a fost implementată cu unele modificări și s-a dovedit , iar coada a fost implementată conform intenției. Dar au trecut mulți ani între publicarea articolelor tale și aplicarea lor practică.
Alexey: Pare vreo 10 ani in cazul cozii.
Michael: Înainte ca aceste caracteristici să apară în biblioteca standard Java?
Vitali: Da. Ce ai făcut ca să se întâmple asta? Sau nu au făcut nimic?
Michael: Vă pot spune cum a intrat MS Queue în Java 5. Cu câțiva ani înainte de a fi lansat, am lucrat cu grupul lui Mark Moyers la Sun Microsystems în laboratorul lor de lângă Boston. A organizat un workshop pentru oameni pe care îi cunoștea și care lucrau la probleme interesante în multithreading, deoarece dorea să găsească subiecte pe care să le vândă companiei lor. Acolo l-am cunoscut prima dată pe Doug Lea. Doug și cu mine și alți aproximativ 25 de oameni de la Sun discutam împreună despre prezentarea lui Doug , care mai târziu a devenit java.util.concurrent. Pe parcurs, Doug a spus că ar dori să folosească coada MS, dar pentru aceasta avea nevoie de un contor pentru numărul de elemente din coada pentru interfață. Adică, acest lucru ar fi trebuit făcut printr-o metodă separată, atomică, precisă și rapidă. Am sugerat să adăugați pur și simplu numere de serie la noduri, luând numărul primului nod și al ultimului și scăzând unul din celălalt. Doug s-a scarpinat pe cap, a spus „de ce nu” și a ajuns să facă exact asta. Am discutat despre implementarea acestei abordări în bibliotecă, dar Doug a făcut el însuși cea mai mare parte a muncii. Drept urmare, a reușit să stabilească un excelent suport pentru multithreading în Java.
Alexey: Deci, dacă am înțeles corect, metoda .size() ar fi trebuit să facă parte din interfața standard de coadă și ar fi trebuit să aibă o complexitate algoritmică de O(1)?
Michael: Da, și pe lângă aceasta, este necesar un contor separat.
Alexey: Pentru că dacă apelați metoda .size() în Java, rezultatul este de așteptat să fie disponibil imediat și nu se bazează pe dimensiunea reală a colecției. Văd, mulțumesc.
Michael: Câțiva ani mai târziu, lucram la structuri de date duale cu studentul meu Bill Scherer - de fapt, despre asta voi vorbi . Doug a venit la noi și a spus că le poate folosi în Java Executor Framework. Împreună cu Bill, au creat două implementări, așa-numitele cozi corecte și injuste. I-am sfătuit în acest proiect, deși nu am participat la scrierea codului propriu-zis. Ca urmare, viteza executorilor a crescut semnificativ.
Vladimir: Ați întâlnit implementări incorecte ale algoritmilor dvs. sau solicitări de adăugare de noi funcții? În general, practica ar trebui să coincidă cu teoria, dar destul de des diferă. Să presupunem că ați scris un algoritm și pe hârtie funcționează, dar oamenii care sunt implicați în implementare au început să vă ceară mai multe caracteristici sau un fel de modificare a algoritmului. Ați avut vreodată astfel de situații?
Michael: Singurul exemplu în care cineva a venit la mine și a întrebat „cum să-l implementez” a fost întrebarea lui Doug, despre care am vorbit deja. Dar au existat câteva cazuri în care s-au făcut modificări interesante pentru a se potrivi nevoilor practice. De exemplu, echipa K42 de la IBM a convertit blocarea MCS și a transformat-o într-o interfață standard, astfel încât să nu fie nevoie să treceți nodul de coadă înainte și înapoi la rutinele de achiziție și eliberare. Datorită acestei interfețe standard, o idee care era frumoasă în teorie a început să funcționeze în practică. Este surprinzător că nu au publicat niciodată un articol despre asta și, deși au primit un brevet, l-au abandonat ulterior. Ideea a fost minunată și încerc să vorbesc despre ea ori de câte ori este posibil.
Au fost și alte cazuri în care oamenii au adus îmbunătățiri la algoritmii pe care i-am publicat. De exemplu, coada MS are un mecanism de instalare în doi pași, ceea ce însemna că existau două CAS-uri pe calea critică a cozii. La mașinile mai vechi, CAS erau destul de scumpe. Intel și alți producători le-au optimizat destul de bine de curând, dar cândva acestea erau instrucțiuni cu 30 de cicluri, așa că nu era de dorit să ai mai mult de unul pe calea critică. Ca rezultat, a fost dezvoltată o altă coadă care a fost similară cu coada MS, dar care avea o singură operație atomică pe calea critică. Acest lucru a fost realizat datorită faptului că într-o anumită perioadă de timp operația ar putea dura O(n) timp, mai degrabă decât O(1). Era puțin probabil, dar posibil. Acest lucru s-a întâmplat din cauza faptului că în anumite momente algoritmul a parcurs coada de la început până la poziția curentă în această coadă. În general, algoritmul s-a dovedit a fi foarte de succes. Din câte știu, nu este foarte utilizat pe scară largă, parțial pentru că operațiunile atomice necesită mult mai puține resurse decât înainte. Dar ideea a fost grozavă. Îmi place foarte mult și munca lui Dave Dice de la Oracle. Tot ceea ce face este foarte practic și folosește fierul foarte inteligent. A avut parte de o mare parte din algoritmii de sincronizare conștienți de NUMA și structurile de date cu mai multe fire.
Vladimir: Când scrieți algoritmi sau predați studenților, rezultatul muncii dvs. nu este vizibil imediat. Comunitatea are nevoie de ceva timp pentru a se familiariza cu, să zicem, un nou articol. Noul algoritm nu își găsește imediat aplicație.
Michael: Este departe de a fi imediat clar dacă articolul va fi semnificativ sau nu. Cred că ar fi interesant să facem un studiu al lucrărilor care au câștigat premii la conferințe. Adică, uită-te la articolele pe care oamenii din comitetele de program le-au considerat la un moment dat cele mai bune. Trebuie să încerci să calculezi după numărul de link-uri și impactul asupra afacerii cât de influente s-au dovedit cu adevărat a fi aceste articole în 10, 20, 25 de ani. Mă îndoiesc că ar exista o corelație puternică între cele două. Nu va fi zero, dar cel mai probabil va fi mult mai slab decât ne-am dori. Multe idei rămân nerevendicate mult timp înainte de a se răspândi. De exemplu, să luăm memoria tranzacțională. Au trecut mai bine de 10 ani de la publicarea articolului original până la momentul în care oamenii au început efectiv să construiască mașini cu acesta. Și înainte de apariția acestei amintiri în produsele comerciale - și toate cele 20. De foarte mult timp nimeni nu a acordat atenție articolului, iar apoi numărul de link-uri către acesta a crescut brusc. Ar fi greu de anticipat acest lucru. Pe de altă parte, uneori ideile găsesc implementare imediată. În urmă cu câțiva ani, am scris o lucrare cu Joe Izraelevitz pentru DISC, care propunea o nouă definiție formală a validității pentru structurile de date persistente care ar putea fi utilizate după ce computerul care le rula s-a prăbușit. Mi-a plăcut articolul de la bun început, dar s-a dovedit a fi mult mai popular decât mă așteptam. A fost folosit de mai multe grupuri diferite și în cele din urmă a devenit definiția standard a structurilor de persistență. Ceea ce, desigur, este frumos.
Vladimir: Există tehnici pe care le utilizați pentru evaluare? Încercați măcar să vă evaluați articolele și studenții? În ceea ce privește dacă persoana pe care ai predat merge în direcția bună.
Michael: Ca toți ceilalți, sunt mai atent la ceea ce fac în acest moment. Din nou, ca toți ceilalți, verific ocazional Google Academic pentru a vedea dacă lucrările mele din trecut sunt citate, dar asta mai mult din curiozitate. În mare parte, sunt absorbit de ceea ce fac studenții mei acum. Când vine vorba de evaluarea lucrărilor curente, o parte din ea sunt considerații estetice, ce este elegant și ce nu. Și la nivel de zi cu zi, întrebările deschise joacă un rol important. De exemplu, un student vine la mine cu un grafic al unor rezultate și încercăm să înțelegem de unde provine un comportament ciudat al graficului. În general, în munca noastră încercăm constant să înțelegem lucruri pe care încă nu le înțelegem.
Memoria tranzacțională
Vitali: Poate putem vorbi puțin despre memoria tranzacțională?
Michael: Cred că merită spus măcar puțin pentru că am depus mult efort în asta. Acesta este un subiect despre care am mai multe publicații decât oricare alta. Dar, în același timp, destul de ciudat, am fost întotdeauna foarte sceptic cu privire la memoria tranzacțională. În opinia mea, (M. Herlihy, J. E. B. Moss) a fost publicat înaintea timpului său. La începutul anilor 1990, ei au sugerat că memoria tranzacțională ar putea ajuta programatorii talentați să lucreze pe structuri de date cu mai multe fire, astfel încât aceste structuri să poată fi apoi folosite ca biblioteci de către programatorii obișnuiți. Adică, ar fi de ajutor pentru Doug Lee să-și facă JSR 166. Dar memoria tranzacțională nu a fost menită să faciliteze programarea cu mai multe fire. Dar exact așa a început să fie perceput la începutul anilor 2000, când s-a răspândit. A fost promovat ca o modalitate de a rezolva problema programării paralele. Această abordare mi s-a părut întotdeauna fără speranță. Memoria tranzacțională ar putea doar să faciliteze scrierea structurilor de date paralele. Asta, mi se pare, este ceea ce a reușit ea.
Despre dificultatea scrierii codului cu mai multe fire
Alexey: Foarte interesant. Se pare că există o anumită barieră între programatorii obișnuiți și cei care pot scrie cod cu mai multe fire. Anul trecut, am vorbit de mai multe ori cu oameni care implementau un cadru algoritmic. De exemplu, cu Martin Thomson, precum și cu programatori care lucrează la biblioteci cu mai multe fire. (Nota editorului: Martin Thompson este un dezvoltator foarte faimos, a scris el и . Și are, de asemenea la conferința noastră Joker 2015, înregistrare video . El este la fel această conferință deasemenea disponibil). Principala provocare, spun ei, este să faci algoritmii atât rapid, cât și ușor de utilizat. Adică încearcă să depășească această barieră și să atragă cât mai mulți oameni în această zonă. Ce crezi despre?
Michael: Aceasta este principala problemă a multithreading-ului: cum să obțineți performanțe ridicate fără a crește complexitatea sistemului.
Alexey: Pentru că atunci când încearcă să evite complexitatea, algoritmul devine mai puțin universal.
Michael: Cheia aici este abstracțiile proiectate corespunzător. Mi se pare că acesta este în general principalul lucru pentru sistemele informatice ca domeniu. Lui Butler Lampson îi place să folosească acest termen și ne numește „negustori de abstracțiuni”. Tehnologiile simple nu există astăzi. Procesoarele pe care le folosim au 10 miliarde de tranzistori – simplitatea este exclusă. În același timp, ISA este mult mai simplu decât procesorul, deoarece am lucrat foarte mult timp pentru a-i oferi performanțe ridicate și o interfață relativ simplă. Dar nici cu ea nu totul este bine. Aceeași problemă este și cu acceleratoarele care apar acum pe piață. Apar întrebări - cum să faci interfața potrivită pentru GPU, un mecanism de criptare, compresie, un mecanism de transcodare, un mecanism de algebră liniară sau chiar un FPGA mai flexibil. Cum se creează o interfață care face instrumentul ușor de utilizat și ascunde complexitatea? Nu va scăpa de el, ci mai degrabă îl va ascunde de un simplu programator.
Alexey: După cum am înțeles, avem încă o barieră în înțelegerea abstracțiilor. Să luăm modelul memoriei; în stadiul nostru de dezvoltare a științei și tehnologiei, aceasta este una dintre principalele abstracții. Datorită acesteia, toți programatorii sunt împărțiți în două grupuri: cea mai mare parte sunt cei care nu o înțeleg, iar cea mai mică parte sunt cei care înțeleg sau cred că înțeleg.
Michael: Aceasta este o întrebare bună - cineva dintre noi înțelege cu adevărat modelul de memorie?
Vitali: Mai ales în C++.
Michael: Vorbește cu Hans Boehm cândva. Este unul dintre cei mai deștepți oameni pe care îi cunosc, un expert de top în modelele de memorie. Îți va spune imediat că sunt multe pe care nu le înțelege. Dar dacă revenim la problema abstracțiilor, atunci, în opinia mea, cea mai importantă idee din domeniul modelelor de memorie din ultimii 30 de ani a fost exprimată. . (Nota editorului: este disponibilă o listă completă a publicațiilor ).
Alexey: Întrebarea mea este: această barieră provine din însăși natura conceptului?
Michael: Nu. Sarita a ajuns la concluzia că, cu abordarea corectă, puteți ascunde cu succes toată complexitatea, puteți obține performanțe ridicate și puteți oferi programatorului un API simplu. Și dacă urmați acest API, puteți obține o consistență consistentă. Cred că acesta este modelul potrivit. Scrieți cod fără curse de date și obțineți consistență secvențială. Desigur, pentru a reduce probabilitatea de a face curse, sunt necesare instrumente speciale, dar asta este o altă chestiune.
Vladimir: Au existat momente în cariera dumneavoastră când o problemă care părea rezolvată s-a transformat brusc într-o catastrofă sau s-a dovedit că această problemă nu era rezolvată? De exemplu, în teorie puteți factoriza orice număr sau puteți determina dacă orice număr este prim. Dar, în practică, acest lucru poate fi dificil de realizat; cu hardware-ul actual este dificil să factorizezi numerele. Ti s-a intamplat ceva asemanator?
Michael: Nu îmi amintesc imediat așa ceva. Au fost momente când mi s-a părut că nu mai e nimic de făcut într-o anumită zonă, dar atunci s-a întâmplat ceva nou și interesant acolo. De exemplu, am crezut că zona de coadă nelimitată a ajuns deja la maturitate. După mai multe îmbunătățiri la coada MNS, nu s-a mai întâmplat mare lucru. Și apoi Morrison (Adam Morrison) și Afek (Yehuda Afek) au inventat . A devenit clar că era posibilă o coadă nelimitată cu mai multe fire, unde de cele mai multe ori exista doar o instrucțiune de preluare și creștere pe calea critică. Și acest lucru a făcut posibilă obținerea unei performanțe mai bune cu un ordin de mărime. Nu este că nu știm că preluarea și creșterea este un lucru foarte util. Eric Freudenthal a scris despre acest lucru în lucrarea sa pe Ultracomputer cu Allan Gottlieb la sfârșitul anilor 1980, dar era vorba despre cozi limitate. Morrison și Afek au putut să folosească fetch-and-increment pe o coadă nelimitată.
Arhitecturi noi. Este aproape victoria memoriei tranzacționale?
Vladimir: Căutați noi soluții arhitecturale care ar putea fi utile pentru algoritmi?
Michael: Desigur, sunt multe lucruri pe care mi-aș dori să le văd implementate.
Vladimir: Ce fel, de exemplu?
Michael: În primul rând, câteva extensii simple ale memoriei noastre tranzacționale la nivel hardware în procesoarele Intel și IBM. În special, aș dori ca încărcarea și magazinul non-tranzacțional care tocmai s-au întâmplat să fie imediat disponibile în cadrul tranzacțiilor. Acestea duc imediat la bucle în secvența întâmplă-înainte, așa că pot fi dificile. Dar dacă mențineți straturi de abstractizare, există o mulțime de lucruri foarte interesante pe care le puteți face în afara tranzacției în timp ce aceasta se întâmplă. Nu știu cât de greu ar fi de implementat acest lucru, dar ar fi foarte util.
Un alt lucru util este încărcarea memoriei cache din memoria de la distanță. Cred că mai devreme sau mai târziu acest lucru se va face. Această tehnologie va permite crearea de sisteme cu memorie dezagregată. Ar fi posibil să se păstreze, să zicem, 100 de terabytes de memorie nevolatilă într-un rack, iar sistemul de operare însuși ar decide în mod dinamic care secțiuni ale acelei memorie ar trebui să corespundă spațiului de adrese fizice al procesoarelor. Acest lucru ar fi extrem de util pentru cloud computing, deoarece ar permite ca cantități mari de memorie să fie furnizate sarcinilor care au nevoie de ea. Cred că cineva o va face.
Vitali: Pentru a termina de vorbit despre memoria tranzacțională, mai am o întrebare pe acest subiect. Memoria tranzacțională va înlocui în cele din urmă structurile standard de date multi-threaded?
Michael: Nu. Tranzacțiile sunt un mecanism speculativ. La nivel de programare acestea sunt încuietori atomice, dar în interior sunt speculații. O astfel de prognoză funcționează dacă majoritatea presupunerilor sunt corecte. Prin urmare, memoria tranzacțională funcționează bine atunci când firele de execuție interacționează cu greu unele cu altele și trebuie doar să vă asigurați că nu există interacțiuni. Dar dacă un mesaj începe între fire, tranzacțiile sunt de puțin folos. Permiteți-mi să vă explic, vorbim despre cazul în care tranzacțiile sunt cuprinse în jurul întregii operațiuni atomice. Ele pot fi încă utilizate cu succes ca componente pentru structuri de date cu mai multe fire. De exemplu, dacă aveți nevoie de un CAS cu trei cuvinte și trebuie să multithread trei lucruri mici în mijlocul unui algoritm cu adevărat multithread care funcționează cu douăzeci de fire în același timp. În general, tranzacțiile pot fi utile, dar nu vor elimina necesitatea de a proiecta corect structuri de date multi-threaded.
Memorie nevolatilă, DIMM Optane, dispozitive ultra-rapide.
Vitali: Ultimul lucru despre care aș dori să vorbesc este subiectul cercetării dumneavoastră curente: memoria nevolatilă. La ce ne putem aștepta în acest domeniu în viitorul apropiat? Poate știți despre implementări eficiente care există deja?
Michael: Nu sunt expert în hardware, știu doar ce am citit în știri și ce îmi spun colegii. Toată lumea a auzit deja că Intel vinde , care au de aproximativ 3 ori latența de citire și de 10 ori latența de scriere decât RAM dinamică. În curând vor fi disponibile în versiuni de volum foarte mare. E amuzant să crezi că ai putea avea un laptop cu câțiva terabytes de RAM adresabilă pe octeți. Este probabil ca peste 10 ani sa decidem sa folosim aceasta noua tehnologie, din moment ce folosim DRAM - doar crestem volumul. Dar datorită independenței energetice, ni se deschid oportunități complet noi. Putem schimba în mod fundamental stiva de stocare astfel încât să nu existe o separare între memoria de lucru adresabilă pe octeți și memoria persistentă structurată în bloc. Astfel, nu va trebui să serializăm tot ceea ce trebuie transferat de la un program rulat la altul în fișiere structurate în bloc. Din aceasta putem deriva multe principii importante care afectează sistemele de operare, mediile de rulare și depozitele de date distribuite. Acest domeniu este foarte interesant de lucrat. Personal, îmi este dificil să prezic la ce va duce toate acestea, dar problemele de aici sunt extrem de distractive. Aici pot exista schimbări revoluționare și ele decurg foarte firesc din munca privind multithreading, deoarece recuperarea eșecului este un proces de „multithreading” alături de funcționarea normală a sistemului.
Al doilea subiect principal la care lucrez în prezent este gestionarea dispozitivelor ultra-rapide și accesul securizat la dispozitive din spațiul utilizatorului cu control sistemic al politicii. În ultimii ani, a existat o tendință de a muta accesul la dispozitiv în spațiul utilizatorului. Acest lucru se face deoarece stiva de nucleu TCP-IP nu poate funcționa deasupra unei interfețe de rețea care are nevoie de un nou pachet la fiecare 5 microsecunde; pur și simplu nu va ține pasul. Prin urmare, producătorii oferă acces direct la dispozitive. Dar aceasta înseamnă că sistemul de operare pierde controlul asupra procesului și nu poate oferi acces adecvat la dispozitiv pentru aplicațiile concurente. Echipa noastră de cercetare consideră că acest neajuns poate fi evitat. Vom avea un articol despre asta la USENIX ATC luna aceasta. Este legat de munca pe persistență, deoarece memoria persistentă cu durată lungă de viață, adresabilă pe octeți, este, în esență, un dispozitiv cu I/O ultra-rapidă care trebuie accesat în spațiul utilizatorului. Această cercetare face posibile noi abordări ale microkernel-urilor, exokernel-urilor și altor încercări tradiționale de a muta în siguranță funcționalitatea din nucleul OS în spațiul utilizatorului.
Vladimir: Memoria adresabilă pe octeți este grozavă, dar există o limitare fizică - viteza luminii. Aceasta înseamnă că va exista inevitabil o întârziere la interacțiunea cu dispozitivul.
Michael: Absolut corect.
Vladimir: Va fi suficientă capacitate pentru a face față noilor sarcini?
Michael: Aceasta este o întrebare excelentă, dar îmi va fi greu să răspund. Ideea procesării în memorie există de ceva vreme, este foarte interesantă, dar și foarte complexă. Nu am lucrat în acest domeniu, dar ar fi grozav dacă s-ar face niște descoperiri acolo. Mi-e teamă că nu mai am nimic de adăugat.
Vladimir: Mai este o problemă. Cantități noi, semnificativ mai mari de RAM vor fi imposibil de încadrat în procesor. Prin urmare, din cauza limitărilor fizice, această memorie RAM trebuie izolată.
Michael: Totul depinde de numărul de defecte în producția de circuite integrate. Dacă ar fi posibil să se creeze plachete semiconductoare în întregime fără defecte, atunci ar fi posibil să se realizeze un întreg microcircuit din el. Dar acum nu știm cum să facem microcircuite mai mari decât timbrele poștale.
Vladimir: Dar tot vorbim de dimensiuni uriașe, cam de centimetri. Acest lucru are inevitabil un impact asupra latenței.
Michael: Da. Nu poți face nimic cu viteza luminii.
Vladimir: Din pacate.
Următoarea mare tendință. Structuri de date duale. Hidra.
Vitali: Din câte am înțeles, prinzi foarte repede noile tendințe. Ai fost unul dintre primii care a lucrat în memoria tranzacțională și unul dintre primii care a lucrat în memoria nevolatilă. Care crezi că va fi următorul mare trend? Sau poate este un secret?
Michael: Sincer să fiu, nu știu. Sper că voi putea observa când apare ceva nou. Nu am avut norocul să inventez singur vreun domeniu nou, dar am avut puțin noroc și am putut începe destul de devreme să lucrez în domenii noi create de alții. Sper că voi putea face asta în viitor.
Alexey: Ultima întrebare din acest interviu va fi despre performanța ta la Hydra și activitățile tale la școală. Dacă am înțeles bine, raportul de la școală va fi despre algoritmi fără blocare, iar la conferință despre structuri duble de date. Ați putea spune câteva cuvinte despre aceste rapoarte?
Michael: În parte, am atins deja aceste subiecte cu tine în acest interviu. Este vorba despre munca pe care am făcut-o cu elevul meu Bill Scherer. El a scris o teză despre ea și Doug Lee a contribuit și el la ea și, în cele din urmă, a devenit parte din cozile sincrone cu mai multe fire din biblioteca Java. Să presupunem că structura de date este citită și scrisă fără blocare, adică fiecare operație are un număr limitat de instrucțiuni pe calea critică. Dacă încercați să eliminați date dintr-un container gol sau să încercați să eliminați anumite date care nu se află în acest container, sunteți imediat informat că acest lucru nu se poate face. Dar acest comportament poate să nu fie acceptabil dacă firul are nevoie într-adevăr de aceste date. Atunci primul lucru care vă vine în minte este să creați o buclă care să întrebe în mod constant dacă au apărut datele necesare. Dar apoi există interferențe pentru toți ceilalți. În plus, cu această abordare, puteți aștepta 10 minute, apoi va veni un alt fir și va primi accidental datele necesare mai întâi. Structurile de date duale încă nu au blocări, dar permit firelor să aștepte corect. Termenul „dublu” înseamnă că structura conține fie date, fie solicitări de date, să le numim anti-date. Deci, dacă încercați să recuperați ceva dintr-un container gol, o solicitare va fi introdusă în container. Acum firul poate aștepta o solicitare fără a deranja pe nimeni altcineva. În plus, structura de date atribuie priorități cererilor, astfel încât, atunci când sunt primite, să le transmită persoanei potrivite. Rezultatul este un mecanism fără blocare care are încă o specificație formală și o performanță bună în practică.
Alexey: Ce așteptări aveți de la această structură de date? Va îmbunătăți performanța în toate cazurile obișnuite sau este mai potrivit pentru anumite situații?
Michael: Este util dacă, în primul rând, aveți nevoie de un container fără blocare și, în al doilea rând, trebuie să așteptați într-o situație în care trebuie să preluați date din containerul care nu se află în el. Din câte știu, cadrul nostru oferă un comportament optim atunci când aceste două condiții sunt îndeplinite. Prin urmare, în aceste cazuri recomand să-l folosești. Principalul avantaj al structurilor de date fără blocare este că evită problemele de performanță. Și așteptarea este foarte importantă în mulți algoritmi dacă datele sunt transferate de la un fir în altul.
Vitali: Permiteți-mi să clarific: veți vorbi despre același lucru atât la școală, cât și la conferință?
Michael: La scoala în general, despre structurile de date multi-threaded, cu principiile de bază subliniate la începutul lecției. Presupun că publicul știe ce fire sunt și este familiarizat cu încuietorile. Pe baza acestor cunoștințe de bază, voi vorbi despre structurile de date fără blocare. Voi oferi o privire de ansamblu asupra celor mai importante probleme din acest domeniu, atingând subiecte precum managementul memoriei. Nu cred că va fi ceva mai complicat decât coada MS.
Alexey: Plănuiți să predați despre structurile duale de date la sfârșitul orei în școală?
Michael: Le voi menționa, dar nu voi petrece mult timp cu ele. Lor le va fi dedicat raportul Hydra. Acesta va acoperi proiectul care a ajuns în cele din urmă în Java, precum și colaborarea cu Joe Israelevich pentru a crea o variantă dublă a cozii LCRQ și crearea unui design aproape universal pentru structurile de date duale.
Alexey: Deci prelegerea de la școală poate fi recomandată pentru începători, iar prelegerea despre structurile de date duble pe Hydra - pentru persoanele care au deja ceva experiență?
Michael: Corectați-mă dacă greșesc, dar publicul de la Hydra va fi destul de divers, inclusiv mulți experți Java și, în general, oameni care nu sunt implicați în mod specific în programarea multi-thread.
Vitali: Da este adevarat.
Alexey: Cel puțin așa sperăm.
Michael: În acest caz, mă voi confrunta cu aceeași problemă cu care am început acest interviu: cum să facem un reportaj atât suficient de bogat în detalii tehnice, cât și accesibil tuturor ascultătorilor.
Vitali: Veți da un raport la fel cum susțineți prelegeri? Adică să vorbești cu publicul și să te adaptezi la situație?
Michael: Mi-e teamă că nu va merge așa, pentru că raportul va avea diapozitive. Slide-urile sunt importante atunci când ascultătorii vorbesc inițial limbi diferite. Mulți oameni le va fi greu să mă înțeleagă în engleză, mai ales dacă vorbesc prea repede. Am ales aceste subiecte pentru că mi-a cerut să vorbesc despre structurile de date fără blocare la SPTDC School; și apoi aveam nevoie de un raport pentru o conferință de grup de utilizatori Java și am vrut să aleg ceva care să fie de interes special pentru programatorii Java. Cea mai ușoară cale a fost să vorbesc despre acele lucruri din biblioteca Java pe care le-am avut o mână într-un fel sau altul.
Alexey: Presupunem că publicul de pe Hydra știe deja ceva despre programarea fără blocare și poate că are ceva experiență în acest domeniu. Dar aceasta este doar o presupunere; situația va deveni mai clară chiar la conferință. Oricum, mulțumesc pentru timpul acordat. Sunt sigur că interviul va fi foarte interesant pentru cititorii noștri. Mulţumesc mult!
Vitali: Mulțumiri.
Michael: Voi fi bucuros să vă cunosc la Sankt Petersburg.
Alexey: Și noi, avem un oraș frumos. Ai fost vreodată aici?
Michael: Nu, nu am fost deloc în Rusia. Dar Sankt Petersburg a fost întotdeauna pe lista locurilor în care nu am fost încă, dar unde îmi doresc foarte mult să merg, așa că am fost foarte bucuros de invitație.
Alexey: Apropo, vom avea un program de excursii pentru vorbitori. Mulțumesc foarte mult pentru interviu și o zi bună!
Puteți continua conversația cu Michael 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