- Tietojenkäsittelytieteen professorina Rochesterin yliopistossa ja kotonaan Wisconsin-Madisonin yliopistossa dekaanina viisi vuotta. Hän tutkii ja opettaa opiskelijoille rinnakkais- ja hajautettua ohjelmointia ja kielisuunnittelua.
Maailma tuntee Michaelin oppikirjasta , entä työ sai Dijkstra-palkinnon yhtenä hajautetun tietojenkäsittelyn tunnetuimmista. Saatat myös tuntea hänet juuri tuon algoritmin kirjoittajana .
Hän kehitti yhdessä Doug Leen kanssa estävät algoritmit ja synkroniset jonot, jotka toimivat Java-kirjastoissa. Toteutus JavaSE 6 paransi suorituskykyä 10 kertaa ThreadPoolExecutor.
Sisältö:
- Varhainen ura, Rochesterin yliopisto. Project Charlotte, Lynx-kieli;
- IEEE Scalable Coherent Interface, MCS-lukitus;
- Selviytyminen jatkuvasti muuttuvassa maailmassa;
- Ovatko oppilaat tyhmempiä? Globaalit trendit, kansainvälistyminen;
- Tehokas työskentely opiskelijoiden kanssa;
- Kuinka pysyä mukana uusien kurssien ja kirjojen valmistelussa;
- Liike-elämän ja korkeakoulujen väliset yhteydet;
- Ideoiden käytännön toteutus. MCS, MS, CLH, JSR 166, työskentely Doug Leen ja muiden kanssa;
- Tapahtumamuisti;
- Uudet arkkitehtuurit. Tapahtumamuistin voitto on lähellä;
- Haihtumaton muisti, Optane DIMM, erittäin nopeat laitteet;
- Seuraava suuri trendi. Kaksoistietorakenteet. Hydra.
Haastattelun suorittaa:
Vitali Aksenov — tällä hetkellä postdoc IST Austriassa ja ITMO-yliopiston tietokonetekniikan laitoksen jäsen. Tekee tutkimusta kilpailukykyisten tietorakenteiden teorian ja käytännön alalla. Ennen työskentelyä IST:llä hän suoritti tohtorin tutkinnon Paris Diderot -yliopistosta ja ITMO-yliopistosta professori Peter Kuznetsovin johdolla.
Aleksei Fedorov - Tuottaja JUG Ru Groupissa, venäläisessä yrityksessä, joka järjestää konferensseja kehittäjille. Aleksei osallistui yli 50 konferenssin valmisteluun, ja hänen ansioluettelonsa sisältää kaiken Oraclen kehitysinsinöörin tehtävästä (JCK, Java Platform Group) Odnoklassnikin kehittäjäksi.
Vladimir Sitnikov - Insinööri Netcrackerissa. Kymmenen vuotta työtä NetCracker OS:n suorituskyvyn ja skaalautuvuuden parissa. Ohjelmisto on teleoperaattoreiden käyttämä verkko- ja verkkolaitteiden hallintaprosessien automatisointiin. Kiinnostunut Java- ja Oracle Database -suorituskykyongelmista. Yli tusinan virallisen PostgreSQL JDBC -ohjaimen suorituskykyparannuksen kirjoittaja.
Varhainen ura, Rochesterin yliopisto. Charlotte-projekti, Lynx-kieli.
alexey: Aluksi halusin kertoa, että Venäjällä me kaikki todella rakastamme tietojenkäsittelytiedettä, tietotieteitä ja algoritmeja. Se on suorastaan säädytöntä. Olemme lukeneet kaiken . Siksi tulevan konferenssin, koulun ja itse haastattelun pitäisi olla erittäin suosittuja. Saimme tähän haastatteluun monia kysymyksiä opiskelijoilta, ohjelmoijilta ja yhteisön jäseniltä, joten olemme erittäin kiitollisia tästä mahdollisuudesta. Saako tietojenkäsittelytiede samanlaista rakkautta Yhdysvalloissa?
Michael: Alamme on niin monipuolinen, sillä on niin monta suuntaa ja se vaikuttaa yhteiskuntaan niin monin eri tavoin, että minun on vaikea antaa teille lopullista vastausta. Mutta tosiasia on, että se on aiheuttanut valtavia muutoksia liike-elämässä, teollisuudessa, taiteessa ja yhteiskunnassa yleensä viimeisten 30 vuoden aikana.
Виталий: Aloitetaan jostain kaukaisesta. Monissa yliopistoissa on jotain erikoistumista yhdelle tietylle alueelle. Carnegie Mellon Universitylle tämä on rinnakkaislaskentaa, MIT:lle salausta, robotteja ja monisäikeistystä. Onko Rochesterin yliopistossa tällaista erikoisalaa?
Michael: Ollakseni rehellinen, sanoisin, että CMU ja MIT ovat erikoistuneet kaikille aloille. Osastomme on aina kiinnittänyt eniten huomiota tekoälyyn. Puolet meillä työskentelevistä ihmisistä on tekoälyn tai ihmisen ja tietokoneen vuorovaikutuksessa - tämä osuus on suurempi kuin muilla osastoilla, ja niin on aina ollut. Mutta kun olin yliopistossa, minulla ei ollut tekoälyn kursseja, enkä koskaan työskennellyt tällä alalla. Osastoni on siis erikoistunut ongelmaan, jonka kanssa minulla ei ole mitään tekemistä. Lohdutuksena on se, että osastomme toiseksi tärkein ongelma on rinnakkais- ja monisäikeinen ohjelmointi eli erikoistumiseni.
Виталий: Aloitit tietojenkäsittelytieteen alalla, kun monisäikeisen ohjelmoinnin ala oli juuri syntymässä. Julkaisuluettelosi osoittaa, että ensimmäiset työsi käsittelivät melko monenlaisia kysymyksiä: muistinhallintaa monisäikeisissä järjestelmissä, hajautettuja tiedostojärjestelmiä, käyttöjärjestelmiä. Miksi tällainen monipuolisuus? Oletko yrittänyt löytää paikkasi tutkimusyhteisössä?
Michael: Opiskelijana osallistuin Wisconsinin yliopistossa, jossa kehitettiin yksi ensimmäisistä hajautetuista käyttöjärjestelmistä. Siellä työskentelin yhdessä Rafael Finkelin kanssa () ja Marvin Solomon (). Väitöskirjani oli omistettu hajautettujen järjestelmien järjestelmäohjelmistojen kielen kehittämiseen - nyt kaikki ovat unohtaneet sen, ja luojan kiitos. Tein Lynx-ohjelmointikielen, jonka tarkoituksena oli helpottaa palvelinten luomista löyhästi kytketylle hajautetulle käyttöjärjestelmälle. Koska olin tuolloin pääosin mukana käyttöjärjestelmissä, oletin urani liittyvän pääasiassa niihin. Mutta Rochester oli hyvin pieni yliopisto, ja tämän vuoksi siellä olevat eri ryhmät olivat hyvin tiiviissä vuorovaikutuksessa toistensa kanssa. Siellä ei ollut tusinaa muuta käyttöjärjestelmää käyttävää henkilöä, jolle voisin puhua, joten kaikki kontaktini olivat ihmisten kanssa, jotka työskentelivät täysin eri aloilla. Pidin siitä todella, monitaituri on minulle suuri etu. Jos puhumme nimenomaan monisäikeisistä tietorakenteista ja synkronointialgoritmeista, aloin työstää niitä täysin vahingossa.
IEEE Scalable Coherent Interface, MCS-lukitus.
Виталий: Voitko kertoa tästä vähän enemmän?
Michael: Tämä on hauska tarina, jota en koskaan kyllästy kertomaan kaikille. Se tapahtui konferenssissa Bostonissa - tämä oli 80-luvun lopulla tai 90-luvun alussa. John Mellor-Crummey (), valmistui tiedekunnastamme. Tunsin hänet, mutta emme olleet aiemmin tehneet yhteistä tutkimusta. Mary Vernon () Wisconsinista piti puheen moniprosessorijärjestelmästä, jota he kehittivät Wisconsinissa: . Tässä Multicubessa oli laitteistotasolla synkronointimekanismi nimeltä Q on Sync Bit, ja myöhemmin se nimettiin uudelleen Q on Lock Bitiksi, koska se kuulosti Colby-juustolta, joka oli sanapeli. Jos olet kiinnostunut monisäikeisistä mekanismeista, tiedät todennäköisesti, että Colbysta tuli lopulta IEEE Scalable Coherent Interface -standardin synkronointimoottori. Tämä oli lukitusmekanismi, joka loi osoittimia välimuistista toiseen laitteistotasolla, jotta jokainen lukon pidike tiesi kenen vuoro oli. Kun John ja minä kuulimme tästä, katsoimme toisiamme ja sanoimme: miksi tämä tehdään laitteistotasolla? Eikö samaa voi saavuttaa vertaa ja vaihtaa? Otimme yhden luokassa makaavista vihkoista ja kirjoitimme siihen , kun Mary jatkoi raporttiaan. Myöhemmin toteutimme sen, kokeilimme, idea osoittautui onnistuneeksi ja julkaisimme artikkelin. Minulle tämä aihe tuntui tuolloin vain hauskalta häiriötekijältä, jonka jälkeen suunnittelin palaavani käyttöjärjestelmiin. Mutta sitten ilmeni toinen samansuuntainen ongelma, ja lopulta synkronoinnista, monisäikeisyydestä ja tietorakenteista tuli erikoisalani. Kuten näette, tämä kaikki tapahtui vahingossa.
Виталий: Olen tuntenut MCS-eston pitkään, mutta tähän asti en tiennyt, että se oli sinun työtäsi, enkä ymmärtänyt, että se oli lyhenne sukunimestäsi.
Kuinka selviytyä jatkuvasti muuttuvassa maailmassa?
alexey: Minulla on kysymys liittyvästä aiheesta. 30 tai 40 vuotta sitten eri erikoisaloilla oli enemmän vapautta. Jos haluat aloittaa uran monisäikeisten tai hajautettujen järjestelmien parissa, olet tervetullut, jos haluat päästä käyttöjärjestelmiin, ei hätää. Jokaisella alueella oli paljon avoimia kysymyksiä ja vähän asiantuntijoita. Nyt on syntynyt kapeat erikoisalat: ei ole olemassa vain yleisten käyttöjärjestelmien asiantuntijoita, on yksittäisten järjestelmien asiantuntijoita. Sama koskee monisäikeisiä ja hajautettuja järjestelmiä. Mutta ongelmana on, että elämämme ei ole loputonta, vaan jokainen voi omistaa vain muutaman vuosikymmenen tutkimukselle. Kuinka selviytyä tässä uudessa maailmassa?
Michael: Emme ole erityisiä tässä suhteessa, sama asia tapahtui kerran muilla alueilla. Olin onnekas, että aloin työskennellä tietojenkäsittelytieteessä, kun ala oli "teini-iässä". Jotkut perustukset oli jo luotu, mutta kaikki oli vielä hyvin epäkypsää. Tämä tilaisuus ei tule usein vastaan. Sähkötekniikka on ollut olemassa hyvin kauan, fysiikka vielä pidempään, matematiikka melkein aikojen alusta. Mutta tämä ei tarkoita, etteikö kukaan enää tekisi mielenkiintoisia löytöjä matematiikassa. On vielä monia avoimia ongelmia, mutta samalla on opittava lisää. Olet oikeassa huomatessasi, että erikoisaloja on nyt paljon enemmän kuin ennen, mutta tämä tarkoittaa vain sitä, että olemme samassa tilanteessa kuin useimmat muut ihmisen toiminnan osa-alueet.
alexey: Olen kiinnostunut ongelman käytännönläheisemmistä puolista täällä. Minulla on matemaattinen tausta ja opintojeni aikana osallistuin usein konferensseihin ja työskentelin erilaisten tieteellisten aiheiden parissa. Huomasin, ettei kukaan kuulijoista ymmärtänyt raporttejani, ja samalla tavalla muiden ihmisten raportit olivat ymmärrettäviä vain heille itselleen. Näin ei ole korkean tason aiheissa, mutta heti kun alat syventyä johonkin, yleisö ei enää pysy perässäsi. Miten suhtaudut tähän?
Michael: Ei aina onnistunut. Tein hiljattain raportin, jossa menin liian syvälle teknisiin yksityiskohtiin. Puheen edetessä kävi selväksi, että suurin osa yleisöstä ei ymmärtänyt minua, joten jouduin sopeutumaan tilanteeseen lennossa. Dioja ei voinut vaihtaa, joten se ei onnistunut kovin hyvin - joten yleisesti ottaen yritän olla käyttämättä dioja. Kaiken kaikkiaan neuvoni on ottaa yleisösi huomioon. Sinun on tiedettävä, kenen kanssa puhut, mikä on heidän tietämyksensä ja mitä heidän on kuultava voidakseen arvostaa työtäsi.
Виталий: Voisitko antaa vihjeen, mistä tässä luennossa oli kyse?
Michael: Ollakseni rehellinen, en haluaisi laajentaa tätä aihetta jättääkseni kyseiset henkilöt anonyymeiksi. Asia on siinä, että joudumme usein liian syvälle käsittelemämme ongelman monimutkaisuuteen, joten meidän on vaikea selittää puheen alussa, miksi ongelma on mielenkiintoinen ja tärkeä ja miten se liittyy asioihin, jotka yleisö jo tietää. Havaintojeni mukaan opiskelijoiden on vaikeinta oppia tämä taito. Ja tämä oli myös äskettäisen raportin heikko kohta. Oikein jäsennellyn raportin tulee alusta alkaen löytää yhteys yleisöön, selittää heille, mikä ongelma tarkalleen ottaen on ja miten se liittyy sen jo tuntemiin aiheisiin. Kuinka tekninen tämä esittely on, riippuu yleisöstä. Jos se on täysin kirjava, raportti voi olla monivaiheinen. Esittelyn tulee olla kaikkien saatavilla, ja loppuvaiheessa teos ei ehkä pysy perässäsi, mutta alasi suhteellisen tuntevat ihmiset voivat selvittää sen.
Ovatko oppilaat tyhmempiä? Globaalit trendit, kansainvälistyminen.
alexey: Olet seurannut opiskelijoita useiden vuosikymmenien ajan. Ovatko opiskelijat tyhmempiä tai älykkäämpiä vuosikymmenestä toiseen tai vuodesta toiseen? Venäjällä professorit valittavat jatkuvasti, että opiskelijat muuttuvat vuosi vuodelta tyhmemmiksi, eikä ole todellakaan selvää, mitä asialle pitäisi tehdä.
Michael: Voit todella kuulla paljon negatiivisuutta meiltä vanhoilta ihmisiltä. Alitajuisesti meillä on taipumus odottaa opiskelijoiden ottavan vastaan kaikki 30 vuoden kokemus, joka meillä on jo. Jos minulla on syvempi ymmärrys kuin vuonna 1985, miksi opiskelijoilla ei ole sitä? Luultavasti siksi, että he ovat 20-vuotiaita, mitä mieltä olette? Mielestäni merkittävimmät muutokset viime vuosikymmeninä ovat olleet demografisessa koostumuksessa: meillä on nyt huomattavasti enemmän kansainvälisiä opiskelijoita kanadalaisia lukuun ottamatta. Aiemmin kanadalaisia oli paljon, koska olemme hyvin lähellä Kanadan rajaa ja sieltä tulevat opiskelijat voivat matkustaa kotiin viikonloppuisin. Mutta nyt Kanadassa on monia hyviä yliopistoja, ja kanadalaiset haluavat opiskella täällä; huomattavasti vähemmän heistä tulee Yhdysvaltoihin.
alexey: Onko tämä mielestäsi paikallinen vai globaali trendi?
Michael: En muista tarkalleen kuka, mutta joku sanoi, että maailma on litteä. Alamme on kansainvälistynyt huomattavasti. Aikaisemmin ne pidettiin yksinomaan Yhdysvalloissa, sitten he päättivät järjestää ne joka neljäs vuosi muissa maissa, ja nyt niitä pidetään kaikkialla maailmassa. Nämä muutokset vaikuttivat vielä enemmän , koska se on aina ollut kansainvälisempi organisaatio kuin ACM. Ja ohjelmatuoleja on Kiinasta, Intiasta, Venäjältä, Saksasta ja monista muista maista, koska nyt on paljon meneillään kaikkialla.
alexey: Mutta luultavasti tällaisessa kansainvälistymisessä on joitain negatiivisia puolia?
Michael: Sanoisin, että kaikki negatiiviset puolet eivät liity tekniikkaan vaan politiikkaan. Olipa kerran pääongelmana se, että Yhdysvallat varasti älykkäimpiä ja lahjakkaimpia ihmisiä eri puolilta maailmaa. Ja nyt suurin ongelma on eri maiden väliset poliittiset pelit viisumien ja maahanmuuton ympärillä.
alexey: Eli esteitä ja sellaisia asioita. Se on selvää.
Vladimir: Henkilökohtaisesti olen kiinnostunut siitä, millaista lähestymistapaa käytät opettaessasi uutta ainetta opiskelijoille. Vaihtoehtoja on useita: voit ensin yrittää innostaa heitä kokeilemaan jotain uutta tai voit kiinnittää enemmän huomiota tietyn tekniikan yksityiskohtiin. Mitä pidät parempana?
Tehokas työskentely opiskelijoiden kanssa
alexey: Ja kuinka löytää pirun tasapaino ensimmäisen ja toisen välillä?
Michael: Ongelmana on, että tunnit eivät aina mene niin kuin haluaisin. Yleensä annan opiskelijoille luettavaa etukäteen, jotta he syventyvät siihen, ymmärtävät parhaan kykynsä mukaan ja muotoilevat kysymyksiä niistä kohdista, joita he eivät ymmärtäneet. Sitten tunnilla voit keskittyä vaikeimpiin hetkiin ja tutkia niitä yhdessä. Näin pidän eniten oppituntien opettamisesta. Mutta kun otetaan huomioon opiskelijoilla nyt oleva taakka, en aina pysty varmistamaan, että he valmistautuvat etukäteen. Tämän seurauksena joudut käyttämään paljon enemmän aikaa materiaalin yleiseen uudelleenkertomiseen kuin haluaisit. Tästä huolimatta yritän pitää tunnimme interaktiivisina. Muuten on helpompi tallentaa video kerran, jonka opiskelijat voivat katsoa kotona. Live-tuntien pointti on ihmisten välinen vuorovaikutus. Luokassa käytän mieluummin liitua ja liitutaulua kuin dioja, paitsi tietyissä tapauksissa, joissa kaavio on liian monimutkainen taululle kuvaamiseksi. Tämän ansiosta minun ei tarvitse pitää kiinni jäykästä tuntisuunnitelmasta. Koska aineiston antamisessa ei ole tiukkaa järjestystä, voin näin räätälöidä sen yleisölle saamieni kysymysten mukaan. Yleensä yritän tehdä tunnit mahdollisimman interaktiivisiksi, jotta esitettävä materiaali riippuu minulle esitettävistä kysymyksistä.
Vladimir: Se on mahtava. Kokemukseni mukaan on melko vaikeaa saada kuuntelijoita esittämään kysymyksiä. Vaikka kysyisit etukäteen kysyäksesi kysymyksiä, olivatpa ne kuinka tyhmiä tai älykkäitä tahansa, he ovat silti hiljaa. Miten suhtaudut tähän?
Michael: Naurat, mutta jos seisot hiljaa tarpeeksi kauan, ennemmin tai myöhemmin kaikki tuntevat olonsa epämukavaksi ja joku kysyy. Tai voit kysyä yksinkertaisen teknisen kysymyksen ja vastauksen kyllä tai ei selvittääksesi, ymmärtävätkö ihmiset juuri sanotun. Onko esimerkiksi datakilpailu yllä olevassa esimerkissä? Kuka niin luulee? Kenen mielestä ei? Kuka ei ymmärrä yhtään mitään, koska yhteensä vain puolet käsistä nousi?
Виталий: Ja jos vastasit väärin, sinut potkitaan luokasta :)
Michael: Jos et ole vastannut mihinkään, sinun tulee esittää kysymys. Minun on ymmärrettävä, mitä opiskelijan tarkalleen tarvitsee tietää vastatakseen juuri esittämääni kysymykseen. Tarvitsen heitä auttamaan minua auttamaan heitä. Olen valmis sopeutumaan niihin, jotta he ymmärtävät ongelman. Mutta jos en tiedä mitä heidän päässään liikkuu, en voi tehdä sitä. Ja jos opiskelijoille ei anneta rauhaa riittävän pitkään, joskus he kysyvät lopulta oikeita kysymyksiä, eli sellaisia, joiden avulla voin nähdä, mitä opiskelijoiden päässä oikein liikkuu.
alexey: Johtavatko nämä kysymykset joskus ideoihin, joita et itse ollut aiemmin ajatellut? Ovatko ne odottamattomia? Antavatko ne sinun tarkastella ongelmaa uudessa valossa?
Michael: On kysymyksiä, jotka avaavat uuden tavan esittää materiaalia. Usein tulee kysymyksiä, jotka johtavat mielenkiintoisiin ongelmiin, joista en aikonut puhua. Opiskelijat kertovat minulle usein, että minulla on taipumus poiketa aiheesta, kun näin tapahtuu. Ja heidän mukaansa tämä on hyvin usein oppitunnin mielenkiintoisin osa. Hyvin harvoin, vain muutaman kerran, opiskelijat esittivät kysymyksiä, jotka saivat uuden suunnan tutkimuksessa ja kasvoivat artikkeliksi. Tämä tapahtuu paljon useammin keskusteluissa opiskelijoiden kanssa kuin oppituntien aikana, mutta toisinaan sitä tapahtui tunneilla.
alexey: Joten opiskelijat kysyivät sinulta kysymyksiä, joiden perusteella oli mahdollista julkaista artikkeli?
Michael: Joo.
Виталий: Kuinka usein keskustelet oppilaiden kanssa? Milloin he haluavat oppia enemmän kuin mitä oppitunnilla käsiteltiin?
Michael: Jatko-opiskelijoideni kanssa - koko ajan. Minulla on niitä noin 5 tai 6, ja keskustelemme heidän kanssaan jostain koko ajan. Ja tämänkaltaiset keskustelut opiskelijoiden kanssa, jotka vain käyvät luokassani, eivät ole kovin yleisiä. Vaikka toivoisin, että tämä tapahtuisi useammin. Epäilen, että he yksinkertaisesti pelkäävät tulla tiedekuntaan virka-aikoina. Joka lukukausi jotkut opiskelijat onnistuvat voittamaan tämän psykologisen esteen, ja on aina erittäin mielenkiintoista keskustella heidän kanssaan tunnin jälkeen. Totta, jos kaikki opiskelijat olisivat yhtä rohkeita, minulla ei yksinkertaisesti olisi tarpeeksi aikaa. Joten ehkä kaikki toimii niin kuin pitää.
Виталий: Kuinka onnistut löytämään aikaa kommunikointiin opiskelijoiden kanssa? Yhdysvalloista tietääkseni opettajilla on paljon työtä - apurahojen hakemista ja muuta vastaavaa.
Michael: Rehellisesti sanottuna opiskelijoiden kanssa työskentely on se osa työtäni, josta pidän eniten. Joten minulla on tarpeeksi motivaatiota tähän. Suurin osa ajastani toimistossani kuluu kaikenlaisiin kokouksiin. Nyt on kesä, joten aikatauluni on vähemmän kiireinen, mutta lukuvuoden aikana minulla on joka päivä klo 9-17 kaikki pakattuna. Tutkimustyöt, katsaukset, apurahat - kaikkea tätä varten on vain illat ja viikonloput.
Kuinka pysyä mukana uusien kurssien ja kirjojen valmistelussa.
alexey: Jatkatko tällä hetkellä jonkin kurssien opettamista, jota olet opettanut pitkään? Vähän kuin johdatus tietojenkäsittelytieteeseen.
Michael: Ensimmäisenä tulee mieleen ohjelmointikielten kurssi.
alexey: Kuinka erilainen tämän kurssin tämän päivän versio on 10, 20, 30 vuotta sitten? Ehkä mielenkiintoisempaa tässä ei ole tietyn kurssin yksityiskohdat, vaan yleiset trendit.
Michael: Ohjelmointikielikurssini oli hieman epätavallinen silloin, kun tein sen. Aloin lukea sitä 1980-luvun lopulla korvaten kollegani Doug Baldwinin (). Kurssin aihe liittyi vain tangentiaalisesti erikoisalaani, mutta hänen lähtiessään olin paras ehdokas kurssin opettajaksi. En pitänyt mistään tuolloin olemassa olevista oppikirjoista, joten päädyin kirjoittamaan tämän kurssin oppikirjan itse. (Toimittajan huomautus: puhumme kirjasta) Sitä käytetään nyt yli 200 yliopistossa ympäri maailmaa. Lähestymistavani on epätavallinen siinä mielessä, että se sekoittaa tietoisesti kielen suunnittelun ja toteutuksen ongelmat ja kiinnittää paljon huomiota näiden näkökohtien väliseen vuorovaikutukseen kaikilla mahdollisilla alueilla. Peruslähestymistapa on säilynyt ennallaan, kuten monet peruskäsitteet: abstraktiot, nimitilat, modulaarisuus, tyypit. Mutta kielten joukko, jolla nämä käsitteet esitetään, on muuttunut täysin. Kun kurssi luotiin ensimmäisen kerran, Pascalissa oli monia esimerkkejä, mutta nykyään monet oppilaistani eivät ole edes kuulleet tästä kielestä. Mutta he tuntevat Swiftin, Gon, Rustin, joten minun on puhuttava nykyään käytössä olevista kielistä. Lisäksi opiskelijat tuntevat nyt hyvin skriptikieliä, mutta kun aloin opettaa tätä kurssia, kyse oli käännetyistä kielistä. Nyt tarvitsemme paljon materiaalia Pythonista, Rubysta ja jopa Perlistä, koska tätä koodia kirjoitetaan nykyään, ja näillä kielillä tapahtuu paljon mielenkiintoista, myös kielisuunnittelun alalla.
Виталий: Sitten seuraava kysymykseni liittyy edelliseen. Kuinka pysyä tällä alueella? Epäilen, että tällaisen kurssin päivittäminen vaatii paljon työtä - sinun täytyy ymmärtää uusia kieliä, ymmärtää tärkeimmät ajatukset. Miten teet tämän?
Michael: En voi ylpeillä, että onnistun aina 100%. Mutta suurimman osan ajasta teen vain sitä, mitä muut tekevät - luen Internetiä. Jos haluan ymmärtää Rustia, Googletan sen, siirryn Mozillan sivulle ja luen siellä julkaistun ohjekirjan. Tämä on osa kaupallisen kehityksen asioita. Jos puhumme tieteestä, sinun on seurattava tärkeimpien konferenssien raportteja.
Yhteys liike-elämän ja korkeakoulujen välillä
Виталий: Puhutaanpa liiketoiminnan ja tieteellisen tutkimuksen välisestä yhteydestä. Teosluettelostasi löysin useita artikkeleita välimuistin koherenssista. Ymmärrän, että välimuistin yhdenmukaisuusalgoritmit olivat epävakaita niiden julkaisuhetkellä? Tai ei ole tarpeeksi laajalle levinnyt. Kuinka yleisiä ajatuksesi olivat käytännössä?
Michael: En ole aivan varma, mistä julkaisuista puhut. Olen tehnyt melko paljon työtä opiskelijoideni Bill Boloskyn kanssa () ja Leonidas Kontotanassis () 1990-luvun alussa Neumann-koneiden muistinhallinnasta. Tuolloin yrityksillä ei vielä ollut ymmärrystä siitä, kuinka moniprosessorijärjestelmä tehdään oikein: kannattaako luoda tuki etämuistin käyttöön laitteistotasolla, kannattaako muistia hajauttaa, onko mahdollista ladata välimuisti etämuisti, vai pitääkö sivuja siirtää leikkaussalissa? Bill ja Leonidas työskentelivät molemmat tällä alueella ja tutkivat lähestymistapoja ilman välimuistin etälatausta. Tämä ei liittynyt suoraan välimuistin koherenssiin, mutta se oli silti työtä NUMA-muistinhallinnan parissa, ja myöhemmin modernit lähestymistavat sivujen sijoittamiseen nykyaikaisissa käyttöjärjestelmissä kasvoivat tästä. Kaiken kaikkiaan Bill ja Leonidas tekivät tärkeää työtä, vaikkakaan eivät kaikkein vaikutusvaltaisimpia tällä alueella – saman asian parissa työskenteli tuolloin monia muita ihmisiä. Myöhemmin työskentelin aiheen parissa, joka liittyy välimuistin koherenssiin laitteiston tapahtumamuistin yhteydessä. Ryhmä, jonka kanssa työskentelin tämän ongelman parissa, sai lopulta useita patentteja. Niiden takana on aika mielenkiintoisia ideoita, mutta en usko, että ne lopulta toteutuvat käytännössä. Tavalla tai toisella minun on vaikea arvioida heidän kannattavuuttaan.
alexey: Tässä yhteydessä henkilökohtaisempi kysymys: kuinka tärkeää sinulle on, että ideasi toteutetaan käytännössä? Vai etkö ajattele sitä?
Michael: Rakastan kysyä tätä kysymystä haastatteluissa muiden ihmisten, hakijoiden tai ehdokkaiden kanssa, jotka haluavat liittyä tiedekuntaan. En usko, että tähän kysymykseen on oikeaa vastausta. Ihmisillä, jotka tekevät hienoja asioita, voi olla hyvin erilaisia motivaatioita. Olen kiinnostunut ongelmista, koska pidän niitä mielenkiintoisina, en niiden käytännön hyödyn vuoksi. Mutta toisaalta, kun jokin mielenkiintoinen asia löytää edelleen käyttöä, pidän siitä todella. Joten täällä ei ole helppoa. Mutta työni alussa minua ei edelleenkään ohjaa ajatus maailman loppukäytöstä, vaan idean harmonia ja halu tutkia sitä ja nähdä mitä siitä tulee. Jos se lopulta antaa käytännön tuloksia, hienoa.
alexey: Koulutuksesi ja kokemuksesi ansiosta pystyt useimpia paremmin arvioimaan muiden ihmisten ideoiden arvon. Voit verrata niitä ja päättää, mikä toimii paremmin minkä kanssa. Olen varma, että sinulla on mielipide asioista, joita suuret valmistajat, kuten Intel, käyttävät tällä hetkellä käytännössä. Kuinka oikea näiden yritysten kurssi teidän näkökulmastanne on?
Michael: Harjoittelu pyörii aina sen ympärillä, mikä voi olla kaupallisesti menestyvää, eli tuottaa voittoa, ja sinun on parempi kysyä siitä joltain muulta. Työni tuloksena on pääosin julkaisuja, ja käyttöjärjestelmien alalla niitä arvioidaan suoritusindikaattoreiden perusteella: nopeus, energiankulutus, koodin koko. Mutta minusta on aina tuntunut, että näitä empiirisiä tuloksia lisätään artikkeleihin vain siksi, että ne voidaan julkaista, ja ihmisten todelliset motiivit työntekoon ovat esteettisiä. Tutkijat arvioivat ratkaisuja taiteellisesta näkökulmasta, he välittävät ideoiden tyylikkyydestä ja yrittävät luoda jotain parempaa kuin olemassa olevat lähestymistavat. Tutkijoita ohjaavat henkilökohtaiset, subjektiiviset, esteettiset motiivit. Mutta tästä ei voi kirjoittaa itse artikkeliin, nämä asiat eivät ole argumentteja ohjelmakomitealle. Onneksi tyylikkäät ratkaisut ovat usein myös nopeita ja edullisia. Kymmenen kollegani ja minä keskustelimme tästä aiheesta noin 15 vuotta sitten ja päädyimme kirjoittamaan siitä artikkelin. Luulen, että voit löytää sen vielä nyt, sitä kutsutaan tai jotain sellaista, sillä on yli tusina kirjoittajaa. Tämä on ainoa artikkeli, jonka kanssa olen kirjoittanut , joten jos haet hänen nimeään julkaisuluettelostani, löydät tarvitsemasi. Siinä puhutaan järjestelmätutkimuksen arvioinnista ja siitä, kuinka tärkeää eleganssi on.
alexey: Tieteessä ja liiketoiminnassa hyväksi pidettyjen standardien välillä on siis ero. Tiede arvioi suorituskykyä, virrankulutusta, TDP:tä, toteutuksen helppoutta ja paljon muuta. Onko sinulla mahdollisuus tehdä tällaista tutkimusta yliopistossa? Onko sinulla laboratorio, jossa on erilaisia koneita ja erilaisia arkkitehtuureja, jossa voit tehdä kokeita?
Michael: Kyllä, osastollamme on paljon erilaisia mielenkiintoisia koneita. Useimmiten ne ovat pieniä, meillä on pieni klusteri ja monia moniprosessorijärjestelmiä erilaisilla kiihdyttimillä. Lisäksi kampuksella on valtava laskentakeskus, joka palvelee useiden kymmenien eri alojen tutkijoita. Siinä on noin tuhat solmua ja kaksikymmentätuhatta ydintä, kaikki Linuxissa. Jos tarvetta ilmenee, voit aina ostaa AWS: n. Meillä ei siis ole merkittäviä rajoituksia laitteiston suhteen.
alexey: Millaista se oli kolmekymmentä vuotta sitten? Oliko silloin ongelmia?
Michael: Se oli vähän erilaista silloin. 1980-luvun puolivälissä ja loppupuolella tieteellä katsottiin olevan pulaa laskentaresursseista. Tämän tilanteen korjaamiseksi National Science Foundation ) loi koordinoidun kokeellisen tutkimuksen ohjelman (Coordinated Experimental Research, CER). Ohjelman tehtävänä oli tarjota tietojenkäsittelytieteen laitosten laskentainfrastruktuuria, ja se on saavuttanut merkittävän muutoksen. Hänen tarjoamillaan rahoilla ostimme Rochesterin yliopistosta 1984 solmun BBN Butterflyn vuonna 128, tämä oli vuosi ennen kuin saavuin sinne. Se oli tuolloin maailman suurin moniprosessorijärjestelmä jaetulla muistilla. Siinä oli 128 prosessoria, joista jokainen oli erillisessä emolevyssä, ja siinä oli neljä telinettä. Jokaisessa prosessorissa oli megatavu muistia, 128 megatavua RAM-muistia oli siihen aikaan käsittämätön määrä. Tälle koneelle toteutimme ensimmäistä kertaa MCS-lukituksen.
alexey: Eli jos ymmärsin oikein, niin onko laitteisto-ongelma tällä hetkellä ratkaistu?
Michael: Yleisesti ottaen kyllä. On olemassa muutamia varoituksia: ensinnäkin, jos teet tietokonearkkitehtuuria sirutasolla, sitä on vaikea tehdä akateemisessa ympäristössä, koska sen tekemiseen on paljon parempia työkaluja liiketoiminnassa. Jos tarvitset jotain alle 10 nanometriä, sinun on tilattava se joltain muulta. Tällä alueella on paljon helpompaa olla Intelin tutkija. Jos työskentelet optisen viestinnän parissa siruilla tai puolijohdemuistilla, löydät liiketoiminnasta teknologioita, jotka eivät ole vielä tieteessä, joten sinun on luotava liittoutumia. Esimerkiksi Stephen Swanson () luotu uusille muistitekniikoille. Tämä lomake ei aina toimi, mutta joissain tapauksissa se voi olla varsin onnistunut. Lisäksi tieteessä tehokkaimpien laskentajärjestelmien kehittäminen on vaikeampaa. Tämän hetken suurimmat supertietokoneprojektit Yhdysvalloissa, Japanissa ja Kiinassa keskittyvät kaikki liiketoimintaan.
Ideoiden käytännön toteutus. MCS, MS, CLH, JSR 166, työskentely Doug Leen ja muiden kanssa.
Виталий: Olet jo puhunut siitä, kuinka aloit työskennellä synkronointialgoritmien parissa. Sinulla on kaksi hyvin kuuluisaa artikkelia aiheesta и , jotka tietyssä mielessä toteutettiin Javassa. (Toimittajan huomautus: kaikki julkaisut ovat katsottavissa ). Siellä tämä esto toteutettiin pienin muutoksin ja se osoittautui , ja jono toteutettiin suunnitellusti. Mutta monta vuotta kului artikkeleidenne julkaisemisen ja niiden käytännön soveltamisen välillä.
alexey: Jonon tapauksessa se näyttää olevan noin 10 vuotta.
Michael: Ennen kuin nämä ominaisuudet ilmestyivät Java-standardikirjastoon?
Виталий: Joo. Mitä teit saadaksesi tämän tapahtumaan? Vai eivätkö he tehneet mitään?
Michael: Voin kertoa, kuinka MS Queue pääsi Java 5:een. Muutama vuosi ennen sen ilmestymistä työskentelin Mark Moyersin ryhmän kanssa Sun Microsystemsissä heidän laboratoriossa lähellä Bostonia. Hän järjesti työpajan tuntemilleen ihmisille, jotka työskentelivät mielenkiintoisten monisäikeisten ongelmien parissa, koska hän halusi löytää aiheita, joita hän voisi myydä heidän yritykselleen. Siellä tapasin ensimmäisen kerran Doug Lean. Doug ja minä ja noin 25 muuta ihmistä Sunista keskustelimme yhdessä Dougin esityksestä aiheesta , josta myöhemmin tuli java.util.concurrent. Matkan varrella Doug sanoi, että hän haluaisi käyttää MS-jonoa, mutta tätä varten hän tarvitsi laskurin käyttöliittymän jonon elementtien lukumäärälle. Eli tämä olisi pitänyt tehdä erillisellä menetelmällä, atomisella, tarkasti ja nopeasti. Ehdotin yksinkertaisesti sarjanumeroiden lisäämistä solmuihin, ottamalla ensimmäisen ja viimeisen solmun numerot ja vähentämällä ne toisista. Doug raapi päätään, sanoi "miksi ei" ja päätyi tekemään juuri niin. Keskustelimme tämän lähestymistavan toteuttamisesta kirjastossa, mutta Doug teki suurimman osan työstä itse. Tämän seurauksena hän onnistui luomaan erinomaisen monisäikeisen tuen Javalle.
alexey: Eli jos ymmärrän oikein, .size()-metodin olisi pitänyt olla osa standardijonoliitäntää ja sen algoritminen monimutkaisuus olisi pitänyt olla O(1)?
Michael: Kyllä, ja tämän lisäksi tarvitaan erillinen laskuri.
alexey: Koska jos kutsut .size()-metodia Javassa, tuloksen odotetaan olevan saatavilla välittömästi eikä perustu kokoelman todelliseen kokoon. Näen, kiitos.
Michael: Muutamaa vuotta myöhemmin työskentelin kaksoistietorakenteiden parissa opiskelijani Bill Schererin kanssa - itse asiassa puhun tästä . Doug tuli luoksemme ja sanoi, että hän voisi käyttää niitä Java Executor Frameworkissa. Yhdessä Billin kanssa he loivat kaksi toteutusta, niin sanotut reilut ja epäreilut jonot. Neuvoin heitä tässä projektissa, vaikka en osallistunut varsinaisen koodin kirjoittamiseen. Tämän seurauksena toimeenpanijoiden nopeus on kasvanut merkittävästi.
Vladimir: Oletko havainnut virheellisiä algoritmejasi tai pyyntöjä lisätä uusia ominaisuuksia? Yleisesti ottaen käytännön pitäisi olla sama kuin teoria, mutta melko usein ne eroavat toisistaan. Oletetaan, että kirjoitit algoritmin, ja paperilla se toimii, mutta toteutuksessa mukana olevat ihmiset alkoivat kysyä sinulta lisää ominaisuuksia tai jonkinlaista algoritmin säätämistä. Onko sinulla koskaan ollut tällaisia tilanteita?
Michael: Ainoa esimerkki, jossa joku tuli luokseni ja kysyi "miten se toteutetaan", oli Dougin kysymys, josta puhuin jo. Mutta on ollut muutamia tapauksia, joissa mielenkiintoisia muutoksia on tehty käytännön tarpeisiin. Esimerkiksi IBM:n K42-tiimi muunsi MCS-lukon ja teki siitä vakiorajapinnan, joten jonosolmua ei tarvinnut siirtää edestakaisin hankinta- ja vapautusrutiineihin. Tämän vakiorajapinnan ansiosta teoriassa kaunis idea alkoi toimia käytännössä. On yllättävää, että he eivät koskaan julkaisseet artikkelia siitä, ja vaikka he saivat patentin, he hylkäsivät sen myöhemmin. Ajatus oli ihana, ja yritän puhua siitä aina kun mahdollista.
On ollut muitakin tapauksia, joissa ihmiset ovat tehneet parannuksia julkaisemiini algoritmeihin. Esimerkiksi MS-jonossa on kaksivaiheinen asennusmekanismi, mikä tarkoitti, että jonon kriittisellä polulla oli kaksi CAS:ää. Vanhemmissa autoissa CAS oli melko kallis. Intel ja muut valmistajat ovat optimoineet ne melko hyvin viime aikoina, mutta joskus nämä olivat 30-jaksoisia ohjeita, joten useamman kuin yhden käyttäminen kriittisellä polulla ei ollut toivottavaa. Tuloksena kehitettiin erilainen jono, joka oli samanlainen kuin MS-jono, mutta jolla oli vain yksi ydinoperaatio kriittisellä polulla. Tämä saavutettiin johtuen siitä, että tietyn ajanjakson aikana toiminta saattoi kestää O(n) aikaa O(1) sijaan. Se oli epätodennäköistä, mutta mahdollista. Tämä johtui siitä, että tietyillä hetkillä algoritmi kulki jonon läpi alusta nykyiseen paikkaan tässä jonossa. Yleisesti ottaen algoritmi osoittautui erittäin onnistuneeksi. Tietääkseni se ei ole kovin laajalti käytössä, osittain siksi, että atomioperaatiot vaativat huomattavasti vähemmän resursseja kuin ennen. Mutta idea oli hieno. Pidän myös todella paljon Oraclen Dave Dicen työstä. Kaikki, mitä hän tekee, on erittäin käytännöllistä ja hän käyttää rautaa erittäin taitavasti. Hänellä oli käsi suuressa osassa NUMA-tietoisia synkronointialgoritmeja ja monisäikeisiä tietorakenteita.
Vladimir: Kun kirjoitat algoritmeja tai opetat opiskelijoita, työsi tulos ei ole heti näkyvissä. Yhteisö tarvitsee jonkin aikaa tutustuakseen vaikkapa uuteen artikkeliin. Uusi algoritmi ei heti löydä sovellusta.
Michael: Ei ole läheskään heti selvää, onko artikkeli merkittävä vai ei. Mielestäni olisi mielenkiintoista tutkia konferensseissa palkittuja papereita. Eli katso artikkeleita, joita ohjelmakomiteoiden ihmiset aikoinaan pitivät parhaimpana. Sinun on yritettävä laskea linkkien määrästä ja vaikutuksesta liiketoimintaan, kuinka vaikuttaviksi nämä artikkelit todella osoittautuivat 10, 20, 25 vuoden kuluttua. Epäilen, että näiden kahden välillä olisi vahva korrelaatio. Se ei ole nolla, mutta todennäköisesti se on paljon heikompi kuin haluaisimme. Monet ideat jäävät käyttämättä pitkään ennen kuin ne leviävät laajalle. Otetaan esimerkiksi tapahtumamuisti. Alkuperäisen artikkelin julkaisusta kului yli 10 vuotta siihen hetkeen, kun ihmiset alkoivat rakentaa koneita sillä. Ja ennen tämän muistin ilmestymistä kaupallisiin tuotteisiin - ja kaikki 20. Hyvin pitkään kukaan ei kiinnittänyt huomiota artikkeliin, ja sitten siihen liittyvien linkkien määrä kasvoi jyrkästi. Tätä olisi vaikea ennustaa etukäteen. Toisaalta joskus ideat toteutuvat välittömästi. Muutama vuosi sitten kirjoitin Joe Izraelevitzin kanssa DISC:lle artikkelin, jossa ehdotettiin uutta muodollista määritelmää pysyville tietorakenteille, joita voitaisiin käyttää niitä käyttävän tietokoneen kaatumisen jälkeen. Pidin artikkelista alusta alkaen, mutta se osoittautui paljon suositummaksi kuin odotin. Useat eri ryhmät käyttivät sitä, ja siitä tuli lopulta pysyvyysrakenteiden vakiomääritelmä. Mikä on tietysti mukavaa.
Vladimir: Onko olemassa tekniikoita, joita käytät arvioinnissa? Yritätkö edes arvioida artikkeleitasi ja oppilaitasi? Mitä tulee siihen, onko opettamasi henkilö menossa oikeaan suuntaan.
Michael: Kuten kaikki muutkin, kiinnitän enemmän huomiota siihen, mitä teen tällä hetkellä. Jälleen, kuten kaikki muutkin, tarkistan ajoittain Google Scholarin nähdäkseni, onko menneisiin kirjoihini viitattu, mutta se johtuu enemmän uteliaisuudesta. Enimmäkseen olen uppoutunut siihen, mitä opiskelijani tekevät nyt. Nykyisen työn arvioinnissa osa on esteettisiä näkökohtia, mikä on tyylikästä ja mikä ei. Ja arjen tasolla avoimilla kysymyksillä on suuri rooli. Esimerkiksi opiskelija tulee luokseni joidenkin tulosten kaavion kanssa, ja yritämme ymmärtää, mistä kaavion outo käyttäytyminen on peräisin. Yleensä työssämme yritämme jatkuvasti ymmärtää asioita, joita emme vielä ymmärrä.
Transaktiomuisti
Виталий: Ehkä voimme puhua hieman tapahtumamuistista?
Michael: Mielestäni kannattaa sanoa ainakin vähän, koska olen panostanut siihen paljon. Tämä on aihe, josta minulla on enemmän julkaisuja kuin mistään muusta. Mutta samaan aikaan, kummallista kyllä, olin aina hyvin skeptinen tapahtumamuistin suhteen. Minun mielestäni, (M. Herlihy, J. E. B. Moss) julkaistiin aikaansa edellä. 1990-luvun alussa he ehdottivat, että tapahtumamuisti voisi auttaa lahjakkaita ohjelmoijia työskentelemään monisäikeisten tietorakenteiden parissa, jotta tavalliset ohjelmoijat voisivat käyttää näitä rakenteita kirjastoina. Toisin sanoen siitä olisi apua Doug Leelle JSR 166:n tekemisessä. Tapahtumamuistin ei kuitenkaan ollut tarkoitus tehdä monisäikeistä ohjelmointia helpoksi. Mutta juuri näin se alettiin käsittää 2000-luvun alussa, kun se yleistyi. Sitä mainostettiin tapana ratkaista rinnakkaisohjelmoinnin ongelma. Tämä lähestymistapa on aina tuntunut minusta toivottomalta. Transaktiomuisti voisi vain helpottaa rinnakkaisten tietorakenteiden kirjoittamista. Minusta näyttää siltä, että hän saavutti tämän.
Tietoja monisäikeisen koodin kirjoittamisen vaikeudesta
alexey: Todella mielenkiintoista. Tavallisten ohjelmoijien ja monisäikeistä koodia kirjoittavien välillä näyttää olevan tietty raja. Viime vuonna puhuin useita kertoja ihmisten kanssa, jotka ottavat käyttöön jotain algoritmista kehystä. Esimerkiksi Martin Thomsonin kanssa sekä ohjelmoijien kanssa, jotka työskentelevät monisäikeisten kirjastojen parissa. (Toimittajan huomautus: Martin Thompson on erittäin kuuluisa kehittäjä, hän kirjoitti и . Ja hänellä myös on Joker 2015 -konferenssissamme, videonauhoitus . Hän on sama tämä konferenssi myös saatavilla). Suurin haaste heidän mukaansa on tehdä algoritmeista sekä nopeita että helppokäyttöisiä. Toisin sanoen he yrittävät voittaa tämän esteen ja houkutella mahdollisimman monia ihmisiä tälle alueelle. Mitä ajattelet siitä?
Michael: Tämä on monisäikeistyksen pääongelma: kuinka saavuttaa korkea suorituskyky lisäämättä järjestelmän monimutkaisuutta.
alexey: Koska kun he yrittävät välttää monimutkaisuutta, algoritmista tulee vähemmän universaali.
Michael: Tärkeintä tässä on oikein suunnitellut abstraktiot. Minusta tuntuu, että tämä on yleensä pääasia tietokonejärjestelmille alana. Butler Lampson käyttää mielellään tätä termiä, ja hän kutsuu meitä "abstraktioiden kauppiaiksi". Yksinkertaisia tekniikoita ei ole nykyään olemassa. Käyttämissämme prosessoreissa on 10 miljardia transistoria – yksinkertaisuus ei tule kysymykseen. Samaan aikaan ISA on paljon yksinkertaisempi kuin prosessori, koska työskentelimme hyvin pitkään tarjotaksemme sille korkean suorituskyvyn ja suhteellisen yksinkertaisen käyttöliittymän. Mutta kaikki ei ole myöskään sujuvaa hänen kanssaan. Sama ongelma on nyt markkinoille tulevissa kiihdyttimissä. Herää kysymyksiä - kuinka tehdä oikea rajapinta GPU:lle, salausmekanismi, pakkaus, transkoodausmekanismi, lineaarinen algebramekanismi tai jopa joustavampi FPGA. Kuinka luoda käyttöliittymä, joka tekee työkalusta helppokäyttöisen ja piilottaa monimutkaisuuden? Se ei pääse eroon siitä, vaan pikemminkin piilottaa sen yksinkertaiselta ohjelmoijalta.
alexey: Ymmärtääkseni meillä on edelleen este abstraktien ymmärtämisessä. Otetaanpa muistimalli; tieteen ja teknologian kehitysvaiheessamme tämä on yksi tärkeimmistä abstraktioista. Sen ansiosta kaikki ohjelmoijat on jaettu kahteen ryhmään: suurin osa on niitä, jotka eivät ymmärrä sitä, ja pienempi osa niitä, jotka ymmärtävät tai luulevat ymmärtävänsä.
Michael: Se on hyvä kysymys - ymmärtääkö kukaan meistä todella muistimallia?
Виталий: Varsinkin C++:ssa.
Michael: Puhu joskus Hans Boehmin kanssa. Hän on yksi älykkäimmistä tuntemistani ihmisistä, johtava muistimallien asiantuntija. Hän kertoo sinulle heti, että on paljon asioita, joita hän ei ymmärrä. Mutta jos palataan abstraktioihin, niin mielestäni muistimallien tärkein ajatus viimeisten 30 vuoden aikana ilmaistaan. . (Toimittajan huomautus: täydellinen luettelo julkaisuista on saatavilla ).
alexey: Kysymykseni kuuluu: johtuuko tämä este konseptin luonteesta?
Michael: Ei. Sarita tuli siihen tulokseen, että oikealla lähestymistavalla voit onnistuneesti piilottaa kaiken monimutkaisuuden, saada korkean suorituskyvyn ja antaa ohjelmoijalle yksinkertaisen API:n. Ja jos noudatat tätä APIa, voit saavuttaa johdonmukaisuuden. Mielestäni tämä on oikea malli. Kirjoita koodi ilman datakilpailuja ja saat peräkkäisen johdonmukaisuuden. Tietenkin kilpailun todennäköisyyden vähentämiseksi tarvitaan erikoistyökaluja, mutta se on toinen asia.
Vladimir: Onko urallasi ollut aikoja, jolloin ratkaistulta näyttänyt ongelma muuttui yhtäkkiä katastrofiksi tai osoittautui, että ongelma oli ratkaisematon? Esimerkiksi teoriassa voit kertoa minkä tahansa luvun tai määrittää, onko mikä tahansa luku alkuluku. Käytännössä tämä voi kuitenkin olla vaikeaa; nykyisellä laitteistolla on vaikea laskea lukuja. Onko sinulle tapahtunut jotain vastaavaa?
Michael: En heti muista mitään sellaista. On ollut aikoja, jolloin minusta on tuntunut, ettei tietyllä alueella ole enää mitään tekemistä, mutta sitten siellä tapahtui jotain uutta ja mielenkiintoista. Ajattelin esimerkiksi, että rajattoman jonotuksen alue oli jo kypsynyt. Useiden MNS-jonon parannusten jälkeen ei tapahtunut enää mitään. Ja sitten Morrison (Adam Morrison) ja Afek (Yehuda Afek) keksivät . Kävi selväksi, että rajoittamaton monisäikeinen jono oli mahdollinen, jossa suurimman osan ajasta oli vain hae ja lisää -käsky kriittisellä polulla. Ja tämä mahdollisti suuruusluokkaa paremman suorituskyvyn saavuttamisen. Kyse ei ole siitä, ettemmekö tietäisi, että hae ja lisääminen on erittäin hyödyllinen asia. Eric Freudenthal kirjoitti tästä Ultracomputer-työssään Allan Gottliebin kanssa 1980-luvun lopulla, mutta se koski rajoitettuja jonoja. Morrison ja Afek pystyivät käyttämään hae ja lisää -toimintoa rajoittamattomassa jonossa.
Uudet arkkitehtuurit. Onko tapahtumamuistin voitto lähellä?
Vladimir: Etsitkö uusia arkkitehtonisia ratkaisuja, joista voisi olla hyötyä algoritmeille?
Michael: Tietysti on monia asioita, jotka haluaisin toteutuvan.
Vladimir: Millainen esim.
Michael: Ensinnäkin muutama yksinkertainen laajennus laitteistotason tapahtumamuistiin Intel- ja IBM-suorittimissa. Erityisesti haluaisin, että tapahtumaan liittymätön kuorma ja varasto olisivat välittömästi saatavilla tapahtumissa. Ne johtavat välittömästi silmukoihin tapahtuu ennen -sarjassa, joten ne voivat olla vaikeita. Mutta jos pidät yllä abstraktiotasoja, voit tehdä monia erittäin mielenkiintoisia asioita tapahtuman ulkopuolella. En tiedä kuinka vaikeaa tämä olisi toteuttaa, mutta se olisi erittäin hyödyllinen.
Toinen hyödyllinen asia on välimuistin lataaminen etämuistista. Uskon, että ennemmin tai myöhemmin tämä toteutuu. Tämä tekniikka mahdollistaa hajautetun muistin järjestelmien luomisen. Telineessä olisi mahdollista pitää esimerkiksi 100 teratavua haihtumatonta muistia, ja käyttöjärjestelmä itse päättäisi dynaamisesti, mitkä tuon muistin osat vastaavat prosessorien fyysistä osoiteavaruutta. Tämä olisi erittäin hyödyllistä pilvipalveluissa, koska se mahdollistaisi suurten muistimäärien tarjoamisen sitä tarvitseville tehtäville. Luulen, että joku tekee sen.
Виталий: Tapahtumamuistista puhumisen lopuksi minulla on vielä yksi kysymys tästä aiheesta. Korvaako tapahtumamuisti lopulta tavalliset monisäikeiset tietorakenteet?
Michael: Ei. Liiketoimet ovat spekulatiivinen mekanismi. Ohjelmointitasolla nämä ovat atomilukkoja, mutta sisällä ne ovat spekulaatioita. Tällainen ennustaminen toimii, jos suurin osa arvauksista pitää paikkansa. Siksi tapahtumamuisti toimii hyvin, kun säikeet eivät juurikaan ole vuorovaikutuksessa toistensa kanssa, ja sinun on vain varmistettava, että vuorovaikutuksia ei ole. Mutta jos viesti alkaa säikeiden välillä, tapahtumista ei ole juurikaan hyötyä. Selitän, puhumme tapauksesta, jossa tapahtumat kiedotaan koko atomin toiminnan ympärille. Niitä voidaan edelleen käyttää menestyksekkäästi monisäikeisten tietorakenteiden komponentteina. Esimerkiksi, jos tarvitset kolmen sanan CAS:n ja sinun on monisäikeinen kolme pientä asiaa keskellä todella monisäikeistä algoritmia, joka toimii kahdellakymmenellä säikeellä samanaikaisesti. Yleensä tapahtumat voivat olla hyödyllisiä, mutta ne eivät poista tarvetta suunnitella oikein monisäikeisiä tietorakenteita.
Haihtumaton muisti, Optane DIMM, erittäin nopeat laitteet.
Виталий: Viimeinen asia, josta haluaisin puhua, on nykyisen tutkimuksesi aihe: haihtumaton muisti. Mitä voimme odottaa tällä alueella lähitulevaisuudessa? Ehkä tiedät jo olemassa olevia tehokkaita toteutuksia?
Michael: En ole laitteisto-asiantuntija, tiedän vain sen, mitä luen uutisista ja mitä kollegani kertovat minulle. Kaikki ovat jo kuulleet, että Intel myy , joilla on noin 3 kertaa suurempi lukuviive ja 10 kertaa kirjoitusviive kuin dynaamisella RAM-muistilla. Niitä on pian saatavilla erittäin suurikokoisina versioina. On hassua ajatella, että sinulla voisi olla kannettava tietokone, jossa on useita teratavuja tavuosoitettavaa RAM-muistia. On todennäköistä, että 10 vuoden kuluttua päätämme käyttää tätä uutta tekniikkaa, koska käytämme DRAM-muistia - lisää vain äänenvoimakkuutta. Mutta energiariippumattomuuden ansiosta meille avautuu täysin uusia mahdollisuuksia. Voimme muuttaa tallennuspinoa perusteellisesti siten, että tavuosoitteellisen työmuistin ja lohkorakenteisen pysyvän muistin välillä ei ole eroa. Siten meidän ei tarvitse sarjoittaa kaikkea, mikä on siirrettävä yhdestä ohjelmasta toiseen lohkorakenteisiksi tiedostoiksi. Tästä voimme johtaa monia tärkeitä periaatteita, jotka vaikuttavat käyttöjärjestelmiin, ajonaikaisiin ympäristöihin ja hajautettuihin tietovarastoihin. Tällä alueella on erittäin mielenkiintoista työskennellä. Minun on henkilökohtaisesti vaikea ennustaa, mihin tämä kaikki johtaa, mutta ongelmat ovat erittäin viihdyttäviä. Tässä saattaa tulla vallankumouksellisia muutoksia, ja ne johtuvat hyvin luonnollisesti monisäikeistyksen työstä, koska vian palautuminen on "monisäikeinen" prosessi järjestelmän normaalin toiminnan rinnalla.
Toinen pääaihe, jonka parissa työskentelen tällä hetkellä, on erittäin nopeiden laitteiden hallinta ja turvallinen pääsy laitteisiin käyttäjätilasta järjestelmällisen politiikan ohjauksen avulla. Viime vuosina on ollut trendi siirtää pääsy laitteeseen käyttäjätilaan. Tämä tapahtuu, koska TCP-IP-ydinpino ei voi toimia verkkoliitännän päällä, joka tarvitsee uuden paketin 5 mikrosekunnin välein; se ei yksinkertaisesti pysy perässä. Siksi valmistajat tarjoavat suoran pääsyn laitteisiin. Mutta tämä tarkoittaa, että käyttöjärjestelmä menettää prosessin hallinnan, eikä se voi tarjota kunnollista pääsyä laitteeseen kilpaileville sovelluksille. Tutkimusryhmämme uskoo, että tämä puute voidaan välttää. Meillä on tästä artikkeli USENIX ATC:ssä tässä kuussa. Se liittyy pysyvyyttä koskevaan työhön, koska pitkäikäinen tavuosoitteellinen pysyvä muisti on pohjimmiltaan ultranopealla I/O:lla varustettu laite, johon on päästävä käyttäjätilassa. Tämä tutkimus mahdollistaa uusia lähestymistapoja mikroytimiin, eksokerneleihin ja muihin perinteisiin yrityksiin siirtää toiminnallisuutta turvallisesti käyttöjärjestelmän ytimestä käyttäjätilaan.
Vladimir: Tavuosoitteellinen muisti on hieno, mutta siinä on fyysinen rajoitus - valonnopeus. Tämä tarkoittaa, että vuorovaikutuksessa laitteen kanssa esiintyy väistämättä viivettä.
Michael: Aivan oikeassa.
Vladimir: Riittääkö kapasiteetti uusien kuormien kestämiseen?
Michael: Tämä on erinomainen kysymys, mutta minun on vaikea vastata siihen. Ajatus muistin käsittelystä on ollut olemassa jo jonkin aikaa, se on erittäin mielenkiintoinen, mutta myös hyvin monimutkainen. En ole työskennellyt tällä alalla, mutta olisi hienoa, jos siellä tehtäisiin joitain löytöjä. Pelkään, ettei minulla ole enää mitään lisättävää.
Vladimir: On vielä yksi ongelma. Uutta, huomattavasti suurempia määriä RAM-muistia on mahdotonta sovittaa prosessoriin. Siksi tämä RAM on eristettävä fyysisten rajoitusten vuoksi.
Michael: Kaikki riippuu integroitujen piirien tuotannossa esiintyvien vikojen määrästä. Jos puolijohdekiekkoja olisi mahdollista luoda täysin ilman vikoja, niin siitä olisi mahdollista tehdä kokonainen mikropiiri. Mutta nyt emme tiedä kuinka tehdä postimerkkejä suurempia mikropiirejä.
Vladimir: Mutta puhumme silti valtavista koosta, noin senttimetreistä. Tällä on väistämättä vaikutusta latenssiin.
Michael: Joo. Valonnopeudelle ei voi mitään.
Vladimir: Valitettavasti.
Seuraava suuri trendi. Kaksoistietorakenteet. Hydra.
Виталий: Ymmärtääkseni saat uudet trendit hyvin nopeasti kiinni. Olit ensimmäisten joukossa, joka työskenteli tapahtumamuistissa, ja yksi ensimmäisistä, joka työskenteli haihtumattomassa muistissa. Mikä on mielestäsi seuraava suuri trendi? Tai ehkä se on salaisuus?
Michael: Rehellisesti sanottuna en tiedä. Toivottavasti huomaan, kun jotain uutta ilmaantuu. Itselläni ei ole ollut onni keksiä mitään uutta alaa, mutta minulla on ollut vähän onnea ja päässyt aika varhain työskennellä muiden luomilla uusilla aloilla. Toivon, että pystyn tekemään tämän tulevaisuudessa.
alexey: Tämän haastattelun viimeinen kysymys koskee suorituskykyäsi Hydrassa ja toimintaasi koulussa. Jos ymmärsin oikein, koulun raportti tulee olemaan estovapaista algoritmeista ja konferenssissa kaksoistietorakenteista. Voisitko sanoa muutaman sanan näistä raporteista?
Michael: Osittain olemme jo käsitelleet näitä aiheita kanssasi tässä haastattelussa. Kyse on työstä, jonka tein opiskelijani Bill Schererin kanssa. Hän kirjoitti siitä opinnäytetyön, ja myös Doug Lee osallistui siihen, ja lopulta siitä tuli osa Java-kirjaston monisäikeisiä synkronisia jonoja. Oletetaan, että tietorakenne luetaan ja kirjoitetaan ilman estoa, eli jokaisessa operaatiossa on rajoitettu määrä käskyjä kriittisellä polulla. Jos yrität poistaa tietoja tyhjästä säilöstä tai yrität poistaa tiettyjä tietoja, joita ei ole tässä säilössä, saat välittömästi tiedon, että tätä ei voi tehdä. Mutta tämä käyttäytyminen ei ehkä ole hyväksyttävää, jos säie todella tarvitsee näitä tietoja. Sitten ensimmäinen asia, joka tulee mieleen, on luoda silmukka, joka kysyy jatkuvasti, onko tarvittavat tiedot ilmestyneet. Mutta sitten kaikki muut häiritsevät. Lisäksi tällä lähestymistavalla voit odottaa 10 minuuttia, ja sitten tulee jokin muu säie, joka saa vahingossa tarvittavat tiedot ensin. Kaksoistietorakenteissa ei edelleenkään ole lukkoja, mutta ne antavat säikeiden odottaa oikein. Termi "kaksois" tarkoittaa, että rakenne sisältää joko dataa tai datapyyntöjä, kutsutaan niitä antidataksi. Joten jos yrität noutaa jotain tyhjästä säiliöstä, konttiin laitetaan sen sijaan pyyntö. Nyt lanka voi odottaa pyyntöä häiritsemättä muita. Lisäksi tietorakenne priorisoi pyynnöt niin, että ne vastaanotettuaan välittää ne oikealle henkilölle. Tuloksena on lukkiutumaton mekanismi, jolla on edelleen muodollinen määrittely ja hyvä suorituskyky käytännössä.
alexey: Mitä odotat tältä tietorakenteelta? Parantaako se suorituskykyä kaikissa yleisissä tapauksissa vai sopiiko se paremmin tiettyihin tilanteisiin?
Michael: Se on hyödyllistä, jos ensinnäkin tarvitset säiliön ilman lukitusta, ja toiseksi sinun on odotettava tilanteessa, jossa sinun on haettava tietoja säilöstä, joka ei ole siinä. Parhaan tietoni mukaan puitteemme tarjoaa optimaalisen toiminnan, kun nämä kaksi ehtoa täyttyvät. Siksi suosittelen sen käyttöä näissä tapauksissa. Lukitsemattomien tietorakenteiden tärkein etu on, että ne välttävät suorituskykyongelmia. Ja odottaminen on erittäin tärkeää monissa algoritmeissa, jos dataa siirretään säikeestä toiseen.
Виталий: Selvennetään: puhutko samasta asiasta sekä koulussa että konferenssissa?
Michael: Koulussa yleensä monisäikeisistä tietorakenteista, perusperiaatteet hahmotellaan oppitunnin alussa. Oletan, että yleisö tietää mitä langat ovat ja tuntee lukot. Tämän perustiedon pohjalta puhun lukitsemattomista tietorakenteista. Annan yleiskatsauksen tämän alan tärkeimmistä ongelmista koskeen esimerkiksi muistinhallinnan aiheisiin. En usko, että siellä on mitään monimutkaisempaa kuin MS-jono.
alexey: Aiotko opettaa kaksoistietorakenteita luokkasi lopussa koulussa?
Michael: Mainitsen ne, mutta en käytä niihin paljon aikaa. Hydra-raportti on omistettu heille. Se kattaa projektin, joka lopulta päätyi Javaan, sekä työskentelyä Joe Israelevichin kanssa LCRQ-jonon kaksoisversion luomiseksi ja lähes universaalin suunnittelun luomista kaksoistietorakenteille.
alexey: Koululuentoa voi siis suositella aloittelijoille ja luentoa kaksoistietorakenteista Hydrassa - jo kokemusta omaaville?
Michael: Korjatkaa, jos olen väärässä, mutta Hydran yleisö tulee olemaan melko monipuolinen, mukaan lukien monet Java-asiantuntijat ja yleensä ihmiset, jotka eivät ole erityisesti mukana monisäikeisessä ohjelmoinnissa.
Виталий: Kyllä, se on totta.
alexey: Ainakin toivomme niin.
Michael: Tässä tapauksessa kohtaan saman ongelman, jolla aloitimme tämän haastattelun: kuinka tehdä raportti sekä riittävän rikas teknisistä yksityiskohdista että kaikkien kuuntelijoiden saatavilla.
Виталий: Annatko raportin samalla tavalla kuin luennoit? Eli puhua yleisölle ja sopeutua tilanteeseen?
Michael: Pelkään, että se ei toimi niin, koska raportissa on dioja. Diat ovat tärkeitä, kun kuuntelijat puhuvat aluksi eri kieliä. Monien ihmisten on vaikea ymmärtää minua englanniksi, varsinkin jos puhun liian nopeasti. Valitsin nämä aiheet, koska pyysi minua puhumaan lukitsemattomista tietorakenteista SPTDC Schoolissa; ja sitten tarvitsin raportin Java-käyttäjäryhmäkonferenssiin, ja halusin valita jotain, mikä kiinnostaisi erityisesti Java-ohjelmoijia. Helpoin tapa oli puhua niistä Java-kirjaston asioista, jotka minulla oli tavalla tai toisella käsissäni.
alexey: Oletamme, että Hydran yleisö tietää jo jotain lukitsemattomasta ohjelmoinnista ja ehkä heillä on kokemusta tältä alueelta. Mutta tämä on vain oletus, tilanne selkenee itse konferenssissa. Joka tapauksessa, kiitos ajastasi. Olen varma, että haastattelu on erittäin mielenkiintoinen lukijoillemme. Kiitos paljon!
Виталий: Kiitos.
Michael: Olen iloinen voidessani tavata sinut Pietarissa.
alexey: Meilläkin on kaunis kaupunki. Oletko koskaan ollut täällä?
Michael: Ei, en ole koskaan käynyt Venäjällä. Mutta Pietari on aina ollut niiden paikkojen listalla, joissa en ole vielä käynyt, mutta jonne todella haluan mennä, joten olin erittäin iloinen kutsusta.
alexey: Muuten, meillä on retkiohjelma puhujille. Lämmin kiitos haastattelusta ja mukavaa päivää!
Voit jatkaa keskusteluasi Michaelin kanssa Hydra 2019 -konferenssissa, joka pidetään 11.-12 Pietarissa. Hän tulee raportin kanssa . Lippuja voi ostaa .
Lähde: will.com