Cliff Click — Cratus'i CTO (IoT-sensorid protsesside parandamiseks), mitme idufirma (sealhulgas Rocket Realtime School, Neurensic ja H2O.ai) asutaja ja kaasasutaja, kellel on olnud mitu edukat väljajäämist. Cliff kirjutas oma esimese kompilaatori 15-aastaselt (Pascal TRS Z-80 jaoks)! Ta on kõige tuntum oma töö poolest C2 puhul Java-s (the Sea of Nodes IR). See kompilaator näitas maailmale, et JIT suudab toota kvaliteetset koodi, mis aitas kaasa Java kujunemisele üheks peamiseks tänapäevaseks tarkvaraplatvormiks. Hiljem aitas Cliff Azul Systems'il ehitada 864 tuuma mäsafraimi puhtale Java-le, mis toetas GC-pause 500 GB kuhjaga 10 millisekundiga. Üldiselt on Cliff töötanud JVM-i kõigi aspektide kallal.

 
See postitus on suur intervjuu Cliffiga. Räägime järgmistest teemadest:

• Üleminek madala taseme optimeerimisele
• Kuidas teha suurt refaktoreerimist
• Kulude modelleerimine
• Madala taseme optimeerimise õpetamine
• Praktilised näited jõudluse parandamisest
• Miks luua oma programmeerimiskeel
• Performantsiinseneri karjäär
• Tehnilised väljakutsed
• Veidi registri ja multi-tuumade jaotamisest
• Elu suurim väljakutse

Intervjuud viib läbi:

• Andrei Satariin Amazon Web Servicesist. Oma karjääri jooksul on ta töötanud täiesti erinevates projektides: testinud Yandexis jaotatud NewSQL andmebaasi, Kaspersky Labis pilveseire süsteemi, Mail.ru-s mitme kasutajaga mängu ja Deutsche Bankis valuutahindade arvutamise teenust. Ta on huvitatud suuremahulisest backend- ja jaotatud süsteemide testimisest.
• Vladimir Sitnikov Netcrackerist. Töötab üle kümne aasta NetCracker OS'i jõudluse ja skaleeritavuse kallal — tarkvara, mida sideoperaatorid kasutavad võrgu juhtimise ja seadmete haldamise automatiseerimiseks. Huvitub Java ja Oracle Database jõudlusest. On autoriks enam kui kümnele jõudluse parandusele ametlikus PostgreSQL JDBC-draivis.

Üleminek madala taseme optimeerimisele

Andrei: Te olete tuntud JIT-kompileerimise, Java ja üldiselt jõudluse valdkonnas, eks? 

Cliff: Just nii!

Andrei: Alustame üldiste küsimustega jõudluse töötlemise kohta. Mida arvate madala taseme ja kõrge taseme optimeerimise valiku vahel, näiteks CPU tasemel töötamisest?

Cliff: Siin on kõik lihtne. Kiireim kood on see, mis kunagi ei käivitu. Seetõttu tuleb alati alustada kõrge tasemega, töötada algoritmide kallal. Paremini kirjutatud O-notation ületab halvemini kirjutatud O-notation, välja arvatud juhul, kui sekkuda mõned piisavalt suured konstandid. Madala taseme asjad tulevad kõige viimasena. Tavaliselt, kui oled optimeerinud kogu ülejäänud stack'i piisavalt hästi ja midagi huvitavat on ikka veel jäänud – see ongi madal tase. Kuidas alustada kõrge taseme juurest? Kuidas teada, et olete teinud piisavalt tööd kõrgel tasemel? No... ei kuidagi. Valmis retsepte ei ole. Tuleb probleemi lahendada, otsustada, mida plaanid teha (et mitte teha edaspidi tarbetu sammud) ja siis saab välja võtta profailer, mis suudab öelda midagi kasulikku. Mingil hetkel saad sa ise aru, et oled vabanenud tarbetutest asjadest ja on aeg madala taseme täpsustamisega tegeleda. See on kindlasti eriline kunstivorm. Palju inimesi teeb tarbetuid asju, aga liigub nii kiiresti, et neil ei ole aega tootlikkuse pärast muretseda. Kuid see on seni, kuni küsimus ei tõuse äkitselt üles. Tavaliselt 99% ajast ei huvita kedagi, millega ma tegelevad, kuni kriitilisel teel ei seisa mingi oluline asi, mis kellelegi korda läheb. Ja siis hakkavad kõik sind kiusama, et «miks see alguses ei töötanud ideaalselt». Üldiselt on alati midagi, mida perfformantsi osas paremaks teha. Aga 99% ajast pole sul mingeid vihjeid! Sa lihtsalt proovid saada midagi tööle ja selle käigus saad sa aru, mis on oluline. Kunagi ei saa ette teada, et just see tükk tuleb teha ideaalseks, seega tuleb põhimõtteliselt olla ideaalne igas asjas. Ja see on võimatu ja sa ei tee nii. Alati on palju asju, mis vajavad parandamist – ja see on täiesti normaalne.

Kuidas teha suurt refaktoreerimist

Andrei: Kuidas te töötate jõudluse nimel? See on tõepoolest keeruline probleem. Näiteks, kas olete pidanud tegelema probleemidega, mis tulenevad suure hulga juba olemasoleva funktsionaalsuse ristumiste tõttu?

Cliff: Ma väldin seda. Kui ma tean, et jõudlus saab probleemiks, siis mõtlen sellele enne, kui hakkan kodeerima, eriti andmestructuuride osas. Kuid sageli avastad sa kõik selle alles hiljem. Ja siis pead võtma äärmuslikke meetmeid ning tegema seda, mida ma nimetan 'üle kirjutama ja valitsema': pead haarama piisavalt suure osa. Osa koodist tuleb nagunii näiteks jõudlusprobleemide või muude põhjuste tõttu ümber kirjutada. Mis iganes põhjus ka ümberkirjutamisel ei oleks, on peaaegu alati parem ümber kirjutada suurem tükk kui väiksem tükk. Sel hetkel hakkavad kõik kartma: 'oh jumal, ei tohi nii palju koodi puutuda!'. Aga tegelikult, see lähenemine töötab peaaegu alati palju paremini. Pead kohe haarama suure probleemi, joonistama selle ümber suure ringi ja ütlema: kõik, mis on ringi sees, kirjutan ümber. Piir on ju palju väiksem kui see sisu, mis on selle sees asendamisele määratud. Ja kui selline piiride määratlemine võimaldab teha tööd seal sees ideaalselt – sul on käed vabaks, tee, mida tahad. Kui sa oled probleemi mõistnud, siis läheb ümberkirjutamisprotsess palju lihtsamaks, seega hammusta suur tükk!
Samas, kui teed suurt ümberkirjutamist ja mõistad, et jõudlus hakkab probleemiks saama, tasub kohe selle pärast muretseda. See muutub tavaliselt lihtsate asjadeks nagu "ärge kopeerige andmeid, haldage andmeid nii lihtsalt kui võimalik, tehke need väiksemaks". Suurte ümberkirjutamiste puhul on olemas standardmeetodid, et jõudlust parandada. Need keskenduvad enamasti andmetele.

Kulude modelleerimine

Andrei: Ühes podcastis rääkisite hinnamudelitest jõudluse kontekstis. Kas saaksite selgitada, mida selle all silmas pidite?

Cliff: Muidugi. Ma sündisin ajastul, kus protsessori efektiivsus oli äärmiselt oluline. Ja see ajastu naaseb — saatus pole ilma irooniata. Ma alustasin elu kaheksabitiste masinatega, minu esimene arvuti töötas 256 baitiga. Just baiti. Kõik oli väga väike. Oli vaja lugeda käske ja kui me hakkasime liikuma kõrgemate programmeerimiskeelte poole, võtsid keeled endaga järjest rohkem ja rohkem tööd. Oli Assambleerimine, siis Basic, seejärel C, ja C võttis enda peale palju detaile, nagu registrite ja käskude jaotamine. Kuid seal oli kõik üsna arusaadav ja kui ma tegin näitaja muutuja eksemplarile, sain ma laadimise ja selle käsu hind oli teada. Riistvara annab välja kindla arvu masina tsükleid, nii et erinevate asjade täitmise kiirus oli võimalik lihtsalt kokku lugeda, liites kõik käsud, mida sa kavatsesid käivitada. Iga compare/test/branch/call/load/store sai kokku liita ja öelda: siin on sinu täitmise aeg. Ainult efektiivsuse parandamisega tegeledes pöörad kindlasti tähelepanu numbritele, mis vastavad väikestele kuumadele tsüklitele. 
Kuid niipea, kui sa lülitud Java, Python ja sarnaste asjade juurde, eemaldud sa kiiresti madalamast tasemest. Milline on getteri kutse maksumus Javas? Kui JIT HotSpot'is kõik õigesti inline'itud, siis on see laadimine, kuid kui ta seda ei teinud – on see funktsioonikutse. Kuna kutse asetub kuumasse tsüklisse, tühistab see kõik muud optimeeringud selles tsüklis. Seetõttu on tegelik maksumus palju suurem. Ja sa kaotad kohe võime vaadata koodijuppi ja mõista, kui palju peaksime selle täitmiseks arvestama protsessori taktsageduse, kasutatud mälu ja vahemälu osas. Kõik see muutub huvitavaks ainult siis, kui süvened tõeliselt jõudlusesse.
Praegu oleme olukorras, kus protsessorite kiirus ei ole viimase kümne aasta jooksul oluliselt muutunud. Vanad ajad naasevad! Te ei saa enam loota heale ühetuumalisele jõudlusele. Kuid kui te siiski tegelete paralleelsete arvutustega – on see äärmiselt keeruline, kõik vaatavad teid nagu James Bondi. Kümnekordsed kiirusetõusud ilmnevad tavaliselt seal, kus keegi midagi ei märka. Paralleelsus nõuab palju tööd. Et saavutada see kümnekordne kiirusetõus, peate mõistma väärtusmudelit. Mis on ja kui palju see maksab. Selleks peate mõistma, kuidas keel sobitub alumisele riistvarale.
Martin Thompson leidis oma blogile suurepärase sõna Mehaaniline kaastunne! Peab aru saama, mida riistvara teeb, kuidas just see seda teeb ja miks see üldse seda teeb. Kasutades seda, on üsna lihtne alustada juhiste arvestamist ja välja selgitada, kuhu täitmisaeg voolab. Kui sul ei ole vastavat ettevalmistust, siis otsid nagu musta kassi pimedas toas. Ma näen pidevalt inimesi, kes optimeerivad jõudlust, kuid kellel pole vähimatki aimu, mida nad üldse teevad. Nad vaevlevad väga ja ei liigu eriti edasi. Ja kui ma võtan sama koodi ja lisan sinna paar väikest nippi ning saavutan viis- või kümnekordse kiiruskasvu, siis nad ütlevad: noh, see pole aus, me teadsime ju, et sa oled parem. Üllatav. Millest ma rääkisin... maksumudelist – see on seotud sellega, mis koodi sa kirjutad ja kui kiiresti see keskmiselt toimib üldises pildis.

Andrei: Ja kuidas sellist mahukust peas hoida? Kas see saavutatakse suure koguse kogemusega, või? Kus sellist kogemust saadakse?

Cliff: Noh, sain kogemus on tulnud keerulisel teel. Programmeerisin assembleris juba siis, kui iga üksiku käsu mõistmine oli veel võimalik. See kõlab tobedalt, kuid sellest ajast on mul peas, mälus igaveseks jäänud Z80 käskude kogum. Ma ei mäleta inimeste nimesid isegi kohe pärast vestlust, kuid mäletan koodi, mis kirjutatud 40 aastat tagasi. Naljakas, see meenutab «"teadlase idioodi"».

Madala taseme optimeerimise õpetamine

Andrei: Kas on olemas lihtsam viis alustada?

Cliff: Jah ja ei. Riistvara, mida me kõik kasutame, pole selle aja jooksul palju muutunud. Kõik kasutavad x86, välja arvatud ARM-il põhinevad nutitelefonid. Kui sa ei tegele mingi tõsise sisseehitatud mõõtmisega, siis on sul kõik sama. Olgu, edasi. Ka juhised pole sajandeid muutunud. On vaja minna ja kirjutada midagi Assembleris. Natuke, aga piisavalt, et hakata aru saama. Te naeratate, aga ma räägin täiesti tõsiselt. On oluline mõista keele ja riistvara seost. Pärast seda tuleb minna, kirjutada natuke ja teha väike mänguline kompilaator väikese mängulise keele jaoks. „Mänguline“ tähendab, et tuleb seda teha arvestatavas ajavahemikus. See võib olla superlihtne, kuid peab genereerima juhiseid. Juhiste genereerimise akt aitab mõista kulumudelit silla ehitamiseks kõrgema taseme koodi ja masina koodi vahel, mida riistvara täidab. See seos jääb mällu kompilaatori kirjutamise käigus. Isegi kõige lihtsam kompilaator. Pärast seda saab hakata vaatama Java't ja seda, kui sügavale on seal semantilised lõhed, ning ehitama nende peale keerukamaid sildu. Java's on palju keerulisem mõista, kas meie sild on hea või halb, mis põhjustab selle kokkuvarisemise ja mis mitte. Aga sul on vaja mingit lähtepunkti, kui vaatad koodi ja mõistad: „aha, see getter peaks iga kord inline'ima.” Ja siis selgub, et mõnikord juhtubki nii, välja arvatud olukordades, kus meetod muutub liiga suureks, ja JIT hakkab inline'ima kõike juhuslikult. Selliste kohtade sooritusvõimet on võimalik hetkega ennustada. Reeglina töötavad getterid hästi, kuid seejärel vaatad suuri kuumi sildu ja mõistad, et seal on mingid funktsiooni kutsed, millel pole selget eesmärki. Just selles seisneb probleem getterite laialdasel kasutamisel; põhjus, miks nad ei inline'ita - ei ole selge, kas see on getter. Kui sul on superväike koodibaas, saad selle lihtsalt meelde jätta ja siis öelda: siin on getter, ja seal on setter. Suures koodibaasis elas iga funktsioon omaenda ajalugu, mis pole kellelegi teada. Profilera ütleb, et oleme kaotanud 24% aega mingis tsüklis ja et selle tsükli toimimiseks tuleb vaadata iga funktsiooni sees. Seda on raske mõista, kui sa ei uuri funktsiooni, ja see aeglustab tõsiselt arusaamise protsessi. Seetõttu ma ei kasuta getterite ja setterite pidevat kasutust; olen läinud uuele tasemele!
Kust leida hinnamudelit? Jah, muidugi, võib lugeda midagi... Kuid ma arvan, et parim viis on tegutseda. Luua väike kompilaator ja see on parim viis hinnamudeli mõistmiseks ja selle enda mõtetes paigutamiseks. Väike kompilaator, mis sobiks mikrolaineahju programmeerimiseks — see on algaja ülesanne. Ma mõtlen, et kui sul on juba programmeerimisoskused, siis peaks neist piisama. Kõik need asjad, nagu stringi parsimine, mis on mingi algebraline väljend, tõmmata sealt välja õiged matemaatilised toimingud õiges järjekorras, võtta õiged väärtused registritest — see kõik on hõlbus. Ja kui sa seda teed, jääb see su ajusse. Ma arvan, et kõik teavad, mida kompilaator teeb. Ja see annab mõistmise hinnamudelist.

Praktilised näited jõudluse parandamisest

Andrei: Millele veel tasub tähelepanu pöörata jõudluse parandamisel?

Cliff: Andmestruktuurid. Jah, tõepoolest, ma ei ole neid loenguid juba pikka aega pidanud... Rocket School. See, see, on one of the larger and more interesting sessions, "Where Your Performance Goes," I gave students an example: two and a half gigabytes of fintech data were read from a CSV file, and then we had to count the number of products sold. Standard tick market data. UDP packets turned into text format since the 70s. Chicago Mercantile Exchange — things like oil, corn, soybeans, and the like. We needed to count these products, the number of transactions, the average volume of funds and goods, etc. It's pretty straightforward trading math: find the product code (that's 1-2 characters in a hash table), get the sum, add it to one of the transaction sets, add volume, add cost, and a few other items. Very simple math. The toy implementation was very straightforward: everything is in the file, I read the file and move through it, splitting individual records into Java strings, looking for the necessary items in them and summing according to the math described above. And it works at some moderate speed.

Nii lähenemisega on kõik selge, mis toimub, ja paralleelsed arvutused siin ei aita, eks? Selgub, et viiekordset jõudluse suurendamist saab saavutada lihtsalt õigete andmestructuuride valimisega. See üllatab isegi kogenud programmeerijaid! Minu konkreetses olukorras oli fookus selles, et ei tohiks teha mälu eraldamisi kuumas tsüklis. No, see ei ole kogu tõde, aga üldiselt – ei tohiks eraldada 'kord X', kui X on piisavalt suur. Kui X on kaks ja pool gigabaiti, ei tohiks eraldada midagi 'kord tähe', 'kord rea', või 'kord välja', midagi sellist. Just sellele kulubki aega. Kuidas see üldse töötab? Kujutage ette, et teen kõne String.split() või BufferedReader.readLine(). Readline muundab võrgu kaudu saadud baitidest iga rea jaoks ühe striingi, iga sada miljonit rida. Ma võtan selle striingi, analüüsin selle ja viskan minema. Miks viskan? Noh, olen ju selle juba töötlenud, kõik. Nii et iga bait, mis on loetud nendest 2.7G-st, salvestatakse kaheks sümboliks striingis, seega juba 5.4G, ja nad ei ole mulle enam millekski vajalikud, seega visatakse nad minema. Kui vaadata mäluliiklust, laeme 2.7G, mis liigub läbi mälu ja mälubussi protsessoris, ja veel kaks korda rohkem saadetakse striingi, mis asub mälus, ja see kõik töötatakse ümber igal uue striingi loomisel. Kuid ma pean selle lugema, riistvara loeb selle, isegi kui see kõik hiljem ümber töötatakse. Ja ma pean selle salvestama, sest olen loonud striingi ja vahemäed on ülekoormatud – vahemäe maht ei suuda 2.7G mahutada. Kokkuvõtteks, iga loetud baidi kohta loen veel kaks lisabaidi ja kirjutan kaks lisabaidi, ning kokku saavad nad suhe 4:1 – sellises sooritusvõimes raiskame mälu läbilaskevõimet. Ja edasi selgub, et kui ma teen String.split() – ma ei tee seda kaugeltki esmakordselt; seal sees võivad olla veel 6-7 valikut. Seepärast toob klassikaline CSV lugemiskood koos järgneva ridade parsimisega kaasa mälu ribalaiuse kadu umbes 14:1 võrreldes sellega, mida te tegelikult oma soovitud näete. Kui need väljastamised kõrvale jätta, on võimalik saavutada viiekordne kiirus.

Ja see ei ole üldse nii keeruline. Kui vaatate koodi õigest vaatenurgast, muutub kõik üsna lihtsaks, kohe kui olete probleemi olemuse mõistnud. Ei tohiks üldse lõpetada mälu eraldamist: probleem seisneb lihtsalt selles, et teete midagi, mis kohe sureb, ja samal ajal põletate olulist ressurssi, milleks on sel juhul mälu ribalaius. See kõik viib jõudluse langemiseni. x86 puhul tuleb tavaliselt aktiivselt põletada protsessori takte, aga siin olete kogu mälu põletanud varem. Lahendus on vähendada eraldamiste arvu. 
Teine probleem on see, et kui profiilerit käivitada, kui mälu lint on lõppenud, just siis, kui see juhtub, siis sa tavaliselt ootad vahemälu tagastumist, kuna see on täis prügi, mida sa just tootnud oled, nende ridadega. Seetõttu iga laadimis- või salvestusoperatsioon muutub aeglaseks, kuna need toovad kaasa vahemälu möödalaskmised – kogu vahemälu on aeglane, oodates, millal prügi välja veetakse. Seetõttu näitab profiiler lihtsalt sooja juhuslikku müra, hajutatuna kogu tsükli ulatuses – ei ole ühtegi eraldi kuuma instruktsiooni või koodi kohta. Ainult müra. Ja kui vaatad GC tsükleid, on need kõik Young Generation'i ulatuses ja ülimugavad – mikrosekundid või millisekundid maksimaalselt. Sest kogu see mälu sureb koheselt. Sa eraldad miljardeid gigabaite, ja ta lõikab neid, ja lõikab, ja jälle lõikab. Kõik see toimub väga kiiresti. Nii et on odavad GC tsüklid, soe müra kogu tsükli ulatuses, kuid me tahame saada 5-kordset kiiruskasvu. Just sel hetkel peaks peas midagi klikkima ja kõlama: 'miks nii?!'. Mälu lint ülevoolu ei kuvata klassikalises siluri, tuleb käivitada riistvaraliste jõudluse loendurite silur ja näha seda ise ja otse. Otse mitte, seda võib kahtluse alla seada nende kolme sümptomi kaudu. Kolmas sümptom on see, kui vaatad, mida sa eraldad, küsid profiilerilt ja ta vastab: 'Sa tegid miljardi rida, kuid GC töötas tasuta.' Kui see juhtub, mõistad, et oled tootnud liiga palju objekte ja põletanud kogu mälu lint. On viis seda probleemi lahendada, kuid see ei ole ilmselge. 

Andmete struktuuriga on probleem: paljas struktuur, mis seisab kõikide sündmuste taga, on liiga suur, see on 2.7G kettale, seega on selle koopia tegemine väga ebasoovitav – soov oleks laadida see kohe võrgubuffrist registritesse, et mitte lugeda-kirjutada sinna ja tagasi viis korda. Kahjuks ei paku Java vaikimisi sulle sellist teeki JDK-s. Aga see on ju triviaalne, eks? Sisuliselt on see 5-10 koodi rida, mis läheb kasutusele sinu enda vahelduva laadija ridade jaoks, mis kordab stringi klassi käitumist, olles samas ümberpakendatud alloleva baitide puhvri ümber. Tulemuseks on, et töötad peaaegu nagu stringidega, aga tegelikult liiguvad seal puhvri suunajad, ja toored bait ei kopeerita kuhugi, ning niimoodi taaskasutatakse samu puhvereid ikka ja jälle, ning operatsioonisüsteem on õnnelik, et saab võtta enda kanda asjad, milleks ta on mõeldud, nagu näiteks peidetud topeltpuhverdamine nende bity puhvritega, ja sina enam ei jahvatata lõputut voolu tarbetutest andmetest. Muide, kas te mõistate, et GC töötamise ajal tagatakse, et iga mälu eraldamine ei ole pärast viimast GC tsüklit protsessorile nähtav? Seega ei saa see kõik kuidagi olla vahemälu, ja see viib 100%-iliselt tagatud möödaminnani. Suunajaga töötamisel x86-l kestab registreerimise lugemine mälust 1-2 tsüklit, ja kui see juhtub, siis maksad, maksad, maksad, kuna kogu mälu on ÜHEKS keskkonnas – ja see ongi mälu eraldamise maksumus. Tegelik maksumus.

Teisisõnu, andmestruktuurid on need, mida on kõige raskem muuta. Ja kui sa saad aru, et oled valinud vale andmestruktuuri, mis tulevikus hävitab jõudluse, on tavaliselt vajalik teha märkimisväärne töö, kuid kui seda ei tehta, läheb asi hullemaks. Esiteks tuleb mõelda andmestruktuuridele, see on oluline. Peamine kulutus tekib seal, kus kasutatakse mahukaid andmestruktuure stiilis 'ma kopeerisin andmestruktuuri X andmestruktuuri Y, sest Y meeldib mulle rohkem välimuselt'. Kuid kopeerimise operatsioon (mis tundub odav) tarbib tegelikult mälu, ja siin peitub kogu kaotatud täitmisaja probleem. Kui mul on hiiglaslik JSON-string ja ma tahan selle teisendada struktureeritud DOM-puu POJO-ks või millegi sarnaseks, siis selle stringi parsimise ja POJO ehitamise operatsioon ning edasi uute päringute tegemine POJO-le tähendab täiendavaid kulusid – see pole odav. Erandiks on see, kui sa jooksed POJO-de üle kordades sagedamini kui stringi. Öeldes lihtsalt, võiks proovida stringi dekodeerida ja välja tõmmata ainult vajaliku, ilma et see muutuks mingiks POJO-ks. Kui kõik see toimub tee peal, kus on nõutav maksimaalne jõudlus, siis igasugused POJO-d on välistatud – tuleb kuidagi otse stringiga tegeleda.

Miks luua oma programmeerimiskeel

Andrei: Te ütlesite, et teadlikkuse mudeli loomiseks tuleb kirjutada oma väike keel…

Cliff: Mitte keel, vaid kompilaator. Keel ja kompilaator on erinevad asjad. Peamine erinevus on peas. 

Andrei: Muide, kui ma ei eksi, katsetate te oma keelte loomisega. Miks?

Cliff: Sest ma saan! Olen poolpensionil, seega on see minu hobi. Olen kogu elu töötanud kellegi teise keelte rakendamise nimel. Samuti olen palju vaeva näinud koodimise stiiliga. Ja veel muidugi, kuna näen probleeme teistes keeltes. Näen, et on paremaid viise tuttavate asjade tegemiseks. Ja ma kasutaksin neid. Mind häirib tõesti näha probleeme enda, Java, Python ja igas teises keeles. Praegu kirjutan React Native'is, JavaScriptis ja Elm'is, mis on hobi, mis ei ole pensioni, vaid aktiivse tööga seotud. Ja ma kirjutan ka Pythonis ning tõenäoliselt jätkan masinõppe arendamist Java back-end'ide jaoks. Populaarseid keeli on palju ja igal neist on huvitavad omadused. Igaühel on oma tugevused ja saate proovida kõik need trikid kokku viia. Seega uurin huvitavaid asju, keele käitumist, püüan välja mõelda mõistliku semantika. Ja seni suudan! Praegu võitlen mälu semantikaga, sest soovin, et see oleks nagu C-s ja Java-s, ning saada tugev mälumudel ja mälu semantika laadimise ja salvestamise jaoks. Samuti soovin automaatset tüübi järeldust nagu Haskell'is. Nii et püüan segada Haskell'i sarnast tüübi järeldust mälu funktsioonidega nagu C-s ja Java-s. Sellega olen viimased 2-3 kuud tegelenud, näiteks.

Andrei: Kui te loote keelt, mis võtab parimaid aspekte teistest keeltest, kas olete mõelnud, et keegi võiks teha vastupidist: võtta teie ideid ja kasutada neid enda heaks?

Cliff: Täpselt nii sünnivad uued keeled! Miks on Java sarnane C-ga? Sest C-l oli hea süntaks, mida kõik mõistsid, ja Java sai inspiratsiooni sellest süntaksist, lisades tüübiohutuse, massiivide piirikontrollid, GC, ja nad parandasid ka mõningaid asju C-s. Nad lisasid omalt poolt. Kuid nad said tõeliselt tugevalt inspiratsiooni, eks? Kõik seisavad hiiglaste õlgadel, kes olid enne sind – just nii toimub progress.

Andrei: Nii nagu mina aru saan, on teie keel mälu kasutamise osas ohutu. Kas olete mõelnud midagi sarnast Rusti borrow checker'ile rakendada? Kas olete seda vaadanud, kuidas see teile meeldib?

Cliff: Noh, ma olen C keeles juba igavesti kirjutanud, kõikide nende malloc ja free abil, ning haldan käsitsi eluea pikkust. Teate, 90-95% käsitsi hallatavatest eluaegadest on sama struktuuriga. Ja see on väga, väga valus omasoodu sellega tegeleda. Tahaks, et kompilaator lihtsalt ütleks, mis seal toimub ja mida sa oma tegevustega saavutasid. Mõnede asjade puhul teeb borrow checker seda automaatselt. Ja ta peab automaatselt andmeid välja kirjutama, kõike mõistma ja isegi mitte koormama mind sellega, et seda mõistmist välja tuua. Ta peaks vähemalt tegema kohalikku eskape-analüüsi, ja ainult siis, kui tal ei lähe korda, peaks juurde lisama tüübi annotatsioone, mis kirjeldavad eluaega – ja sarnane skeem on oluliselt keerulisem kui borrow checker või üldse mingi olemasolev mälu kontrollija. Valik „kõik on korras” ja „ma ei saanud aru” — ei, see peab olema midagi paremat. 
Seega, kui rääkida inimesest, kes on kirjutanud palju C-koodi, siis arvan, et automaatse elutsükli haldamise tugi on äärmiselt oluline. Samuti häirib mind, kui palju mälu Java kasutab, ja peamine kaebus on GC. Java mälu eraldamisel ei saa sa tagasi mälu, mis oli kohalik viimases GC tsüklis. Keeltes, kus mälu juhtimine on täpsem, ei ole see nii. Kui kutsub üles malloc'i, saad kohe mälu, mida just kasutati. Tüüpiliselt teed mäluga mingid ajutised asjad ja saadad selle kohe tagasi. Ja see tagastatakse kohe malloc'i puumi, kust järgmine malloc tsükkel toob selle jälle välja. Seega vähendatakse tegelikku mälu kasutust elavate objektide kogumini antud hetkel, pluss lekete kogum. Ja kui sul ei leki absoluutselt viisil, mis oleks ebaviisakas, asub enamik mälu vahemälus ja protsessoris, ja see töötab kiiresti. Kuid see nõuab palju käsitsi mälu juhtimist malloc ja free abil, kutsudes neid õigel ajal ja õiges kohas. Rust suudab sellega õigesti toime tulla ja paljudel juhtudel isegi pakkuda suuremat jõudlust, kuna mälu tarbimine kitseneb ainult praegustele arvutustele – vastupidiselt ootamisele järgmise GC tsükli ajal, mis mälu vabastab. Lõpuks saime väga huvitava viisi, kuidas jõudlust parandada. Ja see on üsna võimas – ma tegin selliseid asju andmete töötlemisel fintechis ja see võimaldas saavutada umbes viis korda kiiremat tulemust. See on üsna suur kiirus, eriti maailmas, kus protsessorid ei muutu kiiremateks ja me kõik ootame endiselt täiustusi.

Performantsiinseneri karjäär

Andrei: Samuti sooviksin rääkida karjäärist laiemalt. Te olete tuntuks saanud oma töö tõttu JIT-is HotSpotis ja hiljem liikusite Azulisse – mis on samuti JVM ettevõte. Kuid seal tegelesite rohkem riistavaraga kui tarkvaraga. Ja siis äkki suundusite Big Data ja masinõppe poole, seejärel pettuste avastamise peale. Kuidas see juhtus? Need arendusvaldkonnad on väga erinevad.

Cliff: Olen juba üsna pikka aega programmeerimistehnika parjutanud ja kogenud erinevates ülesannetes. Ja kui inimesed ütlevad: „oh, sina oled see, kes tegi JIT-i Java jaoks!“, on see alati naljakas. Kuid enne seda tegelesin PostScripti klooni loomisega – selle keelega, mida Apple kunagi oma laserprinterites kasutas. Enne seda tegin Forth-i keele rakendust. Arvan, et minu jaoks on üldine teema tööriistade arendamine. Kogu elu olen teinud tööriistu, mille abil teised inimesed kirjutavad oma ägedaid programme. Kuid olen tegelenud ka operatsioonisüsteemide, draiverite, tuumadebüügide, operatsioonisüsteemide arendamiseks mõeldud keelte arendamisega, mis alustasid triviaalsetest, kuid ajaga muutusid järjest keerulisemaks. Kuid põhiteema on ikkagi tööriistade arendamine. Suur osa elust kulus Azul ja Sun vahel ja see käsitles Java't. Kuid kui sukeldusin Suurandmete ja Masinõppe valdkonda, panin taas selga oma piduliku mütsi ja rääkisin: „Oh, nüüd on meil tekkinud keeruline probleem ja siin toimub tegelikult hunnik huvitavaid asju ja inimesi, kes midagi teevad“. See on suurepärane arengutee, mida tasub läbida.

Jah, ma armastan hajusaid arvutusi. Minu esimene töö oli ülikooli ajal, C keeles, reklaamiprojektiga. Need olid hajusaid arvutusi Zilog Z80 kiipidel, mis kogusid andmeid analoogsete optiliste tekstide äratundmise jaoks, mida tegi tegelik analooganalüsaator. See oli äge ja täiesti ebatavaline teema. Kuid seal olid probleemid, mingi osa ei olnud õigesti äratuntud, seega oli vajalik pilti välja võtta ja näidata seda inimesele, kes oli juba silmadega lugenud, ja edastada, mida seal öeldakse; ja seetõttu olid seal andmetööd, ja nendel andmetööd olid oma keel. Oli backend, mis töötles seda kõike – paralleelselt töötavad Z80, kus igaühel olid avatud vt100 terminalid – üks inimese kohta, ja Z80-l oli olemas paralleelprogrammeerimise mudel. Üks ühine mälutükk, mida jagasid kõik Z80 selle tähekujulise konfiguratsiooni sees; jagati nii tagaplaat kui ka pool RAM-i jagati võrgu sees, ja veel pool oli privaatne või läks millelegi muule. Mõistlikult keeruline paralleelne hajus süsteem jagatud... pool-jagatava mäluga. Millal see siis oli... Ei oska enam meenutada, kuskil 80ndate keskpaiku. Üsna ammu. 
Jah, oletame, et 30 aastat on piisavalt pikk aeg. Jagatud arvutustega seotud ülesanded on eksisteerinud juba pikka aega, inimesed on ammu nendega võidelnud. Beowulf-klastritega. Sellised klastrid näevad välja nagu... Näiteks: sul on Ethernet ja su kiire x86 on ühendatud sellele Ethernetile, ja nüüd tahad sa saada vale jagatud mälu, sest toona ei saanud keegi tegeleda jagatud arvutuste kodeerimisega, see oli liiga keeruline ja seetõttu oli vale jagatud mälu koos x86 mälu lehekülgede kaitsega. Ja kui sa kirjutasid sellesse lehekülge, siis me ütlesime teistele protsessoritele, et kui nad pääsevad juurde sellele samale jagatud mälule, tuleb see selt sinult laadida. Nii tekkis midagi, mis meenutas vahemälu koherentsuse toetamise protokolli ja tarkvara selle jaoks. Huvitav kontseptsioon. Tegelik probleem oli muidugi midagi muud. Kõik see toimis, kuid sa said kiiresti tootlikkuse probleemide osaliseks, sest keegi ei mõistnud tootlikkuse mudelit piisavalt hästi – millised olid mälule pääsu mustrid, kuidas vältida, et node'id pidevalt üksteist ei pingsaks, ja nii edasi.

H2O-s ma mõtlesin järgmist: arendajad vastutavad selle eest, et määrata, kus peitub paralleelsus ja kus seda ei ole. Olen loonud sellise kodeerimise mudeli, et kõrgetasemelise koodi kirjutamine on lihtne ja mugav. Kuid aeglaselt töötava koodi kirjutamine on keeruline ning see näeb halb välja. Aeglase koodi kirjutamiseks tuleb tõsiselt pingutada, tuleb kasutada mittestandardsed meetodeid. Aeglane kood on esmapilgul silmatorkav. Seetõttu kirjutatakse tavaliselt kood, mis töötab kiiresti, kuid tuleb mõista, mida teha jagatud mälu korral. Kõik see on seotud suurte massiividega ja seal käitumine sarnaneb mittevolatiilsete suurte massiividega paralleelses Javas. Kujutage ette, et kaks lõime kirjutavad paralleelsesse massiivi, üks neist võidab ja teine loomulikult kaotab, ja te ei tea, kes neist on kes. Kui nad ei ole volatiilsed, siis võib järjekord olla suvaline – ja see töötab tõeliselt hästi. Inimesed tõeliselt hoolivad operatsioonide järjekorrast, nad paigutavad õigesti volatile ja õigetes kohtades ootavad nad probleemidega seonduvat jõudluses, mis on seotud mäluga. Vastupidisel juhul kirjutaksid nad lihtsalt koodi tsüklitena alates 1 kuni N, kus N on mõned triljonid, lootes, et kõik keerulised juhtumid muutuvad automaatselt paralleelseks – ja seal see ei toimi. Kuid H2O ei ole see ei Java ega Scala, seda võib pidada „Java miinus miinus”, kui soovite. See on väga arusaadav programmis stiil ja sarnaneb lihtsa koodi kirjutamisega C või Java keeles tsüklite ja massiividega. Samas võib mälu töödelda terabaitide kaupa. Kasutan H2O-d ikka veel. Aeg-ajalt kasutan seda erinevates projektides – ja see on endiselt kõige kiireim lahendus, kümneid kordi konkurentidest ees. Kui teete Big Data-d veergandmetega, on H2O-d väga raske ületada.

Tehnilised väljakutsed

Andrei: Milline on olnud teie karjääri jooksul kõige suurem väljakutse?

Cliff: Kas arutame tehnilist või mitte-tehnilist osa? Ütleksin, et kõige suuremad väljakutsed on mitte-tehnilised. 
Mis osas on tehnilised väljakutsed. Ma lihtsalt võitsin nad. Ma isegi ei tea, mis neist kõige suurem oli, aga neid oli mitu üsna huvitavat, millele kulus palju aega ja vaimset pingutust. Kui ma läksin Suni, olin kindel, et suudan teha kiire kompilaatori, kuid hulk vanemaid arendajaid ütlesid, et mul ei õnnestu kunagi. Ent ma läksin selle teedpidi, kirjutasin kompilaatori kuni registrite jaotajani ning see oli päris kiire. Ta oli sama kiire kui kaasaegne C1, kuid toona oli jaotaja palju aeglasem ja tagantjärele vaadates - see oli suurte andmestruktuuride probleem. Mul oli neid vaja, et kirjutada graafiline registrite jaotaja ning ma ei mõistnud dilemmat, mis tekkis koodi väljendatavuse ja kiirusena, mis eksisteeris sellel ajal ja oli väga oluline. Selgus, et andmestruktuur ületas tavaliselt x86 arhiitekti kande suuruse ja seega, kui ma algselt eeldasin, et registrite jaotaja kulutab 5-10 protsenti kogu JVM-i ajast, siis tegelikult kujunes see 50 protsendi peale.

Aeg möödus, kompilaator muutus järjest täpsemaks ja tõhusamaks, lõpetas üha enam halbade koodide genereerimise ning jõudlus hakkas järjest rohkem meenutama C kompilaatori väljundit. Kui sa loomulikult ei kirjuta mingit jama, mida isegi C ei suuda kiirendada. Kui kirjutad koodi nagu C-s, siis saad ka C tasemel jõudluse palju sagedamini. Ja mida edasi, seda rohkem saadi kood, mis asümptootiliselt sarnanes C tasemega, registrite allocator hakkas meenutama midagi täiustatud… sõltumata sellest, kas su kood töötas kiiresti või aeglaselt. Jätkasin registrite allocatori täiustamist, et see teeks paremaid eraldamisi. See muutus aeglasemaks ja aeglasemaks, aga andis järjest paremat jõudlust olukordades, kus kedagi teist enam ei aidanud. Ma sain sukelduda registrite allocatorisse, kaevata sinna kuu aega tööd ja ühtäkki hakkas kogu kood töötama 5% kiiremini. See juhtus korduvalt ja registrite allocatorist sai midagi kunstiteose sarnast – kõik armastasid või vihkasid seda, ja akadeemia inimesed küsisid küsimusi, nagu 'miks kõik just nii toimub', miks mitte lineaarne skaneerimine, ja milles on vahe. Vastus on endiselt sama: graafivärvimise põhine allocator pluss väga hoolikas vahetuskoodiga töötamine on võidurelv, parim kombinatsioon, mida keegi ei suuda võita. Ja see on tegelikult üsna ebaselge asi. Kõik muu, mida seal kompilaator teeb – need on üsna tuntud asjad, kuigi need on ka kunstitasemele viidud. Ma olen alati teinud asju, mis peaksid kompilaatori kunstiteoseks muutma. Kuid midagi neist ei olnud midagi erakordset – välja arvatud registerallocator. Fokus on selles, et tuleb hoolikalt ühendada koormuse all ja kui see juhtub (ma saan selgitada põhjalikumalt, kui see huvitab), tähendab see, et saab inline'ida agressiivsemalt, ilma et oleks ohtu ületada jõudluse graafiku murdumist. Sel ajal oli palju täislahendusega kompilaatoreid, mis olid kaunistatud igasuguste vidinate ja trikkidega, kus olid register allocatorid, kuid keegi ei suutnud enam nii teha.

Probleem on selles, et kui lisad meetodeid, mis on inline'imiseks sobivad, suurendades ja suurendades inline'imise ala, siis kasutatavate väärtuste hulk ületab kiiresti registrite arvu ja pead hakkama osasid eemaldama. Kriitiline tase saavutatakse tavaliselt siis, kui allocator loobub, ning üks hea splittimise kandidaat maksab rohkem kui teine, mistõttu pead eemaldama täiesti ootamatuid asju. Inline'imise väärtus seisneb selles, et kaotad osa overhead'ist, mis tuleneb kutsumisest ja salvestamisest, sa näed väärtusi seestpoolt ja saad neid edasi optimeerida. Inline'imise hind seisneb selles, et tekib suur hulk elavaid väärtusi, ning kui su registri allocator eemaldab rohkem, kui vajalik, kaotad koheselt. Seepärast on enamikul allokaatoritest probleem: kui inline'imine ületab teatud piiri, algavad kõik asjad, mis kõik toovad kaasa vähenemise ja tootlikkuse on praktiliselt kadunud. Need, kes teevad kompilaatorit, lisavad teatud tõenäosusi: näiteks, et peatada inline'imine, alates teatud piisavalt suurest suurusest, kuna kõik allokatsioonid mõjutavad seda. Nii moodustub graafiku häire – sa inline'id, inline'id, tootlikkus kasvab aeglaselt – ja siis pauk! – see kukub järsult alla, kuna oled inline'inud liiga palju. Nii see kõik töötas kuni Java tulekuni. Java nõuab palju rohkem inline'imist, seega pidin tegema oma allokaatori palju agressiivsemaks, et see oleks tasakaalus, mitte kuitenki langenud. Ja kui sa oled liiga palju inline'inud – ta hakkab väikeseid eemaldama, kuid siiski tuleb hetk, mil „enam ei ole eemaldamist”. See on huvitav tähelepanek ja see tuli mulle lihtsalt kuskilt, mitte ilmselgelt, kuid tasus end hästi ära. Ma alustasin agressiivse inline'imisega ja see viis mind kohtadesse, kus Java ja C tootlikkus kõrvuti. Nad on tõeliselt lähedased – ma saan kirjutada Java koodi, mis on oluliselt kiirem kui C kood ja vastavalt sellele, kuid keskmiselt, suures asjade pildis, on nad enam-vähem võrdsed. Tundub, et osa sellest teenest on registri allocator, mis võimaldab mul inline'ida maksimaalselt põhimõtteliselt. Ma lihtsalt inline'in kõik, mida näen. Küsimus on selles, kas allocator töötab hästi ja kas tulemuseks on mõistlikult töötav kood. See oli suur väljakutse: kõike seda mõista ja end tööle panna.

Veidi registri ja multi-tuumade jaotamisest

Vladimir: Registrite eraldamise probleemid näivad olevat mingi igavese lõputu teema. Kas on kunagi juhtunud, et mingi idee tundus paljutõotav, kuid siis kukkus praktikas läbi?

Cliff: Loomulikult! Registererimist edastamine on valdkond, kus püüad NP-täieliku probleemi lahendamiseks leida mingeid heuristilisi meetodeid. Ja sa ei suuda kunagi saavutada ideaalset lahendust, eks? See on lihtsalt võimatu. Vaadake, Ahead of Time kompileerimine – see töötab samuti halvasti. Jutt käib siin keskmistest juhtudest. Tüüpilisest jõudlusest, nii et saad minna ja mõõta midagi, mida pead heaks tüüpiliseks jõudluseks – lõpuks töötad ju selle parandamise nimel! Registererimise edastamine on teema, mis on täielikult joonistatud jõudlusele. Kui sul on esimene prototüüp, mis töötab ja värvib vajamineva, siis algab töö jõudluse nimel. Pead õppima, kuidas hästi mõõta. Miks see on oluline? Kui on selged andmed, saad vaadata erinevaid osi ja näha: aha, see aitas siin, aga seal kõik kukkus kokku! Tulevad mõned head ideed, sa lisad uue heuristika ja äkki kõik hakkab keskmiselt veidi paremini tööle. Või ei hakka. Mul on olnud sadu juhtumeid, kus me võitlesime viie protsendi jõudluse nimel, mis eraldas meie lahendust eelnevatest registererijatest. Ja iga kord näeb see välja nii: kusagil tuli võit, kusagil kaotus. Kui sul on head jõudlusanalüüsi tööriistad, saad leida kaotavad ideed ja mõista, miks nad kaotavad. Võib-olla tasub kõik jätta nii, nagu on, või võtad tõsisemalt ette peenhäälestuse, või lähed ja parandad midagi muud. See on terve hulk asju! Ma tegin selle laheda häki, aga mul on vaja ka seda, seda ja seda – ja nende kogumine annab teatud parendusi. Üksikud ideed võivad kukkuda. Nii see on NP-täielike probleemide jõudlusega töötamise loomuses.

Vladimir: Tundub, et asjad nagu allocators'ite värvimine on juba lahendatud ülesanne. Noh, teie jaoks on see lahendatud, arvestades, mida te räägite, kas siis tasub üldse…

Cliff: See ei ole lahendatud nagu selline. Sina pead selle 'lahendatud' muutma. On keerulisi ülesandeid ja need tuleb lahendada. Kui see on tehtud, on aeg keskenduda tootlikkusele. Sellele ülesandele tuleb läheneda vastavalt – teha mõõtmisi, koguda statistikat, selgitada olukordi, kui tagasiviimisega eelmisele versioonile su vana nipp jälle tööle hakkas (või vastupidi, lakkas töötamast). Ja mitte loobuda, kuni millegi saavutad. Nagu ma juba ütlesin, kui ägedad ideed, mis ei toiminud, siis ideede valdkonnas on registreerimisvahendites umbkaudu lõpmatu. Näiteks võib lugeda teaduslikke publitseeringuid. Kuigi täna on see valdkond liikunud aeglasemalt ja on selgem kui oma nooruses. Sellegipoolest on seal tohutu hulk inimesi tööle ja kõik nende ideed väärivad proovimist; kõik ootavad oma aega. Ja sa ei saa öelda, kui head need on, kui sa neid ei proovi. Kui hästi need integreeruvad kõigega muuga sinu allokatsioonis, sest allokaator teeb palju erinevaid asju, ja mõned ideed sinu spetsiifilises allokaatoris ei tööta, aga teises allokaatoris – kergelt. Peamine viis allokaatori võitmiseks on aeglane jama põhiteest välja tõmmata ja sundida jagama aeglaste teede piiridel. Seega, kui sa tahad GC-d käivitada, minna aeglast teed, deoptiimiseerida, välja visata erandi, kõik sellelaadsed asjad – sa tead, et need asjad on suhteliselt haruldased. Ja nad on tõepoolest haruldased, ma kontrollisin. Sa teed lisatööd ja tänu sellele kaovad paljud piirangud nendel aeglastel teedel, kuid see ei ole väga oluline, sest need on aeglased ja nendel harva käiakse. Näiteks nullviit – see ei juhtu kunagi, eks? Peab olema mitu teed erinevate asjade jaoks, kuid nad ei tohiks peamise teega seguneda. 

Vladimir: Mida arvate palju tuumade kohta, kui tuumi on kohe tuhandeid? Kas see on kasulik asi?

Cliff: GPU edu näitab, et see on tõeliselt kasulik!

Vladimir: Need on üsna spetsialiseeritud. Aga mis saamoodust on üldotstarbelised protsessorid?

Cliff: Noh, see oli Azul'i ärimudel. Vastus tuli juba ajal, mil inimesed armastasid väga ettearvatavat jõudlust. Sel ajal oli parallelkoodi kirjutamine keerukam. H2O koodimudel skaleerub hästi, kuid see ei ole üldotstarbeline mudel. Vaevu, et natuke üldisem kui GPU kasutamisel. Kas me räägime sellise asja arendamise keerukusest või selle kasutamise keerukusest? Näiteks, huvitav õppetund, mille Azul mulle õpetas, oli see, et väikesed vahemälud on täiesti normaalsed. 

Elu suurim väljakutse

Vladimir: Kuidas on lood mitte tehniliste väljakutsetega?

Cliff: Suurim väljakutse oli mitte olla... lahke ja hea inimestega. Selle tagajärjel sattusin pidevalt äärmiselt konfliktsetesse olukordadesse. Nendes olukordades teadsin, et kõik läheb valesti, kuid ma ei teadnud, kuidas edasi liikuda nende probleemide lahendamisel ja ei suudnud nendega toime tulla. Palju pikaajalisi probleeme, mis kestsid kümneid aastaid, tekkis just niimoodi. See, et Java-s on C1 ja C2 kompilaatorid, on selle otsene tagajärg. Samuti on see, et Java-s ei olnud kümme aastat järjest mitmeastmelist kompileerimist, samuti otsene tagajärg. On ilmne, et meil oli selline süsteem vajalik, kuid mitte ilmne, miks seda ei olnud. Mul olid probleemid ühe inseneriga... või inseneride grupiga. Aegade alguses, kui alustasin tööd Sunis, olin... Okei, mitte ainult siis, mul on tegelikult alati oma arvamus. Ja ma pidasin tõeks, et võin lihtsalt oma tõde otse välja öelda. Eriti kuna ma olin šokeerivalt õige suure osa ajast. Ja kui selline lähenemine sulle ei meeldi... eriti kui sa ilmselgelt eksid ja teed jama... Üldiselt suudavad vähesed inimesed taluda sellist suhtlemisviisi. Kuigi mõned suudavad, näiteks mina. Olen kogu oma elu ehitanud meritokraatlikele põhimõtetele. Kui sa näitad mulle midagi vale, siis pöördun ma kohe ringi ja ütlen: sa ütlesid jama. Samuti vabandan ja kõike muud, tunnustan saavutusi, kui neid üldse on, ja teen teisi õigeid samme. Teisest küljest olen ma šokeerivalt õige šokeerivalt suure protsendi kogu ajast. Ja see ei tööta inimeste suhete osas eriti hästi. Ma ei ürita olla armas, vaid panen küsimuse teravaks. 'See ei hakka kunagi tööle, sest üks, kaks ja kolm.' Ja nemad: 'Oho!'. Oli ka teisi tagajärgi, mida oleks parem ilmselt vahele jätta: näiteks abielu lahutamine ja kümme aastat kestnud depressioon pärast seda.

Väljakutse on võitlus inimeste ja nende arusaamaga sellest, mida sa saad või ei saa teha, mis on oluline ja mis mitte. On olnud palju väljakutseid kodeerimisstiili üle. Ma kirjutan endiselt palju koodi ja tookord pidin isegi aeglustuma, sest tegin liiga palju paralleelseid ülesandeid ja tegin neid halvasti, selle asemel et keskenduda ühele. Kahe peale vaadates kirjutasin ma poole Java JIT meeskonna koodist, C2 meeskonnast. Järgmine kiiruselt kodeerija kirjutas pool aeglasemalt, järgmine veel pool aeglasemalt ja see oli eksponentsiaalne langus. Seitsmes inimene selles reas oli väga, väga aeglane – nii see alati on! Ma puutusin kokku hulga koodiga. Ma vaatasin, kes mida kirjutab, ilma eranditeta, ma kammisin nende koodi, vaatasin kõiki üle ja jätkasin ise rohkem koodi kirjutamist, kui ükski neist. Inimestega selline lähenemine ei toimi hästi. Mõned ei meeldi sellele. Ja kui nad ei suuda sellega toime tulla, algavad igasugused pretensioonid. Näiteks ühel päeval öeldi mulle, et lõpetan koodi kirjutamise, sest ma kirjutan liiga palju koodi, ja see seab meeskonna ohtu, ja minu jaoks kõlas see kõik nagu nali: mees, kui kogu ülejäänud meeskond kaob ja ma jätkan koodi kirjutamist, kaotad ainult poole meeskonnast. Teiselt poolt, kui ma jätkan koodi kirjutamist ja sa kaotad poole meeskonnast – see kõlab nagu väga halb juhtimine. Ma ei ole kunagi tõeliselt selle üle mõelnud, ma ei ole kunagi seda maininud, aga see oli ikkagi kuskil mu peas. Teadvuse tagaküljel keerles mõte: „Kas te kõik naljatate?“. Nii et suurim probleem olin mina ja minu suhted inimestega. Nüüd mõistan ennast palju paremini, ma juhtisin pikka aega programmeerijate tiimi, ja nüüd ütlen inimestele otse: tead, ma olen selline nagu olen, ja teil tuleb sellega toime tulla – ei ole midagi, kui ma siin seisan? Ja kui nad hakkasid sellega toime tulema, hakkas kõik tööle. Ma ei ole tegelikult halb ega hea, mul ei ole halbu kavatsusi ega egoistlikke püüdeid, see on lihtsalt minu olemus, ja see on millegagi elama peab.

Andrei: Viimasel ajal on kõik hakanud rääkima introvertide eneseteadvusest ja üldiselt pehmetest oskustest. Mida selle kohta öelda?

Cliff: Jah, see oli arusaamine ja õppetund, mille ma sain abikaasast lahkumisest. Mida ma selle lahutuse käigus sain, on enese mõistmine. Nii hakkasin ma mõistma ka teisi inimesi. Mõistma, kuidas see suhtlemine toimib. See viis avastusteni, mis tulid üksteise järel. Selgus, kes ma olen ja mida endast kujutan. Mida ma teen: kas ma olen ülesande pärast mures, või väldin konflikti, või midagi muud – ja selline eneseteadvuse tase aitab tõeliselt end kontrolli all hoida. Pärast seda läheb kõik palju lihtsamalt. Üks asi, mille olen avastanud mitte ainult enda, vaid ka teiste programmeerijate puhul, on võimetus sõnadega mõtteid väljendada, kui oled emotsionaalses stressis. Näiteks, istud ja koodid, oled voos, ja siis tulevad inimesed ja hakkavad hüsteeriliselt karjuma, et midagi on katki, ja nüüd rakendatakse sinu suhtes äärmuslikke meetmeid. Ja sa ei suuda isegi sõna öelda, sest oled emotsionaalses stressis. Saadud teadlikkus aitab valmistuda selleks hetkel, kogeda seda ja liikuda tagasiastumisplaani, pärast mida saad juba midagi teha. Nii et jah, kui hakkad mõistma, kuidas see kõik töötab – on see suur, elu muutav sündmus. 
Ma ei suutnud ise õigesti sõnu leida, kuid mäletan tegevuste järjestust. Asjaolu on selles, et see reaktsioon on sama füüsiline kui verbaalne, ja sul on vaja ruumi. Sellist ruumi, zen'i mõttes. Just seda tuleb seletada ja seejärel kohe kõrvale astuda – puhtalt füüsiliselt. Kui ma sõnades vaiksen, saan olukorda emotsioonide osas töötleda. Kui adrenaliin jõuab ajju, lülitab see sind 'löök või põgene’ režiimi, sa ei saa enam midagi öelda, ei – nüüd oled sa idioot, löömiseks mõeldud insener, kes ei suuda väärikat vastust anda ega isegi rünnakut peatada, ning ründaja võib vabalt korduvalt rünnata. Alustuseks pead jälle iseendaks saama, kontrolli tagasi saama, 'löök või põgene’ režiimist välja astuma.

Ja selleks on vajalik verbaalne ruum. Lihtsalt vabalt ruumi. Kui üldse midagi öelda, siis võib just seda väljendada ja seejärel minna tõeliselt leidma endale "ruumi": minna jalutama parki, sulguda duši alla – see ei ole oluline. Peamine on ajutiselt olukorrast lahti saada. Kui suudad vähemalt mõneks sekundiks välja lülituda, tuleb kontroll tagasi, hakkad mõtlema selgemalt. "Hea küll, ma ei ole mingi idioot, ma ei tee lolluseid, ma olen päris kasulik inimene." Kui oled suutnud end veenda, on aeg liikuda järgmisele etapile: mõista, mis juhtus. Sulle rünnati, rünnak tuli ootamatult, see oli ebaaus ja madal lõks. See on halb. Järgmine samm on mõista, miks ründaja seda tegi. Tõeliselt, miks? Võib-olla sellepärast, et ta on ise vihane? Miks ta on vihane? Näiteks sellepärast, et ta on ise eksinud ja ei suuda vastutust võtta? Just niimoodi tuleb olukord ettevaatlikult muuta. Kuid selleks on vajalik manööverdusruum, verbaalne ruum. Kõige esimene samm on katkestada verbaalne kontakt. Lahkuda arutelust sõnades. Tühistada see, minna minema nii kiiresti kui võimalik. Kui see on telefonikõne – pane lihtsalt toru ära – see on oskus, mille olen saanud endise naisest suhtlemisest. Kui vestlus ei vii kuhugi heasse kohta, ütle lihtsalt "nägemiseni" ja pane toru ära. Teiselt poolt toru: "bla-bla-bla", sa vastad: "aah, keda huvitab!" ja paned toru ära. Lihtsalt katkestad vestluse. Viie minuti pärast, kui su võime ratsionaalselt mõelda tagasi tuleb, ja sa natuke jahtud, on võimalik mõelda, mis üldse juhtus ja mis edasi toimub. Ja alustada mõtestatud vastuse koostamist, mitte lihtsalt reageerida emotsioonidele. Minu jaoks oli iseteadvuses läbimurre just see, et emotsionaalses stressis ma ei saa rääkida. Välja minna sellest seisundist, mõelda ja planeerida, kuidas vastata ja probleeme kompenseerida – need on õiged sammud olukordades, kus sa ei saa rääkida. Kõige lihtsam viis on põgeneda olukorrast, kus emotsionaalne stress avaldub, ja lihtsalt lõpetada selles stressis osalemine. Pärast seda saad tagasi mõtlema hakata, kui su mõte tööle hakkab, tekib võimalus rääkida ja nii edasi.

Üks tähtis asi on see, et kohtus üritab vastaspoole advokaat seda sinuga teha – nüüd on juba selge, miks. Sest tal on võimalus sind survestada sellisesse seisundisse, et sa ei suuda isegi oma nime välja öelda, näiteks. Kõige otsesemas mõttes, sa ei suuda rääkida. Kui sinuga juhtub midagi sellist ja tead, et satud kohta, kus sõnalised lahingud käivad, näiteks kohtusse, siis on mõistlik tulla oma advokaadiga. Advokaat kaitseb sind ja peatab sõnalise rünnaku, ning teeb seda täiesti seaduslikul viisil, ning sul taastub kaotatud zen-ruum. Näiteks, mul oli paar korda vaja perekonnale helistada, kohtunik suhtus sellesse üsna sõbralikult, kuid vastaspoole advokaat karjus ja karjus mu peale, ma ei suutnud isegi sõna sisse tuua. Sellistes olukordades toimib minu jaoks kõige paremini vahendaja kasutamine. Vahendaja peatab kogu selle surve, mis voolab sinu peale pideva voona, ning sa avastad vajaliku zen-ruumi, koos sellega taastub ka rääkimise võime. See on terve teadmiste valdkond, kus tuleb palju õppida, palju enda seest avastada, ning kõik see muutub kõrgetasemelisteks strateegilisteks otsusteks, mis on erinevad erinevate inimeste jaoks. Mõnel inimesel pole ülaltoodud probleeme, tavaliselt pole neid inimestel, kes tegelevad kutseliselt müügiga. Kõik need inimesed, kes teenivad elatist sõnadega – tuntud lauljad, luuletajad, usujuhid ja poliitikud, neil on alati, mida öelda. Neil pole selliseid probleeme, aga mul need on.

Andrei: See oli… ootamatu. Suurepärane, me oleme juba piisavalt juttu ajanud ja on aeg see intervjuu lõpetada. Me kohtume kindlasti konverentsil ja saame seda dialooge jätkata. Kohtume Hydral!

Kliiffiga saab vestlust jätkata konverentsil Hydra 2019, mis toimub 11-12. juulil 2019 Peterburis. Ta tuleb oma ettekandega «Azul Hardware Transactional Memory kogemus». Pileteid saab osta ametlikul veebilehelt.

Allikas: habr.com