{"id":35851,"date":"2019-10-31T22:07:03","date_gmt":"2019-10-31T19:07:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java\/"},"modified":"2019-10-31T22:07:03","modified_gmt":"2019-10-31T19:07:03","slug":"bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java","title":{"rendered":"Suur intervjuu Cliff Clickiga \u2014 Java JIT-kompilaatori isa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Suur intervjuu Cliff Clickiga \u2014 Java JIT-kompilaatori isa\" src=\"\/wp-content\/uploads\/2019\/07\/9ea9740ef74c0ae14d334482af115222.png\" style=\"display:block;margin: 0 auto;\" \/><strong>Cliff Click<\/strong> \u2014 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\u00e4ljaj\u00e4\u00e4mist. Cliff kirjutas oma esimese kompilaatori 15-aastaselt (Pascal TRS Z-80 jaoks)! Ta on k\u00f5ige tuntum oma t\u00f6\u00f6 poolest C2 puhul Java-s (the Sea of Nodes IR). See kompilaator n\u00e4itas maailmale, et JIT suudab toota kvaliteetset koodi, mis aitas kaasa Java kujunemisele \u00fcheks peamiseks t\u00e4nap\u00e4evaseks tarkvaraplatvormiks. Hiljem aitas Cliff Azul Systems'il ehitada 864 tuuma m\u00e4safraimi puhtale Java-le, mis toetas GC-pause 500 GB kuhjaga 10 millisekundiga. \u00dcldiselt on Cliff t\u00f6\u00f6tanud JVM-i k\u00f5igi aspektide kallal.<br clear=\"all\"><br \/>\n\u00a0<br \/>\nSee postitus on suur intervjuu Cliffiga. R\u00e4\u00e4gime j\u00e4rgmistest teemadest:<\/p>\n<p><\/p>\n<ul>\n<li>\u00dcleminek madala taseme optimeerimisele<\/li>\n<li>Kuidas teha suurt refaktoreerimist<\/li>\n<li>Kulude modelleerimine<\/li>\n<li>Madala taseme optimeerimise \u00f5petamine<\/li>\n<li>Praktilised n\u00e4ited j\u00f5udluse parandamisest<\/li>\n<li>Miks luua oma programmeerimiskeel<\/li>\n<li>Performantsiinseneri karj\u00e4\u00e4r<\/li>\n<li>Tehnilised v\u00e4ljakutsed<\/li>\n<li>Veidi registri ja multi-tuumade jaotamisest<\/li>\n<li>Elu suurim v\u00e4ljakutse<\/li>\n<\/ul>\n<p><\/p>\n<p>Intervjuud viib l\u00e4bi:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Andrei Satariin<\/strong> Amazon Web Servicesist. Oma karj\u00e4\u00e4ri jooksul on ta t\u00f6\u00f6tanud t\u00e4iesti erinevates projektides: testinud Yandexis jaotatud NewSQL andmebaasi, Kaspersky Labis pilveseire s\u00fcsteemi, Mail.ru-s mitme kasutajaga m\u00e4ngu ja Deutsche Bankis valuutahindade arvutamise teenust. Ta on huvitatud suuremahulisest backend- ja jaotatud s\u00fcsteemide testimisest.<\/li>\n<li><strong>Vladimir Sitnikov<\/strong> Netcrackerist. T\u00f6\u00f6tab \u00fcle k\u00fcmne aasta NetCracker OS'i j\u00f5udluse ja skaleeritavuse kallal \u2014 tarkvara, mida sideoperaatorid kasutavad v\u00f5rgu juhtimise ja seadmete haldamise automatiseerimiseks. Huvitub Java ja Oracle Database j\u00f5udlusest. On autoriks enam kui k\u00fcmnele j\u00f5udluse parandusele ametlikus PostgreSQL JDBC-draivis.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"perehod-k-nizkourovnevym-optimizaciyam\">\u00dcleminek madala taseme optimeerimisele<\/h1>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Te olete tuntud JIT-kompileerimise, Java ja \u00fcldiselt j\u00f5udluse valdkonnas, eks?\u00a0<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Just nii!<\/p>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Alustame \u00fcldiste k\u00fcsimustega j\u00f5udluse t\u00f6\u00f6tlemise kohta. Mida arvate madala taseme ja k\u00f5rge taseme optimeerimise valiku vahel, n\u00e4iteks CPU tasemel t\u00f6\u00f6tamisest?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Siin on k\u00f5ik lihtne. Kiireim kood on see, mis kunagi ei k\u00e4ivitu. Seet\u00f5ttu tuleb alati alustada k\u00f5rge tasemega, t\u00f6\u00f6tada algoritmide kallal. Paremini kirjutatud O-notation \u00fcletab halvemini kirjutatud O-notation, v\u00e4lja arvatud juhul, kui sekkuda m\u00f5ned piisavalt suured konstandid. Madala taseme asjad tulevad k\u00f5ige viimasena. Tavaliselt, kui oled optimeerinud kogu \u00fclej\u00e4\u00e4nud stack'i piisavalt h\u00e4sti ja midagi huvitavat on ikka veel j\u00e4\u00e4nud \u2013 see ongi madal tase. Kuidas alustada k\u00f5rge taseme juurest? Kuidas teada, et olete teinud piisavalt t\u00f6\u00f6d k\u00f5rgel 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\u00e4lja v\u00f5tta profailer, mis suudab \u00f6elda midagi kasulikku. Mingil hetkel saad sa ise aru, et oled vabanenud tarbetutest asjadest ja on aeg madala taseme t\u00e4psustamisega tegeleda. See on kindlasti eriline kunstivorm. Palju inimesi teeb tarbetuid asju, aga liigub nii kiiresti, et neil ei ole aega tootlikkuse p\u00e4rast muretseda. Kuid see on seni, kuni k\u00fcsimus ei t\u00f5use \u00e4kitselt \u00fcles. Tavaliselt 99% ajast ei huvita kedagi, millega ma tegelevad, kuni kriitilisel teel ei seisa mingi oluline asi, mis kellelegi korda l\u00e4heb. Ja siis hakkavad k\u00f5ik sind kiusama, et \u00abmiks see alguses ei t\u00f6\u00f6tanud ideaalselt\u00bb. \u00dcldiselt on alati midagi, mida perfformantsi osas paremaks teha. Aga 99% ajast pole sul mingeid vihjeid! Sa lihtsalt proovid saada midagi t\u00f6\u00f6le ja selle k\u00e4igus saad sa aru, mis on oluline. Kunagi ei saa ette teada, et just see t\u00fckk tuleb teha ideaalseks, seega tuleb p\u00f5him\u00f5tteliselt olla ideaalne igas asjas. Ja see on v\u00f5imatu ja sa ei tee nii. Alati on palju asju, mis vajavad parandamist \u2013 ja see on t\u00e4iesti normaalne.<\/p>\n<p><\/p>\n<h1 id=\"kak-delat-bolshoy-refaktoring\">Kuidas teha suurt refaktoreerimist<\/h1>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Kuidas te t\u00f6\u00f6tate j\u00f5udluse nimel? See on t\u00f5epoolest keeruline probleem. N\u00e4iteks, kas olete pidanud tegelema probleemidega, mis tulenevad suure hulga juba olemasoleva funktsionaalsuse ristumiste t\u00f5ttu?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Ma v\u00e4ldin seda. Kui ma tean, et j\u00f5udlus saab probleemiks, siis m\u00f5tlen sellele enne, kui hakkan kodeerima, eriti andmestructuuride osas. Kuid sageli avastad sa k\u00f5ik selle alles hiljem. Ja siis pead v\u00f5tma \u00e4\u00e4rmuslikke meetmeid ning tegema seda, mida ma nimetan '\u00fcle kirjutama ja valitsema': pead haarama piisavalt suure osa. Osa koodist tuleb nagunii n\u00e4iteks j\u00f5udlusprobleemide v\u00f5i muude p\u00f5hjuste t\u00f5ttu \u00fcmber kirjutada. Mis iganes p\u00f5hjus ka \u00fcmberkirjutamisel ei oleks, on peaaegu alati parem \u00fcmber kirjutada suurem t\u00fckk kui v\u00e4iksem t\u00fckk. Sel hetkel hakkavad k\u00f5ik kartma: 'oh jumal, ei tohi nii palju koodi puutuda!'. Aga tegelikult, see l\u00e4henemine t\u00f6\u00f6tab peaaegu alati palju paremini. Pead kohe haarama suure probleemi, joonistama selle \u00fcmber suure ringi ja \u00fctlema: k\u00f5ik, mis on ringi sees, kirjutan \u00fcmber. Piir on ju palju v\u00e4iksem kui see sisu, mis on selle sees asendamisele m\u00e4\u00e4ratud. Ja kui selline piiride m\u00e4\u00e4ratlemine v\u00f5imaldab teha t\u00f6\u00f6d seal sees ideaalselt \u2013 sul on k\u00e4ed vabaks, tee, mida tahad. Kui sa oled probleemi m\u00f5istnud, siis l\u00e4heb \u00fcmberkirjutamisprotsess palju lihtsamaks, seega hammusta suur t\u00fckk!<br \/>\nSamas, kui teed suurt \u00fcmberkirjutamist ja m\u00f5istad, et j\u00f5udlus hakkab probleemiks saama, tasub kohe selle p\u00e4rast muretseda. See muutub tavaliselt lihtsate asjadeks nagu \"\u00e4rge kopeerige andmeid, haldage andmeid nii lihtsalt kui v\u00f5imalik, tehke need v\u00e4iksemaks\". Suurte \u00fcmberkirjutamiste puhul on olemas standardmeetodid, et j\u00f5udlust parandada. Need keskenduvad enamasti andmetele.<\/p>\n<p><\/p>\n<h1 id=\"model-stoimosti\">Kulude modelleerimine<\/h1>\n<p><\/p>\n<p><strong>Andrei<\/strong>: \u00dches podcastis r\u00e4\u00e4kisite hinnamudelitest j\u00f5udluse kontekstis. Kas saaksite selgitada, mida selle all silmas pidite?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Muidugi. Ma s\u00fcndisin ajastul, kus protsessori efektiivsus oli \u00e4\u00e4rmiselt oluline. Ja see ajastu naaseb \u2014 saatus pole ilma irooniata. Ma alustasin elu kaheksabitiste masinatega, minu esimene arvuti t\u00f6\u00f6tas 256 baitiga. Just baiti. K\u00f5ik oli v\u00e4ga v\u00e4ike. Oli vaja lugeda k\u00e4ske ja kui me hakkasime liikuma k\u00f5rgemate programmeerimiskeelte poole, v\u00f5tsid keeled endaga j\u00e4rjest rohkem ja rohkem t\u00f6\u00f6d. Oli Assambleerimine, siis Basic, seej\u00e4rel C, ja C v\u00f5ttis enda peale palju detaile, nagu registrite ja k\u00e4skude jaotamine. Kuid seal oli k\u00f5ik \u00fcsna arusaadav ja kui ma tegin n\u00e4itaja muutuja eksemplarile, sain ma laadimise ja selle k\u00e4su hind oli teada. Riistvara annab v\u00e4lja kindla arvu masina ts\u00fckleid, nii et erinevate asjade t\u00e4itmise kiirus oli v\u00f5imalik lihtsalt kokku lugeda, liites k\u00f5ik k\u00e4sud, mida sa kavatsesid k\u00e4ivitada. Iga compare\/test\/branch\/call\/load\/store sai kokku liita ja \u00f6elda: siin on sinu t\u00e4itmise aeg. Ainult efektiivsuse parandamisega tegeledes p\u00f6\u00f6rad kindlasti t\u00e4helepanu numbritele, mis vastavad v\u00e4ikestele kuumadele ts\u00fcklitele.\u00a0<br \/>\nKuid niipea, kui sa l\u00fclitud Java, Python ja sarnaste asjade juurde, eemaldud sa kiiresti madalamast tasemest. Milline on getteri kutse maksumus Javas? Kui JIT HotSpot'is k\u00f5ik \u00f5igesti <noindex><a rel=\"nofollow\" href=\"https:\/\/wiki.openjdk.java.net\/display\/HotSpot\/Inlining\">inline'itud<\/a><\/noindex>, siis on see laadimine, kuid kui ta seda ei teinud \u2013 on see funktsioonikutse. Kuna kutse asetub kuumasse ts\u00fcklisse, t\u00fchistab see k\u00f5ik muud optimeeringud selles ts\u00fcklis. Seet\u00f5ttu on tegelik maksumus palju suurem. Ja sa kaotad kohe v\u00f5ime vaadata koodijuppi ja m\u00f5ista, kui palju peaksime selle t\u00e4itmiseks arvestama protsessori taktsageduse, kasutatud m\u00e4lu ja vahem\u00e4lu osas. K\u00f5ik see muutub huvitavaks ainult siis, kui s\u00fcvened t\u00f5eliselt j\u00f5udlusesse.<br \/>\nPraegu oleme olukorras, kus protsessorite kiirus ei ole viimase k\u00fcmne aasta jooksul oluliselt muutunud. Vanad ajad naasevad! Te ei saa enam loota heale \u00fchetuumalisele j\u00f5udlusele. Kuid kui te siiski tegelete paralleelsete arvutustega \u2013 on see \u00e4\u00e4rmiselt keeruline, k\u00f5ik vaatavad teid nagu James Bondi. K\u00fcmnekordsed kiiruset\u00f5usud ilmnevad tavaliselt seal, kus keegi midagi ei m\u00e4rka. Paralleelsus n\u00f5uab palju t\u00f6\u00f6d. Et saavutada see k\u00fcmnekordne kiiruset\u00f5us, peate m\u00f5istma v\u00e4\u00e4rtusmudelit. Mis on ja kui palju see maksab. Selleks peate m\u00f5istma, kuidas keel sobitub alumisele riistvarale.<br \/>\nMartin Thompson leidis oma blogile suurep\u00e4rase s\u00f5na <noindex><a rel=\"nofollow\" href=\"https:\/\/mechanical-sympathy.blogspot.com\/\">Mehaaniline kaastunne<\/a><\/noindex>! Peab aru saama, mida riistvara teeb, kuidas just see seda teeb ja miks see \u00fcldse seda teeb. Kasutades seda, on \u00fcsna lihtne alustada juhiste arvestamist ja v\u00e4lja selgitada, kuhu t\u00e4itmisaeg voolab. Kui sul ei ole vastavat ettevalmistust, siis otsid nagu musta kassi pimedas toas. Ma n\u00e4en pidevalt inimesi, kes optimeerivad j\u00f5udlust, kuid kellel pole v\u00e4himatki aimu, mida nad \u00fcldse teevad. Nad vaevlevad v\u00e4ga ja ei liigu eriti edasi. Ja kui ma v\u00f5tan sama koodi ja lisan sinna paar v\u00e4ikest nippi ning saavutan viis- v\u00f5i k\u00fcmnekordse kiiruskasvu, siis nad \u00fctlevad: noh, see pole aus, me teadsime ju, et sa oled parem. \u00dcllatav. Millest ma r\u00e4\u00e4kisin... maksumudelist \u2013 see on seotud sellega, mis koodi sa kirjutad ja kui kiiresti see keskmiselt toimib \u00fcldises pildis.<\/p>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Ja kuidas sellist mahukust peas hoida? Kas see saavutatakse suure koguse kogemusega, v\u00f5i? Kus sellist kogemust saadakse?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Noh, sain kogemus on tulnud keerulisel teel. Programmeerisin assembleris juba siis, kui iga \u00fcksiku k\u00e4su m\u00f5istmine oli veel v\u00f5imalik. See k\u00f5lab tobedalt, kuid sellest ajast on mul peas, m\u00e4lus igaveseks j\u00e4\u00e4nud Z80 k\u00e4skude kogum. Ma ei m\u00e4leta inimeste nimesid isegi kohe p\u00e4rast vestlust, kuid m\u00e4letan koodi, mis kirjutatud 40 aastat tagasi. Naljakas, see meenutab \u00ab\"<noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%A1%D0%B8%D0%BD%D0%B4%D1%80%D0%BE%D0%BC_%D1%81%D0%B0%D0%B2%D0%B0%D0%BD%D1%82%D0%B0\">teadlase idioodi\"<\/a><\/noindex>\u00bb.<\/p>\n<p><\/p>\n<h1 id=\"obuchenie-nizkourovnevym-optimizaciyam\">Madala taseme optimeerimise \u00f5petamine<\/h1>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Kas on olemas lihtsam viis alustada?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Jah ja ei. Riistvara, mida me k\u00f5ik kasutame, pole selle aja jooksul palju muutunud. K\u00f5ik kasutavad x86, v\u00e4lja arvatud ARM-il p\u00f5hinevad nutitelefonid. Kui sa ei tegele mingi t\u00f5sise sisseehitatud m\u00f5\u00f5tmisega, siis on sul k\u00f5ik 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\u00e4\u00e4gin t\u00e4iesti t\u00f5siselt. On oluline m\u00f5ista keele ja riistvara seost. P\u00e4rast seda tuleb minna, kirjutada natuke ja teha v\u00e4ike m\u00e4nguline kompilaator v\u00e4ikese m\u00e4ngulise keele jaoks. \u201eM\u00e4nguline\u201c t\u00e4hendab, et tuleb seda teha arvestatavas ajavahemikus. See v\u00f5ib olla superlihtne, kuid peab genereerima juhiseid. Juhiste genereerimise akt aitab m\u00f5ista kulumudelit silla ehitamiseks k\u00f5rgema taseme koodi ja masina koodi vahel, mida riistvara t\u00e4idab. See seos j\u00e4\u00e4b m\u00e4llu kompilaatori kirjutamise k\u00e4igus. Isegi k\u00f5ige lihtsam kompilaator. P\u00e4rast seda saab hakata vaatama Java't ja seda, kui s\u00fcgavale on seal semantilised l\u00f5hed, ning ehitama nende peale keerukamaid sildu. Java's on palju keerulisem m\u00f5ista, kas meie sild on hea v\u00f5i halb, mis p\u00f5hjustab selle kokkuvarisemise ja mis mitte. Aga sul on vaja mingit l\u00e4htepunkti, kui vaatad koodi ja m\u00f5istad: \u201eaha, see getter peaks iga kord inline'ima.\u201d Ja siis selgub, et m\u00f5nikord juhtubki nii, v\u00e4lja arvatud olukordades, kus meetod muutub liiga suureks, ja JIT hakkab inline'ima k\u00f5ike juhuslikult. Selliste kohtade sooritusv\u00f5imet on v\u00f5imalik hetkega ennustada. Reeglina t\u00f6\u00f6tavad getterid h\u00e4sti, kuid seej\u00e4rel vaatad suuri kuumi sildu ja m\u00f5istad, et seal on mingid funktsiooni kutsed, millel pole selget eesm\u00e4rki. Just selles seisneb probleem getterite laialdasel kasutamisel; p\u00f5hjus, miks nad ei inline'ita - ei ole selge, kas see on getter. Kui sul on superv\u00e4ike koodibaas, saad selle lihtsalt meelde j\u00e4tta ja siis \u00f6elda: siin on getter, ja seal on setter. Suures koodibaasis elas iga funktsioon omaenda ajalugu, mis pole kellelegi teada. Profilera \u00fctleb, et oleme kaotanud 24% aega mingis ts\u00fcklis ja et selle ts\u00fckli toimimiseks tuleb vaadata iga funktsiooni sees. Seda on raske m\u00f5ista, kui sa ei uuri funktsiooni, ja see aeglustab t\u00f5siselt arusaamise protsessi. Seet\u00f5ttu ma ei kasuta getterite ja setterite pidevat kasutust; olen l\u00e4inud uuele tasemele!<br \/>\nKust leida hinnamudelit? Jah, muidugi, v\u00f5ib lugeda midagi... Kuid ma arvan, et parim viis on tegutseda. Luua v\u00e4ike kompilaator ja see on parim viis hinnamudeli m\u00f5istmiseks ja selle enda m\u00f5tetes paigutamiseks. V\u00e4ike kompilaator, mis sobiks mikrolaineahju programmeerimiseks \u2014 see on algaja \u00fclesanne. Ma m\u00f5tlen, et kui sul on juba programmeerimisoskused, siis peaks neist piisama. K\u00f5ik need asjad, nagu stringi parsimine, mis on mingi algebraline v\u00e4ljend, t\u00f5mmata sealt v\u00e4lja \u00f5iged matemaatilised toimingud \u00f5iges j\u00e4rjekorras, v\u00f5tta \u00f5iged v\u00e4\u00e4rtused registritest \u2014 see k\u00f5ik on h\u00f5lbus. Ja kui sa seda teed, j\u00e4\u00e4b see su ajusse. Ma arvan, et k\u00f5ik teavad, mida kompilaator teeb. Ja see annab m\u00f5istmise hinnamudelist.<\/p>\n<p><\/p>\n<h1 id=\"prakticheskie-primery-uluchsheniya-proizvoditelnosti\">Praktilised n\u00e4ited j\u00f5udluse parandamisest<\/h1>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Millele veel tasub t\u00e4helepanu p\u00f6\u00f6rata j\u00f5udluse parandamisel?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Andmestruktuurid. Jah, t\u00f5epoolest, ma ei ole neid loenguid juba pikka aega pidanud... <noindex>Rocket School<\/noindex>. 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 \u2014 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. <\/p>\n<p><\/p>\n<p>Nii l\u00e4henemisega on k\u00f5ik selge, mis toimub, ja paralleelsed arvutused siin ei aita, eks? Selgub, et viiekordset j\u00f5udluse suurendamist saab saavutada lihtsalt \u00f5igete andmestructuuride valimisega. See \u00fcllatab isegi kogenud programmeerijaid! Minu konkreetses olukorras oli fookus selles, et ei tohiks teha m\u00e4lu eraldamisi kuumas ts\u00fcklis. No, see ei ole kogu t\u00f5de, aga \u00fcldiselt \u2013 ei tohiks eraldada 'kord X', kui X on piisavalt suur. Kui X on kaks ja pool gigabaiti, ei tohiks eraldada midagi 'kord t\u00e4he', 'kord rea', v\u00f5i 'kord v\u00e4lja', midagi sellist. Just sellele kulubki aega. Kuidas see \u00fcldse t\u00f6\u00f6tab? Kujutage ette, et teen k\u00f5ne <code>String.split()<\/code> v\u00f5i <code>BufferedReader.readLine()<\/code>. <code>Readline<\/code> muundab v\u00f5rgu kaudu saadud baitidest iga rea jaoks \u00fche striingi, iga sada miljonit rida. Ma v\u00f5tan selle striingi, anal\u00fc\u00fcsin selle ja viskan minema. Miks viskan? Noh, olen ju selle juba t\u00f6\u00f6tlenud, k\u00f5ik. Nii et iga bait, mis on loetud nendest 2.7G-st, salvestatakse kaheks s\u00fcmboliks striingis, seega juba 5.4G, ja nad ei ole mulle enam millekski vajalikud, seega visatakse nad minema. Kui vaadata m\u00e4luliiklust, laeme 2.7G, mis liigub l\u00e4bi m\u00e4lu ja m\u00e4lubussi protsessoris, ja veel kaks korda rohkem saadetakse striingi, mis asub m\u00e4lus, ja see k\u00f5ik t\u00f6\u00f6tatakse \u00fcmber igal uue striingi loomisel. Kuid ma pean selle lugema, riistvara loeb selle, isegi kui see k\u00f5ik hiljem \u00fcmber t\u00f6\u00f6tatakse. Ja ma pean selle salvestama, sest olen loonud striingi ja vahem\u00e4ed on \u00fclekoormatud \u2013 vahem\u00e4e maht ei suuda 2.7G mahutada. Kokkuv\u00f5tteks, iga loetud baidi kohta loen veel kaks lisabaidi ja kirjutan kaks lisabaidi, ning kokku saavad nad suhe 4:1 \u2013 sellises sooritusv\u00f5imes raiskame m\u00e4lu l\u00e4bilaskev\u00f5imet. Ja edasi selgub, et kui ma teen <code>String.split()<\/code> \u2013 ma ei tee seda kaugeltki esmakordselt; seal sees v\u00f5ivad olla veel 6-7 valikut. Seep\u00e4rast toob klassikaline CSV lugemiskood koos j\u00e4rgneva ridade parsimisega kaasa m\u00e4lu ribalaiuse kadu umbes 14:1 v\u00f5rreldes sellega, mida te tegelikult oma soovitud n\u00e4ete. Kui need v\u00e4ljastamised k\u00f5rvale j\u00e4tta, on v\u00f5imalik saavutada viiekordne kiirus. <\/p>\n<p><\/p>\n<p>Ja see ei ole \u00fcldse nii keeruline. Kui vaatate koodi \u00f5igest vaatenurgast, muutub k\u00f5ik \u00fcsna lihtsaks, kohe kui olete probleemi olemuse m\u00f5istnud. Ei tohiks \u00fcldse l\u00f5petada m\u00e4lu eraldamist: probleem seisneb lihtsalt selles, et teete midagi, mis kohe sureb, ja samal ajal p\u00f5letate olulist ressurssi, milleks on sel juhul m\u00e4lu ribalaius. See k\u00f5ik viib j\u00f5udluse langemiseni. x86 puhul tuleb tavaliselt aktiivselt p\u00f5letada protsessori takte, aga siin olete kogu m\u00e4lu p\u00f5letanud varem. Lahendus on v\u00e4hendada eraldamiste arvu.\u00a0<br \/>\nTeine probleem on see, et kui profiilerit k\u00e4ivitada, kui m\u00e4lu lint on l\u00f5ppenud, just siis, kui see juhtub, siis sa tavaliselt ootad vahem\u00e4lu tagastumist, kuna see on t\u00e4is pr\u00fcgi, mida sa just tootnud oled, nende ridadega. Seet\u00f5ttu iga laadimis- v\u00f5i salvestusoperatsioon muutub aeglaseks, kuna need toovad kaasa vahem\u00e4lu m\u00f6\u00f6dalaskmised \u2013 kogu vahem\u00e4lu on aeglane, oodates, millal pr\u00fcgi v\u00e4lja veetakse. Seet\u00f5ttu n\u00e4itab profiiler lihtsalt sooja juhuslikku m\u00fcra, hajutatuna kogu ts\u00fckli ulatuses \u2013 ei ole \u00fchtegi eraldi kuuma instruktsiooni v\u00f5i koodi kohta. Ainult m\u00fcra. Ja kui vaatad GC ts\u00fckleid, on need k\u00f5ik Young Generation'i ulatuses ja \u00fclimugavad \u2013 mikrosekundid v\u00f5i millisekundid maksimaalselt. Sest kogu see m\u00e4lu sureb koheselt. Sa eraldad miljardeid gigabaite, ja ta l\u00f5ikab neid, ja l\u00f5ikab, ja j\u00e4lle l\u00f5ikab. K\u00f5ik see toimub v\u00e4ga kiiresti. Nii et on odavad GC ts\u00fcklid, soe m\u00fcra kogu ts\u00fckli ulatuses, kuid me tahame saada 5-kordset kiiruskasvu. Just sel hetkel peaks peas midagi klikkima ja k\u00f5lama: 'miks nii?!'. M\u00e4lu lint \u00fclevoolu ei kuvata klassikalises siluri, tuleb k\u00e4ivitada riistvaraliste j\u00f5udluse loendurite silur ja n\u00e4ha seda ise ja otse. Otse mitte, seda v\u00f5ib kahtluse alla seada nende kolme s\u00fcmptomi kaudu. Kolmas s\u00fcmptom on see, kui vaatad, mida sa eraldad, k\u00fcsid profiilerilt ja ta vastab: 'Sa tegid miljardi rida, kuid GC t\u00f6\u00f6tas tasuta.' Kui see juhtub, m\u00f5istad, et oled tootnud liiga palju objekte ja p\u00f5letanud kogu m\u00e4lu lint. On viis seda probleemi lahendada, kuid see ei ole ilmselge.\u00a0<\/p>\n<p><\/p>\n<p>Andmete struktuuriga on probleem: paljas struktuur, mis seisab k\u00f5ikide s\u00fcndmuste taga, on liiga suur, see on 2.7G kettale, seega on selle koopia tegemine v\u00e4ga ebasoovitav \u2013 soov oleks laadida see kohe v\u00f5rgubuffrist 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\u00e4heb kasutusele sinu enda vahelduva laadija ridade jaoks, mis kordab stringi klassi k\u00e4itumist, olles samas \u00fcmberpakendatud alloleva baitide puhvri \u00fcmber. Tulemuseks on, et t\u00f6\u00f6tad peaaegu nagu stringidega, aga tegelikult liiguvad seal puhvri suunajad, ja toored bait ei kopeerita kuhugi, ning niimoodi taaskasutatakse samu puhvereid ikka ja j\u00e4lle, ning operatsioonis\u00fcsteem on \u00f5nnelik, et saab v\u00f5tta enda kanda asjad, milleks ta on m\u00f5eldud, nagu n\u00e4iteks peidetud topeltpuhverdamine nende bity puhvritega, ja sina enam ei jahvatata l\u00f5putut voolu tarbetutest andmetest. Muide, kas te m\u00f5istate, et GC t\u00f6\u00f6tamise ajal tagatakse, et iga m\u00e4lu eraldamine ei ole p\u00e4rast viimast GC ts\u00fcklit protsessorile n\u00e4htav? Seega ei saa see k\u00f5ik kuidagi olla vahem\u00e4lu, ja see viib 100%-iliselt tagatud m\u00f6\u00f6daminnani. Suunajaga t\u00f6\u00f6tamisel x86-l kestab registreerimise lugemine m\u00e4lust 1-2 ts\u00fcklit, ja kui see juhtub, siis maksad, maksad, maksad, kuna kogu m\u00e4lu on <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Cache_inclusion_policy\">\u00dcHEKS keskkonnas<\/a><\/noindex> \u2013 ja see ongi m\u00e4lu eraldamise maksumus. Tegelik maksumus.<\/p>\n<p><\/p>\n<p>Teisis\u00f5nu, andmestruktuurid on need, mida on k\u00f5ige raskem muuta. Ja kui sa saad aru, et oled valinud vale andmestruktuuri, mis tulevikus h\u00e4vitab j\u00f5udluse, on tavaliselt vajalik teha m\u00e4rkimisv\u00e4\u00e4rne t\u00f6\u00f6, kuid kui seda ei tehta, l\u00e4heb asi hullemaks. Esiteks tuleb m\u00f5elda 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\u00e4limuselt'. Kuid kopeerimise operatsioon (mis tundub odav) tarbib tegelikult m\u00e4lu, ja siin peitub kogu kaotatud t\u00e4itmisaja probleem. Kui mul on hiiglaslik JSON-string ja ma tahan selle teisendada struktureeritud DOM-puu POJO-ks v\u00f5i millegi sarnaseks, siis selle stringi parsimise ja POJO ehitamise operatsioon ning edasi uute p\u00e4ringute tegemine POJO-le t\u00e4hendab t\u00e4iendavaid kulusid \u2013 see pole odav. Erandiks on see, kui sa jooksed POJO-de \u00fcle kordades sagedamini kui stringi. \u00d6eldes lihtsalt, v\u00f5iks proovida stringi dekodeerida ja v\u00e4lja t\u00f5mmata ainult vajaliku, ilma et see muutuks mingiks POJO-ks. Kui k\u00f5ik see toimub tee peal, kus on n\u00f5utav maksimaalne j\u00f5udlus, siis igasugused POJO-d on v\u00e4listatud \u2013 tuleb kuidagi otse stringiga tegeleda.<\/p>\n<p><\/p>\n<h1 id=\"zachem-sozdavat-svoy-yazyk-programmirovaniya\">Miks luua oma programmeerimiskeel<\/h1>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Te \u00fctlesite, et teadlikkuse mudeli loomiseks tuleb kirjutada oma v\u00e4ike keel\u2026<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Mitte keel, vaid kompilaator. Keel ja kompilaator on erinevad asjad. Peamine erinevus on peas.\u00a0<\/p>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Muide, kui ma ei eksi, katsetate te oma keelte loomisega. Miks?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Sest ma saan! Olen poolpensionil, seega on see minu hobi. Olen kogu elu t\u00f6\u00f6tanud kellegi teise keelte rakendamise nimel. Samuti olen palju vaeva n\u00e4inud koodimise stiiliga. Ja veel muidugi, kuna n\u00e4en probleeme teistes keeltes. N\u00e4en, et on paremaid viise tuttavate asjade tegemiseks. Ja ma kasutaksin neid. Mind h\u00e4irib t\u00f5esti n\u00e4ha 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\u00f6\u00f6ga seotud. Ja ma kirjutan ka Pythonis ning t\u00f5en\u00e4oliselt j\u00e4tkan masin\u00f5ppe arendamist Java back-end'ide jaoks. Populaarseid keeli on palju ja igal neist on huvitavad omadused. Iga\u00fchel on oma tugevused ja saate proovida k\u00f5ik need trikid kokku viia. Seega uurin huvitavaid asju, keele k\u00e4itumist, p\u00fc\u00fcan v\u00e4lja m\u00f5elda m\u00f5istliku semantika. Ja seni suudan! Praegu v\u00f5itlen m\u00e4lu semantikaga, sest soovin, et see oleks nagu C-s ja Java-s, ning saada tugev m\u00e4lumudel ja m\u00e4lu semantika laadimise ja salvestamise jaoks. Samuti soovin automaatset t\u00fc\u00fcbi j\u00e4reldust nagu Haskell'is. Nii et p\u00fc\u00fcan segada Haskell'i sarnast t\u00fc\u00fcbi j\u00e4reldust m\u00e4lu funktsioonidega nagu C-s ja Java-s. Sellega olen viimased 2-3 kuud tegelenud, n\u00e4iteks.<\/p>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Kui te loote keelt, mis v\u00f5tab parimaid aspekte teistest keeltest, kas olete m\u00f5elnud, et keegi v\u00f5iks teha vastupidist: v\u00f5tta teie ideid ja kasutada neid enda heaks?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: T\u00e4pselt nii s\u00fcnnivad uued keeled! Miks on Java sarnane C-ga? Sest C-l oli hea s\u00fcntaks, mida k\u00f5ik m\u00f5istsid, ja Java sai inspiratsiooni sellest s\u00fcntaksist, lisades t\u00fc\u00fcbiohutuse, massiivide piirikontrollid, GC, ja nad parandasid ka m\u00f5ningaid asju C-s. Nad lisasid omalt poolt. Kuid nad said t\u00f5eliselt tugevalt inspiratsiooni, eks? K\u00f5ik seisavad hiiglaste \u00f5lgadel, kes olid enne sind \u2013 just nii toimub progress.<\/p>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Nii nagu mina aru saan, on teie keel m\u00e4lu kasutamise osas ohutu. Kas olete m\u00f5elnud midagi sarnast Rusti borrow checker'ile rakendada? Kas olete seda vaadanud, kuidas see teile meeldib?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Noh, ma olen C keeles juba igavesti kirjutanud, k\u00f5ikide nende malloc ja free abil, ning haldan k\u00e4sitsi eluea pikkust. Teate, 90-95% k\u00e4sitsi hallatavatest eluaegadest on sama struktuuriga. Ja see on v\u00e4ga, v\u00e4ga valus omasoodu sellega tegeleda. Tahaks, et kompilaator lihtsalt \u00fctleks, mis seal toimub ja mida sa oma tegevustega saavutasid. M\u00f5nede asjade puhul teeb borrow checker seda automaatselt. Ja ta peab automaatselt andmeid v\u00e4lja kirjutama, k\u00f5ike m\u00f5istma ja isegi mitte koormama mind sellega, et seda m\u00f5istmist v\u00e4lja tuua. Ta peaks v\u00e4hemalt tegema kohalikku eskape-anal\u00fc\u00fcsi, ja ainult siis, kui tal ei l\u00e4he korda, peaks juurde lisama t\u00fc\u00fcbi annotatsioone, mis kirjeldavad eluaega \u2013 ja sarnane skeem on oluliselt keerulisem kui borrow checker v\u00f5i \u00fcldse mingi olemasolev m\u00e4lu kontrollija. Valik \u201ek\u00f5ik on korras\u201d ja \u201ema ei saanud aru\u201d \u2014 ei, see peab olema midagi paremat.\u00a0<br \/>\nSeega, kui r\u00e4\u00e4kida inimesest, kes on kirjutanud palju C-koodi, siis arvan, et automaatse eluts\u00fckli haldamise tugi on \u00e4\u00e4rmiselt oluline. Samuti h\u00e4irib mind, kui palju m\u00e4lu Java kasutab, ja peamine kaebus on GC. Java m\u00e4lu eraldamisel ei saa sa tagasi m\u00e4lu, mis oli kohalik viimases GC ts\u00fcklis. Keeltes, kus m\u00e4lu juhtimine on t\u00e4psem, ei ole see nii. Kui kutsub \u00fcles malloc'i, saad kohe m\u00e4lu, mida just kasutati. T\u00fc\u00fcpiliselt teed m\u00e4luga mingid ajutised asjad ja saadad selle kohe tagasi. Ja see tagastatakse kohe malloc'i puumi, kust j\u00e4rgmine malloc ts\u00fckkel toob selle j\u00e4lle v\u00e4lja. Seega v\u00e4hendatakse tegelikku m\u00e4lu kasutust elavate objektide kogumini antud hetkel, pluss lekete kogum. Ja kui sul ei leki absoluutselt viisil, mis oleks ebaviisakas, asub enamik m\u00e4lu vahem\u00e4lus ja protsessoris, ja see t\u00f6\u00f6tab kiiresti. Kuid see n\u00f5uab palju k\u00e4sitsi m\u00e4lu juhtimist malloc ja free abil, kutsudes neid \u00f5igel ajal ja \u00f5iges kohas. Rust suudab sellega \u00f5igesti toime tulla ja paljudel juhtudel isegi pakkuda suuremat j\u00f5udlust, kuna m\u00e4lu tarbimine kitseneb ainult praegustele arvutustele \u2013 vastupidiselt ootamisele j\u00e4rgmise GC ts\u00fckli ajal, mis m\u00e4lu vabastab. L\u00f5puks saime v\u00e4ga huvitava viisi, kuidas j\u00f5udlust parandada. Ja see on \u00fcsna v\u00f5imas \u2013 ma tegin selliseid asju andmete t\u00f6\u00f6tlemisel fintechis ja see v\u00f5imaldas saavutada umbes viis korda kiiremat tulemust. See on \u00fcsna suur kiirus, eriti maailmas, kus protsessorid ei muutu kiiremateks ja me k\u00f5ik ootame endiselt t\u00e4iustusi.<\/p>\n<p><\/p>\n<h1 id=\"karera-performans-inzhenera\">Performantsiinseneri karj\u00e4\u00e4r<\/h1>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Samuti sooviksin r\u00e4\u00e4kida karj\u00e4\u00e4rist laiemalt. Te olete tuntuks saanud oma t\u00f6\u00f6 t\u00f5ttu JIT-is HotSpotis ja hiljem liikusite Azulisse \u2013 mis on samuti JVM ettev\u00f5te. Kuid seal tegelesite rohkem riistavaraga kui tarkvaraga. Ja siis \u00e4kki suundusite Big Data ja masin\u00f5ppe poole, seej\u00e4rel pettuste avastamise peale. Kuidas see juhtus? Need arendusvaldkonnad on v\u00e4ga erinevad.<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Olen juba \u00fcsna pikka aega programmeerimistehnika parjutanud ja kogenud erinevates \u00fclesannetes. Ja kui inimesed \u00fctlevad: \u201eoh, sina oled see, kes tegi JIT-i Java jaoks!\u201c, on see alati naljakas. Kuid enne seda tegelesin PostScripti klooni loomisega \u2013 selle keelega, mida Apple kunagi oma laserprinterites kasutas. Enne seda tegin Forth-i keele rakendust. Arvan, et minu jaoks on \u00fcldine teema t\u00f6\u00f6riistade arendamine. Kogu elu olen teinud t\u00f6\u00f6riistu, mille abil teised inimesed kirjutavad oma \u00e4gedaid programme. Kuid olen tegelenud ka operatsioonis\u00fcsteemide, draiverite, tuumadeb\u00fc\u00fcgide, operatsioonis\u00fcsteemide arendamiseks m\u00f5eldud keelte arendamisega, mis alustasid triviaalsetest, kuid ajaga muutusid j\u00e4rjest keerulisemaks. Kuid p\u00f5hiteema on ikkagi t\u00f6\u00f6riistade arendamine. Suur osa elust kulus Azul ja Sun vahel ja see k\u00e4sitles Java't. Kuid kui sukeldusin Suurandmete ja Masin\u00f5ppe valdkonda, panin taas selga oma piduliku m\u00fctsi ja r\u00e4\u00e4kisin: \u201eOh, n\u00fc\u00fcd on meil tekkinud keeruline probleem ja siin toimub tegelikult hunnik huvitavaid asju ja inimesi, kes midagi teevad\u201c. See on suurep\u00e4rane arengutee, mida tasub l\u00e4bida. <\/p>\n<p><\/p>\n<p>Jah, ma armastan hajusaid arvutusi. Minu esimene t\u00f6\u00f6 oli \u00fclikooli ajal, C keeles, reklaamiprojektiga. Need olid hajusaid arvutusi Zilog Z80 kiipidel, mis kogusid andmeid analoogsete optiliste tekstide \u00e4ratundmise jaoks, mida tegi tegelik analooganal\u00fcsaator. See oli \u00e4ge ja t\u00e4iesti ebatavaline teema. Kuid seal olid probleemid, mingi osa ei olnud \u00f5igesti \u00e4ratuntud, seega oli vajalik pilti v\u00e4lja v\u00f5tta ja n\u00e4idata seda inimesele, kes oli juba silmadega lugenud, ja edastada, mida seal \u00f6eldakse; ja seet\u00f5ttu olid seal andmet\u00f6\u00f6d, ja nendel andmet\u00f6\u00f6d olid oma keel. Oli backend, mis t\u00f6\u00f6tles seda k\u00f5ike \u2013 paralleelselt t\u00f6\u00f6tavad Z80, kus iga\u00fchel olid avatud vt100 terminalid \u2013 \u00fcks inimese kohta, ja Z80-l oli olemas paralleelprogrammeerimise mudel. \u00dcks \u00fchine m\u00e4lut\u00fckk, mida jagasid k\u00f5ik Z80 selle t\u00e4hekujulise konfiguratsiooni sees; jagati nii tagaplaat kui ka pool RAM-i jagati v\u00f5rgu sees, ja veel pool oli privaatne v\u00f5i l\u00e4ks millelegi muule. M\u00f5istlikult keeruline paralleelne hajus s\u00fcsteem jagatud... pool-jagatava m\u00e4luga. Millal see siis oli... Ei oska enam meenutada, kuskil 80ndate keskpaiku. \u00dcsna ammu.\u00a0<br \/>\nJah, oletame, et 30 aastat on piisavalt pikk aeg. Jagatud arvutustega seotud \u00fclesanded on eksisteerinud juba pikka aega, inimesed on ammu nendega v\u00f5idelnud. <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/Beowulf_(%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80)\">Beowulf<\/a><\/noindex>-klastritega. Sellised klastrid n\u00e4evad v\u00e4lja nagu... N\u00e4iteks: sul on Ethernet ja su kiire x86 on \u00fchendatud sellele Ethernetile, ja n\u00fc\u00fcd tahad sa saada vale jagatud m\u00e4lu, sest toona ei saanud keegi tegeleda jagatud arvutuste kodeerimisega, see oli liiga keeruline ja seet\u00f5ttu oli vale jagatud m\u00e4lu koos x86 m\u00e4lu lehek\u00fclgede kaitsega. Ja kui sa kirjutasid sellesse lehek\u00fclge, siis me \u00fctlesime teistele protsessoritele, et kui nad p\u00e4\u00e4sevad juurde sellele samale jagatud m\u00e4lule, tuleb see selt sinult laadida. Nii tekkis midagi, mis meenutas vahem\u00e4lu koherentsuse toetamise protokolli ja tarkvara selle jaoks. Huvitav kontseptsioon. Tegelik probleem oli muidugi midagi muud. K\u00f5ik see toimis, kuid sa said kiiresti tootlikkuse probleemide osaliseks, sest keegi ei m\u00f5istnud tootlikkuse mudelit piisavalt h\u00e4sti \u2013 millised olid m\u00e4lule p\u00e4\u00e4su mustrid, kuidas v\u00e4ltida, et node'id pidevalt \u00fcksteist ei pingsaks, ja nii edasi. <\/p>\n<p><\/p>\n<p>H2O-s ma m\u00f5tlesin j\u00e4rgmist: arendajad vastutavad selle eest, et m\u00e4\u00e4rata, kus peitub paralleelsus ja kus seda ei ole. Olen loonud sellise kodeerimise mudeli, et k\u00f5rgetasemelise koodi kirjutamine on lihtne ja mugav. Kuid aeglaselt t\u00f6\u00f6tava koodi kirjutamine on keeruline ning see n\u00e4eb halb v\u00e4lja. Aeglase koodi kirjutamiseks tuleb t\u00f5siselt pingutada, tuleb kasutada mittestandardsed meetodeid. Aeglane kood on esmapilgul silmatorkav. Seet\u00f5ttu kirjutatakse tavaliselt kood, mis t\u00f6\u00f6tab kiiresti, kuid tuleb m\u00f5ista, mida teha jagatud m\u00e4lu korral. K\u00f5ik see on seotud suurte massiividega ja seal k\u00e4itumine sarnaneb mittevolatiilsete suurte massiividega paralleelses Javas. Kujutage ette, et kaks l\u00f5ime kirjutavad paralleelsesse massiivi, \u00fcks neist v\u00f5idab ja teine loomulikult kaotab, ja te ei tea, kes neist on kes. Kui nad ei ole volatiilsed, siis v\u00f5ib j\u00e4rjekord olla suvaline \u2013 ja see t\u00f6\u00f6tab t\u00f5eliselt h\u00e4sti. Inimesed t\u00f5eliselt hoolivad operatsioonide j\u00e4rjekorrast, nad paigutavad \u00f5igesti volatile ja \u00f5igetes kohtades ootavad nad probleemidega seonduvat j\u00f5udluses, mis on seotud m\u00e4luga. Vastupidisel juhul kirjutaksid nad lihtsalt koodi ts\u00fcklitena alates 1 kuni N, kus N on m\u00f5ned triljonid, lootes, et k\u00f5ik keerulised juhtumid muutuvad automaatselt paralleelseks \u2013 ja seal see ei toimi. Kuid H2O ei ole see ei Java ega Scala, seda v\u00f5ib pidada \u201eJava miinus miinus\u201d, kui soovite. See on v\u00e4ga arusaadav programmis stiil ja sarnaneb lihtsa koodi kirjutamisega C v\u00f5i Java keeles ts\u00fcklite ja massiividega. Samas v\u00f5ib m\u00e4lu t\u00f6\u00f6delda terabaitide kaupa. Kasutan H2O-d ikka veel. Aeg-ajalt kasutan seda erinevates projektides \u2013 ja see on endiselt k\u00f5ige kiireim lahendus, k\u00fcmneid kordi konkurentidest ees. Kui teete Big Data-d veergandmetega, on H2O-d v\u00e4ga raske \u00fcletada.<\/p>\n<p><\/p>\n<h1 id=\"tehnicheskie-chellenzhi\">Tehnilised v\u00e4ljakutsed<\/h1>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Milline on olnud teie karj\u00e4\u00e4ri jooksul k\u00f5ige suurem v\u00e4ljakutse?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Kas arutame tehnilist v\u00f5i mitte-tehnilist osa? \u00dctleksin, et k\u00f5ige suuremad v\u00e4ljakutsed on mitte-tehnilised.\u00a0<br \/>\nMis osas on tehnilised v\u00e4ljakutsed. Ma lihtsalt v\u00f5itsin nad. Ma isegi ei tea, mis neist k\u00f5ige suurem oli, aga neid oli mitu \u00fcsna huvitavat, millele kulus palju aega ja vaimset pingutust. Kui ma l\u00e4ksin Suni, olin kindel, et suudan teha kiire kompilaatori, kuid hulk vanemaid arendajaid \u00fctlesid, et mul ei \u00f5nnestu kunagi. Ent ma l\u00e4ksin selle teedpidi, kirjutasin kompilaatori kuni registrite jaotajani ning see oli p\u00e4ris kiire. Ta oli sama kiire kui kaasaegne C1, kuid toona oli jaotaja palju aeglasem ja tagantj\u00e4rele vaadates - see oli suurte andmestruktuuride probleem. Mul oli neid vaja, et kirjutada graafiline registrite jaotaja ning ma ei m\u00f5istnud dilemmat, mis tekkis koodi v\u00e4ljendatavuse ja kiirusena, mis eksisteeris sellel ajal ja oli v\u00e4ga oluline. Selgus, et andmestruktuur \u00fcletas 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. <\/p>\n<p><\/p>\n<p>Aeg m\u00f6\u00f6dus, kompilaator muutus j\u00e4rjest t\u00e4psemaks ja t\u00f5husamaks, l\u00f5petas \u00fcha enam halbade koodide genereerimise ning j\u00f5udlus hakkas j\u00e4rjest rohkem meenutama C kompilaatori v\u00e4ljundit. 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\u00f5udluse palju sagedamini. Ja mida edasi, seda rohkem saadi kood, mis as\u00fcmptootiliselt sarnanes C tasemega, registrite allocator hakkas meenutama midagi t\u00e4iustatud\u2026 s\u00f5ltumata sellest, kas su kood t\u00f6\u00f6tas kiiresti v\u00f5i aeglaselt. J\u00e4tkasin registrite allocatori t\u00e4iustamist, et see teeks paremaid eraldamisi. See muutus aeglasemaks ja aeglasemaks, aga andis j\u00e4rjest paremat j\u00f5udlust olukordades, kus kedagi teist enam ei aidanud. Ma sain sukelduda registrite allocatorisse, kaevata sinna kuu aega t\u00f6\u00f6d ja \u00fcht\u00e4kki hakkas kogu kood t\u00f6\u00f6tama 5% kiiremini. See juhtus korduvalt ja registrite allocatorist sai midagi kunstiteose sarnast \u2013 k\u00f5ik armastasid v\u00f5i vihkasid seda, ja akadeemia inimesed k\u00fcsisid k\u00fcsimusi, nagu 'miks k\u00f5ik just nii toimub', miks mitte <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Register_allocation#Linear_Scan\">lineaarne skaneerimine<\/a><\/noindex>, ja milles on vahe. Vastus on endiselt sama: graafiv\u00e4rvimise p\u00f5hine allocator pluss v\u00e4ga hoolikas vahetuskoodiga t\u00f6\u00f6tamine on v\u00f5idurelv, parim kombinatsioon, mida keegi ei suuda v\u00f5ita. Ja see on tegelikult \u00fcsna ebaselge asi. K\u00f5ik muu, mida seal kompilaator teeb \u2013 need on \u00fcsna 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 \u2013 v\u00e4lja arvatud registerallocator. Fokus on selles, et tuleb hoolikalt <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Register_allocation\">\u00fchendada<\/a><\/noindex> koormuse all ja kui see juhtub (ma saan selgitada p\u00f5hjalikumalt, kui see huvitab), t\u00e4hendab see, et saab inline'ida agressiivsemalt, ilma et oleks ohtu \u00fcletada j\u00f5udluse graafiku murdumist. Sel ajal oli palju t\u00e4islahendusega kompilaatoreid, mis olid kaunistatud igasuguste vidinate ja trikkidega, kus olid register allocatorid, kuid keegi ei suutnud enam nii teha. <\/p>\n<p><\/p>\n<p>Probleem on selles, et kui lisad meetodeid, mis on inline'imiseks sobivad, suurendades ja suurendades inline'imise ala, siis kasutatavate v\u00e4\u00e4rtuste hulk \u00fcletab kiiresti registrite arvu ja pead hakkama osasid eemaldama. Kriitiline tase saavutatakse tavaliselt siis, kui allocator loobub, ning \u00fcks hea splittimise kandidaat maksab rohkem kui teine, mist\u00f5ttu pead eemaldama t\u00e4iesti ootamatuid asju. Inline'imise v\u00e4\u00e4rtus seisneb selles, et kaotad osa overhead'ist, mis tuleneb kutsumisest ja salvestamisest, sa n\u00e4ed v\u00e4\u00e4rtusi seestpoolt ja saad neid edasi optimeerida. Inline'imise hind seisneb selles, et tekib suur hulk elavaid v\u00e4\u00e4rtusi, ning kui su registri allocator eemaldab rohkem, kui vajalik, kaotad koheselt. Seep\u00e4rast on enamikul allokaatoritest probleem: kui inline'imine \u00fcletab teatud piiri, algavad k\u00f5ik asjad, mis k\u00f5ik toovad kaasa v\u00e4henemise ja tootlikkuse on praktiliselt kadunud. Need, kes teevad kompilaatorit, lisavad teatud t\u00f5en\u00e4osusi: n\u00e4iteks, et peatada inline'imine, alates teatud piisavalt suurest suurusest, kuna k\u00f5ik allokatsioonid m\u00f5jutavad seda. Nii moodustub graafiku h\u00e4ire \u2013 sa inline'id, inline'id, tootlikkus kasvab aeglaselt \u2013 ja siis pauk! \u2013 see kukub j\u00e4rsult alla, kuna oled inline'inud liiga palju. Nii see k\u00f5ik t\u00f6\u00f6tas kuni Java tulekuni. Java n\u00f5uab 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 \u2013 ta hakkab v\u00e4ikeseid eemaldama, kuid siiski tuleb hetk, mil \u201eenam ei ole eemaldamist\u201d. See on huvitav t\u00e4helepanek ja see tuli mulle lihtsalt kuskilt, mitte ilmselgelt, kuid tasus end h\u00e4sti \u00e4ra. Ma alustasin agressiivse inline'imisega ja see viis mind kohtadesse, kus Java ja C tootlikkus k\u00f5rvuti. Nad on t\u00f5eliselt l\u00e4hedased \u2013 ma saan kirjutada Java koodi, mis on oluliselt kiirem kui C kood ja vastavalt sellele, kuid keskmiselt, suures asjade pildis, on nad enam-v\u00e4hem v\u00f5rdsed. Tundub, et osa sellest teenest on registri allocator, mis v\u00f5imaldab mul inline'ida maksimaalselt p\u00f5him\u00f5tteliselt. Ma lihtsalt inline'in k\u00f5ik, mida n\u00e4en. K\u00fcsimus on selles, kas allocator t\u00f6\u00f6tab h\u00e4sti ja kas tulemuseks on m\u00f5istlikult t\u00f6\u00f6tav kood. See oli suur v\u00e4ljakutse: k\u00f5ike seda m\u00f5ista ja end t\u00f6\u00f6le panna.<\/p>\n<p><\/p>\n<h1 id=\"nemnogo-pro-allokaciyu-registrov-i-mnogoyadernost\">Veidi registri ja multi-tuumade jaotamisest<\/h1>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Registrite eraldamise probleemid n\u00e4ivad olevat mingi igavese l\u00f5putu teema. Kas on kunagi juhtunud, et mingi idee tundus paljut\u00f5otav, kuid siis kukkus praktikas l\u00e4bi?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Loomulikult! Registererimist edastamine on valdkond, kus p\u00fc\u00fcad NP-t\u00e4ieliku probleemi lahendamiseks leida mingeid heuristilisi meetodeid. Ja sa ei suuda kunagi saavutada ideaalset lahendust, eks? See on lihtsalt v\u00f5imatu. Vaadake, Ahead of Time kompileerimine \u2013 see t\u00f6\u00f6tab samuti halvasti. Jutt k\u00e4ib siin keskmistest juhtudest. T\u00fc\u00fcpilisest j\u00f5udlusest, nii et saad minna ja m\u00f5\u00f5ta midagi, mida pead heaks t\u00fc\u00fcpiliseks j\u00f5udluseks \u2013 l\u00f5puks t\u00f6\u00f6tad ju selle parandamise nimel! Registererimise edastamine on teema, mis on t\u00e4ielikult joonistatud j\u00f5udlusele. Kui sul on esimene protot\u00fc\u00fcp, mis t\u00f6\u00f6tab ja v\u00e4rvib vajamineva, siis algab t\u00f6\u00f6 j\u00f5udluse nimel. Pead \u00f5ppima, kuidas h\u00e4sti m\u00f5\u00f5ta. Miks see on oluline? Kui on selged andmed, saad vaadata erinevaid osi ja n\u00e4ha: aha, see aitas siin, aga seal k\u00f5ik kukkus kokku! Tulevad m\u00f5ned head ideed, sa lisad uue heuristika ja \u00e4kki k\u00f5ik hakkab keskmiselt veidi paremini t\u00f6\u00f6le. V\u00f5i ei hakka. Mul on olnud sadu juhtumeid, kus me v\u00f5itlesime viie protsendi j\u00f5udluse nimel, mis eraldas meie lahendust eelnevatest registererijatest. Ja iga kord n\u00e4eb see v\u00e4lja nii: kusagil tuli v\u00f5it, kusagil kaotus. Kui sul on head j\u00f5udlusanal\u00fc\u00fcsi t\u00f6\u00f6riistad, saad leida kaotavad ideed ja m\u00f5ista, miks nad kaotavad. V\u00f5ib-olla tasub k\u00f5ik j\u00e4tta nii, nagu on, v\u00f5i v\u00f5tad t\u00f5sisemalt ette peenh\u00e4\u00e4lestuse, v\u00f5i l\u00e4hed ja parandad midagi muud. See on terve hulk asju! Ma tegin selle laheda h\u00e4ki, aga mul on vaja ka seda, seda ja seda \u2013 ja nende kogumine annab teatud parendusi. \u00dcksikud ideed v\u00f5ivad kukkuda. Nii see on NP-t\u00e4ielike probleemide j\u00f5udlusega t\u00f6\u00f6tamise loomuses.<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Tundub, et asjad nagu allocators'ite v\u00e4rvimine on juba lahendatud \u00fclesanne. Noh, teie jaoks on see lahendatud, arvestades, mida te r\u00e4\u00e4gite, kas siis tasub \u00fcldse\u2026<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: See ei ole lahendatud nagu selline. Sina pead selle 'lahendatud' muutma. On keerulisi \u00fclesandeid ja need tuleb lahendada. Kui see on tehtud, on aeg keskenduda tootlikkusele. Sellele \u00fclesandele tuleb l\u00e4heneda vastavalt \u2013 teha m\u00f5\u00f5tmisi, koguda statistikat, selgitada olukordi, kui tagasiviimisega eelmisele versioonile su vana nipp j\u00e4lle t\u00f6\u00f6le hakkas (v\u00f5i vastupidi, lakkas t\u00f6\u00f6tamast). Ja mitte loobuda, kuni millegi saavutad. Nagu ma juba \u00fctlesin, kui \u00e4gedad ideed, mis ei toiminud, siis ideede valdkonnas on registreerimisvahendites umbkaudu l\u00f5pmatu. N\u00e4iteks v\u00f5ib lugeda teaduslikke publitseeringuid. Kuigi t\u00e4na on see valdkond liikunud aeglasemalt ja on selgem kui oma nooruses. Sellegipoolest on seal tohutu hulk inimesi t\u00f6\u00f6le ja k\u00f5ik nende ideed v\u00e4\u00e4rivad proovimist; k\u00f5ik ootavad oma aega. Ja sa ei saa \u00f6elda, kui head need on, kui sa neid ei proovi. Kui h\u00e4sti need integreeruvad k\u00f5igega muuga sinu allokatsioonis, sest allokaator teeb palju erinevaid asju, ja m\u00f5ned ideed sinu spetsiifilises allokaatoris ei t\u00f6\u00f6ta, aga teises allokaatoris \u2013 kergelt. Peamine viis allokaatori v\u00f5itmiseks on aeglane jama p\u00f5hiteest v\u00e4lja t\u00f5mmata ja sundida jagama aeglaste teede piiridel. Seega, kui sa tahad GC-d k\u00e4ivitada, minna aeglast teed, deoptiimiseerida, v\u00e4lja visata erandi, k\u00f5ik sellelaadsed asjad \u2013 sa tead, et need asjad on suhteliselt haruldased. Ja nad on t\u00f5epoolest haruldased, ma kontrollisin. Sa teed lisat\u00f6\u00f6d ja t\u00e4nu sellele kaovad paljud piirangud nendel aeglastel teedel, kuid see ei ole v\u00e4ga oluline, sest need on aeglased ja nendel harva k\u00e4iakse. N\u00e4iteks nullviit \u2013 see ei juhtu kunagi, eks? Peab olema mitu teed erinevate asjade jaoks, kuid nad ei tohiks peamise teega seguneda.\u00a0<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Mida arvate palju tuumade kohta, kui tuumi on kohe tuhandeid? Kas see on kasulik asi?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: GPU edu n\u00e4itab, et see on t\u00f5eliselt kasulik!<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Need on \u00fcsna spetsialiseeritud. Aga mis saamoodust on \u00fcldotstarbelised protsessorid?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Noh, see oli Azul'i \u00e4rimudel. Vastus tuli juba ajal, mil inimesed armastasid v\u00e4ga ettearvatavat j\u00f5udlust. Sel ajal oli parallelkoodi kirjutamine keerukam. H2O koodimudel skaleerub h\u00e4sti, kuid see ei ole \u00fcldotstarbeline mudel. Vaevu, et natuke \u00fcldisem kui GPU kasutamisel. Kas me r\u00e4\u00e4gime sellise asja arendamise keerukusest v\u00f5i selle kasutamise keerukusest? N\u00e4iteks, huvitav \u00f5ppetund, mille Azul mulle \u00f5petas, oli see, et v\u00e4ikesed vahem\u00e4lud on t\u00e4iesti normaalsed.\u00a0<\/p>\n<p><\/p>\n<h1 id=\"samyy-bolshoy-chellenzh-v-zhizni\">Elu suurim v\u00e4ljakutse<\/h1>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Kuidas on lood mitte tehniliste v\u00e4ljakutsetega?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Suurim v\u00e4ljakutse oli mitte olla... lahke ja hea inimestega. Selle tagaj\u00e4rjel sattusin pidevalt \u00e4\u00e4rmiselt konfliktsetesse olukordadesse. Nendes olukordades teadsin, et k\u00f5ik l\u00e4heb valesti, kuid ma ei teadnud, kuidas edasi liikuda nende probleemide lahendamisel ja ei suudnud nendega toime tulla. Palju pikaajalisi probleeme, mis kestsid k\u00fcmneid aastaid, tekkis just niimoodi. See, et Java-s on C1 ja C2 kompilaatorid, on selle otsene tagaj\u00e4rg. Samuti on see, et Java-s ei olnud k\u00fcmme aastat j\u00e4rjest mitmeastmelist kompileerimist, samuti otsene tagaj\u00e4rg. On ilmne, et meil oli selline s\u00fcsteem vajalik, kuid mitte ilmne, miks seda ei olnud. Mul olid probleemid \u00fche inseneriga... v\u00f5i inseneride grupiga. Aegade alguses, kui alustasin t\u00f6\u00f6d Sunis, olin... Okei, mitte ainult siis, mul on tegelikult alati oma arvamus. Ja ma pidasin t\u00f5eks, et v\u00f5in lihtsalt oma t\u00f5de otse v\u00e4lja \u00f6elda. Eriti kuna ma olin \u0161okeerivalt \u00f5ige suure osa ajast. Ja kui selline l\u00e4henemine sulle ei meeldi... eriti kui sa ilmselgelt eksid ja teed jama... \u00dcldiselt suudavad v\u00e4hesed inimesed taluda sellist suhtlemisviisi. Kuigi m\u00f5ned suudavad, n\u00e4iteks mina. Olen kogu oma elu ehitanud meritokraatlikele p\u00f5him\u00f5tetele. Kui sa n\u00e4itad mulle midagi vale, siis p\u00f6\u00f6rdun ma kohe ringi ja \u00fctlen: sa \u00fctlesid jama. Samuti vabandan ja k\u00f5ike muud, tunnustan saavutusi, kui neid \u00fcldse on, ja teen teisi \u00f5igeid samme. Teisest k\u00fcljest olen ma \u0161okeerivalt \u00f5ige \u0161okeerivalt suure protsendi kogu ajast. Ja see ei t\u00f6\u00f6ta inimeste suhete osas eriti h\u00e4sti. Ma ei \u00fcrita olla armas, vaid panen k\u00fcsimuse teravaks. 'See ei hakka kunagi t\u00f6\u00f6le, sest \u00fcks, kaks ja kolm.' Ja nemad: 'Oho!'. Oli ka teisi tagaj\u00e4rgi, mida oleks parem ilmselt vahele j\u00e4tta: n\u00e4iteks abielu lahutamine ja k\u00fcmme aastat kestnud depressioon p\u00e4rast seda.<\/p>\n<p><\/p>\n<p>V\u00e4ljakutse on v\u00f5itlus inimeste ja nende arusaamaga sellest, mida sa saad v\u00f5i ei saa teha, mis on oluline ja mis mitte. On olnud palju v\u00e4ljakutseid kodeerimisstiili \u00fcle. Ma kirjutan endiselt palju koodi ja tookord pidin isegi aeglustuma, sest tegin liiga palju paralleelseid \u00fclesandeid ja tegin neid halvasti, selle asemel et keskenduda \u00fchele. Kahe peale vaadates kirjutasin ma poole Java JIT meeskonna koodist, C2 meeskonnast. J\u00e4rgmine kiiruselt kodeerija kirjutas pool aeglasemalt, j\u00e4rgmine veel pool aeglasemalt ja see oli eksponentsiaalne langus. Seitsmes inimene selles reas oli v\u00e4ga, v\u00e4ga aeglane \u2013 nii see alati on! Ma puutusin kokku hulga koodiga. Ma vaatasin, kes mida kirjutab, ilma eranditeta, ma kammisin nende koodi, vaatasin k\u00f5iki \u00fcle ja j\u00e4tkasin ise rohkem koodi kirjutamist, kui \u00fckski neist. Inimestega selline l\u00e4henemine ei toimi h\u00e4sti. M\u00f5ned ei meeldi sellele. Ja kui nad ei suuda sellega toime tulla, algavad igasugused pretensioonid. N\u00e4iteks \u00fchel p\u00e4eval \u00f6eldi mulle, et l\u00f5petan koodi kirjutamise, sest ma kirjutan liiga palju koodi, ja see seab meeskonna ohtu, ja minu jaoks k\u00f5las see k\u00f5ik nagu nali: mees, kui kogu \u00fclej\u00e4\u00e4nud meeskond kaob ja ma j\u00e4tkan koodi kirjutamist, kaotad ainult poole meeskonnast. Teiselt poolt, kui ma j\u00e4tkan koodi kirjutamist ja sa kaotad poole meeskonnast \u2013 see k\u00f5lab nagu v\u00e4ga halb juhtimine. Ma ei ole kunagi t\u00f5eliselt selle \u00fcle m\u00f5elnud, ma ei ole kunagi seda maininud, aga see oli ikkagi kuskil mu peas. Teadvuse tagak\u00fcljel keerles m\u00f5te: \u201eKas te k\u00f5ik naljatate?\u201c. Nii et suurim probleem olin mina ja minu suhted inimestega. N\u00fc\u00fcd m\u00f5istan ennast palju paremini, ma juhtisin pikka aega programmeerijate tiimi, ja n\u00fc\u00fcd \u00fctlen inimestele otse: tead, ma olen selline nagu olen, ja teil tuleb sellega toime tulla \u2013 ei ole midagi, kui ma siin seisan? Ja kui nad hakkasid sellega toime tulema, hakkas k\u00f5ik t\u00f6\u00f6le. Ma ei ole tegelikult halb ega hea, mul ei ole halbu kavatsusi ega egoistlikke p\u00fc\u00fcdeid, see on lihtsalt minu olemus, ja see on millegagi elama peab.<\/p>\n<p><\/p>\n<p><strong>Andrei<\/strong>: Viimasel ajal on k\u00f5ik hakanud r\u00e4\u00e4kima introvertide eneseteadvusest ja \u00fcldiselt pehmetest oskustest. Mida selle kohta \u00f6elda?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Jah, see oli arusaamine ja \u00f5ppetund, mille ma sain abikaasast lahkumisest. Mida ma selle lahutuse k\u00e4igus sain, on enese m\u00f5istmine. Nii hakkasin ma m\u00f5istma ka teisi inimesi. M\u00f5istma, kuidas see suhtlemine toimib. See viis avastusteni, mis tulid \u00fcksteise j\u00e4rel. Selgus, kes ma olen ja mida endast kujutan. Mida ma teen: kas ma olen \u00fclesande p\u00e4rast mures, v\u00f5i v\u00e4ldin konflikti, v\u00f5i midagi muud \u2013 ja selline eneseteadvuse tase aitab t\u00f5eliselt end kontrolli all hoida. P\u00e4rast seda l\u00e4heb k\u00f5ik palju lihtsamalt. \u00dcks asi, mille olen avastanud mitte ainult enda, vaid ka teiste programmeerijate puhul, on v\u00f5imetus s\u00f5nadega m\u00f5tteid v\u00e4ljendada, kui oled emotsionaalses stressis. N\u00e4iteks, istud ja koodid, oled voos, ja siis tulevad inimesed ja hakkavad h\u00fcsteeriliselt karjuma, et midagi on katki, ja n\u00fc\u00fcd rakendatakse sinu suhtes \u00e4\u00e4rmuslikke meetmeid. Ja sa ei suuda isegi s\u00f5na \u00f6elda, sest oled emotsionaalses stressis. Saadud teadlikkus aitab valmistuda selleks hetkel, kogeda seda ja liikuda tagasiastumisplaani, p\u00e4rast mida saad juba midagi teha. Nii et jah, kui hakkad m\u00f5istma, kuidas see k\u00f5ik t\u00f6\u00f6tab \u2013 on see suur, elu muutav s\u00fcndmus.\u00a0<br \/>\nMa ei suutnud ise \u00f5igesti s\u00f5nu leida, kuid m\u00e4letan tegevuste j\u00e4rjestust. Asjaolu on selles, et see reaktsioon on sama f\u00fc\u00fcsiline kui verbaalne, ja sul on vaja ruumi. Sellist ruumi, zen'i m\u00f5ttes. Just seda tuleb seletada ja seej\u00e4rel kohe k\u00f5rvale astuda \u2013 puhtalt f\u00fc\u00fcsiliselt. Kui ma s\u00f5nades vaiksen, saan olukorda emotsioonide osas t\u00f6\u00f6tleda. Kui adrenaliin j\u00f5uab ajju, l\u00fclitab see sind 'l\u00f6\u00f6k v\u00f5i p\u00f5gene\u2019 re\u017eiimi, sa ei saa enam midagi \u00f6elda, ei \u2013 n\u00fc\u00fcd oled sa idioot, l\u00f6\u00f6miseks m\u00f5eldud insener, kes ei suuda v\u00e4\u00e4rikat vastust anda ega isegi r\u00fcnnakut peatada, ning r\u00fcndaja v\u00f5ib vabalt korduvalt r\u00fcnnata. Alustuseks pead j\u00e4lle iseendaks saama, kontrolli tagasi saama, 'l\u00f6\u00f6k v\u00f5i p\u00f5gene\u2019 re\u017eiimist v\u00e4lja astuma. <\/p>\n<p><\/p>\n<p>Ja selleks on vajalik verbaalne ruum. Lihtsalt vabalt ruumi. Kui \u00fcldse midagi \u00f6elda, siis v\u00f5ib just seda v\u00e4ljendada ja seej\u00e4rel minna t\u00f5eliselt leidma endale \"ruumi\": minna jalutama parki, sulguda du\u0161i alla \u2013 see ei ole oluline. Peamine on ajutiselt olukorrast lahti saada. Kui suudad v\u00e4hemalt m\u00f5neks sekundiks v\u00e4lja l\u00fclituda, tuleb kontroll tagasi, hakkad m\u00f5tlema selgemalt. \"Hea k\u00fcll, ma ei ole mingi idioot, ma ei tee lolluseid, ma olen p\u00e4ris kasulik inimene.\" Kui oled suutnud end veenda, on aeg liikuda j\u00e4rgmisele etapile: m\u00f5ista, mis juhtus. Sulle r\u00fcnnati, r\u00fcnnak tuli ootamatult, see oli ebaaus ja madal l\u00f5ks. See on halb. J\u00e4rgmine samm on m\u00f5ista, miks r\u00fcndaja seda tegi. T\u00f5eliselt, miks? V\u00f5ib-olla sellep\u00e4rast, et ta on ise vihane? Miks ta on vihane? N\u00e4iteks sellep\u00e4rast, et ta on ise eksinud ja ei suuda vastutust v\u00f5tta? Just niimoodi tuleb olukord ettevaatlikult muuta. Kuid selleks on vajalik man\u00f6\u00f6verdusruum, verbaalne ruum. K\u00f5ige esimene samm on katkestada verbaalne kontakt. Lahkuda arutelust s\u00f5nades. T\u00fchistada see, minna minema nii kiiresti kui v\u00f5imalik. Kui see on telefonik\u00f5ne \u2013 pane lihtsalt toru \u00e4ra \u2013 see on oskus, mille olen saanud endise naisest suhtlemisest. Kui vestlus ei vii kuhugi heasse kohta, \u00fctle lihtsalt \"n\u00e4gemiseni\" ja pane toru \u00e4ra. Teiselt poolt toru: \"bla-bla-bla\", sa vastad: \"aah, keda huvitab!\" ja paned toru \u00e4ra. Lihtsalt katkestad vestluse. Viie minuti p\u00e4rast, kui su v\u00f5ime ratsionaalselt m\u00f5elda tagasi tuleb, ja sa natuke jahtud, on v\u00f5imalik m\u00f5elda, mis \u00fcldse juhtus ja mis edasi toimub. Ja alustada m\u00f5testatud vastuse koostamist, mitte lihtsalt reageerida emotsioonidele. Minu jaoks oli iseteadvuses l\u00e4bimurre just see, et emotsionaalses stressis ma ei saa r\u00e4\u00e4kida. V\u00e4lja minna sellest seisundist, m\u00f5elda ja planeerida, kuidas vastata ja probleeme kompenseerida \u2013 need on \u00f5iged sammud olukordades, kus sa ei saa r\u00e4\u00e4kida. K\u00f5ige lihtsam viis on p\u00f5geneda olukorrast, kus emotsionaalne stress avaldub, ja lihtsalt l\u00f5petada selles stressis osalemine. P\u00e4rast seda saad tagasi m\u00f5tlema hakata, kui su m\u00f5te t\u00f6\u00f6le hakkab, tekib v\u00f5imalus r\u00e4\u00e4kida ja nii edasi.<\/p>\n<p><\/p>\n<p>\u00dcks t\u00e4htis asi on see, et kohtus \u00fcritab vastaspoole advokaat seda sinuga teha \u2013 n\u00fc\u00fcd on juba selge, miks. Sest tal on v\u00f5imalus sind survestada sellisesse seisundisse, et sa ei suuda isegi oma nime v\u00e4lja \u00f6elda, n\u00e4iteks. K\u00f5ige otsesemas m\u00f5ttes, sa ei suuda r\u00e4\u00e4kida. Kui sinuga juhtub midagi sellist ja tead, et satud kohta, kus s\u00f5nalised lahingud k\u00e4ivad, n\u00e4iteks kohtusse, siis on m\u00f5istlik tulla oma advokaadiga. Advokaat kaitseb sind ja peatab s\u00f5nalise r\u00fcnnaku, ning teeb seda t\u00e4iesti seaduslikul viisil, ning sul taastub kaotatud zen-ruum. N\u00e4iteks, mul oli paar korda vaja perekonnale helistada, kohtunik suhtus sellesse \u00fcsna s\u00f5bralikult, kuid vastaspoole advokaat karjus ja karjus mu peale, ma ei suutnud isegi s\u00f5na sisse tuua. Sellistes olukordades toimib minu jaoks k\u00f5ige 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\u00e4\u00e4kimise v\u00f5ime. See on terve teadmiste valdkond, kus tuleb palju \u00f5ppida, palju enda seest avastada, ning k\u00f5ik see muutub k\u00f5rgetasemelisteks strateegilisteks otsusteks, mis on erinevad erinevate inimeste jaoks. M\u00f5nel inimesel pole \u00fclaltoodud probleeme, tavaliselt pole neid inimestel, kes tegelevad kutseliselt m\u00fc\u00fcgiga. K\u00f5ik need inimesed, kes teenivad elatist s\u00f5nadega \u2013 tuntud lauljad, luuletajad, usujuhid ja poliitikud, neil on alati, mida \u00f6elda. Neil pole selliseid probleeme, aga mul need on.<\/p>\n<p><\/p>\n<p><strong>Andrei<\/strong>: See oli\u2026 ootamatu. Suurep\u00e4rane, me oleme juba piisavalt juttu ajanud ja on aeg see intervjuu l\u00f5petada. Me kohtume kindlasti konverentsil ja saame seda dialooge j\u00e4tkata. Kohtume Hydral!<\/p>\n<p><\/p>\n<blockquote><p>Kliiffiga saab vestlust j\u00e4tkata konverentsil Hydra 2019, mis toimub 11-12. juulil 2019 Peterburis. Ta tuleb oma ettekandega <noindex><a rel=\"nofollow\" href=\"https:\/\/hydraconf.com\/2019\/talks\/2jix5mst7iduyp9linqhfj\/?utm_source=habr&amp;utm_medium=45871\">\u00abAzul Hardware Transactional Memory kogemus\u00bb<\/a><\/noindex>. Pileteid saab osta <noindex><a rel=\"nofollow\" href=\"https:\/\/hydraconf.ru\/?utm_source=habr&amp;utm_medium=458718\">ametlikul veebilehelt<\/a><\/noindex>.<\/p><\/blockquote>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/jugru\/blog\/458718\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041a\u043b\u0438\u0444\u0444 \u041a\u043b\u0438\u043a \u2014 CTO \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Cratus (IoT \u0441\u0435\u043d\u0441\u043e\u0440\u044b \u0434\u043b\u044f \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432), \u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0441\u043e\u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0441\u0442\u0430\u0440\u0442\u0430\u043f\u043e\u0432 (\u0432\u043a\u043b\u044e\u0447\u0430\u044f Rocket Realtime School, Neurensic \u0438 H2O.ai) \u0441 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c\u0438 \u0443\u0441\u043f\u0435\u0448\u043d\u044b\u043c\u0438 \u044d\u043a\u0437\u0438\u0442\u0430\u043c\u0438. \u041a\u043b\u0438\u0444\u0444 \u043d\u0430\u043f\u0438\u0441\u0430\u043b \u0441\u0432\u043e\u0439 \u043f\u0435\u0440\u0432\u044b\u0439 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440 \u0432 15 \u043b\u0435\u0442 (Pascal \u0434\u043b\u044f TRS Z-80)! \u041d\u0430\u0438\u0431\u043e\u043b\u0435\u0435 \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u0437\u0430 \u0440\u0430\u0431\u043e\u0442\u0443 \u043d\u0430\u0434 \u04212 \u0432 Java (the Sea of Nodes IR). \u042d\u0442\u043e\u0442 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440 \u043f\u043e\u043a\u0430\u0437\u0430\u043b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35851","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u043b\u0438\u0444\u0444 \u041a\u043b\u0438\u043a \u2014 CTO \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Cratus (IoT \u0441\u0435\u043d\u0441\u043e\u0440\u044b \u0434\u043b\u044f \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432), \u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0441\u043e\u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0441\u0442\u0430\u0440\u0442\u0430\u043f\u043e\u0432 (\u0432\u043a\u043b\u044e\u0447\u0430\u044f Rocket Realtime School, Neurensic \u0438 H2O.ai) \u0441 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c\u0438 \u0443\u0441\u043f\u0435\u0448\u043d\u044b\u043c\u0438 \u044d\u043a\u0437\u0438\u0442\u0430\u043c\u0438. \u041a\u043b\u0438\u0444\u0444 \u043d\u0430\u043f\u0438\u0441\u0430\u043b \u0441\u0432\u043e\u0439 \u043f\u0435\u0440\u0432\u044b\u0439 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440 \u0432 15 \u043b\u0435\u0442 (Pascal \u0434\u043b\u044f TRS Z-80)! \u041d\u0430\u0438\u0431\u043e\u043b\u0435\u0435 \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u0437\u0430 \u0440\u0430\u0431\u043e\u0442\u0443 \u043d\u0430\u0434 \u04212 \u0432 Java (the Sea of Nodes IR). \u042d\u0442\u043e\u0442 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440 \u043f\u043e\u043a\u0430\u0437\u0430\u043b\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0411\u043e\u043b\u044c\u0448\u043e\u0435 \u0438\u043d\u0442\u0435\u0440\u0432\u044c\u044e \u0441 \u041a\u043b\u0438\u0444\u0444\u043e\u043c \u041a\u043b\u0438\u043a\u043e\u043c \u2014 \u043e\u0442\u0446\u043e\u043c JIT-\u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0446\u0438\u0438 \u0432 Java | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041a\u043b\u0438\u0444\u0444 \u041a\u043b\u0438\u043a \u2014 CTO \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Cratus (IoT \u0441\u0435\u043d\u0441\u043e\u0440\u044b \u0434\u043b\u044f \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432), \u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0441\u043e\u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0441\u0442\u0430\u0440\u0442\u0430\u043f\u043e\u0432 (\u0432\u043a\u043b\u044e\u0447\u0430\u044f Rocket Realtime School, Neurensic \u0438 H2O.ai) \u0441 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c\u0438 \u0443\u0441\u043f\u0435\u0448\u043d\u044b\u043c\u0438 \u044d\u043a\u0437\u0438\u0442\u0430\u043c\u0438. \u041a\u043b\u0438\u0444\u0444 \u043d\u0430\u043f\u0438\u0441\u0430\u043b \u0441\u0432\u043e\u0439 \u043f\u0435\u0440\u0432\u044b\u0439 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440 \u0432 15 \u043b\u0435\u0442 (Pascal \u0434\u043b\u044f TRS Z-80)! \u041d\u0430\u0438\u0431\u043e\u043b\u0435\u0435 \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u0437\u0430 \u0440\u0430\u0431\u043e\u0442\u0443 \u043d\u0430\u0434 \u04212 \u0432 Java (the Sea of Nodes IR). \u042d\u0442\u043e\u0442 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440 \u043f\u043e\u043a\u0430\u0437\u0430\u043b\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:07:03+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:07:03+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Suur intervjuu Kliiff Kliigiga \u2014 JIT-kompileerimise isa Java-s | ProHoster","description":"Kliiff Klik on ettev\u00f5tte Cratus (IoT sensorid protsesside parandamiseks) CTO, mitme idufirma kaasasutaja ja asutaja (sealhulgas Rocket Realtime School, Neurensic ja H2O.ai) mitmete edukate v\u00e4ljap\u00e4\u00e4sudega. Kliiff kirjutas oma esimese kompilaatori 15-aastaselt (Pascal TRS Z-80 jaoks)! Ta on tuntud oma t\u00f6\u00f6 eest Java C2 peal (the Sea of Nodes IR). See kompilaator n\u00e4itas","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0411\u043e\u043b\u044c\u0448\u043e\u0435 \u0438\u043d\u0442\u0435\u0440\u0432\u044c\u044e \u0441 \u041a\u043b\u0438\u0444\u0444\u043e\u043c \u041a\u043b\u0438\u043a\u043e\u043c \u2014 \u043e\u0442\u0446\u043e\u043c JIT-\u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0446\u0438\u0438 \u0432 Java | ProHoster","og:description":"\u041a\u043b\u0438\u0444\u0444 \u041a\u043b\u0438\u043a \u2014 CTO \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Cratus (IoT \u0441\u0435\u043d\u0441\u043e\u0440\u044b \u0434\u043b\u044f \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432), \u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0441\u043e\u043e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0441\u0442\u0430\u0440\u0442\u0430\u043f\u043e\u0432 (\u0432\u043a\u043b\u044e\u0447\u0430\u044f Rocket Realtime School, Neurensic \u0438 H2O.ai) \u0441 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c\u0438 \u0443\u0441\u043f\u0435\u0448\u043d\u044b\u043c\u0438 \u044d\u043a\u0437\u0438\u0442\u0430\u043c\u0438. \u041a\u043b\u0438\u0444\u0444 \u043d\u0430\u043f\u0438\u0441\u0430\u043b \u0441\u0432\u043e\u0439 \u043f\u0435\u0440\u0432\u044b\u0439 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440 \u0432 15 \u043b\u0435\u0442 (Pascal \u0434\u043b\u044f TRS Z-80)! \u041d\u0430\u0438\u0431\u043e\u043b\u0435\u0435 \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u0437\u0430 \u0440\u0430\u0431\u043e\u0442\u0443 \u043d\u0430\u0434 \u04212 \u0432 Java (the Sea of Nodes IR). \u042d\u0442\u043e\u0442 \u043a\u043e\u043c\u043f\u0438\u043b\u044f\u0442\u043e\u0440 \u043f\u043e\u043a\u0430\u0437\u0430\u043b","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:07:03+00:00","article:modified_time":"2019-10-31T19:07:03+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35851","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:01:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:55:25","updated":"2026-01-22 01:01:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35851","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=35851"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35851\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=35851"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=35851"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=35851"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}