- kettő tulajdonosa. Az első a munkához való (Brown University) és a második, újabb, - (Virginia Műszaki Egyetem). A Dijkstra-díjat olyan munkáért ítélik oda, amelynek jelentősége és befolyása legalább tíz éve látható, és Maurice nyilvánvalóan az egyik leghíresebb szakember a területen. Jelenleg a Brown Egyetem professzoraként dolgozik, és számos, egy bekezdésnyi teljesítményt ért el. Jelenleg a blokkláncot kutatja a klasszikus elosztott számítástechnika keretében.
Korábban Maurice már eljött Oroszországba az SPTCC-re () és kiváló találkozót tartott a JUG.ru Java fejlesztői közösség Szentpéterváron ().
Ez a habrapost egy nagyszerű interjú Maurice Herlihyvel. A következő témákat tárgyalja:
- Kölcsönhatás a tudományos élet és az ipar között;
- Alapítvány a Blockchain Researchért;
- Honnan származnak az áttörő ötletek? A népszerűség hatása;
- PhD Liskov Barbara felügyelete alatt;
- A világ többmagosra vár;
- Az új világ új problémákat hoz. NVM, NUMA és architektúra hackelés;
- Fordítók vs processzorok, RISC vs CISC, megosztott memória vs üzenettovábbítás;
- Törékeny, többszálú kód írásának művészete;
- Hogyan tanítsuk meg a tanulókat összetett többszálú kód írására;
- A „The Art of Multiprocessor Programming” című könyv új kiadása;
- Hogyan találták fel a tranzakciós memóriát;
- Miért érdemes kutatásokat végezni az elosztott számítástechnika területén;
- Leállt-e az algoritmusok fejlesztése, és hogyan tovább?
- Munka a Brown Egyetemen;
- Az egyetemi és a vállalaton belüli kutatás közötti különbség;
- Hidra és SPTDC.
Az interjút készíti:
Vitalij Aksenov – jelenleg az IST Austria posztdoktora és az ITMO Egyetem Számítástechnikai Tanszékének alkalmazottja. Kutatásokat folytat a kompetitív adatszerkezetek elmélete és gyakorlata területén. Mielőtt az IST-nél dolgozott, a Paris Diderot Egyetemen és az ITMO Egyetemen szerzett PhD fokozatot Peter Kuznetsov professzor felügyelete alatt.
Alekszej Fedorov - Producer a JUG Ru Groupnál, egy orosz cégnél, amely konferenciákat szervez fejlesztőknek. Alexey több mint 50 konferencia előkészítésében vett részt, és az önéletrajza mindent tartalmaz az Oracle fejlesztőmérnöki pozíciójától (JCK, Java Platform Group) az Odnoklassniki fejlesztői pozícióig.
Vlagyimir Szitnyikov - Mérnök a Netcrackernél. Tíz évnyi munka a NetCracker OS teljesítményén és méretezhetőségén, amely szoftver, amelyet a távközlési szolgáltatók használnak a hálózati és hálózati berendezések kezelési folyamatainak automatizálására. Érdekelnek a Java és az Oracle Database teljesítményével kapcsolatos problémák. Több mint egy tucat teljesítményjavítás szerzője a hivatalos PostgreSQL JDBC illesztőprogramban.
Kölcsönhatás az akadémia és az ipar között
Alexey: Maurice, Ön nagyon régóta dolgozott akadémiai környezetben, és az első kérdés az akadémiai és az ipari szféra közötti kölcsönhatás. Tudna beszélni arról, hogy a köztük lévő interakciók hogyan változtak az utóbbi időben? Mi történt 20-30 éve és mi történik most?
Maurice: Mindig is igyekeztem szorosan együttműködni kereskedelmi cégekkel, mert érdekes problémáik vannak. Általában nem nagyon érdekli őket sem eredményeik közzététele, sem problémáik részletes magyarázata a világközösség számára. Csak ezeknek a problémáknak a megoldása érdekli őket. Egy ideig ilyen cégeknél dolgoztam. Öt évet töltöttem teljes munkaidőben a Digital Equipment Corporation kutatólaboratóriumában, amely korábban egy nagy számítástechnikai cég volt. Hetente egy napot dolgoztam a Sunnál, a Microsoftnál, az Oracle-nél, és dolgoztam egy kicsit a Facebooknál. Most szombati szabadságra megyek (egy amerikai egyetem professzora körülbelül hatévente egyszer vehet ki ilyen szabadságot egy évre), és dolgozom , ez egy bostoni kriptovaluta cég. A cégekkel való szoros együttműködés mindig is öröm volt, mert így tanulhatsz új és érdekes dolgokat. Még az is lehet, hogy Ön az első vagy a második ember, aki cikket tesz közzé egy kiválasztott témában, ahelyett, hogy azon problémák fokozatos javításán dolgozna, amelyeken már mindenki más dolgozik.
Alexey: Elmondaná nekünk részletesebben, hogyan történik ez?
Maurice: Természetesen. Tudja, amikor a Digital Equipment Corporation-nél dolgoztam, én és Elliot Moss feltaláltuk a tranzakciós memóriát. Nagyon termékeny időszak volt, amikor mindenki érdeklődni kezdett az információs technológia iránt. Párhuzamosság, beleértve, bár többmagos rendszerek még nem léteztek. A Sun és az Oracle napjaiban sokat dolgoztam párhuzamos adatstruktúrákon. A Facebookon dolgoztam a blokklánc projektjükön, amiről nem tudok beszélni, de remélem, hamarosan nyilvános lesz. Jövőre Algorandban egy intelligens szerződéseket tanulmányozó kutatócsoportban fogok dolgozni.
Alexey: A blokklánc nagyon népszerű téma lett az elmúlt néhány évben. Segíti ez a kutatást? Talán megkönnyíti a támogatások megszerzését, vagy az ágazatban működő cégek forrásokhoz való hozzáférését?
Maurice: Már kaptam egy kis támogatást az Ethereum Alapítványtól. A blokklánc népszerűsége nagyon sokat segít abban, hogy a hallgatókat ezen a területen való munkára ösztönözze. Nagyon érdekli őket ez, és izgatottan várják, hogy bekapcsolódjanak, de néha nem veszik észre, hogy a kívülről izgalmasnak tűnő kutatás valóban kemény munkával jár. Mindazonáltal nagyon izgatott vagyok, hogy felhasználhatom ezt a blokklánc körüli misztikumot a diákok vonzására.
De ez még nem minden. Számos blokklánc startup tanácsadó testületében vagyok. Lehet, hogy néhányuk sikerül, van, amelyik nem, de mindig nagyon érdekes látni, tanulmányozni az ötleteiket és tanácsokat adni az embereknek. A legizgalmasabb az, amikor figyelmezteted az embereket, hogy ne tegyenek valamit. Sok minden elsőre jó ötletnek tűnik, de vajon tényleg?
Blockchain Research Alapítvány
Vitalij: Vannak, akik úgy gondolják, hogy a jövő a blokkláncban és annak algoritmusaiban van. Mások pedig azt mondják, hogy ez csak egy újabb buborék. Megosztanád a véleményedet erről a kérdésről?
Maurice: Sok minden rossz, ami a blokklánc világában történik, van, amelyik csak átverés, sok mindent túlértékelnek. Úgy gondolom azonban, hogy ezeknek a tanulmányoknak szilárd tudományos alapja van. Az a tény, hogy a blokklánc világ tele van ideológiai különbségekkel, mutatja az izgalom és az elhivatottság szintjét. Másrészt ez nem különösebben előnyös a tudományos kutatás számára. Nos, ha közzétesz egy cikket, amely egy adott algoritmus hiányosságairól szól, a kapott reakció nem mindig teljesen tudományos. Az emberek gyakran kidobják érzelmeiket. Úgy gondolom, hogy ez a fajta izgalom ezen a területen egyesek számára vonzónak tűnhet, de a nap végén vannak valódi tudományos és mérnöki kérdések, amelyekkel foglalkozni kell. Rengeteg számítástechnika van itt.
Vitalij: Szóval megpróbálod lefektetni a blokklánc-kutatás alapjait, igaz?
Maurice: Egy szilárd, tudományosan és matematikailag megalapozott tudományág alapjait próbálom lefektetni. És a probléma egy része az, hogy néha ellent kell mondanod mások túlzottan kemény álláspontjának, és figyelmen kívül kell hagynod azokat. Néha az emberek megkérdezik, miért dolgozom olyan területen, ahol csak a terroristák és a kábítószer-kereskedők érdeklődnek. Egy ilyen reakció éppoly értelmetlen, mint azoknak a követőknek a viselkedése, akik vakon ismétlik a szavait. Szerintem az igazság valahol középen van. A blokklánc komoly hatással lesz a társadalomra és a globális gazdaságra. De ez a modern technológiának köszönhetően valószínűleg nem fog megtörténni. A modern technológiák fejlődni fognak, és nagyon fontos lesz az, amit a jövőben blokkláncnak neveznek. Lehet, hogy nem is úgy néz ki, mint a modern blokkláncok, ez nyitott kérdés.
Ha az emberek új technológiákat találnak fel, azt továbbra is blokkláncnak fogják hívni. Úgy értem, ahogy a mai Fortrannak semmi köze az 1960-as évek Fortran nyelvéhez, de mindenki Fortrannak hívja. Ugyanez a UNIX-hoz. Az úgynevezett „blokklánc” továbbra is forradalmi lesz. De kétlem, hogy ez az új blokklánc olyan lesz, mint amit ma mindenki szívesen használ.
Honnan származnak az áttörő ötletek? A népszerűség hatása
Alexey: A blokklánc népszerűsége új eredményekhez vezetett tudományos szempontból? Több interakció, több diák, több cég a környéken. Van-e már eredménye ennek a népszerűségnövekedésnek?
Maurice: Ez akkor kezdett érdekelni, amikor valaki átadott egy hivatalos szórólapot egy céghez, amelyik éppen elég sok pénzt gyűjtött össze. Arról írt , amivel több mint ismerem. A szórólapon leírtak egyértelműen technikailag hibásak voltak. Akik mindezt írták, nem igazán értették a probléma mögött meghúzódó modellt... pedig ez a cég rengeteg pénzt gyűjtött össze. Ezt követően a cég csendben lecserélte ezt a szórólapot egy sokkal korrektebb változatra – és nem mondom meg, mi volt ennek a cégnek a neve. Még mindig ott vannak, és nagyon jól vannak. Ez az eset meggyőzött arról, hogy először is a blokklánc egyszerűen az elosztott számítástechnika egy formája. Másodszor, a belépési küszöb (legalábbis akkor, négy évvel ezelőtt) meglehetősen alacsony volt. Az ezen a területen dolgozók nagyon energikusak és intelligensek voltak, de nem olvastak tudományos cikkeket. Megpróbáltak újra feltalálni az ismert dolgokat, és rosszul csinálták. Mára a drámaiság csökkent.
Alexey: Ez nagyon érdekes, mert néhány évvel ezelőtt más tendencia volt. Kicsit olyan ez, mint a front-end fejlesztés, amikor a böngésző alapú front-end fejlesztők teljes technológiákat találtak újra, amelyek már a háttérben is népszerűek voltak: rendszerépítés, folyamatos integráció, ilyesmi.
Maurice: Egyetértek. De ez nem meglepő, mert az igazán áttörő ötletek mindig a kialakult közösségen kívülről származnak. A megalapozott kutatók, különösen az elismert akadémikusok, nem valószínű, hogy bármi igazán úttörőt csinálnának. Könnyű előadást írni a következő konferenciára arról, hogyan javította kissé korábbi munkája eredményeit. Menj el egy konferenciára, találkozz a barátaiddal, beszélgess ugyanazokról a dolgokról. Az áttörő ötletekkel berobbanó emberek pedig szinte mindig kívülről érkeznek. Nem ismerik a szabályokat, nem ismerik a nyelvet, de ennek ellenére... Ha egy kialakult közösségen belül vagy, azt tanácsolom, hogy figyelj az új dolgokra, valamire, ami nem illik bele az összképbe. Bizonyos értelemben kísérletet lehet tenni a külső, gördülékenyebb fejlesztések és az általunk már értett módszerek összekapcsolására. Első lépésként próbáljon meg tudományos alapot teremteni, majd változtasson azon, hogy az új, áttörést jelentő ötletekre is alkalmazható legyen. Úgy gondolom, hogy ez a blokklánc kiválóan alkalmas arra, hogy friss, bomlasztó ötlet legyen.
Alexey: Szerinted miért történik ez? Mert a „kívülálló” embereknek nincsenek a közösségben rejlő sajátos akadályai?
Maurice: Itt egy minta zajlik. Ha elolvassa az impresszionisták történetét a festészetben és általában a művészetben, akkor egy időben a híres művészek elutasították az impresszionizmust. Azt mondták, hogy ez elég gyerekes. Egy generációval később ez a korábban elutasított művészeti forma vált standardtá. Amit a szakterületemen látok: a blokklánc feltalálóit nem a hatalom, a publikációk és az idézettségi index növelése érdekelte, csak valami jót akartak tenni. Így hát leültek és elkezdték csinálni. Hiányzott belőlük egy bizonyos technikai mélység, de ez javítható. Sokkal nehezebb új kreatív ötleteket kitalálni, mint a nem kellően kiforrottakat korrigálni, megerősíteni. Ezeknek a feltalálóknak köszönhetően most van mit csinálnom!
Alexey: Ez hasonló az induló és az örökölt projektek közötti különbséghez. Sok gondolkodási korlátot, korlátot, speciális követelményt stb. örökölünk.
Maurice: Jó hasonlat az elosztott számítástechnika. Gondoljon a blokkláncra úgy, mintha egy startup és elosztott számítástechnika lenne, mint egy nagy, bejáratott vállalat. Az elosztott számítástechnika beszerzése és blokklánccal való egyesítése folyamatban van.
PhD Liskov Barbara felügyelete alatt
Vitalij: Sok kérdésünk van még! Utánajártunk a hátterének, és érdekes tényre bukkantunk a doktori címével kapcsolatban. Igen, ez nagyon régen volt, de úgy tűnik, fontos téma. Ön saját irányítása alatt szerezte meg a PhD fokozatát ! Barbara nagyon jól ismert a programnyelvi közösségben, és általában véve is nagyon ismert ember. Logikus, hogy kutatása a programozási nyelvek területére irányult. Hogyan váltott át a párhuzamos számítástechnikára? Miért döntöttél úgy, hogy témát váltasz?
Maurice: Akkoriban Barbara és csoportja csak az elosztott számítástechnikával foglalkozott, ami nagyon új ötlet volt. Voltak olyanok is, akik szerint az elosztott számítástechnika nonszensz, és értelmetlen az egymással kommunikáló számítógépek. Az elosztott számítástechnikával foglalkozó egyik probléma, amely megkülönbözteti a központosított számítástechnikától, a hibatűrés. Hosszas kutatás után úgy döntöttünk, hogy egy elosztott számítástechnikai programozási nyelvnek olyannak kell lennie, mint az atomi tranzakciók, mert soha nem lehet biztos abban, hogy egy távoli hívás sikeres lesz. A tranzakciók megtörténte után felmerül a párhuzamosságkezelés problémája. Ezután rengeteg munka folyt a rendkívül párhuzamos tranzakciós adatstruktúrák megszerzésén. Aztán amikor leérettségiztem, elmentem és elkezdett keresni egy témát, amin dolgozni lehetne. Eszembe jutott, hogy a számítástechnika az egyes számítógépekről a számítógépek hálózataira költözött. A többprocesszorok a fejlődés természetes folytatását jelentenék – a „többmagos” szó még nem létezett. Arra gondoltam: mi egyenértékű az atomi tranzakciókkal egy többmagos rendszer esetében? Határozottan nem rendszeres tranzakciók, mert túl nagyok és nehezek. És így jött az ötlet és így jött az egész várakozás nélküli szinkronizálás. Ezzel arra a kérdésre próbáltunk választ adni, hogy mi az atomi tranzakciók analógja egy megosztott memóriával rendelkező többprocesszoros rendszerben. Első pillantásra ez a mű teljesen másnak tűnhet, de valójában ugyanannak a témának a folytatása.
A világ többmagosra vár
Vitalij: Említetted, hogy akkoriban nagyon kevés többmagos számítógép volt, igaz?
Maurice: Egyszerűen nem voltak ott. Több úgynevezett szimmetrikus multiprocesszor volt, amelyek alapvetően ugyanarra a buszra csatlakoztak. Ez nem működött túl jól, mert valahányszor egy új cég valami hasonlót hozott létre, az Intel egyetlen processzort bocsátott ki, amely jobb volt a többprocesszorosnál.
Alekszej: Ez nem azt jelenti, hogy azokban az ókorban ez inkább elméleti tanulmány volt?
Maurice: Ez nem egy elméleti tanulmány volt, hanem inkább egy spekulatív tanulmány. Mindez nem arról szólt, hogy sok tétellel dolgozzunk, hanem hipotéziseket állítottunk fel egy akkor még nem létező architektúráról. Erre való a kutatás! Egyetlen cég sem csinált volna ilyesmit; mindez a távoli jövőből való. Valójában ez így volt egészen 2004-ig, amikor is megjelentek az igazi többmagos processzorok. Mivel a processzorok túlmelegednek, a processzort még kicsinyítheti, de gyorsabbá nem. Emiatt megtörtént az átállás a többmagos architektúrákra. És akkor ez azt jelentette, hogy hirtelen hasznot húztak a múltban kidolgozott koncepcióinkból.
Alexey: Mit gondol, miért csak a XNUMX-es években jelentek meg a többmagos processzorok? Akkor miért olyan késő?
Maurice: Ez a hardveres korlátok miatt van. Az Intel, az AMD és más cégek nagyon jók a processzorsebesség növelésében. Amikor egy ponton a processzorok elég kicsik lettek ahhoz, hogy már nem tudták növelni az órajelet, mert a processzorok elkezdtek kiégni. Kicsinyítheti őket, de nem gyorsabb. Ami bennük van - a nagyon kicsi processzor helyett nyolc, tizenhat vagy harminckét processzort is elhelyezhetnek ugyanabba a háztérfogatba, ahol korábban csak egy fért be. Mostantól többszálú és gyors kommunikáció van köztük, mert megosztják a gyorsítótárakat. De nem kényszerítheti őket arra, hogy gyorsabban futjanak – van egy nagyon konkrét sebességkorlátozás. Apránként tovább fejlődnek, de már nem annyira. A fizika törvényei a fejlesztések útjában álltak.
Az új világ új problémákat hoz. NUMA, NVM és architektúra hackelés
Alexey: Nagyon ésszerűen hangzik. Az új többmagos processzorokkal új problémák jelentkeztek. Számított Ön és kollégái ezekre a problémákra? Talán előre tanulmányozta őket? Az elméleti tanulmányokban gyakran nem könnyű megjósolni az ilyen dolgokat. Mikor merültek fel problémák, hogyan feleltek meg az Ön és kollégái elvárásainak? Vagy teljesen újak voltak, és Önnek és kollégáinak sok időt kellett töltenie a felmerülő problémák megoldásával?
Vitalij: Hozzáteszem Alekszej kérdéséhez: helyesen jósolta meg a processzor architektúráját, miközben az elméletet tanulmányozta?
Maurice: Nem 100%. De úgy gondolom, hogy kollégáimmal jó munkát végeztünk a megosztott memóriával rendelkező többmagos előrejelzésben. Úgy gondolom, hogy helyesen jeleztük előre, milyen nehézségekbe ütközik a zárak nélkül működő párhuzamos adatstruktúrák fejlesztése. Az ilyen adatstruktúrák sok alkalmazás számára fontosak voltak, bár nem mindegyik, de gyakran valóban szükség van egy nem zároló adatszerkezetre. Amikor feltaláltuk őket, sokan azzal érveltek, hogy ez hülyeség, hogy minden jól működik a zárakkal. Jól megjósoltuk, hogy számos programozási és adatszerkezeti problémára lesz kész megoldás. Voltak összetettebb problémák is, mint pl – egyenetlen hozzáférés a memóriához. Valójában a többmagos processzorok feltalálásáig nem is gondoltak rájuk, mert túlságosan specifikusak voltak. A kutatói közösség általában előre látható kérdéseken dolgozott. Bizonyos architektúrákkal kapcsolatos hardverproblémáknak a szárnyakon kellett várniuk – valójában ezeknek az architektúráknak a megjelenése. Például senki sem dolgozott igazán GPU-specifikus adatstruktúrákon, mert akkor még nem léteztek GPU-k. Bár sokat dolgoztak rajta , ezek az algoritmusok használatra készek voltak, amint a megfelelő hardver elérhetővé vált. Mindent azonban lehetetlen előre látni.
Alexey: Ha jól értem, a NUMA egyfajta kompromisszum a költségek, a teljesítmény és néhány egyéb dolog között. Van ötletetek, hogy a NUMA miért jelent meg ilyen későn?
Maurice: Szerintem a NUMA a memória előállításához használt hardver problémái miatt létezik: minél távolabb vannak a komponensek, annál lassabb a hozzáférésük. Másrészt ennek az absztrakciónak a második értéke a memória egységessége. Tehát a párhuzamos számítások egyik jellemzője, hogy az összes absztrakció kissé törött. Ha a hozzáférés tökéletesen egységes lenne, minden memória egyenlő távolságra lenne, de ez gazdaságilag, sőt talán fizikailag is lehetetlen. Ezért ez a konfliktus keletkezik. Ha úgy írod le a programot, mintha a memória egységes lenne, akkor nagy valószínűséggel helyes lesz. Abban az értelemben, hogy nem ad rossz válaszokat. De az ő előadása sem fogja elkapni a csillagokat az égről. Hasonlóképpen, ha írsz A gyorsítótár-hierarchia megértése nélkül maga a blokkolás helyes lesz, de elfelejtheti a teljesítményt. Bizonyos értelemben olyan programokat kell írnod, amelyek egy nagyon egyszerű absztrakción élnek, de túl kell csapnod azokat az embereket, akik ezt az absztrakciót adták: tudnod kell, hogy az absztrakció alatt van valami memóriahierarchia, hogy van egy busz közted és ez az emlék között, és így tovább. Így van némi konfliktus az egyénileg hasznos absztrakciók között, ami nagyon konkrét és pragmatikus problémákhoz vezet.
Vitalij: Mi lesz a jövővel? Meg tudja jósolni, hogy a processzorok hogyan fognak tovább fejlődni? Van egy elképzelés, hogy az egyik válasz a tranzakciós memória. Valószínűleg van még valami raktáron.
Maurice: Néhány nagy kihívás előtt áll. Az egyik az, hogy a koherens emlékezet csodálatos absztrakció, de különleges esetekben kezd felbomlani. Így például a NUMA egy élő példa valamire, ahol továbbra is úgy tehet, mintha egységes memória létezne. Valójában nem, a termelékenység megsiratja. Egy ponton az építészeknek fel kell hagyniuk az egyetlen memória architektúra gondolatával; nem lehet örökké úgy tenni, mintha. Új programozási modellekre lesz szükség, amelyek elég könnyen használhatóak és elég nagy teljesítményűek ahhoz, hogy a mögöttes hardvert hatékonyan tegyék. Ez egy nagyon nehéz kompromisszum, mert ha megmutatja a programozóknak a hardverben ténylegesen használt architektúrát, megőrülnek. Túl bonyolult és nem hordozható. Ha túl egyszerű felületet mutat be, a teljesítmény gyenge lesz. Így sok nagyon nehéz kompromisszumot kell megtenni ahhoz, hogy hasznos programozási modelleket biztosítsunk, amelyek az igazán nagy, többmagos processzorokhoz alkalmazhatók. Nem vagyok benne biztos, hogy 2000 magos számítógépen a szakemberen kívül más is képes programozni. És hacsak nem nagyon speciális vagy tudományos számítástechnikával vagy kriptográfiával vagy valami hasonlóval foglalkozik – még mindig egyáltalán nem világos, hogyan kell helyesen csinálni.
Egy másik hasonló terület a speciális architektúrák. A grafikus gyorsítók már régóta léteznek, de klasszikus példájává váltak annak, hogyan lehet egy speciális típusú számítástechnikát egy dedikált chipen futtatni. Ez hozzáadja a maga kihívásait: hogyan kommunikál egy ilyen eszközzel, hogyan programozza azt. Nemrég a környék problémáin dolgoztam . Fogsz egy kis processzort, és egy hatalmas memóriadarabhoz ragasztod, hogy a memória L1 gyorsítótár sebességgel működjön, majd kommunikáljon egy olyan eszközzel, mint pl. – a processzor azzal van elfoglalva, hogy új feladatokat tölt be a memóriamagba. Egy másik érdekes példa adatszerkezetek és kommunikációs protokollok tervezése az ilyen dolgokhoz. Tehát az egyedi processzorok és hardverek még jó ideig javulni fognak.
Alexey: Mi a helyzet a nem felejtő memóriával?)?
Maurice: Ó, ez egy másik nagyszerű példa! Az NVM nagymértékben megváltoztatja azt a módot, ahogyan olyan dolgokat nézünk, mint például az adatstruktúrák. A nem felejtő memória bizonyos értelemben azt ígéri, hogy valóban felgyorsítja a dolgokat. De ez nem fogja megkönnyíteni az életet, mert a legtöbb processzor, gyorsítótár és regiszter továbbra is ingatag. Amikor egy összeomlás után elindul, az állapota és a memóriája nem lesz pontosan ugyanaz, mint az ütközés előtt. Nagyon hálás vagyok az NVM-en dolgozóknak – még sokáig lesz dolguk a kutatóknak, hogy kitalálják a helyességi feltételeket. A számítások akkor helyesek, ha túlélnek egy összeomlást, amelyben a gyorsítótárak és a regiszterek tartalma elveszik, de a fő memória érintetlen marad.
Fordítók vs processzorok, RISC vs CISC, megosztott memória vs üzenettovábbítás
Vladimir: Mi a véleménye a „fordítók kontra processzorok” dilemmáról az utasításkészlet szempontjából? Hadd magyarázzam el azoknak, akik nem értenek hozzá: ha a ferde memóriára vagy valami hasonlóra megyünk, használhatunk egy nagyon egyszerű parancskészletet, és megkérhetjük a fordítót, hogy állítson elő összetett kódot, amely kihasználja az új előnyöket. Vagy mehetünk a másik irányba: hajtsunk végre összetett utasításokat, és kérjük meg a processzort, hogy rendezze át az utasításokat, és végezzen velük egyéb manipulációkat. Mit gondolsz róla?
Maurice: Nem igazán tudok válaszolni erre a kérdésre. Ez a vita négy évtizede tart. Volt idő, amikor között parancsok halmaza és a polgárháborúkat parancsok sorozata vívta. Egy ideig a RISC-esek győztek, de aztán az Intel átépítette a motorjaikat úgy, hogy belsőleg csökkentett utasításkészletet használtak, a teljes készletet pedig kifelé exportálták. Valószínűleg ez egy olyan téma, amelyben minden új generációnak meg kell találnia a saját kompromisszumait és meg kell hoznia a döntéseit. Nagyon nehéz megjósolni, hogy ezek közül melyik lesz jobb. Tehát minden jóslat, amit mondok, egy bizonyos ideig igaz lesz, majd egy ideig ismét hamis, majd ismét igaz.
Alexey: Mennyire gyakori az iparban, hogy egyes ötletek több évtizedig nyernek, a következőben pedig veszítenek? Van más példa is ilyen időszakos változásokra?
Maurice: Az elosztott számítástechnika témájában vannak, akik hisznek és akik hisznek benne . Kezdetben az elosztott számítástechnikában a párhuzamos számítás üzenettovábbítást jelent. Aztán valaki felfedezte, hogy osztott memóriával sokkal könnyebb programozni. A másik oldal azt mondta, hogy a megosztott memória túl bonyolult, mert zárakat és hasonlókat igényel, ezért érdemes áttérni azokra a nyelvekre, ahol egyszerűen csak üzenettovábbítás létezik. Valaki megnézte, mi sült ki ebből, és azt mondta: „Hú, ez az üzenetküldő megvalósítás nagyon hasonlít a megosztott memóriára, mert sok-sok ilyen kis modult hoz létre, üzeneteket küldenek egymásnak, és mindannyian "Csináljunk jobb megosztott memória adatbázist!" Mindez újra és újra megismétlődik, és nem lehet azt mondani, hogy valamelyik félnek biztosan igaza van. Mindig az egyik oldal fog dominálni, mert amint az egyik majdnem nyer, az emberek újra és újra kitalálják a másik fejlesztésének módjait.
A rideg többszálú kód írásának művészete
Alexey: Ez nagyon érdekes. Például, amikor kódot írunk, bármilyen programozási nyelvről is legyen szó, általában absztrakciókat kell létrehoznunk, például cellákat, amelyek olvashatók és írhatók. Valójában azonban bizonyos fizikai szinten ez úgy tűnhet, mintha üzenetet küldenének hardveres buszon keresztül a különböző számítógépek és más eszközök között. Kiderül, hogy a munka az absztrakció mindkét szintjén egyszerre történik.
Maurice: Teljesen igaz, hogy a megosztott memória az üzenettovábbításra épül – buszok, gyorsítótárak és így tovább. De nehéz programokat írni üzenettovábbítással, ezért a hardver szándékosan hazudik, úgy tesz, mintha valami egységes memóriával rendelkezne. Ez megkönnyíti, hogy egyszerű, helyes programokat írjon, mielőtt a teljesítmény romlani kezd. Akkor azt fogja mondani: úgy tűnik, ideje megbarátkozni a gyorsítótárral. És akkor elkezd aggódni a gyorsítótár helye miatt, és onnantól megy. Bizonyos értelemben feltöri az absztrakciót: tudja, hogy ez nem csak lapos, egységes memória, és ezt a tudást gyorsítótár-barát programok írásához fogja használni. Ezt kell tennie valódi problémák esetén. Ez a konfliktus a kapott édes, egyszerű, szép absztrakció és a mögöttes hardver borzalmasan bonyolult megvalósítása között az, ahol mindenki meg fogja kötni a saját kompromisszumát. Van egy könyvem a többprocesszorokról és a szinkronizálásról, és egy ponton egy fejezetet akartam írni az adatstruktúrákról java.util.concurrent. Ha megnézed őket, pl Ezek csodálatos műalkotások. (A szerkesztő megjegyzése: Aki ismeri a Java nyelvet, annak legalább egy pillantást kell vetnie a megvalósításra ConcurrentSkipListMap, a linkeket meg tudod nézni и ). De az én szemszögemből felelőtlenség lenne ezeket megmutatni a diákoknak, mert egy ilyen adatstruktúra olyan, mint egy fickó a cirkuszban, amely kötélen fut egy medvegödör fölött. Ha csak egy apró részletet is megváltoztat, az egész szerkezet összeomlik. Ez a kód már csak azért is nagyon gyors és elegáns, mert tökéletesen meg van írva, de a legkisebb változtatás teljes kudarchoz vezet. Ha ezt a kódot példának adom a hallgatóknak, azonnal azt mondják: én is meg tudom csinálni! És akkor valami repülőgép lezuhan, vagy egy atomreaktor felrobban, és én bűnös leszek, hogy túl sok információt adtam meg nekik rosszkor.
Alexey: Amikor kicsit fiatalabb voltam, sokszor próbáltam tanulmányozni például Doug Lee forráskódját, java.util.concurrent, mivel nyílt forráskódú, nagyon könnyű megtalálni és megérteni, hogy mi történik ott. Nem sikerült túl jól: gyakran teljesen érthetetlen, hogy Doug miért döntött így, amikor mindenki másképp csinálja. Hogyan magyarázza el ezeket a dolgokat a hallgatóinak? Létezik-e konkrét helyes módszer például egy hardcore algoritmus konkrét részleteinek leírására? Hogy csinálod ezt?
Maurice: A rajztanároknak van egy közhelyük, amire először emlékeznek: ha úgy akarsz rajzolni, mint Picasso, először meg kell tanulnod egyszerű valósághű képeket rajzolni, és csak ha ismered a szabályokat, kezdheted meg azokat megszegni. Ha rögtön a szabályok megszegésével kezded, káoszba kerülsz. Először is megtanítom a tanulóknak, hogyan írjanak egyszerű, helyes kódot anélkül, hogy aggódnának a teljesítmény miatt. Azt akarom mondani, hogy itt összetett időzítési problémák leselkednek, ezért ne aggódjon a gyorsítótárak miatt, ne aggódjon a memóriamodellek miatt, csak ellenőrizze, hogy minden megfelelően működik-e. Ez már elég nehéz: a modern programozás önmagában nem könnyű, főleg az új hallgatók számára. És amikor megérzik, hogyan kell a megfelelő programokat írni, azt mondom: nézd meg ezt a két spinlock implementációt: az egyik nagyon lassú, a másik pedig szintén nem túl, de jobb. Matematikailag azonban a két algoritmus ugyanaz. Valójában az egyik gyorsítótár lokalitást használ. Az egyik helyileg gyorsítótárazott adatokon fut, a másik pedig ismételten a buszon keresztül hajt végre műveleteket. Nem tudsz hatékony kódot írni, ha nem érted, mi az, és nem tudod, hogyan lehet megtörni az absztrakciót, és megnézni a mögöttes struktúrát. De ezt nem fogod tudni azonnal elkezdeni. Vannak, akik azonnal elkezdik ezt csinálni, és hisznek a saját zsenialitásukban, általában rosszul végződik, mert nem értik az elveket. Senki sem rajzol úgy, mint Picasso, és nem ír olyan programokat, mint Doug Lee, frissen az egyetemről az első héten. Évekbe telik, mire elérjük ezt a tudásszintet.
Alexey: Kiderült, hogy a problémát két részre osztja: az első a helyesség, a második a teljesítmény?
Maurice: Pontosan. És pontosan ebben a sorrendben. A probléma része az, hogy az új tanulók nem értik meg, hogy a helyességet nehéz elérni. Első pillantásra azt mondják: ez nyilvánvalóan helyes, csak gyorsítani kell. Ezért néha úgy mesélek nekik egy kezdetben hibás algoritmusról, mintha az helyes lenne.
Hogyan tanítsuk meg a diákokat összetett többszálú kód írására
Alexey: Csak azért, hogy lássák, érzékelik-e a fogást?
Maurice: Mindig előre figyelmeztetem, hogy néha helytelen algoritmusokat fogok javasolni. Nem szabad megtéveszteni az embereket. Azt javaslom, hogy vegyék egy kis sóval az információt. Ha mondok valamit, és azt mondom: „Nézd, ez nyilvánvalóan helyes” - ez azt jelzi, hogy valahol megpróbálnak becsapni, és el kell kezdened kérdéseket feltenni. Ezután arra próbálom ösztönözni a tanulókat, hogy továbbra is tegyenek fel kérdéseket, majd azt javaslom: „Mi lesz, ha úgy hagyjuk a dolgokat, ahogy vannak?” És azonnal látják a hibát. De sokkal nehezebb meggyőzni a tanulókat arról, hogy aggódniuk kell a helyesség miatt, mint amilyennek első pillantásra tűnik. Sok ilyen diák középiskolás programozási tapasztalattal rendelkezik, néhányan már munkát is kaptak, és ott végeztek programozást, és mindannyian tele vannak önbizalommal. Ez olyasmi, mint a hadsereg: először meg kell változtatni a hangulatukat, hogy meggyőzze őket, hogy türelmesen közelítsenek a felmerülő problémák megoldásához. Vagy talán olyan, mint a buddhista szerzetesek: először megtanulnak érvelni a helyességről, és miután megértik a helyességgel kapcsolatos érvelés módjait, átléphetnek a következő szintre, és elkezdenek aggódni a teljesítmény miatt.
Alexey: Vagyis néha nem működő példákat mutatsz a diákoknak, aminek köszönhetően visszajelzést kapsz arról, hogy megértik-e a probléma lényegét, hogy rossz kódot és rossz eredményt találnak-e. Szóval, a diákok általában boldoggá vagy szomorúvá tesznek?
Maurice: A diákok szinte mindig megtalálják a hibát. Ha túl lassan keresnek, vezető kérdéseket teszek fel, és itt fontos megérteni, hogy ha soha nem téveszti meg őket, akkor a szavait a végső igazságként fogják felfogni. Aztán megunják, és elkezdenek elaludni, miközben a Facebook-ot olvassák a laptopjukon óra közben. De ha előre megmondod nekik, hogy átverik őket, és hülyének néznek, ha nem érzékelnek egy trükköt, sokkal éberebbek lesznek. Ez több szempontból is jó. Szeretném, ha a diákok ne csak a kérdés megértését kérdőjelezzék meg, hanem a tanár tekintélyét is. Az ötlet az, hogy egy diák bármikor felemelheti a kezét, és azt mondhatja: szerintem rossz, amit most mondtál. Fontos tanulási eszköz. Nem akarom, hogy a hallgatók közül valaki üljön és csendben gondolja magában: mindez teljes hülyeségnek tűnik, de a kezet felemelni túl ijesztő, és különben is, ő professzor, szóval minden, amit mond, az igazság. Ezért, ha előre figyelmeztetik őket, hogy nem feltétlenül igaz minden, amit elmondanak, ösztönözni kell őket, hogy jobban odafigyeljenek az anyagra. Világossá teszem, hogy felemelheti a kezét, és kérdéseket tehet fel. Lehet, hogy a kérdésed hülyén vagy naivnak hangzik, de gyakran így merülnek fel a legjobb kérdések.
Alexey: Nagyon érdekes. Általában az embereknek van valamilyen pszichológiai akadálya, amely nem teszi lehetővé számukra, hogy kérdést tegyenek fel egy professzornak. Főleg, ha sokan vannak a teremben, és mindenki attól tart, hogy a hülye kérdésed megvitatása elveszi ezeknek az embereknek az idejét. Vannak trükkök ennek kezelésére?
Maurice: Gyakran megállok és klasszikus kérdéseket teszek fel. Helyes lenne-e egy állítás, vagy hogyan oldanák meg a megvitatott problémát. Ez kulcsfontosságú művelet, különösen egy óra elején, amikor az emberek még a legkisebb dolgot is zavarba ejtik. Feltesz egy kérdést a diákoknak, és nem mondasz többet. Csend van, mindenki feszült egy kicsit, a feszültség nő, aztán hirtelen valaki nem bírja, megtörik és mondja a választ. Így fordítod meg a helyzetet: tovább hallgatni nehezebb és kényelmetlenebb lesz, mint válaszolni! Ez egy szokásos pedagógiai trükk. A világon minden tanárnak tudnia kell, hogyan kell ezt csinálni.
Alekszej: Most egy kiváló címet kaptunk ennek az interjúnak: „Könnyebb válaszolni, mint hallgatni.”
Vitalij: Hadd kérdezzem meg még egyszer. Topológiai bizonyításokon dolgozol. Egyáltalán hogy keveredtél ebbe, mert az elosztott számítástechnika és a topológia teljesen más dolog!
Maurice: Van egy rejtett kapcsolat. Amikor matematikát tanultam, tiszta matematikát tanultam. Nem érdekelt igazán a számítógép, amíg a tanulmányaim véget nem értek, és nem találtam szembesülni azzal a sürgető szükségszerűséggel, hogy állást kell keresnem. Diákként algebrai topológiát tanultam. Sok évvel később, miközben egy problémán dolgoztunk, az úgynevezett , grafikonokat használtam a probléma modellezésére, és ahogy akkoriban úgy tűnt, megtaláltam a megoldást. Csak le kellett ülni és körbejárni a számlálást. Próbáljon megfelelő választ találni ezen a grafikonon. De az algoritmusom nem működött: kiderült, hogy örökké körbe fog futni. Sajnos mindezt nem lehetett megmagyarázni a gráfelmélet formális nyelvén – azon, amelyet minden informatikus ismer. És akkor eszembe jutott, hogy sok évvel ezelőtt, még a topológiaórákon, használtuk ezt a fogalmat , amely a grafikonok általánosítása magasabb dimenziókra. Aztán feltettem magamnak a kérdést: mi történne, ha a problémát egyszerű komplexumok formájában újrafogalmaznánk? Ez lett a kulcsfontosságú pillanat. Egy erősebb formalizmus használatával a probléma hirtelen sokkal egyszerűbbé válik. Az emberek sokáig harcoltak ellene grafikonok segítségével, de nem tudtak mit tenni. És még most sem tudnak - a helyes válasz nem egy algoritmus, hanem a probléma megoldásának lehetetlenségének bizonyítéka. Vagyis ilyen algoritmus egyszerűen nem létezik. De vagy egyszerű komplexusokon alapul, vagy olyan dolgokon, amelyeket az emberek úgy tettek, mintha nem tekintenének egyszerű komplexeknek. Csak azért, mert valamit új néven nevezel, nem veszíti el a lényegét.
Vitalij: Kiderült, hogy csak szerencséd volt?
Maurice: A szerencse mellett az is készenlét. Ez azt jelenti, hogy ne felejtse el a korábban tanult „haszontalan” dolgokat. Minél több haszontalan dolgot tanulsz meg, annál több ötletet nyerhetsz ki, ha új problémával szembesülsz. Ez a fajta intuitív mintaillesztés azért fontos, mert... Tegyük ezt, ez egy lánc: először azt tapasztaltam, hogy a grafikonok egyáltalán nem, vagy egyáltalán nem működnek, eszembe jutott valami a nyolcas eseményekből évvel ezelőtt és diákéveim, amikor ezeket az egyszerű komplexumokat tanulmányoztuk. Ez viszont lehetővé tette, hogy megtaláljam a régi topológia tankönyvemet, és visszatöltsem a fejembe. De ha nem lett volna ez a régi tudás, soha nem jutottam volna előre az eredeti probléma megoldásában.
„A többprocesszoros programozás művészete” című könyv új kiadása
Alexey: Mondott néhány szót a könyvéről. Valószínűleg nem az a legrosszabb titok, hogy Ön írta a világ leghíresebb többszálú könyvét, . Már körülbelül 11 éves és azóta csak adták ki . Lesz második kiadás?
Maurice: Jó, hogy megkérdezted! Nagyon hamar, vagy három hónap múlva lesz. Van még két szerző, sokkal több anyagot adtunk hozzá, javítottuk az elágazás/csatlakozás párhuzamosságról szóló részt, írtunk egy részt a MapReduce-ról, sok új dolgot adtunk hozzá, és kidobtuk a felesleges dolgokat – ami nagyon érdekes volt az írás idején az első kiadás, de ma már nincs meg. Az eredmény egy nagyon komolyan átdolgozott könyv lett.
Alekszej: Már minden megtörtént, már csak ki kell engedni?
Maurice: Néhány fejezetet még dolgozni kell. Kiadónk (aki szerintem már utál minket) még mindig azt az üzenetet próbálja eljuttatni, hogy gyorsabban kellene dolgoznunk. Nagyon le vagyunk maradva a menetrendtől. Elméletileg elkészíthettük volna ezt a könyvet néhány évvel korábban.
Alexey: Van esély rá, hogy karácsony előtt megkapjuk a könyv új verzióját?
Maurice: Ez a célunk! De annyiszor jósoltam már győzelmet, hogy már senki sem hisz nekem. Valószínűleg ebben a kérdésben sem szabad túlságosan megbíznia bennem.
Alexey: Mindenesetre ez fantasztikus hír. Nagyon tetszett a könyv első kiadása. Mondhatni rajongó vagyok.
Maurice: Remélem, az új kiadás méltó lesz a lelkesedésedhez, köszönöm!
Hogyan találták fel a tranzakciós memóriát
Vitalij: A következő kérdés a tranzakciós memóriára vonatkozik. Ha jól értem, te úttörő vagy ezen a téren, akkor találtad ki, amikor még senki nem gondolt ilyesmire. Miért döntött úgy, hogy erre a területre költözik? Miért tűntek számodra fontosnak a tranzakciók? Gondoltad volna, hogy egyszer majd hardveresen is implementálják?
Maurice: Diplomás kutató korom óta ismerem a tranzakciókat.
Vitalij: Igen, de ezek különböző tranzakciók!
Maurice: Elliott Moss-szal dolgoztam a nem akadályozó szemétgyűjtésen. A problémánk az volt, hogy néhány szót akartunk atomosan megváltoztatni a memóriában, és akkor az algoritmusok nagyon egyszerűek lesznek, és legalább néhányuk hatékonyabb lesz. Használata a a párhuzamos architektúra által biztosított, lehet valamit csinálni, de ez nagyon nem hatékony és csúnya, mert az indirekt indirektság rétegeivel kellene megküzdenie. Meg akarom változtatni a memóriaszavakat, és váltanom kell, mert csak egy mutatót tudok megváltoztatni, ezért valamiféle könyvtárszerű szerkezetre kell mutatniuk. Arról beszélgettünk, milyen jó lenne, ha a hardvert úgy tudnánk megváltoztatni, hogy az egyidejű felvételt is tudjon készíteni. Úgy tűnik, Elliott észrevette ezt: ha megnézzük a gyorsítótár-koherencia protokollokat, máris ezek biztosítják a szükséges funkciók nagy részét. Egy optimista tranzakció során a gyorsítótár koherencia protokollja észreveszi, hogy időzítési ütközés van, és a gyorsítótár . Mi történik, ha spekulatívan futtat egy tranzakciót a gyorsítótárán, és a koherencia protokoll mechanizmusait használja az ütközések észlelésére? A spekulatív hardverarchitektúrát könnyű volt megtervezni. Szóval ezt írtuk a tranzakciós memóriáról. Ugyanakkor a cég, ahol dolgoztam, a Digital Equipment Corporation egy új 64 bites processzort készített Alpha néven. Így hát elmentem és tartottam egy prezentációt az Alpha fejlesztői csoportnak a csodálatos tranzakciós memóriánkról, és megkérdezték: Mennyi plusz bevételhez jutna cégünk, ha mindezt közvetlenül a processzorhoz adnánk? És erre végképp nem tudtam válaszolni, mert technológus vagyok, nem vagyok marketing specialista. Tényleg nem volt mit válaszolnom. Nem nagyon nyűgözte le őket, hogy nem tudok semmit.
Vitalij: Milliárdok! Mondjuk csak milliárdokat!
Maurice: Igen, ezt kellett volna mondanom. Most, a startupok és mindenek korában, tudom, hogyan kell üzleti tervet írni. Hogy hazudhat egy kicsit a potenciális nyereség nagyságáról. De akkoriban ez naivnak tűnt, ezért csak annyit mondtam: „Nem tudom.” Ha megnézzük a tranzakciós emlékezetről szóló kiadvány történetét, észrevehetjük, hogy egy év elteltével többször is hivatkoztak rá, majd körülbelül tíz évig senki sem hivatkozott erre a papírra. Az idézetek 2004 körül jelentek meg, amikor megjelentek az igazi többmagosak. Amikor az emberek felfedezték, hogy párhuzamos kódírással pénzt lehet keresni, új kutatások kezdődtek. Ravi Rajwar , amely valamilyen módon bevezette a fősodorba a tranzakciós memória fogalmát. (A szerkesztő megjegyzése: A cikknek van egy második változata, amely 2010-ben jelent meg és szabadon elérhető ). Hirtelen rájöttek az emberek, hogy mindez pontosan hogyan használható fel, hogyan lehet felgyorsítani a hagyományos, zárral ellátott algoritmusokat. Jó példa arra, ami a múltban csak érdekes tudományos problémának tűnt. És igen, ha annak idején megkérdezte volna, hogy szerintem mindez fontos lesz-e a jövőben, azt mondtam volna: persze, de hogy pontosan mikor, az nem világos. Talán 50 év múlva? A gyakorlatban ez csak egy évtizednek bizonyult. Nagyon jó, ha csinálsz valamit, és már tíz év után az emberek észreveszik.
Miért érdemes kutatásokat végezni az elosztott számítástechnika területén
Vitalij: Ha új kutatásokról beszélünk, mit tanácsolna az olvasóknak – elosztott számítástechnikát vagy többmagos és miért?
Maurice: Manapság könnyű többmagos processzort szerezni, de nehezebb igazi elosztott rendszert felállítani. Azért kezdtem el rajtuk dolgozni, mert valami mást akartam csinálni, mint a doktori disszertációm. Mindig ezt a tanácsot adom az új hallgatóknak: ne írjon folytatást a szakdolgozatának, hanem próbáljon meg új irányba menni. Ráadásul a többszálú feldolgozás is egyszerű. Kísérletezhetek a laptopomon futó saját villámmal anélkül, hogy felkelnék az ágyból. De ha hirtelen egy igazi elosztott rendszert akarnék létrehozni, akkor rengeteg munkát kellene végeznem, hallgatókat vonzanom, stb. Lusta vagyok, és szívesebben dolgoznék többmagos rendszeren. Többmagos rendszereken is könnyebb kísérletezni, mint elosztott rendszereken, mert még egy hülye elosztott rendszerben is túl sok tényezőt kell ellenőrizni.
Vitalij: Mit csinálsz most, a blokkláncot kutatod? Mely cikkekre érdemes először figyelni?
Maurice: Nemrég jelent meg , amelyet tanítványommal, Vikram Saraffal írtam, különösen egy beszélgetéshez a címen három héttel ezelőtt Párizsban. Ez a cikk a gyakorlati elosztott rendszerekről szól, amelyben azt javasoljuk, hogy az Ethereum többszálas legyen. Jelenleg az intelligens szerződések (a blokkláncon futó kód) szekvenciálisan hajtódnak végre. Korábban írtunk egy cikket, amely arról beszélt, hogyan lehet spekulatív tranzakciókkal felgyorsítani a folyamatot. Sok ötletet merítettünk a szoftveres tranzakciós memóriából, és azt mondtuk, hogy ha ezeket az ötleteket az Etherium virtuális gép részévé teszi, akkor minden gyorsabban fog működni. Ehhez azonban az kell, hogy a szerződésekben ne legyenek adatütközések. És akkor azt feltételeztük, hogy a való életben tényleg nincsenek ilyen konfliktusok. De nem volt módunk kideríteni. Aztán eszünkbe jutott, hogy közel egy évtizednyi valódi szerződéstörténet van a kezünkben, ezért kidobtuk az Ethereum blokkláncot, és feltettük magunknak a kérdést: mi történne, ha ezeket a történelmi feljegyzéseket párhuzamosan hajtanák végre? Jelentős sebességnövekedést tapasztaltunk. Az Ethereum kezdeti napjaiban a sebesség nagyon megnőtt, de ma már minden valamivel bonyolultabb, mert kevesebb a szerződés, és megnőtt a sorozatosítást igénylő adatokkal kapcsolatos konfliktusok valószínűsége. De mindez kísérleti munka valós történelmi adatokkal. A jó dolog a blokkláncban, hogy örökké mindenre emlékszik, így visszamehet az időben és tanulmányozhatjuk, mi történt volna, ha különböző algoritmusokat használunk a kód futtatásához. Hogyan tetszett volna az embereknek az új ötletünk a múltban? Az ilyen kutatásokat sokkal könnyebb és élvezetesebb elvégezni, mert van, ami mindent figyel és mindent rögzít. Ez már valami hasonlóbb a szociológiához, mint az algoritmusok fejlesztéséhez.
Leállt az algoritmusok fejlesztése, és hogyan tovább?
Vitalij: Ideje az utolsó elméleti kérdésnek! Úgy érzi, évről évre csökken a versenyképes adatszerkezetek fejlődése? Úgy gondolja, hogy elértük a platót az adatstruktúrák megértésében, vagy lesz néhány jelentős fejlesztés? Talán vannak olyan okos ötletek, amelyek mindent teljesen megváltoztathatnak?
Maurice: Lehet, hogy a hagyományos architektúrák adatstruktúráiban egy fennsíkra értünk. Az új architektúrák adatstruktúrái azonban még mindig nagyon ígéretes terület. Ha például hardveres gyorsítókhoz szeretne adatstruktúrákat létrehozni, akkor a GPU adatstruktúrái nagyon különböznek a CPU adatstruktúráitól. Amikor adatstruktúrákat fejleszt a blokkláncokhoz, ki kell hashálnia az adatdarabokat, majd el kell helyeznie őket valamibe, pl. , a hamisítás megelőzése érdekében. Az utóbbi időben megnövekedett az aktivitás ezen a területen, sokan nagyon jó munkát végeznek. De úgy gondolom, hogy az új architektúrák és új alkalmazások új adatstruktúrákhoz vezetnek. Hagyományos alkalmazások és hagyományos architektúra – lehet, hogy már nincs sok hely a felfedezésre. De ha letérsz a kitaposott ösvényről, és túlnézel a széleken, őrült dolgokat fogsz látni, amelyeket a mainstream nem vesz komolyan – itt történik minden izgalmas dolog.
Vitalij: Ezért ahhoz, hogy nagyon híres kutató legyek, fel kellett találnom a saját építészetemet :)
Maurice: „Ellophatod” valaki mástól az új architektúrát – sokkal könnyebbnek tűnik!
A Brown Egyetemen dolgozik
Vitalij: Mesélnél nekünk többet erről? hol dolgozol? Az információs technológia kapcsán nem sokat tudni róla. Kevesebbet, mint például az MIT-ről.
Maurice: A Brown Egyetem az Egyesült Államok egyik legrégebbi egyeteme. Szerintem csak a Harvard egy kicsit idősebb. A barna része az ún , amely nyolc legrégebbi egyetem gyűjteménye. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Amolyan régi, kicsi és kissé arisztokratikus egyetem. A fő hangsúly a bölcsészettudományi oktatáson van. Ez nem olyan, mint az MIT, az MIT nagyon speciális és technikai. Brown remek hely az orosz irodalom vagy a klasszikus görög nyelv, és természetesen a számítástechnika tanulmányozására. Az átfogó oktatásra összpontosít. A legtöbb diákunk a Facebookra, az Apple-re, a Google-ra jár – így azt gondolom, hogy diákjainknak nem okoz gondot elhelyezkedni az iparban. A Brownhoz mentem dolgozni, mert korábban a Digital Equipment Corporationnél dolgoztam Bostonban. Ez egy olyan cég volt, amely sok érdekes dolgot talált ki, de tagadta a személyi számítógépek jelentőségét. Nehéz sorsú társaság, amelynek alapítói egykor fiatal forradalmárok voltak, semmit sem tanultak és semmit sem felejtettek el, így mintegy tucat éven belül forradalmárokból reakciósokká váltak. Szerettek azzal viccelődni, hogy a személyi számítógépek a garázsban vannak – természetesen egy elhagyatott garázsban. Teljesen nyilvánvaló, hogy a rugalmasabb cégek tönkretették őket. Amikor világossá vált, hogy a cég bajban van, felhívtam egy barátomat Brownban, ami körülbelül egy órára van Bostontól. Abban az időben nem akartam elhagyni Bostont, mert más egyetemeken nemigen nyíltak meg. Ez volt az az idő, amikor még nem volt annyi állás a számítástechnikában, mint most. Brownnak pedig megvolt a nyitása, nem kellett elköltöznöm az otthonomból, nem kellett a családomat sem, és nagyon szeretek Bostonban élni! Így döntöttem úgy, hogy elmegyek Brownhoz. Tetszik. Csodálatosak a diákok, úgyhogy soha nem is próbáltam máshová menni. A szabadságom alatt egy évig dolgoztam a Microsoftnál, egy évig a haifai Technionhoz jártam, most pedig Algorandban leszek. Sok kollégám van mindenhol, ezért az osztálytermeink fizikai elhelyezkedése nem olyan fontos. De a legfontosabbak a diákok, itt ők a legjobbak. Soha nem próbáltam máshová menni, mert nagyon boldog vagyok itt.
Brown amerikai hírneve ellenére meglepően ismeretlen külföldön. Amint látja, most mindent megteszek, hogy kijavítsam ezt az állapotot.
Különbség az egyetemen és a vállalaton belüli kutatás között
Vitalij: Oké, a következő kérdés a digitális berendezésekre vonatkozik. Kutatóként voltál ott. Mi a különbség egy nagyvállalat K+F részlegén végzett munka és az egyetemi munka között? Mik az előnyei és a hátrányai?
Maurice: Húsz évig dolgoztam a Microsoftnál, szorosan együttműködtem a Sun Microsystems, az Oracle, a Facebook és most az Algorand alkalmazottaival. Mindezek alapján szeretném elmondani, hogy lehet első osztályú kutatásokat végezni cégeknél és egyetemeken is. A lényeges különbség az, hogy egy cégnél kollégákkal dolgozol együtt. Ha hirtelen ötletem támad egy még nem létező projektre, meg kell győznöm a társamat, hogy ez jó ötlet. Ha a Brownnál vagyok, akkor azt mondhatom a hallgatóimnak: dolgozzunk az antigravitáción! Vagy elmennek valaki másért, vagy elvállalnak egy projektet. Igen, finanszírozást kell találnom, támogatási kérelmet kell írnom, és így tovább. Mindenesetre mindig sok diák lesz, és egyoldalúan tudsz majd dönteni. De az egyetemen valószínűleg nem fogsz olyan emberekkel dolgozni, mint te. Az ipari kutatás világában először mindenkit meg kell győznie arról, hogy a projektjét érdemes elvállalni. Nem rendelhetek senkinek semmit. És mindkét munkamódszer értékes, mert ha valami igazán őrülten dolgozol, és a kollégáidat nehéz meggyőzni, könnyebb meggyőzni a végzős hallgatókat – különösen, ha fizetsz nekik. Ha olyanon dolgozik, ami nagy tapasztalatot és mély szakértelmet igényel, akkor olyan kollégákra van szüksége, akik azt mondják: „nem, véletlenül értek ehhez a területhez, és rossz az ötleted, nem fog működni”. Ez nagyon hasznos az időveszteség szempontjából. Továbbá, ha az ipari laboratóriumokban sok időt töltesz jelentések írásával, akkor az egyetemen ezt az időt azzal töltöd, hogy pénzt keresel. Ha azt akarom, hogy a diákok el tudjanak menni valahova, akkor máshol kell rá pénzt keresnem. És minél fontosabb a pozíciója az egyetemen, annál több időt kell fordítania a pénzszerzésre. Szóval most már tudod, minek dolgozom – egy profi koldusnak! Mint az egyik szerzetes, aki kínálótányérral mászkál. Általában ez a két tevékenység kiegészíti egymást. Ezért próbálok élni és a földön tartani a lábam mindkét világban.
Vitalij: Úgy tűnik, egy céget nehezebb meggyőzni, mint más tudósokat.
Maurice: Nehezebb, és sokkal több. Sőt, a különböző területeken más: van, aki teljes körű kutatást végez, míg mások a témájukra koncentrálnak. Ha felmennék a Microsoftra vagy a Facebookra, és azt mondanám: csináljunk antigravitációt, aligha értékelnék. De ha pontosan ugyanezt mondanám a végzős hallgatóimnak, nagy valószínűséggel azonnal munkába állnának, bár most gondjaim lennének - elvégre pénzt kell keresnem. De mindaddig, amíg olyasmit szeretne csinálni, ami összhangban van a vállalat céljaival, ez a vállalat nagyon jó hely lehet a kutatáshoz.
Hidra és SPTDC
Vitalij: A kérdéseim a végéhez közelednek, szóval beszéljünk egy kicsit a közelgő oroszországi utazásról.
Maurice: Igen, alig várom, hogy visszatérjek Szentpétervárra.
Alexey: Megtiszteltetés számomra, hogy idén velünk lehet. Ez a második alkalom Szentpéterváron, igaz?
Maurice: Már a harmadik!
Alexey: Értem, de – határozottan a második. Utoljára hívták az iskolát , most egy betűt változtattunk (C-ről D-re, egyidejűleg elosztottra), hangsúlyozva, hogy idén több terület kapcsolódik kifejezetten az elosztott számítástechnikához. Mondana néhány szót az Iskolában és ?
Maurice: Az iskolában a blokklánc alapjairól szeretnék beszélni, és arról, hogy mit tehetsz vele. Szeretném megmutatni, hogy a blokkláncok nagyon hasonlítanak az általunk ismert többszálú programozáshoz, de megvannak a maguk árnyalatai, és ezeket a különbségeket fontos megérteni. Ha hibát követ el egy normál webes alkalmazásban, az egyszerűen bosszantó. Ha bugos kódot ír be egy pénzügyi alkalmazásba, valaki biztosan ellopja az összes pénzét. Ezek a felelősség és a következmények teljesen más szintjei. Beszélek egy kicsit a munkaigazolásról, az intelligens szerződésekről, a különböző blokkláncok közötti tranzakciókról.
Más előadók is dolgoznak majd mellettem, akiknek szintén van mondanivalójuk a blokkláncról, és megegyeztünk, hogy egyeztetünk egymással, hogy a történeteink jól illeszkedjenek egymáshoz. De a mérnöki jelentéshez szeretnék széles közönség számára érthető magyarázatot adni arra vonatkozóan, hogy miért nem szabad elhinni mindent, amit a blokkláncokról hallasz, miért nagyszerű terület a blokklánc, hogyan illeszkedik más ismert ötletekhez, és miért érdemes bátran nézni. a jövő felé.
Alexey: Ezen kívül azt szeretném mondani, hogy ez nem meetup vagy felhasználói csoport formájában fog megtörténni, mint két évvel ezelőtt. Úgy döntöttünk, hogy az iskola közelében tartunk egy kis konferenciát. Ennek az az oka, hogy a Peter Kuznyecovval folytatott kommunikáció után rájöttünk, hogy az iskola csak száz, talán 120 főre korlátozódik. Ugyanakkor nagyon sok mérnök szeretne kommunikálni Önnel, részt venni előadásokon, és általában érdeklődik a téma iránt. Emiatt új konferenciát hoztunk létre . Egyébként van ötleted, hogy miért a Hydra?
Maurice: Mert hét előadó lesz? És le lehet vágni a fejüket, és új hangszórók nőnek helyettük?
Alexey: Remek ötlet új hangszórók fejlesztéséhez. De valójában van itt egy történet. Emlékezzen Odüsszeusz legendájára, ahol között kellett hajóznia ? A hidra olyan, mint Charybdis. A történet az, hogy egyszer felszólaltam egy konferencián, és a többszálú használatról beszéltem. Ezen a konferencián csak két szám volt. A riport elején elmondtam a teremben a hallgatóságnak, hogy most választhatnak Scylla és Charybdis között. Szellemállatom Charybdis, mert Charybdisnek sok feje van, és a témám többszálú. Így jelennek meg a konferenciák nevei.
Mindenesetre kifogytunk a kérdésekből és az időből. Szóval, köszönöm, barátaim, a nagyszerű interjút, és találkozunk az SPTDC School and Hydra 2019-ben!
Maurice-szal folytathatja a beszélgetést a Hydra 2019 konferencián, amelyet 11. július 12-2019-én rendeznek meg Szentpéterváron. Jön majd jelentéssel . Jegyek vásárolhatók .
Forrás: will.com