{"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\/sv\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java","title":{"rendered":"Stort intervju med Cliff Click \u2013 fadern till JIT-kompilering i Java","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Stort intervju med Cliff Click \u2013 fadern till JIT-kompilering i Java\" src=\"\/wp-content\/uploads\/2019\/07\/9ea9740ef74c0ae14d334482af115222.png\" style=\"display:block;margin: 0 auto;\" \/><strong>Cliff Click<\/strong> \u2013 CTO f\u00f6r Cratus (IoT-sensorer f\u00f6r att f\u00f6rb\u00e4ttra processer), grundare och medgrundare av flera startups (inklusive Rocket Realtime School, Neurensic och H2O.ai) med flera framg\u00e5ngsrika exits. Cliff skrev sin f\u00f6rsta kompilator vid 15 \u00e5rs \u00e5lder (Pascal f\u00f6r TRS Z-80)! Mest k\u00e4nd f\u00f6r sitt arbete med C2 i Java (the Sea of Nodes IR). Denna kompilator visade v\u00e4rlden att JIT kan producera kvalitetskoden, vilket var en av faktorerna bakom Java som en av de fr\u00e4msta moderna programplattformarna. D\u00e4refter hj\u00e4lpte Cliff Azul Systems att bygga en 864-k\u00e4rnig mainframe med programvara i ren Java, som hanterade GC-pausar p\u00e5 500 gigabyte heap inom 10 millisekunder. Generellt har Cliff arbetat med alla aspekter av JVM.<br clear=\"all\"><br \/>\n\u00a0<br \/>\nDetta huxleypost \u00e4r ett stort intervju med Cliff. Vi kommer att diskutera f\u00f6ljande \u00e4mnen:<\/p>\n<p><\/p>\n<ul>\n<li>\u00d6verg\u00e5ng till l\u00e5gniv\u00e5optimeringar<\/li>\n<li>Hur man g\u00f6r en omfattande omstrukturering<\/li>\n<li>Kostnadsmodell<\/li>\n<li>Utbildning i l\u00e5gniv\u00e5optimeringar<\/li>\n<li>Praktiska exempel p\u00e5 prestandaf\u00f6rb\u00e4ttringar<\/li>\n<li>Varf\u00f6r skapa ditt eget programmeringsspr\u00e5k<\/li>\n<li>Karri\u00e4r som prestandingenj\u00f6r<\/li>\n<li>Tekniska utmaningar<\/li>\n<li>Lite om registerallokering och flerk\u00e4rnighet<\/li>\n<li>Den st\u00f6rsta utmaningen i livet<\/li>\n<\/ul>\n<p><\/p>\n<p>Intervjuas av:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Andrey Sataryan<\/strong> fr\u00e5n Amazon Web Services. Under sin karri\u00e4r har han arbetat med helt olika projekt: testat distribuerad NewSQL-databas p\u00e5 Yandex, ett molndetekteringssystem p\u00e5 Kaspersky Lab, ett flerspelarspel p\u00e5 Mail.ru och en valutakalkylatorstj\u00e4nst p\u00e5 Deutsche Bank. Han \u00e4r intresserad av testning av storskaliga backend- och distribuerade system.<\/li>\n<li><strong>Vladimir Sitnikov<\/strong> fr\u00e5n Netcracker. Han har arbetat i tio \u00e5r med prestanda och skalbarhet i NetCracker OS \u2013 mjukvara som anv\u00e4nds av telekomoperat\u00f6rer f\u00f6r att automatisera n\u00e4tverks- och n\u00e4tverksutrustningshantering. Han \u00e4r intresserad av prestandafr\u00e5gor relaterade till Java och Oracle Database. F\u00f6rfattare av mer \u00e4n ett dussin prestandaf\u00f6rb\u00e4ttringar i den officiella PostgreSQL JDBC-drivern.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"perehod-k-nizkourovnevym-optimizaciyam\">\u00d6verg\u00e5ng till l\u00e5gniv\u00e5optimeringar<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Du \u00e4r en v\u00e4lk\u00e4nd person inom JIT-kompilering, Java och arbete med prestanda i allm\u00e4nhet, eller hur?\u00a0<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Det st\u00e4mmer!<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: L\u00e5t oss b\u00f6rja med allm\u00e4nna fr\u00e5gor om prestandaarbete. Vad tycker du om valet mellan h\u00f6g- och l\u00e5g-niv\u00e5optimeringar som arbete p\u00e5 CPU-niv\u00e5?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Det \u00e4r enkelt. Den snabbaste koden \u00e4r den som aldrig k\u00f6rs. S\u00e5 det \u00e4r viktigt att alltid b\u00f6rja p\u00e5 en h\u00f6g niv\u00e5 och arbeta med algoritmer. En b\u00e4ttre O-notation sl\u00e5r en s\u00e4mre O-notation, s\u00e5 l\u00e4nge ingen stor konstant blandar sig i. L\u00e5g-niv\u00e5arbete kommer sist. Vanligtvis, om du har optimerat hela den andra stapeln tillr\u00e4ckligt v\u00e4l, och det fortfarande finns n\u00e5got intressant kvar \u2013 d\u00e5 \u00e4r det l\u00e5g niv\u00e5. Men hur b\u00f6rjar man p\u00e5 h\u00f6g niv\u00e5? Hur vet man att man har gjort tillr\u00e4ckligt arbete p\u00e5 h\u00f6g niv\u00e5? Tja\u2026 ingen aning. Det finns inga f\u00e4rdiga recept. Du m\u00e5ste f\u00f6rst\u00e5 problemet, best\u00e4mma vad du t\u00e4nker g\u00f6ra (f\u00f6r att inte g\u00f6ra on\u00f6diga steg senare) och f\u00f6rst d\u00e5 kan du plocka fram en profilerare som kan s\u00e4ga n\u00e5got anv\u00e4ndbart. Vid n\u00e5got tillf\u00e4lle f\u00f6rst\u00e5r du sj\u00e4lv att du har blivit av med on\u00f6diga saker och det \u00e4r dags att b\u00f6rja finjustera p\u00e5 l\u00e5g niv\u00e5. Det \u00e4r absolut en speciell typ av konst. M\u00e5nga g\u00f6r on\u00f6diga saker, men rusar s\u00e5 snabbt att de inte har tid att t\u00e4nka p\u00e5 prestanda. Men det \u00e4r s\u00e5 l\u00e4nge fr\u00e5gan inte blir akut. Oftast \u00e4r 99% av tiden ingen intresserad av vad jag g\u00f6r, f\u00f6rr\u00e4n n\u00e5got viktigt blockerar den kritiska v\u00e4gen och n\u00e5gon bryr sig. Och d\u00e5 b\u00f6rjar alla ifr\u00e5gas\u00e4tta varf\u00f6r det fr\u00e5n b\u00f6rjan inte fungerade perfekt. Det finns alltid n\u00e5got att f\u00f6rb\u00e4ttra i prestandan. Men 99% av tiden har du inga ledtr\u00e5dar! Du f\u00f6rs\u00f6ker bara f\u00e5 n\u00e5got att fungera och under v\u00e4gen inser du vad som \u00e4r viktigt. Du kan aldrig veta i f\u00f6rv\u00e4g att just den h\u00e4r biten m\u00e5ste vara perfekt, s\u00e5 i grunden m\u00e5ste du vara perfekt i allt. Och det \u00e4r om\u00f6jligt och s\u00e5 g\u00f6r du inte. Det finns alltid massor av saker att fixa \u2013 och det \u00e4r helt okej.<\/p>\n<p><\/p>\n<h1 id=\"kak-delat-bolshoy-refaktoring\">Hur man g\u00f6r en omfattande omstrukturering<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Hur arbetar du med prestanda? Det \u00e4r ju ett genomg\u00e5ende problem. Har du till exempel varit tvungen att hantera problem som uppst\u00e5r till f\u00f6ljd av att m\u00e5nga redan existerande funktioner korsar varandra?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Jag f\u00f6rs\u00f6ker undvika det. Om jag vet att prestanda kommer att bli ett problem t\u00e4nker jag p\u00e5 det innan jag b\u00f6rjar koda, s\u00e4rskilt ang\u00e5ende datastrukturer. Men ofta uppt\u00e4cker du allt detta mycket senare. Och d\u00e5 m\u00e5ste du ta till extrema \u00e5tg\u00e4rder och g\u00f6ra det jag kallar \"skriv om och h\u00e4rska\": du m\u00e5ste greppa ett tillr\u00e4ckligt stort stycke. En del av koden m\u00e5ste \u00e4nd\u00e5 skrivas om p\u00e5 grund av prestandaproblem eller n\u00e5got annat. Oavsett orsak till att skriva om koden, \u00e4r det n\u00e4stan alltid b\u00e4ttre att skriva om ett st\u00f6rre segment \u00e4n ett mindre. I det \u00f6gonblicket b\u00f6rjar alla darra av r\u00e4dsla: \"\u00c5h nej, vi f\u00e5r inte r\u00f6ra s\u00e5 mycket kod!\" Men i sj\u00e4lva verket fungerar det n\u00e4stan alltid mycket b\u00e4ttre. Du m\u00e5ste ta itu med det stora problemet, rita en stor cirkel runt det och s\u00e4ga: allt inom cirkeln kommer jag att skriva om. Gr\u00e4nsen \u00e4r mycket mindre \u00e4n det inneh\u00e5ll som ska ers\u00e4ttas. Och om s\u00e5dan gr\u00e4nss\u00e4ttning g\u00f6r att arbetet inuti blir perfekt \u2013 har du fria h\u00e4nder, g\u00f6r vad du vill. S\u00e5 snart du f\u00f6rst\u00e5r problemet g\u00e5r omprosesseringen mycket smidigare, s\u00e5 ta en stor bit!<br \/>\nSamtidigt, n\u00e4r du g\u00f6r om ett stort segment och inser att prestanda kommer att bli ett problem, kan du b\u00f6rja oroa dig f\u00f6r det direkt. Vanligtvis blir det till enkla saker som \"kopiera inte data, hantera data s\u00e5 enkelt som m\u00f6jligt, g\u00f6r dem mindre\". Vid stora omskrivningar finns det standardmetoder f\u00f6r att f\u00f6rb\u00e4ttra prestanda. Och de kretsar n\u00e4stan alltid kring data.<\/p>\n<p><\/p>\n<h1 id=\"model-stoimosti\">Kostnadsmodell<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: I ett av podcastavsnitten pratade ni om kostnadsmodeller i samband med prestanda. Kan ni f\u00f6rklara vad ni menade med det?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Sj\u00e4lvklart. Jag f\u00f6ddes i en tid n\u00e4r processorprestanda var oerh\u00f6rt viktigt. Och den eran \u00e5terv\u00e4nder \u2013 \u00f6det \u00e4r inte utan ironi. Jag b\u00f6rjade leva under tiden f\u00f6r \u00e5ttabitarsmaskiner, min f\u00f6rsta dator fungerade med 256 byte. Just byte. Allt var v\u00e4ldigt litet. Man var tvungen att r\u00e4kna instruktioner och s\u00e5 snart vi b\u00f6rjade avancera upp\u00e5t i programmeringsspr\u00e5kens stack, tog spr\u00e5ken p\u00e5 sig mer och mer. Det fanns assembler, sedan Basic, sedan C, och C tog hand om m\u00e5nga detaljer, som registreringsf\u00f6rdelning och instruktionstypning. Men d\u00e4r var allt ganska tydligt och om jag gjorde en pekare till en instans av en variabel, d\u00e5 skulle jag f\u00e5 load, och kostnaden f\u00f6r den instruktionen \u00e4r k\u00e4nd. H\u00e5rdvaran ger ett k\u00e4nt antal maskincykler, s\u00e5 hastigheten f\u00f6r att k\u00f6ra olika saker kan ber\u00e4knas genom att helt enkelt summera alla instruktioner som du t\u00e4nker k\u00f6ra. Varje compare\/test\/branch\/call\/load\/store kunde summeras och s\u00e4gas: h\u00e4r har du k\u00f6rningstiden. N\u00e4r du arbetar med att f\u00f6rb\u00e4ttra prestanda kommer du definitivt att notera vilka siffror som motsvarar de sm\u00e5 heta cyklerna.\u00a0<br \/>\nMen s\u00e5 snart du v\u00e4xlar till Java, Python och liknande, avl\u00e4gsnar du dig v\u00e4ldigt snabbt fr\u00e5n l\u00e5gniv\u00e5h\u00e5rdvara. Vad kostar det att anropa en getter i Java? Om JIT i HotSpot gjorde allt r\u00e4tt <noindex><a rel=\"nofollow\" href=\"https:\/\/wiki.openjdk.java.net\/display\/HotSpot\/Inlining\">inlinat<\/a><\/noindex>, kommer det att bli load, men om det inte gjorde det \u2013 kommer det att bli ett funktionsanrop. Eftersom anropet ligger p\u00e5 den heta cykeln, kommer det att avbryta alla andra optimeringar i denna cykel. S\u00e5 den verkliga kostnaden kommer att vara mycket h\u00f6gre. Och du f\u00f6rlorar omedelbart f\u00f6rm\u00e5gan att titta p\u00e5 en kodsnutt och f\u00f6rst\u00e5 vad det kostar att k\u00f6ra den i termer av processorhastighet, anv\u00e4nd minne och cache. Allt detta blir intressant f\u00f6rst n\u00e4r du verkligen gr\u00e4ver ner dig i prestanda.<br \/>\nJust nu befinner vi oss i en situation d\u00e4r processorernas hastighet knappt har \u00f6kat p\u00e5 ett decennium. Gamla tider \u00e5terv\u00e4nder! Du kan inte l\u00e4ngre r\u00e4kna med bra prestanda i enkeltr\u00e5dar. Men om du pl\u00f6tsligt ger dig in p\u00e5 parallella ber\u00e4kningar \u2013 det \u00e4r galet komplicerat, alla ser p\u00e5 dig som om du vore James Bond. Tio g\u00e5nger snabbare prestanda uppst\u00e5r vanligtvis d\u00e4r n\u00e5gon har missat n\u00e5got. Parallellitet kr\u00e4ver mycket jobb. F\u00f6r att uppn\u00e5 den d\u00e4r tio g\u00e5nger snabbare prestandan beh\u00f6ver man f\u00f6rst\u00e5 kostnadsmodellen. Vad kostar vad? Och f\u00f6r att g\u00f6ra det m\u00e5ste man f\u00f6rst\u00e5 hur spr\u00e5ket ligger \u00f6ver den underliggande h\u00e5rdvaran.<br \/>\nMartin Thompson har valt ett utm\u00e4rkt ord f\u00f6r sin blogg <noindex><a rel=\"nofollow\" href=\"https:\/\/mechanical-sympathy.blogspot.com\/\">Mechanical Sympathy<\/a><\/noindex>! Man m\u00e5ste f\u00f6rst\u00e5 vad h\u00e5rdvaran kommer att g\u00f6ra, hur den kommer att g\u00f6ra det, och varf\u00f6r den \u00f6verhuvudtaget g\u00f6r det den g\u00f6r. Genom att anv\u00e4nda detta \u00e4r det ganska enkelt att b\u00f6rja r\u00e4kna instruktioner och ta reda p\u00e5 vart exekveringstiden tar v\u00e4gen. Om du inte har r\u00e4tt f\u00f6rberedelse, letar du bara efter en svart katt i ett m\u00f6rkt rum. Jag ser hela tiden folk som optimerar prestanda utan att ha minsta aning om vad de egentligen g\u00f6r. De k\u00e4mpar h\u00e5rt och kommer inte s\u00e4rskilt l\u00e5ngt. Och n\u00e4r jag tar samma kodbit, l\u00e4gger till ett par sm\u00e5 hacks och f\u00e5r fem g\u00e5nger eller tio g\u00e5nger snabbare prestanda, s\u00e4ger de: tja, det \u00e4r inte r\u00e4ttvist, vi visste ju att du var b\u00e4ttre. Otroligt. Vad var jag p\u00e5 v\u00e4g att s\u00e4ga... kostnadsmodellen handlar om den kod du skriver och hur snabbt den i genomsnitt fungerar i det stora hela.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Och hur inneh\u00e5ller man en s\u00e5 stor m\u00e4ngd information i huvudet? Det uppn\u00e5s genom mycket erfarenhet, eller? Var hittar man s\u00e5dan erfarenhet?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Tja, min erfarenhet fick jag inte p\u00e5 ett enkelt s\u00e4tt. Jag programmerade i assembler p\u00e5 den tiden n\u00e4r man kunde f\u00f6rst\u00e5 varje enskild instruktion. Det l\u00e5ter kanske dumt, men sedan dess har jag i mitt minne ett f\u00f6r alltid best\u00e5ende set av Z80-instruktioner. Jag kommer inte ih\u00e5g namnen p\u00e5 m\u00e4nniskor en minut efter samtalet, men jag kommer ih\u00e5g kod som skrevs f\u00f6r 40 \u00e5r sedan. Roligt, det ser ut som ett \"<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\">idiotens vetenskapsman<\/a><\/noindex>\u00bb.<\/p>\n<p><\/p>\n<h1 id=\"obuchenie-nizkourovnevym-optimizaciyam\">Utbildning i l\u00e5gniv\u00e5optimeringar<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>\": Finns det n\u00e5got enklare s\u00e4tt att komma in p\u00e5 det?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Ja och nej. H\u00e5rdvaran som vi alla anv\u00e4nder har inte f\u00f6r\u00e4ndrats s\u00e5 mycket under denna tid. Alla anv\u00e4nder x86, f\u00f6rutom smartphones som k\u00f6r p\u00e5 Arm. Om du inte sysslar med n\u00e5got hardcore embedded s\u00e5 har du helt enkelt samma sak. Okej, vidare. Instruktionerna har inte heller f\u00f6r\u00e4ndrats p\u00e5 \u00e5rhundraden. Man m\u00e5ste g\u00e5 och skriva n\u00e5got i assembler. Lite grann, men tillr\u00e4ckligt f\u00f6r att b\u00f6rja f\u00f6rst\u00e5. Ni ler, men jag s\u00e4ger det helt seri\u00f6st. Man beh\u00f6ver f\u00f6rst\u00e5 kopplingen mellan spr\u00e5k och h\u00e5rdvara. Efter det m\u00e5ste man g\u00e5 och skriva lite kod och skapa en liten leksakskompilator f\u00f6r ett litet leksaksspr\u00e5k.<br \/>\nVar kan man f\u00e5 en kostnadsmodell? Jo, man kan l\u00e4sa n\u00e5got, sj\u00e4lvklart... Men jag tror att det b\u00e4sta s\u00e4ttet \u00e4r att agera. G\u00f6ra en liten kompilator och det skulle vara det b\u00e4sta s\u00e4ttet att f\u00f6rst\u00e5 kostnadsmodellen och passa in den i sitt eget sinne. En liten kompilator som skulle fungera f\u00f6r att programmera en mikrov\u00e5gsugn \u2013 det \u00e4r en uppgift f\u00f6r nyb\u00f6rjare. Jag menar, om du redan har programmeringskunskaper borde det r\u00e4cka. Allt detta med att parsa en str\u00e4ng som kommer att vara n\u00e5got slags algebraiskt uttryck, h\u00e4mta instruktionerna f\u00f6r matematiska operationer i r\u00e4tt ordning, ta r\u00e4tt v\u00e4rden fr\u00e5n registren \u2013 allt detta g\u00e5r att g\u00f6ra ganska l\u00e4tt. Och medan du g\u00f6r det kommer det att etsa sig in i hj\u00e4rnan. Jag tror alla vet vad en kompilator g\u00f6r. Och detta ger f\u00f6rst\u00e5else f\u00f6r kostnadsmodellen.<\/p>\n<p><\/p>\n<h1 id=\"prakticheskie-primery-uluchsheniya-proizvoditelnosti\">Praktiska exempel p\u00e5 prestandaf\u00f6rb\u00e4ttringar<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Vad mer b\u00f6r man t\u00e4nka p\u00e5 n\u00e4r man arbetar med prestanda?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Datatyper. F\u00f6rresten, jag har inte h\u00e5llit de h\u00e4r lektionerna p\u00e5 l\u00e4nge... <noindex>Rocket School<\/noindex>. Det var roligt, men det kr\u00e4vde s\u00e5 mycket energi, och jag har ju ett liv ocks\u00e5! N\u00e5v\u00e4l. S\u00e5, p\u00e5 en av de stora och intressanta lektionerna, \"Vart tar din prestanda v\u00e4gen\", gav jag studenterna ett exempel: tv\u00e5 och ett halvt gigabyte fintech-data l\u00e4stes fr\u00e5n en CSV-fil och n\u00e4sta steg var att r\u00e4kna antalet s\u00e5lda produkter. Vanliga tickande marknadsdata. UDP-paket, omvandlade till textformat, som b\u00f6rjade p\u00e5 70-talet. Chicago Mercantile Exchange \u2013 olika saker som olja, majs, sojab\u00f6nor, och liknande. Det var n\u00f6dv\u00e4ndigt att r\u00e4kna dessa produkter, antalet aff\u00e4rer, det genomsnittliga beloppet av r\u00f6relse av medel och varor, etc. Det \u00e4r ganska enkel handelsmatematik: hitta produktkoden (detta \u00e4r 1-2 tecken i en hash-tabell), f\u00e5 summan, l\u00e4gga till den i en av aff\u00e4rerna, l\u00e4gga till volym, l\u00e4gga till kostnad, och n\u00e5gra andra saker. Mycket enkel matematik. Den leksaksm\u00e4ssiga implementationen var mycket rak p\u00e5 sak: allt ligger i filen, jag l\u00e4ser filen och g\u00e5r igenom den, delar upp individuella poster i Java-str\u00e4ngar, letar efter de n\u00f6dv\u00e4ndiga sakerna och l\u00e4gger ihop enligt ovanst\u00e5ende matematik. Och detta fungerar med en ganska liten hastighet. <\/p>\n<p><\/p>\n<p>Med en s\u00e5dan metod \u00e4r det uppenbart vad som h\u00e4nder, och parallella ber\u00e4kningar hj\u00e4lper inte h\u00e4r, eller hur? Det visar sig att fem g\u00e5nger \u00f6kad prestanda kan uppn\u00e5s enbart genom att v\u00e4lja r\u00e4tt datastrukturer. Detta \u00f6verraskar till och med erfarna programmerare! I mitt specifika fall var fokus att man inte b\u00f6r allokera minne i den heta loopen. N\u00e5v\u00e4l, det \u00e4r inte hela sanningen, men i stort sett \u2013 man b\u00f6r inte allokera \"varje X\", n\u00e4r X \u00e4r tillr\u00e4ckligt stort. N\u00e4r X \u00e4r tv\u00e5 och en halv gigabyte, b\u00f6r man inte allokera n\u00e5got \"per bokstav\", eller \"per rad\", eller \"per f\u00e4lt\"; inget s\u00e5dant. Det \u00e4r just detta som tar tid. Hur fungerar det egentligen? F\u00f6rest\u00e4ll dig att jag g\u00f6r anropet <code>String.split()<\/code> eller <code>BufferedReader.readLine()<\/code>. <code>Readline<\/code> g\u00f6r en str\u00e4ng av en upps\u00e4ttning bytes som kom \u00f6ver n\u00e4tverket, en g\u00e5ng f\u00f6r varje rad, f\u00f6r var och en av hundratals miljoner rader. Jag tar den h\u00e4r str\u00e4ngen, analyserar den och kastar bort den. Varf\u00f6r kastar jag bort den \u2013 ja, jag har redan bearbetat den, det r\u00e4cker. S\u00e5, f\u00f6r varje byte som l\u00e4ses fr\u00e5n dessa 2.7G kommer tv\u00e5 tecken att skrivas till str\u00e4ngen, vilket ger 5.4G, och de beh\u00f6vs inte l\u00e4ngre, s\u00e5 de kastas bort. Om man ser p\u00e5 minnesbandbredden, s\u00e5 laddar vi 2.7G som g\u00e5r genom minnet och minnesbussen i processorn, och sen skickas dubbelt s\u00e5 mycket in i str\u00e4ngen som ligger i minnet, och allt detta bearbetas vid skapandet av varje ny str\u00e4ng. Men jag m\u00e5ste l\u00e4sa den, h\u00e5rdvaran l\u00e4ser den, \u00e4ven om allt senare kommer att bearbetas. Och jag m\u00e5ste skriva den, f\u00f6r jag har skapat en str\u00e4ng och cacheminnena \u00e4r \u00f6verfulla \u2013 cachen kan inte rymma 2.7G. S\u00e5, f\u00f6r varje l\u00e4st byte l\u00e4ser jag tv\u00e5 ytterligare bytes och skriver tv\u00e5 ytterligare bytes, vilket ger ett f\u00f6rh\u00e5llande p\u00e5 4:1 \u2013 p\u00e5 detta s\u00e4tt sl\u00f6sar vi bort minnesbandbredden. Och det visar sig att om jag g\u00f6r <code>String.split()<\/code> \u2013 s\u00e5 g\u00f6r jag det l\u00e5ngt ifr\u00e5n f\u00f6r sista g\u00e5ngen, det kan finnas ytterligare 6-7 f\u00e4lt inuti. D\u00e4rf\u00f6r leder klassisk CSV-l\u00e4sning med efterf\u00f6ljande radparsing till f\u00f6rluster i minnesbandbredd p\u00e5 omkring 14:1 j\u00e4mf\u00f6rt med vad man egentligen skulle vilja ha. Om man sl\u00e4nger bort dessa allokeringar kan man uppn\u00e5 fem g\u00e5nger hastighets\u00f6kning. <\/p>\n<p><\/p>\n<p>Och det \u00e4r inte s\u00e4rskilt sv\u00e5rt. Om du ser p\u00e5 koden fr\u00e5n r\u00e4tt vinkel blir allt ganska enkelt, s\u00e5 snart du inser essensen av problemet. Du b\u00f6r inte sluta allokera minne \u00f6verhuvudtaget: problemet \u00e4r bara att du allokerar n\u00e5got och det d\u00f6r omedelbart, vilket br\u00e4nner en viktig resurs, som i det h\u00e4r fallet \u00e4r minnesbandbredden. Och allt detta leder till prestandafall. P\u00e5 x86 beh\u00f6ver du vanligtvis aktivt br\u00e4nna processortakter, men h\u00e4r har du br\u00e4nt all minne mycket tidigare. L\u00f6sningen \u00e4r att minska antalet allokeringar.\u00a0<br \/>\nEn annan del av problemet \u00e4r att om du k\u00f6r en profilerare n\u00e4r minnesbandbredden \u00e4r slut, precis i det \u00f6gonblick det h\u00e4nder, f\u00f6rv\u00e4ntar du dig vanligtvis att cache-minnet ska \u00e5terv\u00e4nda, eftersom det \u00e4r fullt av skr\u00e4p som du just har skapat, alla dessa str\u00e4ngar. D\u00e4rf\u00f6r blir varje load eller store-operation l\u00e5ngsam, eftersom de leder till cache-missar \u2013 hela cachen blev l\u00e5ngsam, medan den v\u00e4ntade p\u00e5 att skr\u00e4pet skulle l\u00e4mna. S\u00e5 profileraren kommer bara att visa ett varmt, slumpm\u00e4ssigt brus som \u00e4r utspritt \u00f6ver hela cykeln \u2013 det kommer inte att finnas n\u00e5gon specifik het instruktion eller plats i koden. Bara brus. Och om du tittar p\u00e5 GC-cykler, kommer de alla att vara i Young Generation och super snabba \u2013 mikrosekunder eller millisekunder h\u00f6gst. F\u00f6r all denna minne d\u00f6r omedelbart. Du allokerar miljarder gigabyte, och den sk\u00e4r, och sk\u00e4r, och sk\u00e4r igen. Allt detta sker mycket snabbt. S\u00e5 det finns billiga GC-cykler, varmt brus \u00f6ver hela cykeln, men vi vill ha en 5-faldig acceleration. Vid det \u00f6gonblicket borde n\u00e5got klicka i huvudet och l\u00e5ta som: 'Varf\u00f6r \u00e4r det s\u00e5?!'. \u00d6verskridande av minnesbandbredden visas inte i en klassisk debugger, du m\u00e5ste k\u00f6ra en debugger f\u00f6r h\u00e5rdvaru\u00f6vervakning av prestanda och se det direkt och personligen. Inte direkt kan det misst\u00e4nkas fr\u00e5n dessa tre symptom. Det tredje symptomet \u00e4r n\u00e4r du ser vad du allokerar, fr\u00e5gar profileraren, och den svarar: 'Du har gjort en miljard str\u00e4ngar, men GC har arbetat gratis'. S\u00e5 fort detta intr\u00e4ffar, f\u00f6rst\u00e5r du att du har skapat f\u00f6r m\u00e5nga objekt och br\u00e4nt hela minnesbandbredden. Det finns ett s\u00e4tt att f\u00f6rst\u00e5 detta, men det \u00e4r inte uppenbart.\u00a0<\/p>\n<p><\/p>\n<p>Problemet ligger i datakonstruktionen: den r\u00e5a strukturen bakom allt som p\u00e5g\u00e5r \u00e4r f\u00f6r stor, det \u00e4r 2,7G p\u00e5 disken, s\u00e5 att g\u00f6ra en kopia av den h\u00e4r saken \u00e4r mycket o\u00f6nskat \u2013 det \u00e4r b\u00e4ttre att ladda den direkt fr\u00e5n det n\u00e4tverksbytebuffret till registren, s\u00e5 att man inte beh\u00f6ver l\u00e4sa och skriva fram och tillbaka fem g\u00e5nger. Tyv\u00e4rr ger Java dig som standard inte ett s\u00e5dant bibliotek i JDK. Men det \u00e4r ju trivialt, eller hur? I praktiken handlar det om 5-10 rader kod som g\u00e5r till att implementera en egen buffrad radladdare, som upprepar beteendet hos klassstr\u00e4ngar, men som \u00e4nd\u00e5 \u00e4r en omslutning kring den underliggande bytebuffern. Resultatet blir att du arbetar n\u00e4stan som om du hade att g\u00f6ra med str\u00e4ngar, men i sj\u00e4lva verket flyttas pekarna p\u00e5 bufferten, och r\u00e5a byte kopieras ingenstans, och p\u00e5 s\u00e5 s\u00e4tt \u00e5teranv\u00e4nds samma buffrar g\u00e5ng p\u00e5 g\u00e5ng, och operativsystemet \u00e4r lyckligt \u00f6ver att hantera de saker som det \u00e4r avsett f\u00f6r, som dold dubbel buffring av dessa bytebuffrar, och du sj\u00e4lv maler inte l\u00e4ngre en o\u00e4ndlig str\u00f6m av on\u00f6diga data. F\u00f6rresten, f\u00f6rst\u00e5r ni, n\u00e4r man arbetar med GC garanteras det att varje minnesallokering inte kommer att synas av processorn efter den senaste GC-cykeln? S\u00e5, allt detta kan inte vara i cachen, och sen intr\u00e4ffar en 100%-ig garanti p\u00e5 en miss. N\u00e4r man arbetar med en pekare tar det 1-2 cykler att l\u00e4sa en register fr\u00e5n minnet i x86, och s\u00e5 snart detta sker, betalar du, betalar du, betalar du, f\u00f6r allt minne \u00e4r p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Cache_inclusion_policy\">NIO-cache<\/a><\/noindex> \u2013 och detta \u00e4r kostnaden f\u00f6r minnesallokering. Den verkliga kostnaden.<\/p>\n<p><\/p>\n<p>Med andra ord \u00e4r datastrukturer det som \u00e4r sv\u00e5rast att \u00e4ndra. Och s\u00e5 snart du inser att du har valt fel datastruktur, som senare kommer att p\u00e5verka prestandan negativt, kr\u00e4vs det vanligtvis en betydande arbetsinsats f\u00f6r att korrigera detta. Om du inte g\u00f6r det, kommer det bara att bli v\u00e4rre. Fr\u00e4mst m\u00e5ste man t\u00e4nka p\u00e5 datastrukturer, det \u00e4r viktigt. Den st\u00f6rsta kostnaden h\u00e4r infaller med tunga datastrukturer, som man b\u00f6rjar anv\u00e4nda med tanken \"jag kopierade datastrukturen X till datastrukturen Y, f\u00f6r Y tilltalar mig mer estetiskt\". Men kopieringsoperationen (som verkar billig) tar faktiskt upp minnesbandbredd, och h\u00e4r ligger allt f\u00f6rlorad exekveringstid. Om jag har en enorm str\u00e4ng med JSON och jag vill omvandla den till ett strukturerat DOM-tr\u00e4d av POJO eller n\u00e5got liknande, s\u00e5 blir parsningen av den str\u00e4ngen och konstruktionen av POJO, och sedan nya referenser till POJO kostsamma \u2013 det \u00e4r ingen billig aff\u00e4r. Utom n\u00e4r du kommer att arbeta med POJO mycket oftare \u00e4n med str\u00e4ngen. I st\u00e4llet kan man \u00f6verv\u00e4ga att avkoda str\u00e4ngen och dra ut det som beh\u00f6vs, utan att f\u00f6rvandla det till n\u00e5gra POJO. Om allt detta sker i en situation d\u00e4r maximal prestanda kr\u00e4vs, \u00e4r det b\u00e4st att undvika POJO \u2013 man beh\u00f6ver p\u00e5 n\u00e5got s\u00e4tt gr\u00e4va direkt i str\u00e4ngen.<\/p>\n<p><\/p>\n<h1 id=\"zachem-sozdavat-svoy-yazyk-programmirovaniya\">Varf\u00f6r skapa ditt eget programmeringsspr\u00e5k<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Du sa att f\u00f6r att f\u00f6rst\u00e5 kostnadsmodellen beh\u00f6ver man skriva ett litet eget spr\u00e5k\u2026<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Inte ett spr\u00e5k, utan en kompilator. Ett spr\u00e5k och en kompilator \u00e4r olika saker. Den st\u00f6rsta skillnaden ligger i ditt eget sinne.\u00a0<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: F\u00f6r \u00f6vrigt, s\u00e5 vitt jag vet, experimenterar du med att skapa egna spr\u00e5k. Varf\u00f6r?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: F\u00f6r jag kan! Jag \u00e4r delvis pensionerad, s\u00e5 det h\u00e4r \u00e4r min hobby. Jag har hela mitt liv realiserat andras spr\u00e5k. Jag har ocks\u00e5 arbetat mycket med kodningsstil. Dessutom ser jag problem i andra spr\u00e5k. Jag ser att det finns b\u00e4ttre s\u00e4tt att g\u00f6ra vanliga saker. Och jag skulle anv\u00e4nda dem. Jag \u00e4r bara frustrerad \u00f6ver att se problem hos mig sj\u00e4lv, i Java, i Python, i vilket annat spr\u00e5k som helst. Just nu skriver jag i React Native, JavaScript och Elm som en hobby, som inte handlar om pensionering, utan om aktivt arbete. Och jag skriver ocks\u00e5 i Python och kommer troligtvis forts\u00e4tta arbeta med maskininl\u00e4rning f\u00f6r Java-backends. Det finns m\u00e5nga popul\u00e4ra spr\u00e5k och alla har intressanta egenskaper. Varje spr\u00e5k har n\u00e5got unikt och man kan f\u00f6rs\u00f6ka sammanfoga alla dessa funktioner. S\u00e5 jag studerar intressanta saker, spr\u00e5kets beteende, f\u00f6rs\u00f6ker komma p\u00e5 rimlig semantik. Och hittills lyckas jag! Just nu arbetar jag med minnessemantiken, f\u00f6r jag vill ha den som i C och Java, och f\u00e5 en stark minnesmodell och minnessemantik f\u00f6r laddningar och lagringar. Samtidigt vill jag ha automatisk typutdragning som i Haskell. S\u00e5 jag f\u00f6rs\u00f6ker blanda Haskell-liknande typutdragning med minne som fungerar som i C och Java. Det \u00e4r vad jag har sysslat med de senaste 2-3 m\u00e5naderna, till exempel.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Om du bygger ett spr\u00e5k som tar de b\u00e4sta aspekterna fr\u00e5n andra spr\u00e5k, har du t\u00e4nkt p\u00e5 att n\u00e5gon skulle kunna g\u00f6ra det motsatta: ta dina id\u00e9er och anv\u00e4nda dem i sitt sinne?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Just s\u00e5 h\u00e4r f\u00f6ds nya spr\u00e5k! Varf\u00f6r liknar Java C? F\u00f6r att C hade en bra syntax som alla f\u00f6rstod, och Java inspirerades av den syntaxen, medan den lade till typ-s\u00e4kerhet, gr\u00e4nskontroller f\u00f6r arrayer, GC, och de f\u00f6rb\u00e4ttrade \u00e4ven vissa saker fr\u00e5n C. De lade till sina egna. Men de var ganska inspirerade, eller hur? Alla st\u00e5r p\u00e5 axlarna av j\u00e4ttar som kom f\u00f6re dig \u2013 det \u00e4r s\u00e5 framsteg g\u00f6rs.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Som jag f\u00f6rst\u00e5r det kommer ditt spr\u00e5k att vara s\u00e4kert n\u00e4r det g\u00e4ller anv\u00e4ndning av minne. Har du funderat p\u00e5 att implementera n\u00e5got liknande som borrow checker fr\u00e5n Rust? Har du tittat p\u00e5 det, vad tycker du om det?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Ja, jag har programmerat i C i en evighet, med alla dessa malloc och free, och jag hanterar minneslivscykeln manuellt. Ni vet, 90-95% av den manuella hanteringen av livscykeln har samma struktur. Och det \u00e4r v\u00e4ldigt, v\u00e4ldigt sm\u00e4rtsamt att g\u00f6ra detta f\u00f6r hand. Jag \u00f6nskar att compilern bara kunde ber\u00e4tta vad som h\u00e4nder och vad jag har \u00e5stadkommit med mina handlingar. F\u00f6r vissa saker g\u00f6r borrow checker det h\u00e4r direkt. Dessutom borde det automatiskt generera information, f\u00f6rst\u00e5 allt och inte ens belasta mig med att beh\u00f6va formulera den f\u00f6rst\u00e5elsen. Det borde \u00e5tminstone g\u00f6ra en lokal escape-analys, och f\u00f6rst om det misslyckas, d\u00e5 m\u00e5ste man l\u00e4gga till typannoteringar som beskriver livscykeln \u2013 och en s\u00e5dan schema \u00e4r mycket mer komplicerad \u00e4n borrow checker, eller \u00f6verhuvudtaget vilken befintlig minneskontroller som helst. Valet mellan 'allt \u00e4r bra' och 'jag f\u00f6rstod ingenting' \u2013 nej, det borde finnas n\u00e5got b\u00e4ttre.\u00a0<br \/>\nSom en person som har skrivit mycket kod i C anser jag att ha st\u00f6d f\u00f6r automatisk livscykelhantering \u00e4r avg\u00f6rande. Dessutom har jag tr\u00f6ttnat p\u00e5 hur mycket Java anv\u00e4nder minne, och huvudsakligt klagom\u00e5l \u00e4r p\u00e5 GC. N\u00e4r minne allokeras i Java f\u00e5r du inte tillbaka det minne som var lokalt under den senaste GC-cykeln. I spr\u00e5k med mer exakt minneshantering \u00e4r det inte s\u00e5. Om du kallar malloc f\u00e5r du direkt minne som vanligtvis just har anv\u00e4nts. Oftast g\u00f6r du tillf\u00e4lliga saker med minnet och returnerar det omedelbart. Och det returneras direkt till malloc-poolen, och n\u00e4sta malloc-cykel drar upp det igen. D\u00e4rf\u00f6r minskar det verkliga minnesanv\u00e4ndandet till de aktiva objekten vid en viss tidpunkt, plus l\u00e4ckor. Om du inte har l\u00e4ckor p\u00e5 ett helt oacceptabelt s\u00e4tt, s\u00e5 lagras det mesta av minnet i cachar och processorn, och det fungerar snabbt. Men det kr\u00e4ver mycket manuell minneshantering med malloc och free, anropade i r\u00e4tt ordning och p\u00e5 r\u00e4tt st\u00e4llen. Rust kan hantera detta korrekt sj\u00e4lv och i m\u00e5nga fall ge till och med b\u00e4ttre prestanda, eftersom minnesf\u00f6rbrukningen begr\u00e4nsas till aktuella ber\u00e4kningar \u2013 till skillnad fr\u00e5n att v\u00e4nta p\u00e5 n\u00e4sta GC-cykel som ska frig\u00f6ra minne. I slut\u00e4ndan har vi f\u00e5tt ett mycket intressant s\u00e4tt att f\u00f6rb\u00e4ttra prestanda. Och ganska kraftfullt \u2013 jag har arbetat med s\u00e5dana saker vid databehandling f\u00f6r fintech, och det gjorde det m\u00f6jligt att uppn\u00e5 ungef\u00e4r femfaldig hastighets\u00f6kning. Det \u00e4r en ganska stor \u00f6kning, s\u00e4rskilt i en v\u00e4rld d\u00e4r processorer inte blir snabbare, medan vi fortfarande v\u00e4ntar p\u00e5 f\u00f6rb\u00e4ttringar.<\/p>\n<p><\/p>\n<h1 id=\"karera-performans-inzhenera\">Karri\u00e4r som prestandingenj\u00f6r<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Jag skulle ocks\u00e5 vilja fr\u00e5ga lite om karri\u00e4ren i stort. Du blev k\u00e4nd genom ditt arbete med JIT i HotSpot och flyttade sedan till Azul \u2013 och det \u00e4r ocks\u00e5 ett JVM-f\u00f6retag. Men du har jobbat mer med h\u00e5rdvara \u00e4n mjukvara. Och sedan pl\u00f6tsligt bytte du till Big Data och Maskininl\u00e4rning, och sedan till bedr\u00e4geridetektion. Hur kom det sig? Det \u00e4r v\u00e4ldigt olika utvecklingsomr\u00e5den.<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Jag har sysslat med programmering ganska l\u00e4nge och har hunnit med m\u00e5nga olika projekt. Och n\u00e4r folk s\u00e4ger: \u201e\u00e5h, du \u00e4r den som gjorde JIT f\u00f6r Java!\u201c, s\u00e5 \u00e4r det alltid roligt. Men innan dess var jag involverad i en klon av PostScript \u2013 det spr\u00e5ket som Apple en g\u00e5ng anv\u00e4nde f\u00f6r sina laserskrivare. Innan dess gjorde jag en implementation av spr\u00e5ket Forth. Jag tror att ett gemensamt tema f\u00f6r mig \u00e4r utveckling av verktyg. Jag har alltid skapat verktyg som hj\u00e4lper andra att skriva sina fantastiska program. Men jag har ocks\u00e5 varit involverad i utvecklingen av operativsystem, drivrutiner, k\u00e4rndebuggers, spr\u00e5k f\u00f6r operativsystem som b\u00f6rjade enkelt men med tiden blev mer och mer komplexa. Men det huvudsakliga temat \u00e4r \u00e4nd\u00e5 verktygsutveckling. En stor del av mitt liv har \u00e4gnats \u00e5t Azul och Sun, och det handlade om Java. Men n\u00e4r jag b\u00f6rjade med Big Data och Maskininl\u00e4rning tog jag \u00e5terigen p\u00e5 mig min festhatt och sa: \u201e\u00c5h, nu har vi ett icke-trivialt problem, och h\u00e4r h\u00e4nder det verkligen massor av intressanta saker och m\u00e4nniskor som g\u00f6r n\u00e5got.\u201c Det \u00e4r en fantastisk v\u00e4g f\u00f6r utveckling som \u00e4r v\u00e4rd att g\u00e5. <\/p>\n<p><\/p>\n<p>Ja, jag \u00e4lskar verkligen distribuerade ber\u00e4kningar. Mitt f\u00f6rsta jobb var under studietiden med C, p\u00e5 ett reklamprojekt. Det handlade om distribuerade ber\u00e4kningar p\u00e5 Zilog Z80-chip som samlade data f\u00f6r analog optisk teckenigenk\u00e4nning, utf\u00f6rd av en riktig analog analysator. Det var ett coolt och helt galet \u00e4mne. Men det fanns problem; vissa delar k\u00e4nde inte igen r\u00e4tt, s\u00e5 man var tvungen att ta fram bilden och visa den f\u00f6r en person som redan sett p\u00e5 den och rapportera vad den sa. D\u00e4rf\u00f6r fanns det jobb med data, och dessa jobb hade sitt eget spr\u00e5k. Det fanns en backend som hanterade allt detta \u2013 parallella Z80:or som k\u00f6rde vt100-terminaler \u2013 en per person, och det fanns en modell f\u00f6r parallell programmering p\u00e5 Z80. En gemensam minnesdel som alla Z80 delade inom en stj\u00e4rnkonfiguration; backplane delades och h\u00e4lften av RAM delades inom n\u00e4tverket, medan den andra h\u00e4lften var privat eller gick till n\u00e5got annat. En meningsfullt komplex parallell distribuerad system med delad... halvdelad minne. N\u00e4r var det\u2026 Redan sv\u00e5rt att minnas, n\u00e5gon g\u00e5ng i mitten av 80-talet. Ganska l\u00e4nge sedan.\u00a0<br \/>\nJa, vi kan anse att 30 \u00e5r \u00e4r ganska l\u00e4nge. Utmaningar relaterade till distribuerade ber\u00e4kningar har funnits l\u00e4nge; m\u00e4nniskor har k\u00e4mpat mot dem i \u00e5ratal. <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>-kluster. Dessa kluster ser ut som... Till exempel: det finns Ethernet och din snabba x86 \u00e4r ansluten till detta Ethernet, och nu vill du f\u00e5 fake shared memory, eftersom ingen kunde syssla med kodning av distribuerad ber\u00e4kning d\u00e5, det var f\u00f6r sv\u00e5rt, och d\u00e4rf\u00f6r fanns det fake shared memory med sidminnesskydd p\u00e5 x86, och om du skrev till denna sida, s\u00e5 sa vi till de andra processorerna att om de fick tillg\u00e5ng till samma shared memory, m\u00e5ste den laddas fr\u00e5n dig, och p\u00e5 s\u00e5 s\u00e4tt skapades n\u00e5got som liknar ett protokoll f\u00f6r cache-koh\u00e4rens och mjukvara f\u00f6r detta. En intressant koncept. Det verkliga problemet var f\u00f6rst\u00e5s ett annat. Allt detta fungerade, men du fick snabbt prestandaproblem, eftersom ingen f\u00f6rstod prestandamodellen p\u00e5 tillr\u00e4ckligt bra niv\u00e5 \u2013 vilka \u00e5tkomstm\u00f6nster f\u00f6r minnet det fanns, hur man skulle se till att noderna inte o\u00e4ndligt pingade varandra, och s\u00e5 vidare. <\/p>\n<p><\/p>\n<p>I H2O kom jag p\u00e5 f\u00f6ljande: utvecklarna sj\u00e4lva ansvarar f\u00f6r att definiera var parallellism g\u00f6mmer sig och var den inte finns. Jag har kommit p\u00e5 en kodningsmodell som g\u00f6r det enkelt och l\u00e4tt att skriva h\u00f6gpresterande kod. Men att skriva l\u00e5ngsam kod \u00e4r sv\u00e5rt, den kommer att se d\u00e5lig ut. Det kr\u00e4vs en seri\u00f6s insats f\u00f6r att skriva l\u00e5ngsam kod; man m\u00e5ste anv\u00e4nda ovanliga metoder. L\u00e5ngsam kod syns vid f\u00f6rsta \u00f6gonkastet. Som en f\u00f6ljd av detta skrivs kod som vanligtvis fungerar snabbt, men man m\u00e5ste ta reda p\u00e5 vad man ska g\u00f6ra vid delad minne. Allt detta \u00e4r knutet till stora arrayer, och beteendet d\u00e4r liknar icke-volatile stora arrayer i Java parallellk\u00f6rning. T\u00e4nk dig att tv\u00e5 tr\u00e5dar skriver till en parallell array, en av dem vinner, och den andra f\u00f6rlorar, och du vet inte vem som \u00e4r vem. Om de inte \u00e4r volatila kan ordningen vara vad som helst \u2013 och det fungerar verkligen bra. M\u00e4nniskor bryr sig verkligen om operationsordning; de placerar volatile korrekt och f\u00f6rv\u00e4ntar sig problem med prestanda, relaterade till minnet. Annars skulle de bara skriva kod som loopar fr\u00e5n 1 till N, d\u00e4r N \u00e4r n\u00e5gra triljoner, i hopp om att alla komplexa fall automatiskt blir parallella \u2013 och det fungerar inte d\u00e4r. Men i H2O \u00e4r det varken Java eller Scala, man kan kalla det 'Java minus minus', om man vill. Det \u00e4r en v\u00e4ldigt l\u00e4ttf\u00f6rst\u00e5elig programmeringsstil och liknar skrivandet av enkel kod i C eller Java med loopar och arrayer. Men man kan ocks\u00e5 hantera terabyte av minne. Jag anv\u00e4nder fortfarande H2O. Ibland anv\u00e4nder jag det i olika projekt \u2013 och det \u00e4r fortfarande den snabbaste saken, tiotals g\u00e5nger snabbare \u00e4n konkurrenterna. Om du arbetar med Big Data med kolumn\u00e4ra data \u00e4r det mycket sv\u00e5rt att \u00f6vertr\u00e4ffa H2O.<\/p>\n<p><\/p>\n<h1 id=\"tehnicheskie-chellenzhi\">Tekniska utmaningar<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Vad har varit den st\u00f6rsta utmaningen under din karri\u00e4r?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Diskuterar vi den tekniska eller icke-tekniska delen av fr\u00e5gan? Jag skulle s\u00e4ga att de st\u00f6rsta utmaningarna \u00e4r icke-tekniska.\u00a0<br \/>\nN\u00e4r det kommer till tekniska utmaningar. Jag \u00f6vervann dem enkelt. Jag vet knappt vilken som var den st\u00f6rsta, men det fanns flera ganska intressanta som tog en hel del tid och mental kamp. N\u00e4r jag b\u00f6rjade p\u00e5 Sun var jag s\u00e4ker p\u00e5 att jag skulle skapa en snabb kompilator, medan en massa seniorer sa att jag aldrig skulle lyckas. Men jag fortsatte p\u00e5 den v\u00e4gen, skrev en kompilator hela v\u00e4gen till registerallokatorn, och den blev ganska snabb. Den var lika snabb som den moderna C1, men d\u00e5 var allokatorn mycket l\u00e5ngsammare, och n\u00e4r jag ser tillbaka var det ett problem med den stora datakonstruktionen. Jag beh\u00f6vde den f\u00f6r att skriva en grafisk registerallokator och jag f\u00f6rstod inte dilemmat mellan kodens uttrycksfullhet och hastighet, som var relevant p\u00e5 den tiden och v\u00e4ldigt viktigt. Det visade sig att datakonstruktionen vanligtvis \u00f6versteg cache-storleken p\u00e5 x86 fr\u00e5n den tiden, s\u00e5 om jag ursprungligen antog att registerallokatorn skulle st\u00e5 f\u00f6r 5-10 procent av den totala tid som JIT:ade, s\u00e5 blev det i verkligheten 50 procent. <\/p>\n<p><\/p>\n<p>Tiden gick, kompilatorn blev allt mer tydlig och effektiv, slutade generera avskyv\u00e4rt kod i fler fall, och prestandan b\u00f6rjade allt oftare likna det som C-kompilatorn levererade. Om du f\u00f6rst\u00e5s inte skrev skr\u00e4p som ens C inte kunde optimera. Om du skrev kod som i C, fick du ocks\u00e5 prestanda som i C i fler fall. Ju l\u00e4ngre tiden gick, desto oftare fick jag kod som asymptotiskt \u00f6verensst\u00e4mde med C-niv\u00e5, registerallokatorn b\u00f6rjade likna n\u00e5got f\u00e4rdigt... oavsett om din kod k\u00f6rdes snabbt eller l\u00e5ngsamt. Jag fortsatte att arbeta p\u00e5 allokatorn s\u00e5 att den skulle g\u00f6ra b\u00e4ttre allokeringar. Den blev l\u00e5ngsammare och l\u00e5ngsammare, men levererade allt b\u00e4ttre prestanda i de fall d\u00e4r ingen annan lyckades. Jag kunde dyka ner i registerallokatorn, gr\u00e4va ner en m\u00e5nads arbete d\u00e4r, och pl\u00f6tsligt b\u00f6rjade hela koden k\u00f6ra 5% snabbare. Det h\u00e4nde g\u00e5ng p\u00e5 g\u00e5ng och registerallokatorn blev som ett konstverk \u2013 alla \u00e4lskade eller hatade den, och akademikerna st\u00e4llde fr\u00e5gor som \"varf\u00f6r g\u00f6rs allt p\u00e5 det h\u00e4r s\u00e4ttet\", varf\u00f6r inte. <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Register_allocation#Linear_Scan\">linj\u00e4r skanning<\/a><\/noindex>, och vad \u00e4r skillnaden. Svaret \u00e4r fortfarande detsamma: en allokerare baserad p\u00e5 grafm\u00e5lning plus mycket noggrant arbete med buffertkoden \u00e4r ett vinnande verktyg, den b\u00e4sta kombinationen som ingen kan besegra. Och detta \u00e4r en ganska subtil sak. Allt annat som d\u00e4r g\u00f6rs av kompilatorn \u00e4r ganska v\u00e4ldokumenterade saker, \u00e4ven om de ocks\u00e5 har f\u00f6rfinats till en konstform. Jag har alltid gjort saker som skulle omvandla kompilatorn till ett konstverk. Men inget av detta har varit extraordin\u00e4rt \u2013 f\u00f6rutom registerallokeraren. Po\u00e4ngen \u00e4r att man m\u00e5ste vara noggrann <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Register_allocation\">s\u00e5ga av<\/a><\/noindex> under belastning, och om det h\u00e4nder (jag kan f\u00f6rklara mer om det om det \u00e4r intressant) inneb\u00e4r det att man kan inlinera mer aggressivt, utan risk f\u00f6r att \u00f6verskrida brytpunkten f\u00f6r prestandadiagrammet. P\u00e5 den tiden fanns det massor av fullfj\u00e4drade kompilatorer, \u00f6verbelamrade med gimmickar och pryttlar, som hade registerallokerare, men ingen kunde n\u00e5gonsin g\u00f6ra det p\u00e5 nytt. <\/p>\n<p><\/p>\n<p>Problemet \u00e4r att om du l\u00e4gger till metoder som ska inlineas, och \u00f6kar inlineomr\u00e5det, s\u00e5 \u00f6verstiger upps\u00e4ttningen av anv\u00e4nda v\u00e4rden genast antalet register, och du m\u00e5ste b\u00f6rja spilla. Den kritiska niv\u00e5n intr\u00e4ffar vanligtvis n\u00e4r allokatorn ger upp, och en bra kandidat f\u00f6r spilling \u00e4r lika med en annan, och du b\u00f6rjar spilla riktigt vilda saker. V\u00e4rdet av inlining h\u00e4r \u00e4r att du f\u00f6rlorar en del overhead, overhead f\u00f6r anrop och bevarande; du kan se v\u00e4rdena inuti och du kan optimera dem vidare. Kostnaden f\u00f6r inlining \u00e4r att det skapas ett stort antal levande v\u00e4rden, och om din registerallokator spillar mer \u00e4n n\u00f6dv\u00e4ndigt, f\u00f6rlorar du direkt. D\u00e4rf\u00f6r har de flesta allokatorer ett problem: n\u00e4r inlining passerar en viss gr\u00e4ns b\u00f6rjar allt i v\u00e4rlden att spilla, och prestandan kan sv\u00e4mmas bort i toaletten. De som implementerar kompilatorn l\u00e4gger till vissa heuristik: till exempel, att stoppa inlining efter en viss tillr\u00e4ckligt stor storlek, eftersom allokeringarna f\u00f6rst\u00f6r allt. Det skapas en b\u00f6jning i prestandadiagrammet \u2013 du inlinear, inlinear, prestandan \u00f6kar l\u00e5ngsamt \u2013 och sedan bang! \u2013 den faller ner snabbt som en domkraft, f\u00f6r du har inlineat f\u00f6r mycket. S\u00e5 har det fungerat fram till Java. Java kr\u00e4ver mycket mer inlining, s\u00e5 jag var tvungen att g\u00f6ra min allokator mycket mer aggressiv, s\u00e5 att den j\u00e4mnades ut ist\u00e4llet f\u00f6r att falla, och om du inlinear f\u00f6r mycket \u2013 b\u00f6rjar den spillas, men sedan kommer \u00e4nd\u00e5 ett \u00f6gonblick d\u00e4r det inte finns mer spilling. Det \u00e4r en intressant observation och den kom till mig helt pl\u00f6tsligt, inte uppenbar, men v\u00e4l v\u00e4rd insatsen. Jag b\u00f6rjade med aggressiv inlining och det ledde mig till platser d\u00e4r prestandan f\u00f6r Java och C g\u00e5r hand i hand. De \u00e4r faktiskt ganska lika \u2013 jag kan skriva Java-kod som \u00e4r betydligt snabbare \u00e4n C-kod och liknande, men i det stora hela \u00e4r de ungef\u00e4r j\u00e4mf\u00f6rbara. Jag tror att en del av denna f\u00f6rtj\u00e4nst kommer fr\u00e5n registerallokatorn, som l\u00e5ter mig inlinea p\u00e5 ett r\u00e4tt primitivt s\u00e4tt. Jag inlinear helt enkelt allt jag ser. Fr\u00e5gan h\u00e4r \u00e4r om allokatorn fungerar bra, och om det resulterande koden \u00e4r rimligt fungerande. Det var en stor utmaning: att f\u00f6rst\u00e5 allt detta och f\u00e5 det att fungera.<\/p>\n<p><\/p>\n<h1 id=\"nemnogo-pro-allokaciyu-registrov-i-mnogoyadernost\">Lite om registerallokering och flerk\u00e4rnighet<\/h1>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Problem som registreringsallokering verkar vara ett evigt \u00e4mne. Det \u00e4r intressant att fr\u00e5ga sig om det fanns n\u00e5gon id\u00e9 som verkade lovande men sedan misslyckades i praktiken?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Sj\u00e4lvklart! Registreringsallokering \u00e4r ett omr\u00e5de d\u00e4r du f\u00f6rs\u00f6ker hitta heuristik f\u00f6r att l\u00f6sa ett NP-fullst\u00e4ndigt problem. Och du kommer aldrig att kunna uppn\u00e5 en perfekt l\u00f6sning, eller hur? Det \u00e4r helt enkelt om\u00f6jligt. T\u00e4nk p\u00e5 Ahead of Time-kompilering \u2013 den fungerar ocks\u00e5 d\u00e5ligt. H\u00e4r talar vi om genomsnittliga fall. Om typisk prestanda, s\u00e5 du kan g\u00e5 och m\u00e4ta n\u00e5got som du anser vara bra typisk prestanda \u2013 i slut\u00e4ndan arbetar du ju med att f\u00f6rb\u00e4ttra den! Registreringsallokering \u00e4r ett \u00e4mne helt \u00e4gnat \u00e5t prestanda. S\u00e5 snart du har en f\u00f6rsta prototyp som fungerar och m\u00e5lar det som beh\u00f6ver m\u00e5las, b\u00f6rjar arbetet med prestanda. Du m\u00e5ste l\u00e4ra dig att m\u00e4ta ordentligt. Varf\u00f6r \u00e4r detta viktigt? Om det finns tydliga data kan du titta p\u00e5 olika omr\u00e5den och se: aha, det hj\u00e4lpte h\u00e4r, men d\u00e4r br\u00f6ts allt ihop! Det dyker upp bra id\u00e9er, du l\u00e4gger till en ny heuristik och pl\u00f6tsligt fungerar allt i genomsnitt lite b\u00e4ttre. Eller inte. Jag har haft m\u00e5nga fall d\u00e4r vi k\u00e4mpade f\u00f6r fem procent prestanda som skiljde v\u00e5r utveckling fr\u00e5n den tidigare allokatorn. Och varje g\u00e5ng ser det ut s\u00e5 h\u00e4r: n\u00e5gonstans vinner, n\u00e5gonstans f\u00f6rlorar. Om du har bra verktyg f\u00f6r prestandaanalys kan du hitta de f\u00f6rlorande id\u00e9erna och f\u00f6rst\u00e5 varf\u00f6r de f\u00f6rlorar. Kanske \u00e4r det v\u00e4rt att l\u00e5ta allt vara som det \u00e4r, eller s\u00e5 kanske vi beh\u00f6ver ta ett mer seri\u00f6st grepp om finjusteringen, eller g\u00e5 och fixa n\u00e5got annat. Det handlar om en hel upps\u00e4ttning saker! Jag gjorde den h\u00e4r coola hack, men jag beh\u00f6ver ocks\u00e5 det, och det, och det \u2013 och den sammanlagda kombinationen ger vissa f\u00f6rb\u00e4ttringar. Enskilda insatser kan misslyckas. S\u00e5dan \u00e4r naturen av att arbeta med prestanda f\u00f6r NP-fullst\u00e4ndiga problem.<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Det k\u00e4nns som om fr\u00e5gor som m\u00e5lning i allokatorer \u00e4r ett redan l\u00f6st problem. Tja, f\u00f6r er tycks det l\u00f6st, baserat p\u00e5 vad ni ber\u00e4ttar, s\u00e5 \u00e4r det ens v\u00e4rt\u2026<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Det \u00e4r inte varken l\u00f6st eller ol\u00f6st. Det \u00e4r du som m\u00e5ste g\u00f6ra det till \"l\u00f6st\". Det finns tunga uppgifter och de m\u00e5ste l\u00f6sas. N\u00e4r detta \u00e4r gjort, kommer det dags att fokusera p\u00e5 prestanda. Man m\u00e5ste f\u00f6rh\u00e5lla sig till detta arbete p\u00e5 r\u00e4tt s\u00e4tt \u2013 utf\u00f6ra benchmarktester, samla in m\u00e4tv\u00e4rden, f\u00f6rklara situationer n\u00e4r en rollback till en tidigare version f\u00e5r din gamla hack att fungera igen (eller tv\u00e4rtom, sluta fungera). Och ge inte upp f\u00f6rr\u00e4n du har uppn\u00e5tt n\u00e5got. Som jag n\u00e4mnde, finns det fantastiska id\u00e9er som inte fungerade, men inom registerallokeringsomr\u00e5det \u00e4r id\u00e9er i princip o\u00e4ndliga. Man kan till exempel l\u00e4sa vetenskapliga publikationer. \u00c4ven om detta omr\u00e5de nu r\u00f6r sig l\u00e5ngsammare och har blivit tydligare \u00e4n p\u00e5 sin ungdom, arbetar en o\u00e4ndlig m\u00e4ngd m\u00e4nniskor inom detta omr\u00e5de, och alla deras id\u00e9er \u00e4r v\u00e4rda att pr\u00f6va; alla v\u00e4ntar p\u00e5 sitt tillf\u00e4lle. Och du kan inte s\u00e4ga hur bra de \u00e4r om du inte pr\u00f6var dem. Hur v\u00e4l de integreras med allt annat i din allokerare, eftersom allokeraren g\u00f6r m\u00e5nga saker, och vissa id\u00e9er kommer inte att fungera i din specifika allokerare, men kanske fungerar de i en annan. Huvudstrategin f\u00f6r en allokerare \u00e4r att ta bort l\u00e5ngsamma sekvenser fr\u00e5n den prim\u00e4ra v\u00e4gen och tvinga uppdelning vid gr\u00e4nserna f\u00f6r de l\u00e5ngsamma v\u00e4garna. D\u00e4rf\u00f6r, om du vill starta GC, f\u00f6lja den l\u00e5ngsamma v\u00e4gen, deoptimera, kasta undantag, allt s\u00e5dant \u2013 du vet att dessa saker \u00e4r relativt s\u00e4llsynta. Och de \u00e4r faktiskt s\u00e4llsynta, jag har kollat. Du g\u00f6r extra arbete och d\u00e4rmed f\u00f6rsvinner m\u00e5nga begr\u00e4nsningar p\u00e5 dessa l\u00e5ngsamma v\u00e4gar, men det spelar inte s\u00e5 stor roll eftersom de \u00e4r l\u00e5ngsamma och s\u00e4llan anv\u00e4nds. Till exempel, en nullpekaresituation \u2013 det h\u00e4nder aldrig, eller hur? Du beh\u00f6ver ha flera v\u00e4gar f\u00f6r olika situationer, men de ska inte kollidera p\u00e5 den prim\u00e4ra v\u00e4gen.\u00a0<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Vad tycker du om flerk\u00e4rniga processorer n\u00e4r det finns tusentals k\u00e4rnor? \u00c4r det n\u00e5got anv\u00e4ndbart?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Framg\u00e5ngen f\u00f6r GPU:er visar att det faktiskt \u00e4r ganska anv\u00e4ndbart!<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: De \u00e4r ganska specialiserade. Vad s\u00e4gs om allm\u00e4nna processorer?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Ja, det var aff\u00e4rsmodellen f\u00f6r Azul. Svaret kom under en tid n\u00e4r m\u00e4nniskor verkligen uppskattade f\u00f6ruts\u00e4gbar prestanda. Det var ganska sv\u00e5rt att skriva parallellkod d\u00e5. H2O-kodningsmodellen \u00e4r v\u00e4lskalbar, men den \u00e4r inte en allm\u00e4n anv\u00e4ndningsmodell. Kanske n\u00e5got mer generell \u00e4n n\u00e4r man anv\u00e4nder GPU. Pratar vi om sv\u00e5righeterna med att utveckla n\u00e5got s\u00e5dant eller sv\u00e5righeterna med att anv\u00e4nda det? Till exempel, en intressant l\u00e4xa som Azul l\u00e4rde mig, ganska ov\u00e4ntad: sm\u00e5 cachar \u00e4r bra.\u00a0<\/p>\n<p><\/p>\n<h1 id=\"samyy-bolshoy-chellenzh-v-zhizni\">Den st\u00f6rsta utmaningen i livet<\/h1>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Hur \u00e4r det med icke-tekniska utmaningar?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Den st\u00f6rsta utmaningen var att inte vara... sn\u00e4ll och bra mot folk. Som en f\u00f6ljd hamnade jag st\u00e4ndigt i extremt konfliktfyllda situationer. I de som jag visste gick snett, men jag visste inte hur jag skulle g\u00e5 vidare med att l\u00f6sa dessa problem och kunde inte hantera dem. M\u00e5nga l\u00e5ngvariga problem som p\u00e5g\u00e5tt i \u00e5rtionden uppkom just p\u00e5 det s\u00e4ttet. Att det finns C1- och C2-kompilatorer i Java \u00e4r en direkt f\u00f6ljd av detta. Att det inte fanns n\u00e5got flerniv\u00e5kompilering i Java under ett decennium \u00e4r ocks\u00e5 en direkt f\u00f6ljd. Det \u00e4r uppenbart att vi beh\u00f6vde ett s\u00e5dant system, men inte uppenbart varf\u00f6r det inte fanns. Jag hade problem med en ingenj\u00f6r... eller en grupp ingenj\u00f6rer. L\u00e5ngt tillbaka, n\u00e4r jag b\u00f6rjade arbeta p\u00e5 Sun, var jag... Okej, inte bara d\u00e5, jag har alltid min egen \u00e5sikt om allt. Och jag ans\u00e5g att jag kunde ta den h\u00e4r min sanningen och framf\u00f6ra den rakt p\u00e5 sak. Speciellt eftersom jag var chockerande r\u00e4tt merparten av tiden. Och om du inte gillar det f\u00f6rh\u00e5llningss\u00e4ttet... s\u00e4rskilt om du uppenbarligen har fel och g\u00f6r dumheter... Ja, f\u00e5 m\u00e4nniskor kunde tolerera den typen av kommunikation. Men vissa kunde, till exempel jag. Jag har byggt hela mitt liv p\u00e5 meritoriska principer. Om du visar mig n\u00e5got fel, v\u00e4nder jag mig genast om och s\u00e4ger: du sa n\u00e5got dumt. Givetvis ber jag om urs\u00e4kt, och allt det d\u00e4r, jag erk\u00e4nner meriterna om det finns n\u00e5gra, och jag g\u00f6r andra korrekta handlingar. \u00c5 andra sidan har jag chockerande r\u00e4tt en chockerande stor procent av tiden. Och det fungerar inte s\u00e4rskilt bra i relationer med m\u00e4nniskor. Jag str\u00e4var inte efter att vara trevlig, utan st\u00e4ller fr\u00e5gan p\u00e5 sin spets. \"Det h\u00e4r kommer aldrig att fungera, f\u00f6r att ett, tv\u00e5 och tre.\" Och de s\u00e4ger: \"Oj!\". Det fanns andra konsekvenser ocks\u00e5, som kanske \u00e4r b\u00e4ttre att hoppa \u00f6ver: till exempel de som ledde till skilsm\u00e4ssa fr\u00e5n min fru och ett decennium av depression efter det.<\/p>\n<p><\/p>\n<p>Utmaningen handlar om att k\u00e4mpa mot m\u00e4nniskor och deras uppfattningar om vad du kan eller inte kan g\u00f6ra, vad som \u00e4r viktigt och vad som inte \u00e4r det. Det har funnits m\u00e5nga utmaningar kring kodningsstil. Jag skriver fortfarande mycket kod, och under den tiden var jag tvungen att sakta ner, eftersom jag gjorde f\u00f6r m\u00e5nga parallella uppgifter och gjorde dem d\u00e5ligt, ist\u00e4llet f\u00f6r att fokusera p\u00e5 en enda. N\u00e4r jag ser tillbaka skrev jag h\u00e4lften av koden f\u00f6r Java JIT-teamet och C2-teamet. N\u00e4sta snabbaste kodare skrev h\u00e4lften s\u00e5 snabbt, den efter honom \u00e4nnu l\u00e5ngsammare och det var en exponentiell nedg\u00e5ng. Den sjunde personen i raden var v\u00e4ldigt, v\u00e4ldigt l\u00e5ngsam \u2013 s\u00e5 \u00e4r det alltid! Jag har r\u00f6rt vid en massa kod. Jag har sett vad alla skriver, utan undantag, jag har granskat deras kod, och jag fortsatte fortfarande att skriva mer \u00e4n n\u00e5gon av dem. Denna metod fungerar inte s\u00e5 bra med m\u00e4nniskor. Vissa gillar inte det. Och n\u00e4r de inte kan hantera det, b\u00f6rjar alla m\u00f6jliga klagom\u00e5l. Till exempel sa n\u00e5gon till mig en g\u00e5ng att jag skulle sluta skriva kod, eftersom jag skrev f\u00f6r mycket kod, och det hotade teamet. F\u00f6r mig l\u00e4t allt detta som ett sk\u00e4mt: om hela kvarvarande teamet f\u00f6rsvinner och jag forts\u00e4tter skriva kod, f\u00f6rlorar du bara h\u00e4lften av teamet. \u00c5 andra sidan, om jag forts\u00e4tter skriva kod och du f\u00f6rlorar h\u00e4lften av teamet \u2013 det l\u00e5ter som v\u00e4ldigt d\u00e5lig ledarskap. Jag har aldrig t\u00e4nkt s\u00e4rskilt mycket p\u00e5 det, aldrig pratat om det, men det var \u00e4nd\u00e5 n\u00e5gonstans i mitt huvud. En tanke som snurrade runt i bakhuvudet: \"\u00c4r ni p\u00e5 riktigt?\". S\u00e5 den st\u00f6rsta problemen var jag och mina relationer med m\u00e4nniskor. Nu f\u00f6rst\u00e5r jag mig sj\u00e4lv mycket b\u00e4ttre, jag har l\u00e4nge varit teamledare f\u00f6r programmerare, och nu s\u00e4ger jag rakt ut till folk: du vet, jag \u00e4r den jag \u00e4r, och ni f\u00e5r hantera mig \u2013 \u00e4r det okej om jag st\u00e5r h\u00e4r? Och n\u00e4r de b\u00f6rjade hantera det, b\u00f6rjade allt fungera. Jag \u00e4r faktiskt varken d\u00e5lig eller bra, jag har inga d\u00e5liga avsikter eller sj\u00e4lviska str\u00e4vanden, det \u00e4r bara min natur, och man m\u00e5ste p\u00e5 n\u00e5got s\u00e4tt leva med det.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Nyligen har alla b\u00f6rjat prata om sj\u00e4lvmedvetenhet f\u00f6r introverta och om mjuka f\u00e4rdigheter \u00f6verlag. Vad kan man s\u00e4ga om det?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>Ja, det var en insikt och en l\u00e4xa som jag fick ut av min skilsm\u00e4ssa fr\u00e5n min fru. Det jag l\u00e4rde mig av skilsm\u00e4ssan \u2013 \u00e4r f\u00f6rst\u00e5elsen f\u00f6r mig sj\u00e4lv. S\u00e5 b\u00f6rjade jag f\u00f6rst\u00e5 andra m\u00e4nniskor. F\u00f6rst\u00e5 hur denna interaktion fungerar. Det ledde till insikter en efter en. Jag blev medveten om vem jag \u00e4r och vad jag representerar. Vad jag g\u00f6r: antingen \u00e4r jag fokuserad p\u00e5 uppgiften, eller s\u00e5 undviker jag konflikt, eller n\u00e5got annat \u2013 och denna niv\u00e5 av sj\u00e4lvk\u00e4nnedom hj\u00e4lper verkligen till att h\u00e5lla mig lugn. Efter det g\u00e5r allt mycket l\u00e4ttare. En sak som jag har uppt\u00e4ckt, inte bara hos mig sj\u00e4lv utan ocks\u00e5 hos andra programm\u00f6rer \u2013 \u00e4r of\u00f6rm\u00e5gan att verbalisera tankar n\u00e4r man \u00e4r i ett tillst\u00e5nd av k\u00e4nslom\u00e4ssig stress. Till exempel, du sitter och kodar, \u00e4r i ett fl\u00f6desl\u00e4ge, och pl\u00f6tsligt kommer n\u00e5gon springande och b\u00f6rjar skrika i panik om att n\u00e5got har g\u00e5tt s\u00f6nder, och att extrema \u00e5tg\u00e4rder nu kommer att till\u00e4mpas. Och du kan inte f\u00e5 fram ett ord, f\u00f6r du befinner dig i ett tillst\u00e5nd av k\u00e4nslom\u00e4ssig stress. Den f\u00f6rv\u00e4rvade kunskapen g\u00f6r att du kan f\u00f6rbereda dig f\u00f6r detta \u00f6gonblick, \u00f6verleva det och g\u00e5 \u00f6ver till en retr\u00e4ttplan, efter vilket du kan b\u00f6rja agera. S\u00e5 ja, n\u00e4r du b\u00f6rjar f\u00f6rst\u00e5 hur allt det h\u00e4r fungerar \u2013 \u00e4r det en enorm livsf\u00f6r\u00e4ndrande h\u00e4ndelse.\u00a0<br \/>\nJag kunde sj\u00e4lv inte hitta de r\u00e4tta orden, men jag minns handlingssekvensen. Po\u00e4ngen \u00e4r att denna reaktion \u00e4r lika fysisk som verbal, och du beh\u00f6ver utrymme. S\u00e5dant utrymme, i zen-sinne. Det \u00e4r precis detta som m\u00e5ste f\u00f6rklaras, och sedan omedelbart backa \u2013 rent fysiskt backa. N\u00e4r jag \u00e4r tyst med ord, kan jag bearbeta situationen p\u00e5 en k\u00e4nslom\u00e4ssig niv\u00e5. N\u00e4r adrenalin n\u00e5r hj\u00e4rnan och sl\u00e5r om dig till \"sl\u00e5 eller fly\"-l\u00e4get, kan du inte l\u00e4ngre s\u00e4ga n\u00e5got, nej \u2013 nu \u00e4r du en idiot, en ingenj\u00f6r f\u00f6r att bli slagen, of\u00f6rm\u00f6gen till ett v\u00e4rdigt svar eller ens f\u00f6r att stoppa attacken, och angriparen kan fritt attackera igen och igen. F\u00f6rst m\u00e5ste du bli dig sj\u00e4lv igen, \u00e5terf\u00e5 kontrollen, och komma ut ur \"sl\u00e5 eller fly\"-l\u00e4get. <\/p>\n<p><\/p>\n<p>Och f\u00f6r detta beh\u00f6vs ett verbalt utrymme. Bara en fri plats. Om man \u00f6verhuvudtaget ska s\u00e4ga n\u00e5got, kan man just p\u00e5st\u00e5 detta och sedan g\u00e5 ut och faktiskt hitta sitt \"utrymme\": ta en promenad i parken, st\u00e4nga in sig i duschen \u2013 spelar ingen roll. Det viktiga \u00e4r att tempor\u00e4rt koppla bort fr\u00e5n situationen. S\u00e5 snart du ens f\u00f6r en kort stund kopplar bort, kommer kontrollen tillbaka, och du b\u00f6rjar t\u00e4nka klart. \"Okej, jag \u00e4r inte n\u00e5gon idiot, jag g\u00f6r inte dumma saker, jag \u00e4r en r\u00e4tt s\u00e5 nyttig person.\" S\u00e5 snart du har \u00f6vertygat dig sj\u00e4lv, \u00e4r det dags att g\u00e5 vidare till n\u00e4sta steg: f\u00f6rst\u00e5 vad som har h\u00e4nt. Du blev attackerad, attacken kom fr\u00e5n ett ov\u00e4ntat h\u00e5ll, det var en or\u00e4ttvis och skamlig f\u00e4lla. Det \u00e4r d\u00e5ligt. N\u00e4sta steg \u00e4r att f\u00f6rst\u00e5 varf\u00f6r angriparen beh\u00f6vde g\u00f6ra det. Verkligen, varf\u00f6r? Kanske f\u00f6r att han sj\u00e4lv \u00e4r rasande? Varf\u00f6r \u00e4r han rasande? Till exempel f\u00f6r att han sj\u00e4lv har misslyckats och inte kan ta ansvar? P\u00e5 detta s\u00e4tt beh\u00f6ver du noggrant bearbeta hela situationen. Men f\u00f6r detta beh\u00f6vs utrymme f\u00f6r man\u00f6vrering, ett verbalt utrymme. Det f\u00f6rsta steget \u00e4r att bryta det verbala kontakten. G\u00e5 bort fr\u00e5n diskussionen verbalt. Avbryt det, kom bort s\u00e5 snabbt som m\u00f6jligt. Om det \u00e4r ett telefonsamtal \u2013 l\u00e4gg bara p\u00e5 luren \u2013 detta \u00e4r en f\u00e4rdighet jag fick fr\u00e5n att prata med min exfru. Om samtalet inte leder till n\u00e5got bra, s\u00e4g bara \"hejd\u00e5\" och l\u00e4gg p\u00e5. P\u00e5 andra sidan r\u00f6ret: \"bla-bla-bla\", du svarar: \"aha, hejd\u00e5!\" och l\u00e4gger p\u00e5. Du avbryter samtalet. Fem minuter senare, n\u00e4r du f\u00e5r tillbaka din f\u00f6rm\u00e5ga att t\u00e4nka klart, har du svalnat lite, blir det m\u00f6jligt att t\u00e4nka igenom vad som verkligen h\u00e4nde och vad som ska h\u00e4nda h\u00e4rn\u00e4st. Och b\u00f6rja formulera ett genomt\u00e4nkt svar, ist\u00e4llet f\u00f6r att bara reagera k\u00e4nslom\u00e4ssigt. F\u00f6r mig har det varit en genombrott i sj\u00e4lvmedvetande att inse att jag inte kan prata i situationer med k\u00e4nslom\u00e4ssig stress. Att ta sig ur detta tillst\u00e5nd, t\u00e4nka igenom och planera hur man ska svara och kompensera f\u00f6r problemen \u2013 det \u00e4r de r\u00e4tta stegen n\u00e4r man inte kan prata. Det enklaste s\u00e4ttet \u00e4r att springa bort fr\u00e5n situationen d\u00e4r den k\u00e4nslom\u00e4ssiga stressen uppst\u00e5r och bara sluta delta i den stressen. Efter det \u00e5terf\u00e5r du f\u00f6rm\u00e5gan att t\u00e4nka, n\u00e4r du kan t\u00e4nka, dyker m\u00f6jligheten att prata upp, och s\u00e5 vidare.<\/p>\n<p><\/p>\n<p>F\u00f6r att vara \u00e4rlig, i domstolen f\u00f6rs\u00f6ker motpartens advokat anv\u00e4nda detta mot dig \u2013 nu f\u00f6rst\u00e5r du varf\u00f6r. F\u00f6r att han har m\u00f6jlighet att trycka ner dig till en punkt d\u00e4r du inte ens kan uttala ditt eget namn, till exempel. I bokstavlig mening, kan du inte prata. Om detta h\u00e4nder dig och om du vet att du kommer att befinna dig p\u00e5 en plats d\u00e4r verbala strider p\u00e5g\u00e5r, som i en domstol, kan du ta med dig din advokat. Advokaten kommer att st\u00e5 upp f\u00f6r dig och avbryta den verbala attacken, och han g\u00f6r det helt lagenligt, och ditt f\u00f6rlorade zenutrymme kommer att \u00e5terv\u00e4nda. Till exempel, jag beh\u00f6vde ringa min familj ett par g\u00e5nger, domaren var helt v\u00e4nlig, men motpartens advokat skrek och skrek p\u00e5 mig, jag kunde inte ens f\u00e5 in ett ord. I s\u00e5dana fall fungerar anv\u00e4ndningen av en medlare b\u00e4st f\u00f6r mig. Medlaren stoppar allt detta tryck som fl\u00f6dar \u00f6ver dig fr\u00e5n en oavbruten str\u00f6m, du \u00e5terfinner det n\u00f6dv\u00e4ndiga zenutrymmet, och med det kommer f\u00f6rm\u00e5gan att prata tillbaka. Det \u00e4r ett helt kunskapsomr\u00e5de, d\u00e4r det finns mycket att l\u00e4ra sig, mycket att uppt\u00e4cka inom sig sj\u00e4lv, och allt detta f\u00f6rvandlas till h\u00f6gkvalitativa strategiska beslut, som \u00e4r olika f\u00f6r olika m\u00e4nniskor. Vissa har inte de ovan beskrivna problemen, vanligtvis har de inte problem, personer som arbetar professionellt med f\u00f6rs\u00e4ljning. Alla dessa m\u00e4nniskor som lever p\u00e5 sina ord \u2013 k\u00e4nda s\u00e5ngare, poeter, religi\u00f6sa ledare och politiker, de har alltid n\u00e5got att s\u00e4ga. De har inte dessa problem, men jag har dem.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Det var\u2026 ov\u00e4ntat. Bra, vi har redan pratat mycket och det \u00e4r dags att avsluta denna intervju. Vi kommer definitivt att tr\u00e4ffas p\u00e5 konferensen och kan forts\u00e4tta denna dialog. Vi ses p\u00e5 Hydra!<\/p>\n<p><\/p>\n<blockquote><p>Det kommer att vara m\u00f6jligt att forts\u00e4tta kommunicera med Cliff p\u00e5 konferensen Hydra 2019, som kommer att \u00e4ga rum den 11-12 juli 2019 i Sankt Petersburg. Han kommer att delta med en presentation <noindex><a rel=\"nofollow\" href=\"https:\/\/hydraconf.com\/2019\/talks\/2jix5mst7iduyp9linqhfj\/?utm_source=habr&amp;utm_medium=45871\">\u00abThe Azul Hardware Transactional Memory experience\u00bb<\/a><\/noindex>. Biljetter kan k\u00f6pas <noindex><a rel=\"nofollow\" href=\"https:\/\/hydraconf.ru\/?utm_source=habr&amp;utm_medium=458718\">p\u00e5 den officiella sajten<\/a><\/noindex>.<\/p><\/blockquote>\n<p>K\u00e4lla: <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.4 - 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\/sv\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\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\/sv\/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\udd47 Stort intervju med Cliff Click \u2013 fadern av JIT-kompilering i Java | ProHoster","description":"Cliff Click \u2014.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/35851","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=35851"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/35851\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=35851"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=35851"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=35851"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}