- mint számítástechnika professzora a Rochesteri Egyetemen és otthonában, a Wisconsin–Madison Egyetemen öt évig volt dékán. Kutatja és tanítja a hallgatókat a párhuzamos és elosztott programozásról és nyelvi tervezésről.
Michaelt a tankönyvből ismeri a világ , mi a helyzet a munkával Dijkstra-díjat kapott, mint az egyik leghíresebb az elosztott számítástechnika területén. Ön is ismerheti őt ennek az algoritmusnak a szerzőjeként .
Doug Lee-vel együtt kifejlesztette a nem blokkoló algoritmusokat és szinkron sorokat, amelyek a Java-könyvtárakat táplálják. Végrehajtás a JavaSE 6-ban tízszeresére javította a teljesítményt ThreadPoolExecutor.
Tartalom:
- Pályafutás elején, a Rochesteri Egyetemen. Charlotte projekt, Lynx nyelv;
- IEEE méretezhető koherens interfész, MCS zárolás;
- Túlélés egy folyamatosan változó világban;
- Egyre hülyébbek a diákok? Globális trendek, nemzetközivé válás;
- Hatékony munka a tanulókkal;
- Hogyan lehet lépést tartani az új tanfolyamok és könyvek előkészítésével;
- Kapcsolatok az üzleti élet és a tudományos élet között;
- Az ötletek gyakorlati megvalósítása. MCS, MS, CLH, JSR 166, Doug Lee-vel és másokkal együttműködve;
- Tranzakciós memória;
- Új architektúrák. A tranzakciós memória győzelme közel van;
- Nem felejtő memória, Optane DIMM, ultragyors eszközök;
- A következő nagy trend. Kettős adatstruktúra. Hydra.
Az interjút készíti:
Vitalij Aksenov – jelenleg az IST Austria posztdoktora és az ITMO Egyetem Számítástechnikai Tanszékének tagja. 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.
Pályafutás elején, a Rochesteri Egyetemen. Charlotte projekt, Lynx nyelv.
Alex: Először is el akartam mondani, hogy Oroszországban mindannyian nagyon szeretjük a számítástechnikát, az adattudományt és az algoritmusokat. Ez egyenesen obszcén. Mindent elolvastunk . Ezért a közelgő konferencia, iskola és maga ez az interjú is nagyon népszerű lesz. Ehhez az interjúhoz sok kérdést kaptunk diákoktól, programozóktól és a közösség tagjaitól, ezért nagyon hálásak vagyunk ezért a lehetőségért. A számítástechnika ugyanilyen szeretettel bír az Egyesült Államokban?
Michael: A mi szakterületünk annyira szerteágazó, sok iránya van, és olyan sokféleképpen hat a társadalomra, hogy nehéz határozott választ adni. De tény, hogy óriási változásokat hozott az üzleti életben, az iparban, a művészetben és általában a társadalomban az elmúlt 30 évben.
Виталий: Kezdjük valami távolival. Sok egyetemen létezik valami olyan, hogy egy adott területen szakosodnak. A Carnegie Mellon Egyetem számára ez a párhuzamos számítástechnika, az MIT számára pedig a kriptográfia, a robotok és a többszálú feldolgozás. Van ilyen specializáció a Rochesteri Egyetemen?
Michael: Őszintén szólva azt mondanám, hogy a CMU és az MIT minden területre specializálódott. Tanszékünk mindig is a mesterséges intelligenciára fordította a legnagyobb figyelmet. A nálunk dolgozók fele mesterséges intelligenciával vagy ember-számítógép interakcióval foglalkozik – ez az arány magasabb, mint más részlegeknél, és mindig is így volt. De amikor egyetemre jártam, nem volt MI-kurzusom, és soha nem dolgoztam ezen a területen. Tehát az osztályom egy olyan problémára specializálódott, amihez semmi közöm. Vigasztal, hogy tanszékünk második legfontosabb problémája a párhuzamos és többszálú programozás, vagyis az én szakterületem.
Виталий: A számítástechnikával akkor kezdett el dolgozni, amikor a többszálú programozás területe még csak kialakulóban volt. Publikációinak listája azt mutatja, hogy első munkái meglehetősen széles kérdéskörrel foglalkoztak: memóriakezelés többszálú rendszerekben, elosztott fájlrendszerek, operációs rendszerek. Miért ilyen sokoldalúság? Próbáltad megtalálni a helyed a kutatói közösségben?
Michael: Diákként részt vettem a Wisconsini Egyetemen, ahol az egyik első elosztott operációs rendszert fejlesztették ki. Ott dolgoztam együtt Rafael Finkellel () és Marvin Solomon (). A disszertációm az elosztott rendszerek rendszerszoftvereinek nyelvének fejlesztésével foglalkozott - mára mindenki megfeledkezett róla, és hála Istennek. Megalkottam a Lynx programozási nyelvet, aminek az volt a célja, hogy megkönnyítse a szerverek létrehozását egy laza csatolású elosztott operációs rendszerhez. Mivel akkoriban főleg operációs rendszerekkel foglalkoztam, feltételeztem, hogy a pályafutásom elsősorban ezekhez kötődik majd. De Rochester nagyon kicsi egyetem volt, és emiatt a különböző csoportok nagyon szorosan kölcsönhatásba léptek egymással. Nem volt ott egy tucat másik operációs rendszerrel foglalkozó ember, akivel beszélhetnék, így minden kapcsolatom olyanokkal volt, akik teljesen más területeken dolgoztak. Nagyon élveztem, nagy előny számomra, hogy sokoldalú vagyok. Ha már konkrétan többszálú adatstruktúrákról és szinkronizációs algoritmusokról beszélünk, akkor teljesen véletlenül kezdtem el ezeken dolgozni.
IEEE méretezhető koherens interfész, MCS zárolás.
Виталий: Mesélnél erről egy kicsit bővebben?
Michael: Ez egy vicces történet, amit soha nem fáradok el elmondani mindenkinek. Egy konferencián történt Bostonban – ez a 80-as évek végén vagy a 90-es évek elején volt. John Mellor-Crummey (), karunkon végzett. Ismertem, de korábban nem végeztünk közös kutatást. Mary Vernon () Wisconsinból egy többprocesszoros rendszerről tartott előadást, amelyet Wisconsinban fejlesztettek ki: . Ennek a Multicube-nak volt egy hardverszintű szinkronizálási mechanizmusa, amelyet Q on Sync Bit-nek hívtak, majd később átnevezték Q on Lock Bit-re, mert úgy hangzott, mint a Colby sajt, ami szójáték volt. Ha érdeklik a többszálú mechanizmusok, akkor valószínűleg tudja, hogy a Colby végül az IEEE Scalable Coherent Interface szabvány szinkronizáló motorja lett. Ez egy olyan zárszerkezet volt, amely hardverszinten mutatókat hozott létre az egyik gyorsítótárból a másikba, így minden zártartó tudta, kinek a sora van. Amikor John és én hallottunk erről, egymásra néztünk, és azt mondtuk: miért csináljuk ezt hardver szinten? Nem érhető el ugyanez az összehasonlítás és csere használatával? Elővettük az egyik füzetet, ami az osztályteremben hevert, és ráfirkáltunk , miközben Mary folytatta beszámolóját. Ezt követően megvalósítottuk, kísérleteztünk, az ötlet sikeresnek bizonyult, és megjelentettük a cikket. Akkoriban számomra ez a téma csak egy mókás figyelemelterelésnek tűnt, ami után terveztem, hogy visszatérek az operációs rendszerekhez. Ekkor azonban egy másik probléma is felmerült, és végül a szinkronizálás, a többszálú és az adatstruktúrák lettek a szakterületem. Amint látja, mindez véletlenül történt.
Виталий: Régóta ismerem az MCS-blokkolást, de eddig nem tudtam, hogy ez az Ön munkája, és nem értettem, hogy ez az Ön vezetékneveinek rövidítése.
Hogyan lehet túlélni egy folyamatosan változó világban?
Alex: Kapcsolódó témában lenne egy kérdésem. 30-40 évvel ezelőtt nagyobb volt a szabadság a különböző szakterületeken. Ha többszálas vagy elosztott rendszerekben szeretnél karriert kezdeni, szívesen látod, ha operációs rendszerekkel szeretnél foglalkozni, semmi gond. Mindegyik területen sok nyitott kérdés és kevés szakértő volt. Mára szűk szakterületek jelentek meg: nem csak általában az operációs rendszerekkel foglalkoznak, hanem az egyes rendszerekre is. Ugyanez a helyzet a többszálú és elosztott rendszerekkel. De a probléma az, hogy életünk nem végtelen, mindenki csak néhány évtizedet tud a kutatásra fordítani. Hogyan lehet túlélni ebben az új világban?
Michael: Ebben a tekintetben nem vagyunk különlegesek, más területeken is megtörtént egyszer. Szerencsém volt, hogy a számítástechnikával akkor kezdtem el dolgozni, amikor a terület a „tinédzser” éveiben járt. Néhány alapot már lefektettek, de minden még nagyon kiforratlan volt. Ez a lehetőség nem gyakran adódik. Az elektrotechnika nagyon régóta létezik, a fizika még régebben, a matematika szinte az idők kezdete óta. De ez nem jelenti azt, hogy ma már senki sem tesz érdekes felfedezéseket a matematikában. Sok nyitott probléma van még, de ugyanakkor még többet kell tanulni. Jogosan jegyzi meg, hogy ma sokkal több szakterület létezik, mint korábban, de ez csak azt jelenti, hogy ugyanabban a helyzetben találjuk magunkat, mint az emberi tevékenység legtöbb más területe.
Alex: Engem itt a kérdés gyakorlatiasabb aspektusa érdekel. Matematikai múlttal rendelkezem, tanulmányaim alatt gyakran vettem részt konferenciákon és dolgoztam különféle tudományos témákon. Felfedeztem, hogy a hallgatóságból senki sem értette a beszámolóimat, és ugyanígy mások beszámolói is csak saját maguk számára érthetőek. A magas szintű témákban ez nem így van, de amint elkezdesz elmélyülni valamiben, a közönség már nem tud veled lépést tartani. Hogyan kezeli ezt?
Michael: Nem mindig sikeres. Nemrég készítettem egy jelentést, amelyben túl mélyre mentem a technikai részletekbe. A beszélgetés előrehaladtával kiderült, hogy a hallgatóság nagy része nem ért engem, így menet közben kellett alkalmazkodnom a helyzethez. A csúszdákat nem lehetett cserélni, így nem sikerült túl jól – úgyhogy általában véve igyekszem nem diákat használni. Összességében azt tanácsolom, hogy vegye figyelembe a közönségét. Tudnia kell, hogy kivel beszél, milyen szintű tudással rendelkezik, és mit kell hallania ahhoz, hogy értékelje a munkáját.
Виталий: Tudna adni egy tippet, hogy miről szólt ez az előadás?
Michael: Hogy őszinte legyek, inkább nem térnék ki erre a témára, hogy névtelenül hagyjam az érintetteket. A lényeg az, hogy gyakran túlságosan mélyen belemerülünk a probléma bonyolultságába, amin dolgozunk, ezért a beszéd elején nehéz elmagyaráznunk, miért érdekes és fontos a probléma, és hogyan kapcsolódik azokhoz a kérdésekhez, a közönség már tudja. Megfigyeléseim szerint ezt a képességet tanulják meg a legnehezebben a tanulók. És ez volt a legutóbbi jelentésem gyenge pontja is. Egy megfelelően felépített riportnak a kezdetektől fogva kapcsolatot kell találnia a hallgatósággal, el kell magyaráznia nekik, hogy pontosan mi a probléma, és hogyan kapcsolódik az általa már ismert témákhoz. A közönségtől függ, hogy mennyire technikai ez a bevezetés. Ha teljesen tarka, akkor a riport lehet többlépcsős. A bevezetőnek mindenki számára elérhetőnek kell lennie, és a végére előfordulhat, hogy a darab már nem tud veled lépést tartani, de a szakterületedet viszonylag jól ismerő emberek rájönnek.
Egyre hülyébbek a diákok? Globális trendek, nemzetközivé válás.
Alex: Több évtizede figyeli a diákokat. A diákok évtizedről évtizedre vagy évről évre butábbak vagy okosabbak? Oroszországban a professzorok folyamatosan panaszkodnak, hogy a hallgatók évről évre hülyébbek, és tényleg nem világos, hogy mit kell tenni ez ellen.
Michael: Tényleg sok negatívumot lehet hallani tőlünk, öregektől. Tudat alatt hajlamosak vagyunk arra számítani, hogy a hallgatók magukba szívják mindazt a 30 év tapasztalatát, amivel már rendelkezünk. Ha mélyebb megértésem van, mint 1985-ben, akkor a hallgatóknak miért nincs meg? Valószínűleg azért, mert 20 évesek, mit gondolsz? Azt gondolom, hogy az elmúlt évtizedek legjelentősebb változásai a demográfiai összetételben történtek: mára lényegesen több külföldi hallgatónk van, a kanadaiak kivételével. Régen sok volt a kanadai, mert nagyon közel vagyunk a kanadai határhoz, és onnan a diákok hétvégenként hazautazhatnak. De ma már sok jó egyetem van Kanadában, és a kanadaiak szívesebben tanulnak itt, jóval kevesebben jönnek belőlük az USA-ba.
Alex: Ön szerint ez lokális vagy globális trend?
Michael: Nem emlékszem pontosan ki, de valaki azt mondta, hogy a világ lapos. Területünk sokkal nemzetközibbé vált. Korábban kizárólag az Egyesült Államokon belül rendezték meg, majd úgy döntöttek, hogy 4 évente egyszer más országokban is megrendezik, most pedig a világ minden táján megrendezik. Ezek a változások még jobban érintették , hiszen mindig is nemzetközibb szervezet volt, mint az ACM. És vannak programszékek Kínából, Indiából, Oroszországból, Németországból és még sok más országból, mert most mindenhol sok minden történik.
Alex: De valószínűleg van néhány negatív oldala az ilyen nemzetközivé válásnak?
Michael: Azt mondanám, hogy minden negatív szempont nem a technológiára, hanem a politikára vonatkozik. Valamikor a fő probléma az volt, hogy az Egyesült Államok a legokosabb és legtehetségesebb embereket lopta el a világ országaiból. És most a fő probléma a különböző országok közötti politikai játszmák a vízumokkal és a bevándorlással kapcsolatban.
Alex: Azaz akadályok és hasonlók. Ez egyértelmű.
Vladimir: Személy szerint engem az érdekel, hogy milyen megközelítést alkalmazol, amikor új tantárgyat tanítasz a diákoknak. Különböző lehetőségek állnak rendelkezésre: először megpróbálhatja őket valami új kipróbálására ösztönözni, vagy jobban odafigyelhet egy adott technológia működésének részleteire. Mit szeretsz jobban?
Hatékony munka a tanulókkal
Alex: És hogyan lehet megtalálni az átkozott egyensúlyt az első és a második között?
Michael: A probléma az, hogy az órák nem mindig úgy mennek, ahogy szeretném. Általában előre adok olvasnivalót a tanulóknak, hogy elmélyüljenek benne, legjobb tudásuk szerint megértsék, és kérdéseket fogalmazzanak meg azokkal a részekkel kapcsolatban, amelyeket nem tudtak megérteni. Ezután az órán a legnehezebb pillanatokra koncentrálhat, és együtt fedezheti fel azokat. Én így szeretek a legjobban órákat tartani. De tekintettel arra, hogy most milyen terhelés nehezedik a hallgatókra, nem mindig tudom megbizonyosodni arról, hogy előre felkészülnek. Ebből kifolyólag sokkal több időt kell az anyag általános újramesélésére fordítania, mint amennyit szeretne. Ennek ellenére igyekszem óráinkat interaktívan tartani. Ellenkező esetben egyszerűbb videót rögzíteni, amelyet a tanulók otthon megnézhetnek. Az élő órák lényege az emberi interakció. Az órákon szívesebben használok krétát és táblát, mint diákat, kivéve bizonyos esetekben, amikor egy diagram túl bonyolult ahhoz, hogy a táblán ábrázoljam. Ennek köszönhetően nem kell merev óravázlathoz ragaszkodnom. Mivel nincs szigorú sorrend, ahogyan az anyagot adom, így a kapott kérdések függvényében a hallgatósághoz szabhatom. Általában arra törekszem, hogy az órákat a lehető leginteraktívabbá tegyem, hogy az általam bemutatott anyag a hozzám feltett kérdésektől függjön.
Vladimir: Ez nagyszerű. Tapasztalataim szerint meglehetősen nehéz rávenni a hallgatókat, hogy kérdéseket tegyenek fel. Még ha előre meg is kéred, hogy kérdezz, bármilyen ostoba vagy okos is legyen, akkor is hallgatnak. Hogyan kezeli ezt?
Michael: Nevetni fogsz, de ha elég sokáig állsz csendben, előbb-utóbb mindenki kényelmetlen lesz, és valaki feltesz egy kérdést. Vagy feltehet egy egyszerű technikai kérdést igennel vagy nemmel annak megállapítására, hogy az emberek megértik-e az imént elhangzottakat. Például van-e adatverseny a fenti példában? Ki gondolja így? Ki gondolja, hogy nem? Ki az, aki egyáltalán nem ért semmit, mert összességében csak a kezek fele ment fel?
Виталий: És ha rosszul válaszoltál, akkor kikerülsz az óráról :)
Michael: Ha nem válaszolt semmire, akkor tegyél fel egy kérdést. Meg kell értenem, hogy pontosan mit kell tudnia a hallgatónak, hogy válaszoljon az imént feltett kérdésre. Szükségem van rájuk, hogy segítsenek nekik. Kész vagyok alkalmazkodni hozzájuk, hogy megértsék a problémát. De ha nem tudom, mi jár a fejükben, nem tudom megtenni. És ha elég sokáig nem ad békét a diákoknak, néha a végén felteszik a megfelelő kérdéseket, vagyis olyanokat, amelyek lehetővé teszik, hogy lássam, mi jár pontosan a hallgatók fejében.
Alex: Ezek a kérdések néha olyan gondolatokhoz vezetnek, amelyekre korábban nem gondoltál? Váratlanok? Lehetővé teszik, hogy egy problémát új megvilágításba helyezzen?
Michael: Vannak kérdések, amelyek az anyag bemutatásának új módját nyitják meg. Gyakran vannak olyan kérdések, amelyek olyan érdekes problémákhoz vezetnek, amelyekről nem terveztem beszélni. A diákok gyakran mondják nekem, hogy hajlamos vagyok eltérni a témától, amikor ez megtörténik. És ezek szerint nagyon gyakran ez a lecke legérdekesebb része. Nagyon ritkán, csak néhány alkalommal tettek fel a hallgatók olyan kérdéseket, amelyek új kutatási irányt indítottak, és cikkté nőttek ki. Ez sokkal gyakrabban fordul elő a diákokkal folytatott beszélgetések során, nem pedig az órákon, de időnként előfordult az órákon.
Alex: Tehát a hallgatók olyan kérdéseket tettek fel, amelyek alapján aztán lehetett cikket publikálni?
Michael: Igen.
Виталий: Milyen gyakran folytat ilyen beszélgetéseket a diákokkal? Mikor szeretnének többet tanulni, mint amiről az óra során szó volt?
Michael: Végzős diákjaimmal – folyamatosan. Körülbelül 5-6 van belőle, és mindig megbeszélünk velük valamit. És nem túl gyakoriak az ilyen jellegű beszélgetések olyan diákokkal, akik egyszerűen csak az én óráimat látogatják. Bár szeretném, ha ez gyakrabban történne meg. Gyanítom, hogy egyszerűen félnek bejönni a karra munkaidőben. Minden félévben néhány diáknak sikerül leküzdenie ezt a pszichológiai akadályt, és mindig nagyon érdekes velük beszélgetni óra után. Igaz, ha minden diák ilyen bátor lenne, egyszerűen nem lenne elég időm. Szóval lehet, hogy minden úgy működik, ahogy kell.
Виталий: Hogyan tud időt szakítani a hallgatókkal való kommunikációra? Amennyire én tudom, az USA-ban a tanároknak sok munkájuk van - ösztöndíjra pályázni és hasonlók.
Michael: Őszintén szólva, a diákokkal való munka az a része a munkámnak, amelyet a legjobban élvezek. Szóval van elég motivációm ehhez. Az irodámban eltöltött idő nagy részét mindenféle értekezleten töltöm. Most nyár van, így kevésbé zsúfolt az időbeosztásom, de tanév közben minden nap 9-től 17-ig mindent összepakoltam. Kutatómunka, áttekintések, támogatások – mindehhez csak esték és hétvégék vannak.
Hogyan lehet lépést tartani az új tanfolyamok és könyvek előkészítésével.
Alex: Folytatja jelenleg olyan kurzusok oktatását, amelyeket már régóta oktat? Valami olyan, mint a számítástechnika bevezetése.
Michael: Az első dolog, ami itt eszembe jut, az egy programnyelvi tanfolyam.
Alex: Mennyiben különbözik a kurzus mai verziója a 10, 20, 30 évvel ezelőttitől? Talán itt nem az adott tanfolyam részletei, hanem az általános trendek az érdekesebbek.
Michael: A programozási nyelvekkel kapcsolatos kurzusom kissé szokatlan volt abban az időben, amikor létrehoztam. Az 1980-as évek végén kezdtem el olvasni, kollégám, Doug Baldwin helyére.). A kurzus témája csak érintőlegesen kapcsolódott a szakterületemhez, de amikor elment, én voltam a legalkalmasabb a tanfolyam oktatóira. Az akkoriban létező tankönyvek egyike sem tetszett, így végül magam írtam a tankönyvet ehhez a tanfolyamhoz. (A szerkesztő megjegyzése: a könyvről beszélünk) Ma már több mint 200 egyetemen használják szerte a világon. Megközelítésem szokatlan abban, hogy szándékosan keveri a nyelvi tervezés és megvalósítás problémáit, és minden lehetséges területen nagy figyelmet fordít e szempontok kölcsönhatására. Az alapszemlélet változatlan maradt, ahogy sok alapfogalom is: absztrakciók, névterek, modularitás, típusok. De teljesen megváltozott azoknak a nyelveknek a készlete, amelyekkel ezeket a fogalmakat demonstrálják. A kurzus létrehozásakor sok példa volt Pascalban, de ma sok tanítványom nem is hallott erről a nyelvről. De ismerik a Swiftet, a Go-t, a Rust-ot, szóval beszélnem kell a ma használt nyelvekről. Ezenkívül a hallgatók már jól ismerik a szkriptnyelveket, de amikor elkezdtem tanítani ezt a kurzust, az összesített nyelvekről szólt. Most nagyon sok anyagra van szükségünk a Pythonról, a Rubyról, sőt a Perlről is, mert manapság ezt írják a kódok, és nagyon sok érdekesség történik ezeken a nyelveken, többek között a nyelvi tervezés terén is.
Виталий: Akkor a következő kérdésem az előzőhöz kapcsolódik. Hogyan lehet lépést tartani ezen a területen? Gyanítom, hogy egy ilyen kurzus frissítése sok munkát igényel - új nyelveket kell értenie, meg kell értenie a fő gondolatokat. Hogy csinálod ezt?
Michael: Nem dicsekedhetek azzal, hogy mindig 100%-osan sikerül. De legtöbbször csak azt csinálom, amit mindenki más – olvasok az interneten. Ha meg akarom érteni a Rustot, akkor rákeresek a Google-ra, felmegyek a Mozilla oldalára és elolvasom az ott feltett kézikönyvet. Ez része a kereskedelmi fejlesztésben előforduló dolgoknak. Ha a tudományról beszélünk, akkor követnie kell a fő konferenciákon készült jelentéseket.
Kapcsolat az üzleti élet és a tudományos élet között
Виталий: Beszéljünk az üzleti és a tudományos kutatás kapcsolatáról. A munkáinak listájában több cikket is találtam a gyorsítótár koherenciájáról. Úgy értem, hogy a gyorsítótár-konzisztencia algoritmusai instabilok voltak a közzétételükkor? Vagy nem eléggé elterjedt. Mennyire voltak gyakoriak az elképzelései a gyakorlatban?
Michael: Nem tudom pontosan, melyik kiadványokról beszél. Elég sokat dolgoztam a tanítványaimmal, Bill Boloskyval () és Leonidas Kontotanassis () az 1990-es évek elején a Neumann gépek memóriakezeléséről. Abban az időben az üzleti életnek még nem volt fogalma arról, hogyan kell megfelelően elkészíteni egy többprocesszoros rendszert: érdemes-e hardverszintű támogatást létrehozni a távoli memória eléréséhez, érdemes-e a memóriát elosztani, lehetséges-e a gyorsítótár betöltése távoli memória, vagy szükséges-e oldalak mozgatása a műtőben? Bill és Leonidas egyaránt ezen a területen dolgozott, és távoli gyorsítótár-betöltés nélküli megközelítéseket fedezett fel. Ez nem közvetlenül a gyorsítótár koherenciájával függött össze, de ez még a NUMA memóriakezelésen volt, és ebből fejlődtek ki a modern operációs rendszerekben az oldalelhelyezés modern megközelítései. Összességében Bill és Leonidas fontos munkát végzett, bár nem a legbefolyásosabbak ezen a területen – akkoriban sok más ember is dolgozott ugyanezen. Később a gyorsítótár koherenciájával kapcsolatos témán dolgoztam a hardveres tranzakciós memória kontextusában. A csoport, amellyel ezen a problémán dolgoztam, számos szabadalmat kapott. Elég érdekes ötletek vannak mögöttük, de nem hiszem, hogy a gyakorlatban megvalósulnak. Így vagy úgy, de nehéz megítélnem a jövedelmezőségüket.
Alex: Ezzel kapcsolatban egy személyesebb kérdés: mennyire fontos számodra, hogy az elképzeléseid a gyakorlatban is megvalósuljanak? Vagy nem gondolsz rá?
Michael: Szeretem feltenni ezt a kérdést másokkal, jelentkezőkkel vagy a karhoz csatlakozni kívánó jelöltekkel folytatott interjúk során. Szerintem erre a kérdésre nincs helyes válasz. Azoknak, akik klassz dolgokat csinálnak, nagyon eltérő motivációik lehetnek. Engem azért vonzanak a problémák, mert személy szerint érdekesnek tartom őket, nem pedig a gyakorlati hasznuk miatt. De másrészt, ha valami érdekes dolog mégis alkalmazásra talál, azt nagyon szeretem. Szóval itt nem könnyű. De munkám kezdetén még mindig nem a világ végfelhasználásának gondolata vezérel, hanem az ötlet harmóniája és a vágy, hogy feltárjam, és meglássam, mi sül ki belőle. Ha végül gyakorlati eredményeket ad, akkor nagyszerű.
Alex: Képzettségének és tapasztalatának köszönhetően a legtöbben jobban meg tudod ítélni mások ötleteit. Összehasonlíthatja őket, és meghatározhatja, melyik melyikkel működik jobban. Biztos vagyok benne, hogy van véleménye azokról a dolgokról, amelyeket jelenleg a gyakorlatban használnak olyan nagy gyártók, mint az Intel. Az Ön szemszögéből mennyire helyes az az irány, amelyet ezek a cégek követnek?
Michael: A gyakorlat mindig a körül forog, hogy mi lehet kereskedelmileg sikeres, azaz profitot termel, és erről jobb, ha valaki mást kérdez meg. Munkám során többnyire publikációk születnek, az operációs rendszerek területén pedig teljesítménymutatók: sebesség, energiafogyasztás, kódméret alapján értékelik. De nekem mindig úgy tűnt, hogy ezeket az empirikus eredményeket csak azért adják hozzá a cikkekhez, hogy megjelenhessenek, és az emberek valódi munkamotivációi esztétikusak. A kutatók művészi szempontból értékelik a megoldásokat, törődnek azzal, hogy az ötletek mennyire elegánsak, és igyekeznek a meglévő megközelítéseknél jobbat alkotni. A kutatókat személyes, szubjektív, esztétikai indítékok vezérlik. De magában a cikkben nem lehet erről írni, ezek nem érvek a programbizottság számára. Szerencsére az elegáns megoldások gyakran gyorsak és olcsók is. Körülbelül 15 évvel ezelőtt egy tucat kollégámmal megvitattuk ezt a témát, és végül egy cikket írtunk róla. Szerintem még most is megtalálod, úgy hívják vagy valami ehhez hasonló, több mint egy tucat szerzője van. Ez az egyetlen cikk, amelynek én vagyok a szerzője , tehát ha rákeresel a nevére a publikációs listámon, megtalálod, amire szükséged van. A rendszerkutatás értékeléséről és az elegancia fontosságáról szól.
Alex: Tehát különbség van a tudományban és az üzleti életben jónak tartott színvonal között. A tudomány értékeli a teljesítményt, az energiafogyasztást, a TDP-t, a könnyű implementációt és még sok mást. Van lehetőséged ilyen jellegű kutatásokat folytatni az egyetemen? Van egy laboratóriuma különböző gépekkel és különböző architektúrákkal, ahol kísérleteket végezhet?
Michael: Igen, a részlegünkön sok különböző érdekes gép található. Leggyakrabban kicsik, van egy kis klaszterünk és sok többprocesszoros rendszerünk különböző gyorsítókkal. Ezenkívül az egyetemen van egy hatalmas számítástechnikai központ, amely több tucat különböző tudományág tudósait szolgálja ki. Körülbelül ezer csomópontja és húszezer magja van, mind Linuxon. Ha szükség van rá, mindig vásárolhat néhány AWS-t. Tehát a hardverrel kapcsolatban nincsenek jelentős megkötéseink.
Alex: Milyen volt harminc évvel ezelőtt? Akkor voltak problémák?
Michael: Akkor egy kicsit más volt. Az 1980-as évek közepén-végén úgy vélték, hogy a tudomány szűkös volt a számítási erőforrásokhoz. A helyzet orvoslására a Nemzeti Tudományos Alapítvány ) koordinált kísérleti kutatási programot hozott létre (Coordinated Experimental Research, CER). A program küldetése az volt, hogy számítástechnikai infrastruktúrát biztosítson a számítástechnikai tanszékek számára, és jelentős változást ért el. Az általa biztosított pénzből mi a Rochesteri Egyetemen vettünk egy 1984 csomós BBN Butterfly-t 128-ben, egy évvel azelőtt, hogy megérkeztem volna. Abban az időben ez volt a világ legnagyobb többprocesszoros rendszere megosztott memóriával. 128 processzora volt, mindegyik külön alaplapon, és négy racket foglalt el. Mindegyik processzornak egy megabájt memóriája volt, 128 megabájt RAM akkoriban elképzelhetetlen mennyiségnek számított. Ezen a gépen valósítottunk meg először MCS zárolást.
Alex: Tehát ha jól értem, akkor jelenleg a hardver probléma megoldódott?
Michael: Általában igen. Van néhány figyelmeztetés: először is, ha a számítógépes architektúrát chipszinten végzi, akkor ezt akadémiai környezetben nehéz megtenni, mert az üzleti életben sokkal jobb eszközök állnak rendelkezésre. Ha 10 nanométernél kisebbre van szüksége, akkor mástól kell megrendelnie. Ezen a területen sokkal könnyebb kutatónak lenni az Intelnél. Ha chipeken vagy szilárdtest-memóriákon dolgozik optikai kommunikáción, olyan technológiákat találhat az üzleti életben, amelyek még nem ismertek a tudományban, ezért szövetségeket kell létrehoznia. Például Stephen Swanson () létrehozta új memóriatechnológiákhoz. Ez a forma nem mindig működik, de bizonyos esetekben igen sikeres lehet. Ráadásul a tudományban a legerősebb számítástechnikai rendszerek fejlesztése nehezebb. Az Egyesült Államokban, Japánban és Kínában jelenleg zajló legnagyobb szuperszámítógép-projektek mind az üzleti életre összpontosítanak.
Az ötletek gyakorlati megvalósítása. MCS, MS, CLH, JSR 166, Doug Lee-vel és másokkal együttműködve.
Виталий: Ön már beszélt arról, hogyan kezdett el dolgozni a szinkronizálási algoritmusokon. Két nagyon híres cikked van erről и , amelyeket bizonyos értelemben Java-ban valósítottak meg. (A szerkesztő megjegyzése: minden publikáció megtekinthető ). Ott ezt a blokkolást néhány változtatással végrehajtották, és kiderült , és a várólistát a tervezett módon implementálták. De sok év telt el a cikkei megjelenése és gyakorlati alkalmazása között.
Alex: Körülbelül 10 évnek tűnik a sor esetében.
Michael: Mielőtt ezek a szolgáltatások megjelentek a Java szabványkönyvtárban?
Виталий: Igen. Mit tettél, hogy ez megtörténjen? Vagy nem csináltak semmit?
Michael: Elmondhatom, hogyan került az MS Queue a Java 5-be. Néhány évvel a megjelenése előtt Mark Moyers csoportjával dolgoztam a Sun Microsystemsnél a Boston melletti laborjukban. Szervezett egy workshopot az általa ismert embereknek, akik érdekes problémákon dolgoztak a többszálú feldolgozásban, mert olyan témákat akart találni, amelyeket el tud adni a cégüknek. Ott találkoztam először Doug Leával. Doug és én, valamint körülbelül 25 másik ember a Suntól együtt beszélgettünk Doug előadásáról , amely később java.util.concurrent lett. Útközben Doug elmondta, hogy szeretné használni az MS queue-t, de ehhez szüksége volt egy számlálóra az interfész sorában lévő elemek számára. Vagyis ezt külön módszerrel kellett volna, atomosan, pontosan és gyorsan. Azt javasoltam, hogy egyszerűen adjunk hozzá sorozatszámokat a csomópontokhoz, vegyük az első és az utolsó csomópont számát, és vonjuk ki az egyiket a másikból. Doug megvakarta a fejét, azt mondta, hogy „miért ne”, és végül ezt tette. Megbeszéltük ennek a megközelítésnek a megvalósítását a könyvtárban, de Doug a munka nagy részét maga végezte. Ennek eredményeként sikerült kitűnő többszálú támogatást létrehoznia a Java nyelven.
Alex: Tehát, ha jól értem, a .size() metódusnak a szabványos queue interfész része kellett volna lennie, és O(1) algoritmikus bonyolultságúnak kellett volna lennie?
Michael: Igen, és ezen felül külön pult szükséges.
Alex: Mert ha Javaban meghívod a .size() metódust, akkor az eredmény várhatóan azonnal elérhető lesz, és nem a gyűjtemény tényleges mérete alapján. Értem köszönöm.
Michael: Néhány évvel később kettős adatstruktúrákon dolgoztam a tanítványommal, Bill Schererrel – valójában erről fogok beszélni . Doug odajött hozzánk, és azt mondta, hogy használhatja őket a Java Executor Frameworkben. Billel közösen két implementációt hoztak létre, az úgynevezett fair és unfair queues-t. Én adtam nekik tanácsot ebben a projektben, bár a tényleges kód megírásában nem vettem részt. Ennek eredményeként a végrehajtók sebessége jelentősen megnőtt.
Vladimir: Találkozott-e az algoritmusok helytelen megvalósításával vagy új funkciók hozzáadására vonatkozó kéréssel? Általában a gyakorlatnak egybe kell esnie az elmélettel, de gyakran eltérnek egymástól. Tegyük fel, hogy írtál egy algoritmust, és papíron az működik, de a megvalósításban részt vevő emberek további funkciókat vagy az algoritmus valamiféle módosítását kezdtek kérni. Volt már ilyen helyzeted?
Michael: Az egyetlen példa, amikor valaki odajött hozzám és megkérdezte, hogy „hogyan kell megvalósítani”, az Doug kérdése volt, amelyről már beszéltem. De volt néhány olyan eset, amikor érdekes változtatásokat hajtottak végre a gyakorlati igényeknek megfelelően. Például az IBM K42-es csapata átalakította az MCS-zárat, és szabványos interfésszel alakította ki, így nem kellett oda-vissza átadni a sorcsomópontot az beszerzési és kiadási rutinoknak. Ennek a szabványos felületnek köszönhetően egy elméletben gyönyörű ötlet kezdett működni a gyakorlatban. Meglepő, hogy soha nem publikáltak róla cikket, és bár kaptak szabadalmat, később felhagytak vele. Az ötlet csodálatos volt, és igyekszem beszélni róla, amikor csak lehetséges.
Más esetek is előfordultak, amikor az emberek javították az általam közzétett algoritmusokat. Például az MS várólista kétlépéses telepítési mechanizmussal rendelkezik, ami azt jelentette, hogy két CAS volt a várólista kritikus útvonalán. A régebbi autókon a CAS meglehetősen drága volt. Az Intel és más gyártók a közelmúltban elég jól optimalizálták őket, de valamikor ezek 30 ciklusos utasítások voltak, így nem volt kívánatos, hogy egynél több legyen a kritikus úton. Ennek eredményeként egy másik, az MS várólistához hasonló sort fejlesztettek ki, amely azonban csak egy atomi művelettel rendelkezett a kritikus úton. Ez annak köszönhető, hogy egy bizonyos időtartam alatt a művelet O(1) helyett O(n) időt vehet igénybe. Valószínűtlen volt, de lehetséges. Ez annak köszönhető, hogy bizonyos pillanatokban az algoritmus bejárta a sort az elejétől a jelenlegi pozícióig. Általában véve az algoritmus nagyon sikeresnek bizonyult. Tudomásom szerint nem túl széles körben használják, részben azért, mert az atomműveletek lényegesen kevesebb erőforrást igényelnek, mint korábban. De az ötlet nagyszerű volt. Nagyon szeretem az Oracle-ből származó Dave Dice munkásságát is. Minden, amit csinál, nagyon praktikus, és nagyon ügyesen használja a vasat. A NUMA-tudatos szinkronizációs algoritmusok és a többszálú adatszerkezetek nagy részében ő volt a keze.
Vladimir: Amikor algoritmusokat ír vagy tanít a diákoknak, a munkája eredménye nem látható azonnal. A közösségnek időre van szüksége, hogy megismerkedjen mondjuk egy új cikkel. Az új algoritmus nem talál azonnal alkalmazást.
Michael: Korántsem egyértelmű, hogy a cikk jelentős lesz-e vagy sem. Szerintem érdekes lenne tanulmányozni a konferenciákon díjazott előadásokat. Vagyis nézd meg azokat a cikkeket, amelyeket a programbizottságokban egy időben a legjobbnak tartottak. Meg kell próbálnia kiszámolni a linkek száma és az üzleti életre gyakorolt hatás alapján, hogy ezek a cikkek 10, 20, 25 év alatt milyen hatással voltak valójában. Kétlem, hogy a kettő között szoros összefüggés lenne. Nem lesz nulla, de nagy valószínűséggel sokkal gyengébb lesz, mint szeretnénk. Sok ötlet hosszú ideig keresetlen marad, mielőtt széles körben elterjedne. Vegyük például a tranzakciós memóriát. Több mint 10 év telt el az eredeti cikk megjelenésétől addig, amíg az emberek ténylegesen elkezdtek vele gépeket építeni. És mielőtt ez a memória megjelent a kereskedelmi termékekben - és mind a 20. Nagyon sokáig senki sem figyelt a cikkre, majd a rá mutató hivatkozások száma meredeken nőtt. Ezt nehéz lenne előre megjósolni. Másrészt néha az ötletek azonnal megvalósításra találnak. Néhány évvel ezelőtt írtam egy tanulmányt Joe Izraelevitz-cel a DISC számára, amelyben új formális definíciót javasoltam az érvényességnek a perzisztens adatstruktúrákra vonatkozóan, amelyeket az őket futtató számítógép összeomlása után lehetne használni. A cikk kezdettől fogva tetszett, de sokkal népszerűbb lett, mint amire számítottam. Számos különböző csoport használta, és végül a perzisztencia struktúrák standard definíciójává vált. Ami persze szép.
Vladimir: Vannak olyan technikák, amelyeket az értékeléshez használ? Megpróbálja egyáltalán értékelni a cikkeit és a hallgatóit? Abban a tekintetben, hogy az általad tanított személy jó irányba halad-e.
Michael: Mint mindenki, én is jobban odafigyelek arra, amit jelenleg csinálok. Ismétlem, mint mindenki más, időnként megnézem a Google Tudóst, hátha hivatkoznak korábbi dolgozataimra, de ez inkább csak kíváncsiságból. Leginkább azzal foglalkozom, amit a tanítványaim csinálnak most. A jelenlegi munka értékelésénél az esztétikai szempontok is részei, mi az elegáns és mi nem. A hétköznapi szinten pedig nagy szerepe van a nyitott kérdéseknek. Például egy diák jön hozzám néhány eredmény grafikonjával, és megpróbáljuk megérteni, honnan származik a grafikon furcsa viselkedése. Általánosságban elmondható, hogy munkánk során folyamatosan igyekszünk megérteni olyan dolgokat, amelyeket még nem értünk.
Tranzakciós memória
Виталий: Esetleg beszélhetnénk egy kicsit a tranzakciós memóriáról?
Michael: Szerintem érdemes legalább egy keveset szólni, mert rengeteg erőfeszítést tettem bele. Ez az a téma, amelyről több publikációm van, mint bármelyik másiknál. Ugyanakkor furcsa módon mindig nagyon szkeptikus voltam a tranzakciós memóriával kapcsolatban. Szerintem, (M. Herlihy, J. E. B. Moss) korát megelőzve jelent meg. Az 1990-es évek elején azt javasolták, hogy a tranzakciós memória segítsen a tehetséges programozóknak többszálú adatstruktúrákon dolgozni, így ezeket a struktúrákat azután könyvtárként használhatják a hétköznapi programozók. Vagyis ez segítene Doug Lee számára, aki a JSR 166-ot megcsinálja. A tranzakciós memória azonban nem az volt, hogy megkönnyítse a többszálú programozást. De pontosan így kezdték felfogni a 2000-es évek elején, amikor széles körben elterjedt. A párhuzamos programozás problémájának megoldásaként hirdették. Ez a megközelítés mindig is reménytelennek tűnt számomra. A tranzakciós memória csak megkönnyítené a párhuzamos adatstruktúrák írását. Nekem úgy tűnik, ez az, amit elért.
A többszálú kód írásának nehézségeiről
Alex: Nagyon érdekes. Úgy tűnik, van egy bizonyos határ a rendszeres programozók és azok között, akik többszálú kódot tudnak írni. Tavaly többször beszéltem olyan emberekkel, akik valamilyen algoritmikus keretrendszert implementáltak. Például Martin Thomsonnal, valamint többszálú könyvtárakon dolgozó programozókkal. (A szerkesztő megjegyzése: Martin Thompson nagyon híres fejlesztő, írta и . És neki is van Joker 2015 konferenciánkon, videófelvétel . Ő is ugyanaz ezt a konferenciát is elérhető). A fő kihívás szerintük az algoritmusok gyors és könnyen használhatóvá tétele. Vagyis megpróbálják leküzdeni ezt a gátat, és minél több embert vonzani erre a területre. Mit gondolsz róla?
Michael: Ez a multithreading fő problémája: hogyan lehet nagy teljesítményt elérni a rendszer összetettségének növelése nélkül.
Alex: Mert amikor megpróbálják elkerülni a bonyolultságot, az algoritmus kevésbé lesz univerzális.
Michael: A kulcs itt a megfelelően megtervezett absztrakciók. Számomra úgy tűnik, hogy általában ez a legfontosabb a számítógépes rendszerekben, mint területen. Butler Lampson szívesen használja ezt a kifejezést, és „absztrakciók kereskedőinek” nevez bennünket. Egyszerű technológiák ma már nem léteznek. Az általunk használt processzorok 10 milliárd tranzisztorral rendelkeznek – az egyszerűség szóba sem jöhet. Ugyanakkor az ISA sokkal egyszerűbb, mint a processzor, hiszen nagyon sokáig dolgoztunk azon, hogy nagy teljesítményt és viszonylag egyszerű felületet biztosítsunk neki. De vele sem minden zökkenőmentes. Ugyanez a probléma a piacon megjelenő gyorsítókkal is. Felmerülnek a kérdések – hogyan készítsünk megfelelő interfészt a GPU-hoz, titkosítási mechanizmust, tömörítést, átkódolási mechanizmust, lineáris algebrai mechanizmust vagy akár rugalmasabb FPGA-t. Hogyan készítsünk olyan felületet, amely könnyen használhatóvá teszi az eszközt, és elrejti a bonyolultságot? Nem szabadul meg tőle, inkább elrejti egy egyszerű programozó elől.
Alex: Ha jól értem, még mindig van egy gát az absztrakciók megértésében. Vegyük a memóriamodellt; a tudomány és a technológia fejlettségi fokán ez az egyik fő absztrakció. Ennek köszönhetően minden programozó két csoportra oszlik: a nagyobb rész azok, akik nem értik, és a kisebbik azok, akik értik, vagy azt hiszik, hogy értik.
Michael: Ez egy jó kérdés – tényleg érti valamelyikünk a memóriamodellt?
Виталий: Főleg C++-ban.
Michael: Beszélj valamikor Hans Boehmmal. Ő az egyik legokosabb ember, akit ismerek, a memóriamodellek vezető szakértője. Azonnal elmondja, hogy sok mindent nem ért. De ha visszatérünk az absztrakciók kérdéséhez, akkor véleményem szerint az elmúlt 30 év legfontosabb gondolata fogalmazódott meg a memóriamodellek területén. . (A szerkesztő megjegyzése: a publikációk teljes listája elérhető ).
Alex: A kérdésem a következő: ez az akadály a fogalom természetéből fakad?
Michael: Nem. Sarita arra a következtetésre jutott, hogy a megfelelő megközelítéssel sikeresen elrejtheti az összes bonyolultságot, nagy teljesítményt érhet el, és egy egyszerű API-t adhat a programozónak. És ha követi ezt az API-t, konzisztens konzisztenciát érhet el. Szerintem ez a megfelelő modell. Írjon kódot adatversenyek nélkül, és kapjon szekvenciális következetességet. Természetesen a versenyzés valószínűségének csökkentése érdekében speciális eszközökre van szükség, de az már más kérdés.
Vladimir: Előfordult már a pályafutása során, hogy egy megoldottnak tűnő probléma hirtelen katasztrófává vált, vagy kiderült, hogy ez a probléma megoldhatatlan? Például elméletben bármilyen számot faktorozhat, vagy meghatározhatja, hogy bármelyik szám prím-e. De a gyakorlatban ez nehéz lehet; a jelenlegi hardverrel nehéz a számokat faktorálni. Veled is történt valami hasonló?
Michael: Egyből nem emlékszem ilyesmire. Volt, hogy úgy tűnt számomra, hogy egy adott területen már nincs mit tenni, de aztán ott történt valami új és érdekes. Például azt hittem, hogy a korlátlan sorban állás területe már elérte az érettséget. Az MNS-sor többszöri fejlesztése után már semmi sem történt. Aztán Morrison (Adam Morrison) és Afek (Yehuda Afek) feltalálta . Világossá vált, hogy korlátlan számú többszálas sor lehetséges, ahol legtöbbször csak egy letöltés és növelés utasítás volt a kritikus úton. Ez pedig lehetővé tette egy nagyságrenddel jobb teljesítmény elérését. Nem arról van szó, hogy nem tudjuk, hogy az előhívás és növelés nagyon hasznos dolog. Eric Freudenthal az 1980-as évek végén írt erről az Ultracomputerről Allan Gottlieb-el írt munkájában, de ez a korlátozott sorokról szólt. Morrison és Afek képesek voltak a letöltés és növelés funkciót használni egy korlátlan sorban.
Új architektúrák. Közel van a tranzakciós memória győzelme?
Vladimir: Olyan új építészeti megoldásokat keres, amelyek hasznosak lehetnek az algoritmusok számára?
Michael: Természetesen sok olyan dolog van, amit szeretnék megvalósítani.
Vladimir: Például milyen?
Michael: Először is néhány egyszerű bővítés a hardverszintű tranzakciós memóriánkhoz Intel és IBM processzorokban. Különösen azt szeretném, ha az imént felmerült nem tranzakciós terhelés és tároló azonnal elérhető lenne a tranzakciókon belül. Azonnal hurkokhoz vezetnek a történés előtti sorrendben, így nehézkesek lehetnek. De ha fenntartja az absztrakciós rétegeket, sok nagyon érdekes dolgot tehet a tranzakción kívül, miközben az történik. Nem tudom mennyire lenne nehéz ezt megvalósítani, de nagyon hasznos lenne.
Egy másik hasznos dolog a gyorsítótár betöltése távoli memóriából. Szerintem előbb-utóbb ez megtörténik. Ez a technológia lehetővé teszi dezaggregált memóriával rendelkező rendszerek létrehozását. Lehetne mondjuk 100 terabájt nem felejtő memóriát tartani egy rackben, és maga az operációs rendszer dinamikusan döntené el, hogy a memória mely szakaszai feleljenek meg a processzorok fizikai címterének. Ez rendkívül hasznos lenne a számítási felhőben, mivel lehetővé tenné, hogy nagy mennyiségű memóriát biztosítsanak az azt igénylő feladatokhoz. Szerintem valaki megcsinálja.
Виталий: Hogy a tranzakciós memóriáról beszéljek, még egy kérdésem van ezzel a témával kapcsolatban. A tranzakciós memória végül felváltja a szabványos többszálú adatstruktúrákat?
Michael: Nem. A tranzakciók spekulatív mechanizmusok. Programozási szinten ezek atomzárak, de belül spekulációk. Az ilyen előrejelzés akkor működik, ha a legtöbb találgatás helyes. Ezért a tranzakciós memória jól működik, ha a szálak alig lépnek interakcióba egymással, és csak meg kell győződnie arról, hogy nincs interakció. De ha egy üzenet elindul a szálak között, a tranzakcióknak nem sok haszna van. Hadd magyarázzam el, arról az esetről beszélünk, amikor a tranzakciók a teljes atomművelet köré fonódnak. Továbbra is sikeresen használhatók többszálú adatstruktúrák komponenseiként. Például, ha szüksége van egy háromszavas CAS-ra, és három apró dolgot kell többszálon átfűznie egy valóban többszálú algoritmus közepén, amely húsz szállal működik egyszerre. A tranzakciók általában hasznosak lehetnek, de nem szüntetik meg a többszálú adatstruktúrák megfelelő tervezésének szükségességét.
Nem felejtő memória, Optane DIMM, ultragyors eszközök.
Виталий: Az utolsó dolog, amiről szeretnék beszélni, az aktuális kutatásának témája: a nem felejtő memória. Mire számíthatunk ezen a területen a közeljövőben? Esetleg tud olyan hatékony megvalósításról, amely már létezik?
Michael: Nem vagyok hardverszakértő, csak azt tudom, amit a hírekben olvasok, és amit a kollégáim mondanak. Mindenki hallott már arról, hogy az Intel árul , amelyek körülbelül 3-szor nagyobb olvasási és 10-szeres írási késleltetéssel rendelkeznek, mint a dinamikus RAM. Hamarosan nagyon nagy példányszámban is elérhetők lesznek. Vicces belegondolni, hogy több terabájt bájt címezhető RAM-mal rendelkező laptopja lehet. Valószínű, hogy 10 év múlva úgy döntünk, hogy ezt az új technológiát használjuk, mivel DRAM-ot használunk - csak növelje a hangerőt. De az energiafüggetlenségnek köszönhetően teljesen új lehetőségek nyílnak meg előttünk. Alapvetően megváltoztathatjuk a tárolóvermet, hogy ne legyen szétválasztás a bájtcímezhető munkamemória és a blokk-strukturált állandó memória között. Így nem kell mindent, amit az egyik futott programból a másikba át kell vinnünk blokk-strukturált fájlokba szerializálnunk. Ebből számos fontos alapelvet levezethetünk, amelyek hatással vannak az operációs rendszerekre, a futási környezetekre és az elosztott adattárolókra. Ezen a területen nagyon érdekes dolgozni. Személy szerint számomra nehéz megjósolni, hogy mindez mihez fog vezetni, de a problémák itt rendkívül szórakoztatóak. Forradalmi változások történhetnek itt, és ezek nagyon természetesen következnek a többszálas munkából, hiszen a hibajavítás a rendszer normál működése mellett "többszálas" folyamat.
A második fő téma, amelyen jelenleg dolgozom, az ultragyors eszközök kezelése és az eszközökhöz való biztonságos hozzáférés a felhasználói térből szisztémás házirend-vezérléssel. Az elmúlt években az a tendencia, hogy az eszközhöz való hozzáférést a felhasználói területre helyezik át. Ez azért van így, mert a TCP-IP kernelverem nem tud működni olyan hálózati interfészen, amelynek 5 mikromásodpercenként új csomagra van szüksége; egyszerűen nem fog lépést tartani. Ezért a gyártók közvetlen hozzáférést biztosítanak az eszközökhöz. Ez azonban azt jelenti, hogy az operációs rendszer elveszti az irányítást a folyamat felett, és nem tud megfelelő hozzáférést biztosítani az eszközhöz a versengő alkalmazások számára. Kutatócsoportunk úgy véli, hogy ez a hiányosság elkerülhető. Ebben a hónapban lesz egy cikkünk erről a USENIX ATC-nél. Ez a perzisztenciával kapcsolatos munkához kapcsolódik, mivel a hosszú élettartamú bájtcímezhető perzisztens memória lényegében egy ultragyors I/O-val rendelkező eszköz, amelyet a felhasználói térben kell elérni. Ez a kutatás új megközelítéseket tesz lehetővé a mikrokernelekhez, exokernelekhez és más hagyományos kísérletekhez, amelyekkel biztonságosan áthelyezhető a funkcionalitás az operációs rendszer kerneléből a felhasználói térbe.
Vladimir: A bájtcímezhető memória nagyszerű, de van egy fizikai korlát - a fénysebesség. Ez azt jelenti, hogy elkerülhetetlenül késések lépnek fel az eszközzel való interakció során.
Michael: Teljesen igaza van.
Vladimir: Lesz-e elég kapacitás az új terhelések megbirkózásához?
Michael: Ez egy kiváló kérdés, de nehéz lesz válaszolnom. A memóriában való feldolgozás ötlete már jó ideje létezik, nagyon érdekes, de nagyon összetett is. Nem dolgoztam ezen a területen, de jó lenne, ha itt születnének néhány felfedezés. Attól tartok, nincs több hozzáfűznivalóm.
Vladimir: Van még egy probléma. Új, lényegesen nagyobb mennyiségű RAM nem fér bele a CPU-ba. Ezért a fizikai korlátok miatt ezt a RAM-ot el kell különíteni.
Michael: Minden az integrált áramkörök gyártása során fellépő hibák számától függ. Ha teljesen hibamentesen lehetne félvezető lapkákat készíteni, akkor egy egész mikroáramkört lehetne belőle készíteni. De most nem tudjuk, hogyan készítsünk mikroáramköröket a postai bélyegeknél nagyobbra.
Vladimir: De még mindig hatalmas méretekről beszélünk, centiméterekről. Ez elkerülhetetlenül hatással van a késleltetésre.
Michael: Igen. A fénysebesség ellen nem tudsz mit tenni.
Vladimir: Sajnálatos módon.
A következő nagy trend. Kettős adatstruktúra. Hydra.
Виталий: Ha jól értem, nagyon gyorsan elkapod az új trendeket. Ön az elsők között dolgozott tranzakciós memóriában, és az elsők között, aki nem felejtő memóriában dolgozott. Szerinted mi lesz a következő nagy trend? Vagy talán ez titok?
Michael: Őszintén szólva nem tudom. Remélem, észre fogom venni, ha valami újdonság érkezik. Egyedül nem volt szerencsém semmilyen új területet kitalálni, de volt egy kis szerencsém, és elég korán elkezdhettem dolgozni mások által létrehozott új területeken. Remélem, a jövőben is képes leszek erre.
Alex: Az utolsó kérdés ebben az interjúban a Hydránál végzett teljesítményedről és az iskolai tevékenységeidről szól. Ha jól értem, az iskolában a blokkolásmentes algoritmusokról, a konferencián pedig a kettős adatstruktúrákról lesz szó. Mondana néhány szót ezekről a jelentésekről?
Michael: Részben ezeket a témákat már érintettük veled ebben az interjúban. Arról a munkáról szól, amit a tanítványommal, Bill Schererrel végeztem. Szakdolgozatot írt róla, és Doug Lee is hozzájárult hozzá, és végül a Java könyvtár többszálas szinkron sorainak részévé vált. Tegyük fel, hogy az adatstruktúra olvasása és írása blokkolás nélkül történik, vagyis minden műveletnek korlátozott számú utasítása van a kritikus úton. Ha egy üres tárolóból próbál eltávolítani adatokat, vagy megpróbál eltávolítani bizonyos adatokat, amelyek nem ebben a tárolóban vannak, azonnal értesítjük, hogy ez nem lehetséges. Ez a viselkedés azonban nem biztos, hogy elfogadható, ha a szálnak valóban szüksége van ezekre az adatokra. Ezután az első dolog, ami eszünkbe jut, egy ciklus létrehozása, amely folyamatosan megkérdezi, hogy megjelentek-e a szükséges adatok. De akkor mindenki mást zavar. Ráadásul ezzel a megközelítéssel várhatsz 10 percet, majd jön valami másik szál, és véletlenül előbb kapja meg a szükséges adatokat. A kettős adatszerkezetek továbbra sem rendelkeznek zárral, de lehetővé teszik a szálak megfelelő várakozását. A "dupla" kifejezés azt jelenti, hogy a struktúra vagy adatokat vagy adatkéréseket tartalmaz, nevezzük ezeket anti-adatnak. Tehát ha egy üres tárolóból próbál lekérni valamit, akkor a rendszer egy kérést küld a tárolóba. Most a szál várhat egy kérésre anélkül, hogy bárki mást zavarna. Ezenkívül az adatstruktúra prioritásokat rendel a kérésekhez, így a megérkezésükkor továbbítja azokat a megfelelő személynek. Az eredmény egy nem reteszelő mechanizmus, amely még mindig rendelkezik formális specifikációkkal és jó a gyakorlatban.
Alex: Mit vár el ettől az adatstruktúrától? Minden általános esetben javítja a teljesítményt, vagy alkalmasabb bizonyos helyzetekre?
Michael: Hasznos, ha egyrészt zárolás nélküli konténerre van szüksége, másrészt várnia kell egy olyan helyzetben, amikor olyan adatokat kell lekérnie a tárolóból, amely nincs benne. Legjobb tudomásom szerint keretrendszerünk optimális viselkedést biztosít, ha ez a két feltétel teljesül. Ezért ezekben az esetekben javaslom a használatát. A zár nélküli adatstruktúrák fő előnye, hogy elkerülik a teljesítményproblémákat. A várakozás pedig nagyon fontos sok algoritmusban, ha az egyik szálból a másikba adatátvitel történik.
Виталий: Pontosítok: ugyanarról fog beszélni az iskolában és a konferencián is?
Michael: Iskolában általánosságban a többszálú adatstruktúrákról, a lecke elején felvázolt alapelvekkel. Feltételezem, hogy a közönség tudja, mi a szál, és ismeri a zárakat. Ezen alapismeretek alapján fogok beszélni a zármentes adatstruktúrákról. Áttekintést adok az e terület legfontosabb problémáiról, olyan témákat érintve, mint a memóriakezelés. Szerintem az MS-sornál nem lesz bonyolultabb.
Alex: Tervezi, hogy az iskolai óra végén a kettős adatstruktúrákról tanít?
Michael: Megemlítem őket, de nem fogok rájuk sok időt fordítani. A Hydra-jelentést nekik ajánljuk. Ez lefedi azt a projektet, amely végül bejutott a Java-ba, valamint Joe Israelevich-csal együttműködve az LCRQ-sor kettős változatának létrehozására, valamint egy szinte univerzális kialakításra a kettős adatstruktúrákra.
Alex: Tehát az iskolai előadás kezdőknek ajánlható, a kettős adatstruktúrákról szóló előadás a Hydra-n - azoknak, akik már rendelkeznek némi tapasztalattal?
Michael: Javítsatok ki, ha tévedek, de a Hydra közönsége meglehetősen sokszínű lesz, sok Java-szakértő, és általában olyan emberek is, akik nem foglalkoznak kifejezetten többszálú programozással.
Виталий: Igen igaz.
Alex: Legalábbis reméljük.
Michael: Ebben az esetben ugyanazzal a problémával fogok szembesülni, mint amivel ezt az interjút kezdtük: hogyan lehet egy riportot technikai részletekben kellően gazdagon és minden hallgató számára hozzáférhetővé tenni.
Виталий: Ugyanúgy fogsz beszámolót tartani, mint előadásokat tartani? Vagyis beszélni a közönséggel és alkalmazkodni a helyzethez?
Michael: Attól tartok, hogy ez nem így fog menni, mert a riportnak lesznek diákjai. A diák akkor fontos, ha a hallgatók kezdetben különböző nyelveken beszélnek. Sok embernek nehéz lesz megértenie angolul, különösen, ha túl gyorsan beszélek. Azért választottam ezeket a témákat megkért, hogy beszéljek az SPTDC School zármentes adatstruktúráiról; majd szükségem volt egy jelentésre egy Java felhasználói csoport konferenciájára, és olyat akartam választani, ami kifejezetten a Java programozókat érdekelné. A legegyszerűbb az volt, hogy a Java-könyvtárban azokról a dolgokról beszéltem, amelyekben így vagy úgy volt a kezem.
Alex: Feltételezzük, hogy a Hydra közönsége már tud valamit a zár nélküli programozásról, és talán van némi tapasztalata ezen a területen. De ez csak feltételezés, a helyzet magától a konferencián fog világosabbá válni. Mindenesetre köszönöm az idejét. Biztos vagyok benne, hogy az interjú nagyon érdekes lesz olvasóink számára. Nagyon köszönöm!
Виталий: Köszönöm.
Michael: Örülök, hogy találkozunk Szentpéterváron.
Alex: Nekünk is szép városunk van. Voltál már itt valaha?
Michael: Nem, még soha nem voltam Oroszországban. De Szentpétervár mindig is ott volt azon helyek listáján, ahol még nem, de ahová nagyon szeretnék eljutni, ezért nagyon örültem a meghívásnak.
Alex: Egyébként lesz egy kirándulási programunk az előadóknak. Köszönöm szépen az interjút, további szép napot!
Michaellel 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