{"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":"Suurep\u00e4rane intervjuu Cliff Clickiga - JIT-kompileerimise isa Javast","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Suurep\u00e4rane intervjuu Cliff Clickiga - JIT-kompileerimise isa Javast\" src=\"\/wp-content\/uploads\/2019\/07\/9ea9740ef74c0ae14d334482af115222.png\" style=\"display:block;margin: 0 auto;\" \/><strong>Cliff Click<\/strong> \u2014 CTO of Cratus (IoT sensors for process improvement), founder and co-founder of several startups (including Rocket Realtime School, Neurensic, and H2O.ai) with several successful exits. Cliff wrote his first compiler at the age of 15 (Pascal for TRS Z-80)! He is best known for his work on C2 in Java (the Sea of Nodes IR). This compiler showed the world that JIT can produce quality code, which was one of the factors that established Java as one of the major modern software platforms. Later, Cliff helped Azul Systems build an 864-core mainframe with software in pure Java that supported GC pauses on a 500-gigabyte heap within 10 milliseconds. In fact, Cliff has worked on all aspects of the JVM.<br clear=\"all\"><br \/>\n\u00a0<br \/>\nThis Habr post is a comprehensive interview with Cliff. We will discuss the following topics:<\/p>\n<p><\/p>\n<ul>\n<li>Transitioning to low-level optimizations<\/li>\n<li>How to perform a major refactoring<\/li>\n<li>Cost model<\/li>\n<li>Learning low-level optimizations<\/li>\n<li>Practical examples of performance improvements<\/li>\n<li>Why create your own programming language<\/li>\n<li>The career of a performance engineer<\/li>\n<li>Technical challenges<\/li>\n<li>A bit about register allocation and multithreading<\/li>\n<li>The biggest challenge in life<\/li>\n<\/ul>\n<p><\/p>\n<p>The interviewers are:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Andrey Satarin<\/strong> from Amazon Web Services. In his career, he has worked on various projects: testing a distributed NewSQL database at Yandex, a cloud detection system at Kaspersky Lab, a multiplayer game at Mail.ru, and a currency pricing service at Deutsche Bank. He is interested in testing large-scale backend and distributed systems.<\/li>\n<li><strong>Vladimir Sitnikov<\/strong> from Netcracker. He has been working on the performance and scalability of NetCracker OS for ten years \u2014 software used by telecommunications operators to automate network management and equipment processes. He is passionate about Java and Oracle Database performance issues. He is the author of more than a dozen performance improvements in the official PostgreSQL JDBC driver.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"perehod-k-nizkourovnevym-optimizaciyam\">Transitioning to low-level optimizations<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: You are a well-known person in the world of JIT compilation, Java, and performance work in general, are you not?\u00a0<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: That's right!<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Let's start with some general questions about performance work. What do you think about the choice between high-level and low-level optimizations such as CPU-level work?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Siin on k\u00f5ik lihtne. Kiireim kood on see, mis kunagi ei t\u00f6\u00f6ta. Seet\u00f5ttu tuleb alati alustada k\u00f5rge tasemega ja t\u00f6\u00f6tada algoritmide kallal. Parema O-m\u00e4rgise \u00fcletab halvem O-m\u00e4rgise, juhul kui piisavalt suured muutujad ei sekkuma. Madalat taset k\u00e4sitletakse viimasena. T\u00fc\u00fcpiliselt, kui olete kogu \u00fclej\u00e4\u00e4nud nipi piisavalt h\u00e4sti optimeerinud ja on endiselt midagi huvitavat \u2013 siis on see madal tase. Kuid kuidas alustada k\u00f5rge tasemega? Kuidas teada, et olete k\u00f5rgel tasemel piisavalt t\u00f6\u00f6d teinud? No... ei kuidagi. Pole valmis retsepte. Tuleb aru saada probleemist, v\u00e4lja selgitada, mida soovite teha (et mitte teha edasisi tarbetuid samme) ja siis saab lahti v\u00f5tta profilers, mis v\u00f5ib \u00f6elda midagi kasulikku. Teatud hetkel m\u00f5istate, et olete p\u00e4\u00e4senud tarbetutest asjadest ning on aeg tegeleda madala taseme t\u00e4psustamisega. See on kindlasti eriline kunstivorm. Paljud inimesed teevad tarbetuid asju, kuid edasi liikuda nii kiiresti, et neil pole aega j\u00f5udluse p\u00e4rast muretseda. Aga see on seni, kuni k\u00fcsimus ei t\u00f5use esile. T\u00fc\u00fcpiliselt 99% ajast ei huvita kedagi, millega ma tegelen, kuni kriitilisel teel ei teki olulist asja, mis kellelegi korda l\u00e4heb. Ja siis k\u00f5ik hakkavad sinult k\u00fcsima, \u201emiks see algusest peale ei t\u00f6\u00f6tanud t\u00e4iuslikult\u201d. Kokkuv\u00f5ttes, alati on midagi, mida j\u00f5udluses parandada. Kuid 99% ajast pole sul vihjeid! Sa lihtsalt p\u00fc\u00fcad midagi t\u00f6\u00f6tama panna ja selle k\u00e4igus m\u00f5istad, mis on oluline. Kunagi ei saa ette teada, et see konkreetne t\u00fckk peab olema ideaalne, seega pead p\u00f5him\u00f5tteliselt olema ideaalne k\u00f5iges. Ja see ei ole v\u00f5imalik ning sa seda ei tee. Alati on palju asju, mille kallal t\u00f6\u00f6tada \u2013 ja see on t\u00e4iesti normaalne.<\/p>\n<p><\/p>\n<h1 id=\"kak-delat-bolshoy-refaktoring\">How to perform a major refactoring<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Kuidas te t\u00f6\u00f6tate j\u00f5udluse kallal? See on ju \u00fcldine probleem. N\u00e4iteks, kas olete pidanud tegelema probleemidega, mis tulenevad suure hulga juba olemasoleva funktsionaalsuse ristumisest?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Ma v\u00e4ldin seda. Kui ma tean, et j\u00f5udlus saab probleemi p\u00f5hjuseks, m\u00f5tlen ma sellele enne, kui hakkan kodeerima, eriti andmestruktuuride osas. Aga sageli avastad sa k\u00f5ik need probleemid liiga hilja. Siis tuleb astuda \u00e4\u00e4rmuslikke samme ja teha seda, mida ma nimetan '\u00fcmbersalvestamiseks ja domineerimiseks': tuleb haarata piisavalt suur t\u00fckk. Osa koodist tuleb ikkagi \u00fcmber kirjutada, olgu p\u00f5hjuseks j\u00f5udluse probleemid v\u00f5i midagi muud. \u00dcksk\u00f5ik milline \u00fcmberkirjutamise p\u00f5hjus, on peaaegu alati parem \u00fcmber kirjutada suurem t\u00fckk kui v\u00e4iksem. Sel hetkel hakkavad k\u00f5ik kartma: 'oh jumal, ei tohi nii palju koodi puudutada!'. Kuid tegelikult toimib selline l\u00e4henemine peaaegu alati palju paremini. Tuleb kohe haarata suure probleemiga, joonistada selle \u00fcmber suur ring ja \u00f6elda: k\u00f5ik, mis on ringi sees, ma kirjutan \u00fcmber. Piir on ju palju v\u00e4iksem kui see sisu, mis on selle sees, mis tuleb asendada. Ja kui selline piiride joonistamine v\u00f5imaldab t\u00f6\u00f6 siseselt ideaalselt teha \u2013 sul on k\u00e4ed vabad, tee, mida iganes soovid. Kui sa oled aru saanud probleemist, l\u00e4heb \u00fcmberkirjutamise protsess palju sujuvamalt, seega hammusta suur t\u00fckk!<br \/>\nSamas, kui teed \u00fcmberkirjutamise suure t\u00fcki ja m\u00f5istad, et j\u00f5udlus saab probleemiks, v\u00f5id kohe hakata selle p\u00e4rast muretsema. Tavaliselt muutuvad need lihtsad asjad, nagu '\u00e4rge kopeeri andmeid, hallake andmeid v\u00f5imalikult lihtsalt, tehke neid v\u00e4hemaks'. Suurtes \u00fcmberkirjutamistes on standardseid viise, kuidas j\u00f5udlust parandada. Ja need keerlevad peaaegu alati andmete \u00fcmber.<\/p>\n<p><\/p>\n<h1 id=\"model-stoimosti\">Cost model<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: \u00dches teie podkastis r\u00e4\u00e4kisite hindamismudelitest j\u00f5udluse kontekstis. Kas saaksite selgitada, mida te selle all silmas pidite?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Loomulikult. Ma s\u00fcndisin ajastul, mil protsessorite j\u00f5udlus oli \u00e4\u00e4rmiselt oluline. Ja see ajastu naaseb taas \u2013 saatusel ei puudunud iroonia. Ma hakkasin elama ajal, mil olid kaheksabitised masinad, minu esimene arvuti t\u00f6\u00f6tas 256 baitiga. Just baitidega. K\u00f5ik oli v\u00e4ga v\u00e4ike. Pidi lugema k\u00e4ske ja niipea, kui me hakkasime liikuma programmeerimiskeelte virnas \u00fclespoole, hakkasid keeled endale v\u00f5tmisele \u00fcha rohkem ja rohkem. Oli Assembler, siis Basic, siis C, ja C v\u00f5ttis enda alla paljusid detaile, nagu registrite ja k\u00e4skude jaotamine. Kuid seal oli k\u00f5ik \u00fcsna arusaadav ja kui ma tegin n\u00e4itaja muutuja eksemplarile, siis sain ma load k\u00e4su ja selle k\u00e4su hind oli teada. Riistvara annab teada kindla hulga masina ts\u00fckleid, seega v\u00f5is erinevate asjade t\u00e4itmise kiirus arvutada lihtsalt, liites k\u00f5ik k\u00e4sud, millele plaanisin k\u00e4ivitada. Iga compare\/test\/branch\/call\/load\/store sai kokku liita ja \u00f6elda: siin on t\u00e4itmise aeg. Kui tegid j\u00f5udluse parandamise nimel t\u00f6\u00f6d, panid kindlasti t\u00e4hele, mis numbrid vastavad v\u00e4ikestele kuumadele ts\u00fcklitele.\u00a0<br \/>\nAga niipea, kui l\u00fclitad Java, Python ja sarnaste asjade vahel, kaldud v\u00e4ga kiiresti eemal madalama taseme riistvarast. Mis on Java getter'i kutsumise hind? Kui JIT HotSpot'is k\u00f5ik \u00f5igesti <noindex><a rel=\"nofollow\" href=\"https:\/\/wiki.openjdk.java.net\/display\/HotSpot\/Inlining\">inline'inud<\/a><\/noindex>, siis on see load, kuid kui ta ei teinud seda \u2013 on see funktsiooni kutsumine. Kuna kutse on kuumas ts\u00fcklis, t\u00fchistab see k\u00f5ik muud optimeerimised selles ts\u00fcklis. Seega on tegelik hind palju suurem. Ja sa kaotad kohe v\u00f5ime vaadata koodil\u00f5iku ja m\u00f5ista, kui palju meil tasub seda t\u00e4ita protsessori taktsageduse, kasutatava m\u00e4lu ja vahem\u00e4lu m\u00f5ttes. K\u00f5ik see muutub huvitavaks, kui t\u00f5eliselt s\u00fcvened j\u00f5udlusesse.<br \/>\nN\u00fc\u00fcd oleme olukorras, kus protsessorite kiirus pole enam peaaegu k\u00fcmme aastat kasvanud. Vanad ajad on tagasi! Te ei saa enam loota heale \u00fchetuumalisele j\u00f5udlusele. Kuid kui teete paralleelseid arvutusi \u2013 see on uskumatult keeruline, k\u00f5ik vaatavad teid nagu James Bondi. K\u00fcmnekordsed kiirused tekivad tavaliselt seal, kus keegi midagi t\u00e4helepanuta j\u00e4ttis. Paralleelsus n\u00f5uab palju t\u00f6\u00f6d. K\u00fcmnekordse kiiruskasvu saavutamiseks peate m\u00f5istma kulumudelit. Mida ja kui palju see maksab. Ja selleks peate aru saama, kuidas keel sobib alumisele riistvarale.<br \/>\nMartin Thompson leidis oma blogi jaoks suurep\u00e4rase s\u00f5na. <noindex><a rel=\"nofollow\" href=\"https:\/\/mechanical-sympathy.blogspot.com\/\">Mehaaniline kaastunne.<\/a><\/noindex>! On vajalik m\u00f5ista, mida riistvara plaanib teha, kuidas see t\u00e4pselt seda teeb ja miks see tegelikult seda teeb. Kasutades seda, on \u00fcsna lihtne hakata loendama juhiseid ja aru saama, kuhu t\u00e4itmise aeg l\u00e4heb. Kui te pole vastava ettevalmistusega, otsite lihtsalt musta kassi pimedas toas. Ma n\u00e4en pidevalt inimesi, kes optimeerivad j\u00f5udlust, kellel pole v\u00e4himatki aimu, mida nad \u00fcldse teevad. Nad vaevavad end v\u00e4ga ja ei edene just kuigi palju. Ja kui ma v\u00f5tan sama koodi ja lisan sinna paar v\u00e4ikest nippi ning saavutavad viiekordse v\u00f5i k\u00fcmnekordse kiiruskasvu, \u00fctlevad nad: no, see pole aus, me teadsime ju, et sa oled parem. H\u00e4mmastav. Millest see jutt on... kulumudelist \u2013 see r\u00e4\u00e4gib sellest, millist koodi te kirjutate ja kui kiiresti see keskmiselt t\u00f6\u00f6tab kogu pildis.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Ja kuidas sellist mahtu peas hoida? Kas see saavutatakse suure kogemuse kaudu, v\u00f5i? Kust sellist kogemust saada?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Noh, oma kogemuse sain ma mitte k\u00f5ige lihtsamal viisil. Programmeerisin Assemblers veel siis, kui iga \u00fcksiku juhisega sai tutvuda. See k\u00f5lab rumalalt, kuid sellest ajast on mul peas, m\u00e4lus, igaveseks j\u00e4\u00e4nud Z80 juhiste komplekt. Ma ei m\u00e4leta inimeste nimesid juba minut p\u00e4rast vestlust, kuid m\u00e4letan 40 aastat tagasi kirjutatud koodi. Huvitav, see n\u00e4eb v\u00e4lja nagu \u201e<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\">teadlasest idioodi<\/a><\/noindex>\u00bb.<\/p>\n<p><\/p>\n<h1 id=\"obuchenie-nizkourovnevym-optimizaciyam\">Learning low-level optimizations<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Kas on mingi lihtsam viis sisse elada?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Jah ja ei. Riistad, mida me k\u00f5ik kasutame, pole selle aja jooksul kuigi palju muutunud. K\u00f5ik kasutavad x86, v\u00e4lja arvatud Armil p\u00f5hinevad nutitelefonid. Kui sa ei tegele hardcore-embeddediga, on sul k\u00f5ik sama. Hea, j\u00e4tkame. Juhised pole samuti sajandeid muutunud. Tuleb minna ja kirjutada midagi Assemblys. Veidi, aga piisavalt, et alustada arvestamist. Sa naeratad, aga ma r\u00e4\u00e4gin t\u00e4iesti t\u00f5siselt. Pead m\u00f5istma keele ja riista vastavust. P\u00e4rast seda pead minema ja natuke kirjutama ning tegema v\u00e4ikese m\u00e4ngu kompilaatori v\u00e4ikesele m\u00e4ngu keelele. \u201eM\u00e4nge\u201d t\u00e4hendab, et tuleb teha see m\u00f5istliku ajaga. See v\u00f5ib olla superlihtne, aga peab genereerima juhiseid. Juhiste genereerimise akt aitab m\u00f5ista, milline on kulumudel silla ehitamiseks k\u00f5rgetasemelise koodi ja masina koodi vahel, mis k\u00e4itub riistvaral. See vastavus j\u00e4\u00e4b meelde kompilaatori kirjutamise hetkel. Isegi k\u00f5ige lihtsama kompilaatori kirjutamise hetkel. P\u00e4rast seda saab hakata vaatama Java keelt ja mille poolest semantiline vahe on palju s\u00fcgavam ning kuidas selle \u00fcle on keerulisem sildu ehitada. Java's on palju raskem aru saada, kas meie sild on hea v\u00f5i halb, mis viib selle kokkuvarisemiseni ja mis mitte. Aga sul on vaja mingit alust, millega vaadat koodi ja m\u00f5ista: \u201eah, see getter peab iga kord inline'ima.\u201d Ja siis selgub, et m\u00f5nikord see juhtubki, v\u00e4lja arvatud juhul, kui meetod muutub liiga suureks, ja JIT hakkab k\u00f5ike j\u00e4rjest inline'ima. Selliste kohtade tulemuslikkust saab koheselt ennustada. \u00dcldiselt t\u00f6\u00f6tavad getterid h\u00e4sti, aga siis vaatad suuri kuumi sildu ja m\u00f5istad, et seal liiguvad mingid funktsiooni kutsed, millel ei ole selge, mida nad teevad. See on probleem getterite laialdases kasutuses, p\u00f5hjus, miks nad ei inline'ita \u2013 pole selge, kas see on getter. Kui sul on superv\u00e4ike koodibaas, saad selle lihtsalt meelde j\u00e4tta ja siis \u00f6elda: see on getter, aga see on setter. Suures koodibaasis elab iga funktsioon oma lugu, mis ei ole kellelegi kuigi teada. Profilera \u00fctleb, et oleme kaotanud 24% aega mingis silmus ja et selle silmuse tegevuse m\u00f5istmiseks pead vaatama igat funktsiooni sees. Seda on v\u00f5imatu m\u00f5ista, teadmata funktsiooni, ja see aeglustab t\u00f5eliselt arusaamisprotsessi. Seet\u00f5ttu ma ei kasuta getterit ja setterit, ma olen j\u00f5udnud uuele tasemele!<br \/>\nKust leida hinnamudelit? No, muidugi v\u00f5ib midagi lugeda... Aga ma arvan, et parim viis on tegutseda. Luua v\u00e4ike kompilaator ja see on parim viis m\u00f5ista hinnamudelit ja panna see oma peadesse. V\u00e4ike kompilaator, mis sobiks mikrolaineahi programmeerimiseks \u2013 see on algaja \u00fclesanne. No, ma pean silmas, et kui sul juba on programmeerimisoskused, siis peaks sellest piisama. K\u00f5ik need asjad nagu stringi parsimine, mis sul on mingisugune algebraline v\u00e4ljend, v\u00f5tta sealt v\u00e4lja matemaatiliste operatsioonide juhised \u00f5iges j\u00e4rjekorras, v\u00f5tta \u00f5iged v\u00e4\u00e4rtused registritest \u2013 k\u00f5ik see on lihtne. Ja samal ajal, kui sa seda teed, j\u00e4\u00e4b see sinu ajju. Ma arvan, et k\u00f5ik teavad, millega kompilaator tegeleb. Ja see annab arusaama hinnamudelist.<\/p>\n<p><\/p>\n<h1 id=\"prakticheskie-primery-uluchsheniya-proizvoditelnosti\">Practical examples of performance improvements<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Millele veel t\u00e4helepanu p\u00f6\u00f6rata tulemuste parandamise t\u00f6\u00f6 k\u00e4igus?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Andmestruktuurid. Muide, ma pole ammu neid tunde pidanud... <noindex>Rocket School<\/noindex>. See oli naljakas, aga n\u00f5udis nii palju vaeva, aga mul on ju ka eluk\u00e4ik! Noh, nii et \u00fcks suur ja huvitav tund, \"Kuhu l\u00e4heb teie tulemus\", andsin \u00fcli\u00f5pilastele n\u00e4ite: kaks ja pool gigabaiti finantsteabeandmeid loeti CSV-failist ja siis tuli arvestada m\u00fc\u00fcdavate toodete arvu. Tavalised turuandmed. UDP-paketid, muudetud tekstivormingusse, alates 70ndatest. Chicago Mercantile Exchange \u2013 igasugused asjad nagu \u00f5li, mais, sojaoad ja nii edasi. Tuli arvestada neid tooteid, tehingute arvu, keskmist rahaliikumist ja kaupu jne. See on \u00fcsna lihtne kaubandusteadus: leida toote kood (see on 1-2 s\u00fcmbolit hash-tabelis), saada summa, lisada see \u00fche tehingu kogumisse, lisada maht, lisada hind ja paar muud asja. V\u00e4ga lihtne matemaatika. M\u00e4nguklassi teostus oli v\u00e4ga otsekohene: k\u00f5ik on failis, ma loen faili ja liigun selle kaudu, jagades \u00fcksikud kirjed Java stringideks, otsin neist vajalikke asju ja liidan vastavalt \u00fclaltoodud matemaatikale. Ja see t\u00f6\u00f6tab mingi v\u00e4ikese kiirusaga. <\/p>\n<p><\/p>\n<p>Sellest l\u00e4henemisest on k\u00f5ik selge, mis toimumas on, ja paralleelsed arvutused ei aita siin, eks? Selgub, et viiekordset j\u00f5udluse suurenemist saab saavutada lihtsalt \u00f5ige andmestruktuuride valimisega. See \u00fcllatab isegi kogenud programmeerijaid! Minu konkreetses olukorras oli keskpunkt see, et m\u00e4lu eraldamine kuumas ts\u00fcklis ei ole hea. No, see ei ole kogu t\u00f5de, aga \u00fcldiselt \u2013 ei tohi eraldada 'iga X' puhul, kui X on piisavalt suur. Kui X on kaks ja pool gigabaiti, siis ei peaks midagi 'iga t\u00e4he' v\u00f5i 'iga rea' v\u00f5i 'iga v\u00e4lja' jaoks eraldama, mitte midagi sellist. Just sellele kulubki aega. Kuidas see \u00fcldse t\u00f6\u00f6tab? Kujutage ette, et kutsun esile <code>String.split()<\/code> v\u00f5i <code>BufferedReader.readLine()<\/code>. <code>Readline<\/code> moodustab stringi andmebaidist, mis on saadetud v\u00f5rgu kaudu, igaks read \u00fche korra, iga sada miljonit read jaoks. Ma v\u00f5tan selle stringi, anal\u00fc\u00fcsin seda et ja viskan \u00e4ra. Miks viskan \u00e4ra \u2013 noh, olen selle juba t\u00f6\u00f6tlenud, k\u00f5ik. Seega igasuguse byte'i kohta, mis on loetud nendest 2.7G-st, salvestatakse kaks s\u00fcmbolit stringis, st juba 5.4G, ja need ei ole mulle enam millekski vajalikud, seega visatakse \u00e4ra. Kui vaadata m\u00e4lu l\u00e4bilaskev\u00f5imet, laeme 2.7G, mis l\u00e4bib m\u00e4lu ja protsessori m\u00e4busid, ning seej\u00e4rel saadetakse kaks korda rohkem stringiks, mis asub m\u00e4lus, ja k\u00f5ik see purustatakse iga uue stringi loomise k\u00e4igus. Kuid ma pean selle lugema, raud loeb selle, isegi kui seej\u00e4rel k\u00f5ik purustatakse. Ja ma pean selle kirjutama, sest ma olen loonud stringi ja vahem\u00e4lu on t\u00e4is - vahem\u00e4lu ei saa mahutada 2.7G. Seega igasuguse loetud byte'i kohta loen veel kaks lisabyte'i ja kirjutan kaks lisabyte'i, ja l\u00f5puks on nende suhe 4:1 - sellises suhtes raiskame m\u00e4lu l\u00e4bilaskev\u00f5imet. Ja edasi selgub, et kui ma teen <code>String.split()<\/code> \u2013 teen seda kaugel mitte viimast korda, seal sees v\u00f5ib olla veel 6-7 v\u00e4lja. Seet\u00f5ttu toob klassikaline CSV lugemis- ja stringide parsimise kood kaasa m\u00e4lu l\u00e4bilaskev\u00f5ime kadu umbes 14:1 v\u00f5rreldes sellega, mida te tegelikult sooviksite omada. Kui need eraldamised \u00e4ra visata, siis v\u00f5ib saavutada viiekordse kiiruse. <\/p>\n<p><\/p>\n<p>Ja see ei ole \u00fcldse nii keeruline. Kui vaatate koodi \u00f5igelt k\u00f5rvalt, muutub see \u00fcsna lihtsaks kohe, kui olete probleemist aru saanud. Ei tasu \u00fcldse m\u00e4ludelegatsiooni l\u00f5petada: probleem on ainult selles, et te jagate m\u00e4luruumi ja see sureb kohe, samal ajal p\u00f5letades olulist ressurssi, mis antud juhul on m\u00e4lu ribalaius. Ja kogu see toob kaasa j\u00f5udluse languse. x86 puhul tuleb tavaliselt aktiivselt p\u00f5letada protsessorits\u00fckleid, kuid siin p\u00f5letate kogu m\u00e4lu palju varem. Lahendus on v\u00e4hendada m\u00e4ludelegatsioonide arvu.\u00a0<br \/>\nTeine probleem on see, et kui k\u00e4ivitada profiler, kui m\u00e4lu ribalaius on l\u00f5ppenud, just siis, kui see juhtub, siis ootad tavaliselt m\u00e4lukahe tagasitulekut, sest see on t\u00e4is pr\u00fcgi, mille just ise genereerisite, k\u00f5igi nende ridadega. Seet\u00f5ttu iga load v\u00f5i store operatsioon muutub aeglaseks, kuna need toovad kaasa m\u00e4lukaevu tabamised \u2014 kogu vahem\u00e4lu muutub aeglaseks, oodates, millal siit\u00e4 pr\u00fcgistas. Seet\u00f5ttu n\u00e4itab profiler vaid sooja juhuslikku m\u00fcra, mis on hajutatud kogu ts\u00fckli ulatuses \u2014 ei tule \u00fchtegi eraldi kuumast instruktsioonist ega koha koodis. Ainult m\u00fcra. Ja kui vaatad GC ts\u00fckleid, siis k\u00f5ik need on noortele, ja \u00fcliv\u00f5imsad \u2014 mikrosekundid v\u00f5i millisekundid maksimum. Sest kogu see m\u00e4lu sureb hetkega. Sa jaotad miljard gigabaiti ja see k\u00e4rbib ja k\u00e4rbib ning k\u00e4rbib j\u00e4lle. K\u00f5ik see toimub v\u00e4ga kiiresti. Saadud tulemuseks on madala hinnaga GC ts\u00fcklid, soe m\u00fcra kogu ts\u00fckli ulatuses, kuid me soovime saada 5-kordset kiirendust. Sel hetkel peaks midagi olema selge ja kostma: \u00abmiks nii?!\u00bb. M\u00e4lu ribalaiuse \u00fcletamine ei kuvata klassikalisest silurist, tuleb k\u00e4ivitada riistvara j\u00f5udluse arvutite silur ja n\u00e4ha seda iseseisvalt ja otse. Ja mitte otse ei saa kahtlustada neid kolme s\u00fcmptomit. Kolmas s\u00fcmptom on siis, kui vaatad, mida jagad, k\u00fcsid profilerilt ja ta vastab: \u00abSa tegid miljoneid ridu, kuid GC t\u00f6\u00f6tas tasuta\u00bb. Kui see juhtub, saad aru, et moodustasid liiga palju objekte ja p\u00f5letad kogu m\u00e4lu ribalaiuse. On viis sellest aru saada, kuid see pole ilmne.\u00a0<\/p>\n<p><\/p>\n<p>Andmete struktuuri probleem: alusskeem, mis on kogu toimingu taga, on liiga suur, see on 2,7 G kettal, seet\u00f5ttu ei ole selle koopia tegemine soovitatav \u2013 soovitakse laadida see otse v\u00f5rgu baidipuhvrist registritesse, et mitte lugeda ja kirjutada sinna-sinna viis korda. Kahjuks ei paku Java vaikimisi sellist teeki JDK osana. Kuid see on t\u00f5eliselt triviaalne, eks? Sisuliselt on see 5-10 rida koodi, mis viib sellise oma puhverdatud stringi laadija loomise, mis kordab stringiklassi k\u00e4itumist, olles samas madalamate baidipuhvrite \u00fcmber. Tulemusena n\u00e4ib, et t\u00f6\u00f6tad peaaegu nagu stringidega, kuid tegelikult liiguvad seal viidud puhvri n\u00e4itajad, ja toored baidid ei kopeerita kuhugi, seega kasutatakse samu puhverid korduvalt, samas kui operatsioonis\u00fcsteem on \u00f5nnelik selle \u00fcle, et v\u00f5tab enda kanda asjad, milleks ta on m\u00f5eldud, n\u00e4iteks peidetud topeltpuvverdus nende baidipuhvrite puhul, ja sina ise ei purustagi l\u00f5putut voolu mittevajalikest andmetest. Muide, kas te m\u00f5istate, et GC t\u00f6\u00f6tamisel garanteeritakse, et iga m\u00e4lu eraldamine ei ole protsessorile n\u00e4htav p\u00e4rast viimast GC ringi? Seet\u00f5ttu ei saa see k\u00f5ik kuidagi olla vahem\u00e4lus ja edasi toimub 100% garanteeritud m\u00f6\u00f6dalaskmine. Viidiku kasutamisel v\u00f5tab x86-l registreist m\u00e4lu lugemine 1-2 ts\u00fcklit ja kohe kui see juhtub, maksad, maksad, maksad, kuna m\u00e4lu k\u00f5ik on <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Cache_inclusion_policy\">NINE vahem\u00e4ed<\/a><\/noindex> \u2013 ja see on m\u00e4lu eraldamise hind. Reaalne hind.<\/p>\n<p><\/p>\n<p>Teisis\u00f5nu, andmestruktuurid on need, mida on k\u00f5ige raskem muuta. Ja kui te olete aru saanud, et olete valinud vale andmestruktuuri, mis tapab tulevikus j\u00f5udluse, vajate tavaliselt palju t\u00f6\u00f6d selle parandamiseks; kui seda ei tehta, l\u00e4heb asi halvemaks. K\u00f5igepealt tuleb m\u00f5elda andmestruktuuridele, see on oluline. Peamine kulu seisneb nende rikkaid andmestruktuuride peale, mida hakata kasutama stiilis \u201ema kopeerisin andmestruktuuri X andmestruktuuri Y, sest Y meeldib mulle rohkem kujunduse poolest\u201d. Kuid kopeerimisoperatsioon (mis tundub odav) kasutab tegelikult m\u00e4luressursse ja just siin peitub kogu kadunud t\u00f6\u00f6aeg. Kui mul on hiiglaslik JSON-string ja ma tahan selle muuta struktureeritud DOM-puudeks POJO v\u00f5i midagi sarnast, siis selle stringi parseerimise ja POJO ehitamise operatsioon ning hiljem uue p\u00f6\u00f6rdumise POJO juurde lisanduvad toimetamis- ja kulud \u2013 see ei ole odav. V\u00e4lja arvatud juhul, kui te jooksete POJO-d palju sagedamini kui stringide kaudu. Kohapeal v\u00f5ib proovida stringi dekodeerida ja sealt ainult vajalik \u00e4ra v\u00f5tta, ilma et see muudetaks mingiks POJO-ks. Kui k\u00f5ik see toimub teel, kus n\u00f5utakse maksimaalset j\u00f5udlust, mingeid POJO-sid ei ole \u2013 peate kuidagi otse stringis kaevama.<\/p>\n<p><\/p>\n<h1 id=\"zachem-sozdavat-svoy-yazyk-programmirovaniya\">Why create your own programming language<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Te \u00fctlesite, et kulumudeli m\u00f5istmiseks peate kirjutama oma v\u00e4ikese keele\u2026<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Mitte keel, vaid kompilaator. Keel ja kompilaator on erinevad asjad. Peamine erinevus on teie peas.\u00a0<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: \u00dcldiselt tean, et eksperimenteerite oma keelte loomisega. Miks?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Sest, et saan! Olen poolselt pensionil, nii et see on minu hobi. Olen kogu elu realiseerinud kellegi teise keeli. Ja ma olen palju t\u00f6\u00f6tanud kodeerimisstiili kallal. Samuti n\u00e4en ma probleeme muudes keeltes. N\u00e4en, et on paremaid viise tuttavate asjade tegemiseks. Ja ma kasutan neid. Olen lihtsalt kurnatud, et n\u00e4ha probleeme endas, Java's, Pythonis v\u00f5i mis tahes muus keeles. Hetkel kirjutan React Native, JavaScripti ja Elmiga hobi korras, mis ei ole pensionile j\u00e4\u00e4mise, vaid aktiivse t\u00f6\u00f6 tegemisega seotud. Ja ma kirjutan ka Pythonis ning t\u00f5en\u00e4oliselt j\u00e4tkan masin\u00f5ppe arendamist Java-taustade jaoks. Populaarseid keeli on palju ning igal\u00fchel neist on huvitavad omadused. Iga\u00fcks on hea millegi poolest ja v\u00f5ib proovida nende k\u00f5igi nippe kokku viia. Seega, uurin huvitavaid asju, keele k\u00e4itumist, p\u00fc\u00fcan v\u00e4lja m\u00f5elda arusaadavat semantikat. Ja seni on mul see \u00f5nnestunud! Praegu v\u00f5itlen m\u00e4lu semantika kallal, kuna soovin, et see oleks nagu C ja Java, saavutades tugeva m\u00e4lumudeli ja m\u00e4lu semantika laadimiste ja salvestuste jaoks. Samuti, et oleks automaatne t\u00fc\u00fcpide j\u00e4reldus nagu Haskellis. Nii et \u00fcritan segada Haskell'i sarnast t\u00fc\u00fcbi j\u00e4reldust m\u00e4luga, mis t\u00f6\u00f6tab nagu C ja Java. Sellega olen viimased 2-3 kuud tegelenud n\u00e4iteks.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Kui te ehitate keelt, mis v\u00f5tab teisi keeli parimaid aspekte, kas olete m\u00f5elnud, et keegi teeb vastupidist: v\u00f5tab teie ideed ja kasutab neid enda keeles?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Just nii s\u00fcnnivad uued keeled! Miks Java sarnaneb C-ga? Sest C-l oli hea s\u00fcntaks, mida k\u00f5ik m\u00f5istsid ja Java sai inspiratsiooni sellest s\u00fcntaksist, lisades sinna t\u00fc\u00fcbikeerukuse, massiivi piiride kontrolli, GC ja nad parandasid ka m\u00f5ningaid C omadusi. Nad lisasid omi. Kuid nad said t\u00f5eliselt tugevat inspiratsiooni, eks? K\u00f5ik seisavad enne sind olnud hiiglaste \u00f5lgadel - just nii toimub areng.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Nagu ma aru saan, on teie keel m\u00e4lu kasutamise osas ohutu. Kas olete m\u00f5elnud midagi sarnast Rusti borrow checker'ile rakendada? Olete seda vaadanud, kuidas see teile meeldib?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Ma olen juba ammu C keeles programmeerinud, kasutades k\u00f5iki neid malloc ja free abil m\u00e4lu haldamist k\u00e4sitsi. Teate, 90-95% k\u00e4sitsi haldatud elueast j\u00e4rgib sama struktuuri. Ja see on v\u00e4ga, v\u00e4ga t\u00fc\u00fctu, kui seda k\u00e4sitsi teha. Tahaks, et kompilaator lihtsalt teataks, mis toimub ja mida olete oma toimingutega saavutanud. M\u00f5ned asjad teeb borrow checker seda vaikimisi. Lisaks peaks see automaatselt andma teavet, m\u00f5istma k\u00f5ike ja mitte koormama mind selle arusaamise edasiandmisega. See peaks teostama v\u00e4hemalt kohaliku p\u00f5genemisanal\u00fc\u00fcsi, ja ainult siis, kui see ei \u00f5nnestu, tuleks lisada t\u00fc\u00fcpi annotatsioone, mis kirjeldavad eluea - ja selline skeem on oluliselt keerulisem kui borrow checker v\u00f5i m\u00f5ni muu olemasolev m\u00e4lutest. Valik \u201ek\u00f5ik on korras\u201d ja \u201ema ei saanud \u00fcldse aru\u201d \u2014 ei, peaks olema midagi paremat.\u00a0<br \/>\nNii et, inimesena, kes on kirjutanud palju C keeles, arvan, et automaatse eluts\u00fckli halduse tugi on \u00e4\u00e4rmiselt oluline. Ja veel, mind h\u00e4irib, kui palju m\u00e4lu Java kasutab ja peamine kaebus on GC. Kui Java-s m\u00e4lu eraldatakse, ei tule tagasi m\u00e4lu, mis oli kohaliku GC viimases ts\u00fcklis. Keeledes, kus m\u00e4lu haldus on t\u00e4psem, ei ole see nii. Kui kutsud malloc'i, siis saad kohe m\u00e4lu, mida tavaliselt just kasutati. \u00dcldiselt teed m\u00e4luga mingid ajutised asjad ja annad kohe tagasi. Ja see naaseb koheselt malloc'i basseinile, ning j\u00e4rgmine malloc'i ts\u00fckkel t\u00f5mbab selle j\u00e4lle v\u00e4lja. Seega v\u00e4heneb tegelik m\u00e4lu kasutamine elavate objektide kogumini konkreetsel hetkel, pluss leke. Ja kui sul ei leki k\u00f5ik t\u00e4iesti kohutavalt, siis j\u00e4\u00e4b enamus m\u00e4lu vahem\u00e4ludesse ja protsessorisse, ning see t\u00f6\u00f6tab kiiresti. Kuid see n\u00f5uab palju k\u00e4si m\u00e4luhaldust malloc'i ja free abil, mis on kutsutud \u00f5igesti \u00f5igesse kohta. Rust suudab sellega ise \u00f5igesti hakkama saada ja paljudel juhtudel pakkuda isegi suuremat j\u00f5udlust, kuna m\u00e4lu tarbimine kitseneb ainult praegustele arvutustele \u2013 vastupidiselt ootusele, et j\u00e4rgmine GC ts\u00fckkel vabastab m\u00e4lu. L\u00f5ppkokkuv\u00f5ttes saime v\u00e4ga huvitava viisi j\u00f5udluse parandamiseks. Ja \u00fcsna v\u00f5imas \u2013 m\u00f5tlesin, et olen tegelenud selliste asjadega andmete t\u00f6\u00f6tlemisel finantstehnoloogias, ning see v\u00f5imaldas saavutada kiiruset\u00f5usu ligi viie korra. See on \u00fcsna suur kiiruset\u00f5us, 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\">The career of a performance engineer<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Samuti tahaksin k\u00fcsida karj\u00e4\u00e4ri \u00fcldiselt. Te saate tuntuks JIT-i t\u00f6\u00f6tamise kaudu HotSpot'is, seej\u00e4rel liigutasite Azulisse \u2013 ja see on samuti JVM-ettev\u00f5te. Kuid tegelesite n\u00fc\u00fcd rohkem riistvaraga kui tarkvaraga. Ja siis j\u00e4rsku p\u00f6\u00f6rdusite Big Data ja Masin\u00f5ppe poole, seej\u00e4rel petuskatsete avastamisele. Kuidas see nii juhtus? Need on v\u00e4ga erinevad arenduse valdkonnad.<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Olen juba \u00fcsna pikka aega programmeerimisega tegelenud ja olen j\u00f5udnud paljudele erinevatele tegevustele. Ja kui inimesed \u00fctlevad: \u201eoh, sina olid see, kes tegi JIT Java jaoks!\u201d, siis see on alati naljakas. Enne seda tegelesin PostScripti klooni loomisega \u2013 selle keele, mida Apple kunagi kasutas oma laserprinterites. Ja enne seda tegin Forth keele rakendust. Ma arvan, et minu \u00fchine teema on t\u00f6\u00f6riistade arendamine. Olen kogu elu teinud t\u00f6\u00f6riistu, millega teised inimesed kirjutavad oma \u00e4gedaid programme. Kuid olen tegelenud ka operatsioonis\u00fcsteemide, draiverite, tuumadebbugerite, operatsioonis\u00fcsteemide arendamiseks m\u00f5eldud keelte arendamisega, mis algasid triviaalsetena, kuid aja jooksul muutusid j\u00e4rjest keerulisemaks. Kuid p\u00f5hiline teema on ikkagi t\u00f6\u00f6riistade arendamine. Suur osa elust m\u00f6\u00f6dus Azuli ja Sunny vahel, ja see oli seotud Java\u2019ga. Kuid kui ma hakkasin tegelema suurandmete ja masin\u00f5ppega, panin j\u00e4lle oma piduliku m\u00fctsi p\u00e4he ja \u00fctlesin: \u201eOh, n\u00fc\u00fcd on meil keeruline probleem, ja siin toimub palju huvitavaid asju ja inimesi, kes midagi teevad.\u201d See on suurep\u00e4rane arengutee, mida tasub l\u00e4bida. <\/p>\n<p><\/p>\n<p>Jah, ma armastan t\u00f5eliselt hajusalt arvutamist. Minu esimene t\u00f6\u00f6 oli \u00fclikooliajal C keeles reklaamiprojektis. See h\u00f5lmas hajusalt arvutamist Zilog Z80 kiipide peal, mis kogusid andmeid analoogsete optiliste tekstide tuvastamiseks, mida tegi t\u00f5eline analooganal\u00fcsaator. See oli \u00e4ge ja t\u00e4iesti ebanormaalne teema. Kuid seal olid probleemid, mingi osa ei tuvastatud \u00f5igesti, seega tuli v\u00f5tta pilt ja n\u00e4idata seda inimesele, kes oli juba silmadega lugenud ja teatada, mis seal kirjas on, ja seet\u00f5ttu olid seal andmet\u00f6\u00f6d, milles olid oma keel. Oli tagaplaan, mis k\u00f5ike seda t\u00f6\u00f6tles \u2013 paralleelselt t\u00f6\u00f6tavad Z80, millel olid aktiivsed vt100 terminalid \u2013 iga\u00fchele \u00fcks, ja Z80 eba\u00fchtne programmeerimisviis. Teatud \u00fchine m\u00e4lut\u00fckk, mida jagasid k\u00f5ik Z80 'd konfiguratsioonis \u201et\u00e4ht\u201c; jagati ka tagaplaan ja pool RAM 'ist jagati v\u00f5rgus, samas kui teine pool j\u00e4i privaatseks v\u00f5i l\u00e4ks millegi muu jaoks. M\u00f5istlikult keeruline paralleelne hajus jaotuss\u00fcsteem jagatud... osaliselt jagatud m\u00e4luga. Millal see juhtus... Ei m\u00e4leta isegi, kuskil 80-ndate keskpaiku. \u00dcsna kaua tagasi.\u00a0<br \/>\nJah, oletame, et 30 aastat on piisavalt kaua. Hajusalt arvutamisega seotud \u00fclesanded eksisteerivad piisavalt kaua, inimesed on ammusest ajast selle kallal vaeva n\u00e4inud. <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>-klasteritega. Sellised klastrid n\u00e4evad v\u00e4lja nagu... N\u00e4iteks, kui sul on Ethernet ja sinu kiire x86 on sellele Ethernetile \u00fchendatud, siis soovid n\u00fc\u00fcd saada vale jagatud m\u00e4lu, sest tol ajal ei saanud keegi tegeleda jaotatud arvutamise kodeerimisega, see oli liiga keeruline, ja seet\u00f5ttu oli vale jagatud m\u00e4lu x86 lehek\u00fclgede kaitsega. Kui sa kirjutasid sellele lehek\u00fcljele, siis \u00fctlesime teistele protsessoritele, et kui nad saavad ligip\u00e4\u00e4su samale jagatud m\u00e4lule, tuleb see sinult laadida. Nii tekkis midagi, mis meenutas vahem\u00e4lu j\u00e4rjepidevuse protokolli ja selle tarkvara. Huvi pakkuda kontseptsioon. T\u00f5eline probleem oli muidugi teises. K\u00f5ik see t\u00f6\u00f6tas, kuid sa said kiiresti j\u00f5udlusprobleeme, sest keegi ei m\u00f5istnud j\u00f5udlusmudelit piisavalt h\u00e4sti \u2013 millised olid seal m\u00e4lule juurdep\u00e4\u00e4su mustrid, kuidas teha nii, et node'id ei pingsimoodi \u00fcksteist ei kontrolliks, jne. <\/p>\n<p><\/p>\n<p>H2O-s m\u00f5tlesin v\u00e4lja j\u00e4rgmise: arendajad vastutavad selle eest, et tuvastada, kus paralleelsus on olemas ja kus see puudub. Olen v\u00e4lja t\u00f6\u00f6tanud kodeerimismudeli, mis lihtsustab k\u00f5rge j\u00f5udlusega koodi kirjutamist. K\u00fcll aga on aeglase toimimisega koodi kirjutamine keeruline ja see n\u00e4eb halb v\u00e4lja. Aeglase koodi kirjutamiseks tuleb t\u00f5siselt pingutada, kasutada tuleb ebatavalisi meetodeid. Aeglaselt toimiv kood on n\u00e4ha esimesest pilgust. Seet\u00f5ttu kirjutatakse tavaliselt kood, mis t\u00f6\u00f6tab kiiresti, kuid tihti tuleb tegeleda jagatud m\u00e4lu probleemidega. See k\u00f5ik on seotud suurte massiividega ja k\u00e4itumine seal sarnaneb mittes\u00fcntaktiliste suurte massiividega paralleelses Javas. Kujutage ette, et kaks l\u00f5ime kirjutavad paralleelsesse massiivi, \u00fcks neist v\u00f5idab ja teine kaotab, kuid te ei tea, kumb on kumb. Kui nad ei ole mittes\u00fcnteetilised, v\u00f5ib j\u00e4rjekord olla mistahes \u2013 ja see t\u00f5epoolest t\u00f6\u00f6tab. Inimesed t\u00f5epoolest hoolivad operatsioonide j\u00e4rjekorrast, nad paigutavad volatiilseid muutujaid \u00f5igesti ja \u00f5igetes kohtades ootavad nad m\u00e4luga seotud j\u00f5udluse probleeme. Vastupidisel juhul kirjutaksid nad lihtsalt koodi ts\u00fcklitena 1-st N-ni, kus N on mingid triljonid, lootes, et k\u00f5ik keerulised juhtumid muutuvad automaatselt paralleelseks \u2013 ja seal see ei toimi. Kuid H2O ei ole ei Java ega Scala, seda v\u00f5ib pidada \u201eJava miinus miinus\u201d, kui tahad. See on v\u00e4ga arusaadav programmeerimisstiil ja see sarnaneb lihtsa C v\u00f5i Java koodi kirjutamisele ts\u00fcklite ja massiividega. Samas saab m\u00e4lu hallata terabaitidega. Ma kasutan endiselt H2O-d. Aeg-ajalt kasutan seda erinevates projektides \u2013 ja see on endiselt k\u00f5ige kiirem lahendus, mis on k\u00fcmneid kordi konkurentidest parem. Kui teete Big Data kolonnandmetega, on H2O-d v\u00e4ga keeruline \u00fcletada.<\/p>\n<p><\/p>\n<h1 id=\"tehnicheskie-chellenzhi\">Technical challenges<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Mis on olnud teie suurim v\u00e4ljakutse kogu teie karj\u00e4\u00e4ri jooksul?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Kas arutame tehnilist v\u00f5i mitte-tehnilist k\u00fcsimust? \u00dctleksin, et suurimad v\u00e4ljakutsed on mitte-tehnilised.\u00a0<br \/>\nMis tehnilised v\u00e4ljakutsed. Ma lihtsalt v\u00f5itsin need. Ma isegi ei tea, mis neist k\u00f5ige suurem oli, kuid mitu neist olid \u00fcsna huvitavad, mille jaoks kulus palju aega ja vaimset v\u00f5itlust. Kui ma tulin Suni, olin kindel, et teen kiire kompilaatori, kuid hulk kogenud spetsialiste k\u00fcsis, et mul ei \u00f5nnestu kunagi midagi. Kuid l\u00e4ksin selle teed, kirjutasin kompilaatori, sealhulgas registreerimisallokaatori, ja see oli \u00fcsna kiire. See oli sama kiire nagu kaasaegne C1, kuid tol ajal oli allokaator palju aeglasem ja tagasi vaadates \u2013 see oli probleeme suurte and Structuresiga. Mul oli seda vaja, et kirjutada graafiline registreerimisallokaator, ja ma ei m\u00f5istnud dilemma koodi v\u00e4ljendusv\u00f5ime ja kiirus, mis tollal eksisteeris ja oli v\u00e4ga oluline. Selgus, et andmestruktuur \u00fcletab tavaliselt x86 ajal suuruse vahem\u00e4lu ja seet\u00f5ttu, kui ma algselt arvasin, et registreerimisallokaator t\u00f6\u00f6tab 5-10 protsenti kogu JIT-imise ajast, siis tegelikult osutus see 50 protsendiks. <\/p>\n<p><\/p>\n<p>Aeg m\u00f6\u00f6dus, kompilaator muutus j\u00e4rjest selgemaks ja t\u00f5husamaks, l\u00f5petas eemaldamise tekitamise halva koodi suuremas osas juhtudel ning tootlikkus hakkas \u00fcha enam meenutama seda, mida C kompilaator pakub. Kui sa muidugi ei kirjuta mingit jama, mida isegi C ei kiirenda. Kui kirjutad koodi nagu C, saad ka tootlikkuse, mis on C sarnane suuremas osas juhtudel. Ja mida kaugemale, seda sagedamini saadud kood oli as\u00fcmptootiliselt C tasemetega, registreerimisallokaator hakkas meenutama midagi l\u00f5petatut\u2026 s\u00f5ltumata sellest, kas sinu kood t\u00f6\u00f6tab kiiresti v\u00f5i aeglaselt. J\u00e4tkasin allokaatori kallal t\u00f6\u00f6tamist, et see teeks paremaid eraldamisi. See muutus j\u00e4rjest aeglasemaks, kuid andis \u00fcha paremat tegevust olukordades, kus keegi ei suutnud enam hakkama saada. Ma sain sukelduda registreerimisallokaatorisse, matta sinna kuu t\u00f6\u00f6 ja \u00e4kitselt hakkas kogu kood t\u00f6\u00f6tama 5% kiiremini. See juhtus korduvasti ja registreerimisallokaatorist sai midagi kunstiteose taolist \u2013 k\u00f5ik armastasid v\u00f5i vihkasid seda, ning akadeemia inimesed k\u00fcsisid, miks k\u00f5ik t\u00e4pselt nii tehakse, miks mitte <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Register_allocation#Linear_Scan\">lineaarne skaneerimine<\/a><\/noindex>, ja mis on erinevus. Vastus on endiselt sama: graafi v\u00e4rvimise p\u00f5hine allocator pluss v\u00e4ga hoolikas t\u00f6\u00f6tamine puhverkoodiga on triumfi relv, parim kombinatsioon, mida keegi ei suuda \u00fcletada. Ja see on \u00fcsna mitteilmne asi. K\u00f5ik muu, mida kompilaator seal teeb \u2013 on \u00fcsna \u00f5ppinud asjad, kuigi need on samuti viidud kunstitasemele. Olen alati teinud asju, mis pidid muutma kompilaatori kunstiteoseks. Kuid midagi sellest ei olnud midagi erakordset \u2013 v\u00e4lja arvatud registrite allocator. Kinnitatud on see, et tuleb hoolikalt <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Register_allocation\">l\u00f5hustada<\/a><\/noindex> koormuse all ja kui see juhtub (ma v\u00f5in selgitada l\u00e4hemalt, kui see on huvitav), siis t\u00e4hendab see, et saab agressiivsemalt sissetoomist teha, ilma et riskiks suureneda j\u00f5udlusgraafi katkestamise \u00fcle. Tol ajal oli palju t\u00e4ismahus kompilaatoreid, mis olid ehtitud nipsasjade ja vidinatega, kus olid registrite allocatorid, kuid keegi ei suutnud enam nii teha. <\/p>\n<p><\/p>\n<p>Probleem on see, et kui lisad meetodeid, mis sobivad inlininguks, suurendades ja suurendades inlininguala, siis kasutatavate v\u00e4\u00e4rtuste kogum \u00fcletab kohe registreid ning peab toimuma spilling. Kriitiline tase j\u00f5uab tavaliselt k\u00e4tte siis, kui allocator annab alla, ja \u00fcks hea kandidaadi spilling viib teise, ning sa spilling mingeid t\u00e4iesti kummalisi asju. Inliningu v\u00e4\u00e4rtus seisneb selles, et kaotad osa overhead\u2019ist, mis tuleb kutse ja salvestamise peale, sa saad n\u00e4ha v\u00e4\u00e4rtusi sees ja saad neid veel optimeerida. Inliningu maksumus seisneb selles, et tekib suur hulk elavaid v\u00e4\u00e4rtusi, ja kui su registri allocator spilling rohkem, kui vajalik, kaotad kohe. Seet\u00f5ttu on enamikul allocatoritest probleem: kui inlining l\u00e4heb teatud piirist \u00fcle, hakkavad k\u00f5ik asjad spilling ja j\u00f5udlus v\u00f5ib olla kui vette visatud. Need, kes rakendavad kompileerijat, lisavad m\u00f5ningaid heuristikat: n\u00e4iteks, et peatada inlining, kui see saavutab mingi piisavalt suure suuruse, kuna allocatsioonid rikuvad k\u00f5ik \u00e4ra. Nii tekib j\u00f5udluse graafiku murdumine \u2013 sa inliningid, inliningid, j\u00f5udlus kasvab vaikselt \u2013 ja siis pl\u00f5ks! \u2013 see kukub j\u00e4rsku, sest sa oled inlininginud liiga palju. Nii toimis k\u00f5ik enne Java saabumist. Java n\u00f5uab palju rohkem inliningut, seega pidin oma allocatorit tegema palju agressiivsemaks, et see ei kukuks ja kui sa oled inlininginud liiga palju \u2013 hakkab see spillingima, kuid siiski tuleb hetk, mil \u201eenam ei spillingi\u201c. See on huvitav t\u00e4helepanek ja see tuli mulle lihtsalt kuskilt, mitte ilmne, kuid h\u00e4sti tasuv. Ma asusin r\u00fcndava inlininguga ja see viis mind kohtadesse, kus Java ja C j\u00f5udlus k\u00e4ivad k\u00f5rvuti. Nad on t\u00f5eliselt l\u00e4hedal \u2013 ma saan kirjutada Java koodi, mis on palju kiirem kui C kood, ja nii edasi, kuid keskmiselt, suure pildi kontekstis, on nad ligikaudu v\u00f5rdsed. Arvatavasti on osa sellest teenest registri allocator, mis v\u00f5imaldab mul inliningida maksimaalselt lolli moodi. Ma inliningin lihtsalt k\u00f5ik, mida n\u00e4en. K\u00fcsimus on selles, kas allocator t\u00f6\u00f6tab h\u00e4sti, kas tulemusena on m\u00f5istlikult t\u00f6\u00f6tav kood. See oli suur v\u00e4ljakutse: m\u00f5ista seda k\u00f5ike ja sundida see t\u00f6\u00f6le.<\/p>\n<p><\/p>\n<h1 id=\"nemnogo-pro-allokaciyu-registrov-i-mnogoyadernost\">A bit about register allocation and multithreading<\/h1>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Probleemid, nagu registrite jaotamine, tunduvad olema igavene teema. Kas on kunagi olnud nii, et m\u00f5ni idee tundus lootustandev, kuid kukkus praktikas l\u00e4bi?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Loomulikult! Registrite jaotamine on valdkond, kus NP-t\u00e4ieliku probleemi lahendamiseks \u00fcritad leida mingeid heuristikaid. Ja sa ei saa kunagi ideaalsele lahendusele j\u00f5uda, eks? See on lihtsalt v\u00f5imatu. Vaata, Ahead of Time kompileerimine \u2013 see t\u00f6\u00f6tab ka halvasti. R\u00e4\u00e4gime siin mingitest 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, sa ju t\u00f6\u00f6tad selle parandamise nimel! Registrite jaotamine on teema, mis on t\u00e4ielikult p\u00fchendatud j\u00f5udlusele. Niipea kui sul on esimene protot\u00fc\u00fcp, mis t\u00f6\u00f6tab ja v\u00e4rvib, nagu vaja, algab t\u00f6\u00f6 j\u00f5udluse kallal. Pead \u00f5ppima h\u00e4sti m\u00f5\u00f5tma. Miks see oluline on? Kui on selged andmed, saad vaadata erinevaid osi ja n\u00e4ha: aha, see aitas siin, aga seal l\u00e4ks k\u00f5ik katki! Tulevad v\u00e4lja head ideed, sa lisad uue heuristika ja \u00e4kki hakkab k\u00f5ik keskmiselt veidi paremini t\u00f6\u00f6le. V\u00f5i mitte. Mul oli rohkesti juhtumeid, kus me v\u00f5itlesime viie protsendi j\u00f5udluse nimel, mis eristas meie arendust eelmisest jaoturist. Ja iga kord n\u00e4eb see v\u00e4lja nii: kuskil v\u00f5itsime, kuskil kaotasime. Kui sul on head j\u00f5udluse anal\u00fc\u00fcsi t\u00f6\u00f6riistad, saad leida kaotavad ideed ja m\u00f5ista, miks nad kaotavad. V\u00f5ib-olla tasub j\u00e4tta k\u00f5ik nii, nagu on, aga v\u00f5ib-olla peaks t\u00f5sisemalt j\u00f5udluse h\u00e4\u00e4lestamiseks j\u00e4rele m\u00f5tlema v\u00f5i minema ja midagi muud parandama. See on terve hulk asju! Ma tegin selle toreda nippi, aga mulle on vaja ka seda, ja seda, ja seda \u2013 ja nende kogusumma toob kaasa teatavaid parandusi. Ja \u00fcksikud v\u00f5ivad eba\u00f5nnestuda. 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 jaotajate v\u00e4rvimine on juba lahendatud \u00fclesanne. Noh, teie jaoks lahendatud, arvestades, mida te r\u00e4\u00e4gite, nii et kas siis \u00fcldse tasub\u2026<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: See, it's not solved as such. It's you who must turn it into a 'solved' one. There are hard problems, and they need solving. When that's done, it's time to work on performance. This work needs to be approached appropriately \u2014 conduct benchmarks, gather metrics, explain situations where reverting to a previous version made your old hack work again (or vice versa, caused it to stop working). And don\u2019t give up until you achieve something. As I\u2019ve said, there are great ideas that didn\u2019t work out, but in the realm of register allocation, ideas are practically infinite. For instance, you can read scientific publications. Although this area has started moving much slower now and has become clearer than in its early days. Nevertheless, an entire infinity of people works in this field, and all their ideas are worth trying, they are all waiting for their moment. You can't tell how good they are unless you try them out. How well they integrate with everything else in your allocator, since an allocator does a multitude of things, and some ideas might not work in your specific allocator but could flourish in another. The main way for an allocator to win is to pull the slow stuff out of the main path and force a split across the boundaries of slow paths. So, if you want to trigger GC, take the slow path, deoptimize, throw exceptions, everything in that vein \u2014 you know these things are relatively rare. And they really are rare; I\u2019ve checked. You put in extra work, and as a result, numerous constraints on these slow paths disappear, but that\u2019s not very significant because they are slow and rarely traversed. For example, a null pointer \u2014 it never happens, right? You need to have several paths for different things, but they shouldn't interfere on the main one.\u00a0<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: What do you think about multi-core processing when there are thousands of cores at once? Is it a useful thing?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: The success of GPUs shows that it's quite beneficial!<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: They are quite specialized. What about general-purpose processors?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Noh, see oli Azul'i \u00e4rimudel. Vastus tuli veel ajal, mil inimesed armastasid v\u00e4ga prognoositavat j\u00f5udlust. Sel ajal oli paralleelse koodi kirjutamine keeruline. H2O kodeerimismudel skaleerub h\u00e4sti, kuid see ei ole \u00fcldotstarbeline mudel. Ainult veidi \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 andis, sai siit: v\u00e4ikesed vahem\u00e4lud on t\u00e4iesti okei.\u00a0<\/p>\n<p><\/p>\n<h1 id=\"samyy-bolshoy-chellenzh-v-zhizni\">The biggest challenge in life<\/h1>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Ent kuidas on asjadega, mis ei ole tehnilised v\u00e4ljakutsed?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Suurim v\u00e4ljakutse oli mitte olla... lahke ja hea inimeste suhtes. Selle tagaj\u00e4rjel satun pidevalt \u00e4\u00e4rmiselt konfliktsetesse olukordadesse. Situatsioonides, kus ma teadsin, et k\u00f5ik l\u00e4heb valesti, kuid ei teadnud, kuidas edasi liikuda nende probleemide lahendamisel ja ei saanud nendega hakkama. Palju pikaajalisi probleeme, mis kestsid k\u00fcmneid aastaid, ilmus just sellisel viisil. See, et Java-s on C1 ja C2 kompilaatorid, on sellest otsene tagaj\u00e4rg. See, et Java-s ei olnud k\u00fcmme aastat mitmeastmelist kompileerimist, on samuti otsene tagaj\u00e4rg. On t\u00f5en\u00e4oline, et meil sellist s\u00fcsteemi t\u00f5eliselt vajasime, kuid pole selge, miks seda ei olnud. Mul olid probleemid \u00fche inseneriga... v\u00f5i inseneride grupiga. Aastaid tagasi, kui ma hakkasin t\u00f6\u00f6tama Sunis, olin ma... Okei, mitte ainult siis, mul on tegelikult alati oma arvamus. Ja ma pean t\u00f5eks, et saaks lihtsalt v\u00f5tta oma t\u00f5e ja \u00f6elda seda otse. Eriti arvestades, et mul oli enamikul ajast \u0161okeerivalt \u00f5igus. Ja kui sulle see l\u00e4henemine ei meeldi... eriti kui sa oled ilmselgelt vale ja teed rumalusi... \u00dcldiselt, mitte paljud inimesed ei suutnud sellist suhtlemisviisi taluda. Kuigi m\u00f5ned suudavad, n\u00e4iteks mina. Olen kogu elu ehitanud meritokraatia p\u00f5him\u00f5tetele. Kui sa n\u00e4itad mulle midagi vale, p\u00f6\u00f6rdun ma kohe ringi ja \u00fctlen: sa \u00fctlesid rumalust. Sellega loomulikult palun vabandust ja k\u00f5ik selline, tunnustan saavutusi, kui neid t\u00f5esti on, ja teen teisi \u00f5igeid samme. Teiselt poolt, mul on \u0161okeerivalt palju \u00f5igus \u0161okeerivalt suure osa ajast. Ja see ei m\u00f5ju suhetes inimestega h\u00e4sti. Ma ei proovi isegi olla armas, vaid panen k\u00fcsimuse teravalt ette. \u201eSee ei t\u00f6\u00f6ta kunagi, sest p\u00f5hjus, kaks ja kolm.\u201d Ja nemad on sellised: \u201eOi!\u201d. Oli ka teisi tagaj\u00e4rgi, mida oleks parem ilmselt vahele j\u00e4tta: n\u00e4iteks need, mis viisid lahutuseni oma naisest ja k\u00fcmne aasta jooksul kestnud depressioonini p\u00e4rast seda.<\/p>\n<p><\/p>\n<p>V\u00e4ljakutse on v\u00f5itlus inimestega, nende arusaamadega, mida sa saad teha v\u00f5i mitte, mis on oluline ja mis mitte. On olnud palju v\u00e4ljakutseid koodimist\u00fc\u00fcbi osas. Ma kirjutan endiselt palju koodi, ja tookord pidin isegi aeglustama, sest tegin liiga palju paralleelseid \u00fclesandeid ja tegin need halvasti, selle asemel et keskenduda \u00fchele. Tagasi vaadates kirjutasin ma poole Java JIT meeskonna koodist, C2 meeskonnast. Kiiruselt j\u00e4rgmine koodija kirjutas poole aeglasemalt, j\u00e4rgmine veel poole aeglasemalt ja see oli eksponentsiaalne langus. Seitsmes inimene selles reas oli v\u00e4ga, v\u00e4ga aeglane \u2013 nii see ikka kipub olema! Ma puutusin kokku hulga koodiga. Ma vaatasin, kes mida kirjutab, ilma eranditeta, uurisin nende koodi, tegin iga\u00fche \u00fclevaate ja kirjutasin endiselt rohkem, kui keegi nendest. Inimeste jaoks selline l\u00e4henemine ei toimi v\u00e4ga h\u00e4sti. M\u00f5ned ei armasta seda. Ja kui nad ei suuda sellega toime tulla, siis hakkavad igasugused kaebused. N\u00e4iteks \u00f6eldi mulle kord, et pean l\u00f5petama koodi kirjutamise, kuna ma kirjutan liiga palju koodi ja see seab meeskonna ohtu, ja minu jaoks k\u00f5las see nagu nalja: kutid, kui kogu \u00fclej\u00e4\u00e4nud meeskond kaob ja ma j\u00e4tkan koodi kirjutamist, kaotad sa ainult poole meeskonnast. Teisest k\u00fcljest, kui ma j\u00e4tkan koodi kirjutamist ja sa kaotad poole meeskonna \u2013 see k\u00f5lab v\u00e4ga halva juhtimise poolena. Ma ei ole kunagi eriti m\u00f5elnud sellele, kunagi sellest r\u00e4\u00e4kinud, aga see oli ikkagi kuskil mu peas. Teadvuse tagahoovis keerles m\u00f5te: \"Kas te l\u00f5butsete v\u00f5i?\" Seega, k\u00f5ige suurem probleem olin mina ja minu suhted inimestega. N\u00fc\u00fcd m\u00f5istan ennast palju paremini, olen pikalt juhtinud programmiere ning n\u00fc\u00fcd \u00fctlen otse inimestele: tead, ma olen selline, nagu olen, ja teil tuleb minuga leppida \u2013 kas saan siin seista? Ja kui nad hakkasid sellega toime tulema, hakkas k\u00f5ik paremini toimima. Ma ei ole tegelikult ei halb ega hea, mul pole mingeid halbu kavatsusi v\u00f5i isekaid eesm\u00e4rke, see on lihtsalt minu olemus ja sellega tuleb kuidagi elada.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Alles hiljuti hakati r\u00e4\u00e4kima eneseteadlikkusest introvertide jaoks ja \u00fcldiselt pehmetest oskustest. Mida selle kohta \u00f6elda?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Jah, see oli arusaam ja \u00f5ppetund, mille ma oma lahutusest naisega sain. Mida ma oma lahutusest \u00f5ppisin \u2013 see on arusaam enda kohta. Nii hakkasin ma m\u00f5istma teisi inimesi. M\u00f5istma, kuidas see interaktsioon toimib. See t\u00f5i endaga kaasa avastusi j\u00e4rjestikku. Ilmnes arusaam, kes ma olen ja mida endast kujutan. Mida ma teen: kas olen mures \u00fclesande p\u00e4rast, v\u00e4ldin konflikti v\u00f5i midagi muud \u2013 ja selline eneseteadlikkuse tase aitab t\u00f5eliselt hoida end kontrolli all. P\u00e4rast seda l\u00e4heb k\u00f5ik palju lihtsamalt. \u00dcks asi, mille ma avastasin mitte ainult enda, vaid ka teiste programmeerijate juures \u2013 on v\u00f5imetus v\u00e4ljendada m\u00f5tteid, kui sa oled emotsionaalses stressis. N\u00e4iteks istud ja kodeerid, oled voos ja siis jookseb keegi sinu juurde ning hakkab h\u00fcsteeriliselt karjuma, et midagi on katki ja n\u00fc\u00fcd rakendatakse sinule \u00e4\u00e4rmuslikke meetmeid. Ja sa ei suuda s\u00f5nagi \u00f6elda, sest oled emotsionaalses stressis. Omandatud teadmised v\u00f5imaldavad valmistuda selle hetkeks, seda \u00fcle elada ja liikuda taganemisplaani juurde, p\u00e4rast mida on v\u00f5imalik midagi ette v\u00f5tta. Nii et jah, kui hakkad aru saama, kuidas see k\u00f5ik toimib \u2013 see on suur elu muutnud s\u00fcndmus.\u00a0<br \/>\nMina ise ei suutnud leida \u00f5iged s\u00f5nad, kuid m\u00e4letan tegevuste j\u00e4rjekorda. \u00dcksikasjalikult on see reaktsioon \u2013 f\u00fc\u00fcsiliselt sama palju kui verbaalselt, ja sul on vaja ruumi. Sellist ruumi, zen-m\u00f5ttes. Just seda tuleb seletada ja seej\u00e4rel kohe k\u00f5rvale astuda \u2013 f\u00fc\u00fcsiliselt k\u00f5rvale astuda. Kui ma ei r\u00e4\u00e4gi, saan ma olukorda emotsioonide osas t\u00f6\u00f6delda. Kui adrenaliin j\u00f5uab ajju, l\u00fclitab sind see re\u017eiimisse 'l\u00f6\u00f6 v\u00f5i p\u00f5gene', sa ei saa enam midagi r\u00e4\u00e4kida, ei \u2013 n\u00fc\u00fcd oled sa idiot, l\u00f6\u00f6misteks m\u00f5eldud insener, kes ei suuda anda v\u00e4\u00e4rilist vastust ega isegi peatada r\u00fcnnakut, ja r\u00fcndaja saab vabalt uuesti ja uuesti r\u00fcnnata. Esiteks pead taas iseendaks saama, taastama kontrolli, v\u00e4ljumiseks re\u017eiimist 'l\u00f6\u00f6 v\u00f5i p\u00f5gene'. <\/p>\n<p><\/p>\n<p>Ja selleks on vajalik verbaalne ruum. Lihtsalt vaba ruum. Kui midagi \u00f6elda, siis saabki just seda v\u00e4ita, ja seej\u00e4rel minna t\u00f5eliselt leida endale \"ruum\": jalutada pargis, sulguda du\u0161i alla \u2013 pole t\u00e4htis. Peamine on ajutiselt end olukorrast eemaldada. Niipea kui sa v\u00e4hemalt paariks sekundiks eemaldud, naaseb kontroll, hakkad m\u00f5tlema selgelt. \"Noh, ma ei ole ju mingi idioot, ma ei tee rumalaid asju, ma olen \u00fcsna kasulik inimene.\" Niipea kui sa suudad end veenda, on aeg liikuda j\u00e4rgmisele etapile: m\u00f5ista, mis juhtus. Sulle r\u00fcnnati, r\u00fcnnak tuli kohast, kust ei oodatud, see oli ebaaus ja k\u00fc\u00fcniline l\u00f5ks. See on halb. J\u00e4rgmine samm on m\u00f5ista, miks r\u00fcndajal seda vajalik oli. T\u00f5eliselt, miks? V\u00f5ib-olla sellep\u00e4rast, et ta ise on vihane? Miks ta on vihane? N\u00e4iteks sellep\u00e4rast, et ta eksis ja ei saa vastutust v\u00f5tta? Nii tuleb hoolikalt k\u00e4sitleda kogu olukorda. Kuid selleks on vaja man\u00f6\u00f6verdusruumi, verbaalset ruumi. K\u00f5ige esimene samm on katkestada verbaalne kontakt. Eemale minna aruteludest s\u00f5nades. T\u00fchistada see, minna minema nii kiiresti kui v\u00f5imalik. Kui see on telefonik\u00f5ne - lihtsalt pane toru \u00e4ra - see on oskus, mille ma sain suhtlemisest oma endise abikaasaga. Kui k\u00f5ne ei vii kuskile headesse kohtadesse, lihtsalt \u00fctle \"head aega\" ja pane toru \u00e4ra. Teiselt poolt toru: \"bla-bla-bla\", sa vastad: \"aha, t\u0161au!\" ja paned toru \u00e4ra. Lihtsalt katkestad vestluse. Viie minuti p\u00e4rast, kui su m\u00f5tlemisv\u00f5ime naaseb, oled sa natuke jahtunud, on v\u00f5imalik m\u00f5elda, mis siis ikkagi juhtus ja mis edasi saab. Ja hakata formuleerima m\u00f5eldud vastust, mitte lihtsalt reageerida emotsioonidele. Minu jaoks oli l\u00e4bimurdeks eneseteadvuses see, et emotsionaalse stressi korral ei suuda ma r\u00e4\u00e4kida. Sellest seisundist v\u00e4lja astuda, m\u00f5elda ja planeerida, kuidas vastata ja kompenseerida probleeme \u2013 need on \u00f5iged sammud, kui sa ei saa r\u00e4\u00e4kida. Lihtsaim viis on p\u00f5geneda olukorrast, kus emotsionaalne stress ilmneb ja lihtsalt l\u00f5petada selles stressis osalemine. P\u00e4rast seda saad sa m\u00f5elda, kui sa suudad m\u00f5elda, tekib v\u00f5imalus r\u00e4\u00e4kida ja nii edasi.<\/p>\n<p><\/p>\n<p>Muide, kohtus \u00fcritab vastaspoole advokaat seda sinuga teha \u2013 n\u00fc\u00fcd on juba selge, miks. Sest tal on v\u00f5imalus sind nii maha suruda, et sa ei suuda isegi oma nime v\u00e4lja \u00f6elda, n\u00e4iteks. Kirja s\u00f5nas m\u00f5ttes, sa ei saa r\u00e4\u00e4kida. Kui sinuga juhtub nii ja kui sa tead, et j\u00f5uad kohta, kus k\u00e4ivad s\u00f5nalised lahingud, kohtusse, siis v\u00f5ib tulla oma juristiga. Jurist kaitseb sind ja l\u00f5petab s\u00f5nalise r\u00fcnnaku ning teeb seda t\u00e4iesti seaduslikul teel, ja sinu kadunud zen-ruum naaseb. N\u00e4iteks, mul oli paar korda vaja helistada perele, kohtunik suhtus sellesse \u00fcsna s\u00f5bralikult, kuid vastaspoole advokaat karjus ja karjus mulle peale, ma ei saanud isegi s\u00f5na vahele \u00f6elda. Sellistes olukordades t\u00f6\u00f6tab minu jaoks k\u00f5ige paremini vahendaja kasutamine. Vahendaja l\u00f5petab kogu selle pideva surve, mis sinu peale voolab, sa avastad vajaliku zen-ruumi, koos sellega naaseb ka r\u00e4\u00e4kimisv\u00f5ime. See on terve teadmiste valdkond, milles tuleb palju \u00f5ppida, palju endas avastada, ja k\u00f5ik see muutub k\u00f5rgetasemelisteks strateegilisteks otsusteks, mis on erinevad eri inimeste vahel. M\u00f5nel inimesel ei ole eespool kirjeldatud probleeme, tavaliselt puuduvad need inimestel, kes tegelevad professionaalselt 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 ei ole selliseid probleeme, kuid mul on need olemas.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: See oli\u2026 ootamatu. Suurep\u00e4rane, me oleme juba p\u00e4ris palju r\u00e4\u00e4kinud ja on aeg see intervjuu l\u00f5petada. Me kohtume kindlasti konverentsil ja saame seda dialooge j\u00e4tkata. Kohtume Hydra konverentsil!<\/p>\n<p><\/p>\n<blockquote><p>J\u00e4tkata suhtlemist Cliffiga saab Hydra 2019 konverentsil, mis toimub 11.-12. juulil 2019 Peterburis. Ta tuleb ettekandega <noindex><a rel=\"nofollow\" href=\"https:\/\/hydraconf.com\/2019\/talks\/2jix5mst7iduyp9linqhfj\/?utm_source=habr&amp;utm_medium=45871\">\u201eThe Azul Hardware Transactional Memory experience\u201c<\/a><\/noindex>. Piletid on saadaval <noindex><a rel=\"nofollow\" href=\"https:\/\/hydraconf.ru\/?utm_source=habr&amp;utm_medium=458718\">ametlikult 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 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u043b\u0438\u0444\u0444 \u041a\u043b\u0438\u043a \u2014.\" \/>\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) 5.0.1.1\" \/>\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.\" \/>\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 Cliff Clickiga \u2013 Java JIT-kompileerimise isa | ProHoster","description":"Cliff Click \u2013.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}