ProHoster > Blog > Stjórnsýsla > Frábært viðtal við Cliff Click, föður JIT safnsins í Java

Frábært viðtal við Cliff Click, föður JIT safnsins í Java

Frábært viðtal við Cliff Click, föður JIT safnsins í JavaCliff Click — Tæknistjóri Cratus (IoT skynjarar til að bæta ferli), stofnandi og meðstofnandi nokkurra sprotafyrirtækja (þar á meðal Rocket Realtime School, Neurensic og H2O.ai) með nokkrum vel heppnuðum hætti. Cliff skrifaði sinn fyrsta þýðanda 15 ára gamall (Pascal fyrir TRS Z-80)! Hann er þekktastur fyrir vinnu sína á C2 í Java (Hnútahafið IR). Þessi þýðandi sýndi heiminum að JIT gæti framleitt hágæða kóða, sem var einn af þáttunum í tilkomu Java sem einn helsti nútíma hugbúnaðarvettvangur. Síðan hjálpaði Cliff Azul Systems að byggja upp 864 kjarna stórtölvu með hreinum Java hugbúnaði sem styður GC hlé á 500 gígabæta hrúgu innan 10 millisekúndna. Almennt séð tókst Cliff að vinna að öllum þáttum JVM.

 
Þessi habrapost er frábært viðtal við Cliff. Við munum ræða um eftirfarandi efni:

  • Umskipti yfir í hagræðingar á lágu stigi
  • Hvernig á að gera stóra endurnýjun
  • Kostnaðarlíkan
  • Hagræðingarþjálfun á lágu stigi
  • Hagnýt dæmi um aukna frammistöðu
  • Af hverju að búa til þitt eigið forritunarmál
  • Ferill árangursverkfræðings
  • Tæknilegar áskoranir
  • Smá um skráaúthlutun og fjölkjarna
  • Stærsta áskorunin í lífinu

Viðtalið er tekið af:

  • Andrey Satarín frá Amazon Web Services. Á ferli sínum tókst honum að vinna í allt öðrum verkefnum: hann prófaði NewSQL dreifðan gagnagrunn í Yandex, skýjaskynjunarkerfi í Kaspersky Lab, fjölspilunarleik í Mail.ru og þjónustu til að reikna út gjaldeyrisverð í Deutsche Bank. Hef áhuga á að prófa stórfelld bakenda og dreifð kerfi.
  • Vladimir Sitnikov frá Netcracker. Tíu ára vinna við frammistöðu og sveigjanleika NetCracker OS, hugbúnaðar sem fjarskiptafyrirtæki nota til að gera sjálfvirkan net- og netbúnaðarstjórnunarferli. Hef áhuga á frammistöðumálum Java og Oracle Database. Höfundur meira en tugi árangursbóta í opinbera PostgreSQL JDBC reklanum.

Umskipti yfir í hagræðingar á lágu stigi

Andrew: Þú ert stórt nafn í heimi JIT samantektar, Java og frammistöðuvinnu almennt, ekki satt? 

Cliff: Það er svona!

Andrew: Byrjum á nokkrum almennum spurningum um frammistöðuvinnu. Hvað finnst þér um valið á milli fínstillingar á háu og lágu stigi eins og að vinna á örgjörvastigi?

Cliff: Já, hér er allt einfalt. Hraðasta kóðinn er sá sem aldrei keyrir. Þess vegna þarftu alltaf að byrja á háu stigi, vinna með reiknirit. Betri O-tákn mun slá verri O-tákn, nema einhverjir nógu stórir fastar komi inn í. Hlutir á lágu stigi fara síðast. Venjulega, ef þú hefur fínstillt restina af staflanum þínum nógu vel og það er enn eitthvað áhugavert eftir, þá er það lágt stig. En hvernig á að byrja á háu stigi? Hvernig veistu að nægjanlegt starf á háu stigi hafi verið unnið? Jæja... engan veginn. Það eru engar tilbúnar uppskriftir. Þú þarft að skilja vandamálið, ákveða hvað þú ætlar að gera (til að gera ekki óþarfa ráðstafanir í framtíðinni) og svo geturðu afhjúpað prófílarann, sem getur sagt eitthvað gagnlegt. Á einhverjum tímapunkti áttarðu þig sjálfur á því að þú hefur losað þig við óþarfa hluti og það er kominn tími til að fínstilla á lágu stigi. Þetta er örugglega sérstök list. Það er fullt af fólki að gera óþarfa hluti, en fara svo hratt að þeir hafa engan tíma til að hafa áhyggjur af framleiðni. En þetta er þangað til spurningin vaknar berum orðum. Venjulega 99% tilvika er engum sama um hvað ég geri, þangað til það augnablik kemur mikilvægur hlutur á hinni mikilvægu braut sem engum er sama um. Og hér byrja allir að nöldra þig um „af hverju það virkaði ekki fullkomlega frá upphafi. Almennt séð er alltaf eitthvað sem þarf að bæta í frammistöðu. En í 99% tilfella hefurðu engar vísbendingar! Þú ert bara að reyna að láta eitthvað virka og í því ferli finnurðu út hvað er mikilvægt. Þú getur aldrei vitað fyrirfram að þetta stykki þurfi að vera fullkomið, svo í rauninni þarftu að vera fullkomið í öllu. En þetta er ómögulegt og þú gerir það ekki. Það er alltaf margt sem þarf að laga – og það er alveg eðlilegt.

Hvernig á að gera stóra endurnýjun

Andrew: Hvernig vinnur þú að gjörningi? Þetta er þverskurðarvandamál. Til dæmis, hefur þú einhvern tíma þurft að vinna að vandamálum sem koma upp vegna skurðpunkta mikillar núverandi virkni?

Cliff: Ég reyni að forðast það. Ef ég veit að árangur verður vandamál, hugsa ég um það áður en ég byrja að kóða, sérstaklega með gagnauppbyggingu. En oft uppgötvar maður þetta allt seinna. Og þá þarftu að fara í öfgafullar ráðstafanir og gera það sem ég kalla "endurskrifa og sigra": þú þarft að grípa nógu stórt stykki. Sumt af kóðanum verður samt að endurskrifa vegna frammistöðuvandamála eða einhvers annars. Hver svo sem ástæðan fyrir endurskrifa kóða er, það er næstum alltaf betra að endurskrifa stærra verk en minna. Á þessu augnabliki byrja allir að hrista af ótta: „Guð minn góður, þú getur ekki snert svo mikinn kóða! En í rauninni virkar þessi nálgun nánast alltaf miklu betur. Þú þarft strax að takast á við stórt vandamál, teikna stóran hring utan um það og segja: Ég mun endurskrifa allt inni í hringnum. Ramminn er mun minni en innihaldið inni í honum sem þarf að skipta út. Og ef slík afmörkun landamæra gerir þér kleift að vinna verkið fullkomlega, eru hendur þínar frjálsar, gerðu það sem þú vilt. Þegar þú hefur skilið vandamálið er endurritunarferlið miklu auðveldara, svo taktu þér stóran bita!
Á sama tíma, þegar þú gerir stóra endurskrifun og gerir þér grein fyrir því að frammistaða verður vandamál, geturðu strax byrjað að hafa áhyggjur af því. Þetta breytist venjulega í einfalda hluti eins og „ekki afrita gögn, stjórna gögnum eins einfaldlega og mögulegt er, gera þau lítil. Í stórum endurskrifum eru staðlaðar leiðir til að bæta árangur. Og þeir snúast nánast alltaf um gögn.

Kostnaðarlíkan

Andrew: Í einu af podcastunum talaðir þú um kostnaðarlíkön í samhengi við framleiðni. Geturðu útskýrt hvað þú varst að meina með þessu?

Cliff: Vissulega. Ég fæddist á tímum þegar frammistaða örgjörva var afar mikilvæg. Og þetta tímabil snýr aftur - örlögin eru ekki án kaldhæðni. Ég byrjaði að lifa á dögum átta bita véla; fyrsta tölvan mín virkaði með 256 bæti. Nákvæmlega bæti. Allt var mjög lítið. Það þurfti að telja leiðbeiningar og þegar við fórum að færa okkur upp forritunarmálsbunkann tóku tungumálin meira og meira á sig. Það var Assembler, svo Basic, síðan C, og C sá um mikið af smáatriðum, eins og skráningarúthlutun og kennsluvali. En þarna var allt alveg á hreinu og ef ég benti á tilvik af breytu þá fengi ég álag og kostnaðurinn við þessa kennslu er þekktur. Vélbúnaðurinn framleiðir ákveðinn fjölda vélalota, þannig að hægt er að reikna út hraða mismunandi hluta með því einfaldlega að leggja saman allar leiðbeiningarnar sem þú ætlar að keyra. Hægt væri að leggja saman hverja samanburð/prófun/útibú/símtal/hlaða/verslun og segja: það er framkvæmdartíminn fyrir þig. Þegar þú vinnur að því að bæta frammistöðu muntu örugglega borga eftirtekt til hvaða tölur samsvara litlum heitum lotum. 
En um leið og þú skiptir yfir í Java, Python og álíka hluti ferðu mjög fljótt frá vélbúnaði á lágu stigi. Hvað kostar að hringja í getter í Java? Ef JIT í HotSpot er rétt inlined, það mun hlaðast, en ef það gerði þetta ekki, verður það aðgerðarkall. Þar sem símtalið er á heitri lykkju mun það hnekkja öllum öðrum hagræðingum í þeirri lykkju. Þess vegna verður raunkostnaður mun hærri. Og þú missir strax hæfileikann til að horfa á kóða og skilja að við ættum að framkvæma það með tilliti til klukkuhraða örgjörva, minni og skyndiminni sem notað er. Allt þetta verður aðeins áhugavert ef þú kemst virkilega inn í frammistöðuna.
Nú erum við í þeirri stöðu að örgjörvahraði hefur varla aukist í áratug. Gamli dagurinn er kominn aftur! Þú getur ekki lengur treyst á góðan árangur með einum þræði. En ef þú ferð allt í einu í samhliða tölvuvinnslu, þá er það ótrúlega erfitt, allir líta á þig eins og James Bond. Tífalt hröðun hér á sér stað venjulega á stöðum þar sem einhver hefur klúðrað einhverju. Samhliða krefst mikillar vinnu. Til að fá þessa XNUMXx hraða þarftu að skilja kostnaðarlíkanið. Hvað og hvað kostar það? Og til að gera þetta þarftu að skilja hvernig tungan passar á undirliggjandi vélbúnaðinn.
Martin Thompson valdi frábært orð yfir bloggið sitt Vélræn samúð! Þú þarft að skilja hvað vélbúnaðurinn ætlar að gera, hvernig hann mun gera það nákvæmlega og hvers vegna hann gerir það sem hann gerir í fyrsta lagi. Með því að nota þetta er frekar auðvelt að byrja að telja leiðbeiningar og finna út hvert framkvæmdartíminn er að fara. Ef þú ert ekki með viðeigandi þjálfun ertu bara að leita að svörtum ketti í dimmu herbergi. Ég sé fólk hagræða frammistöðu allan tímann sem hefur ekki hugmynd um hvað í fjandanum það er að gera. Þeir þjást mikið og eru ekki að taka miklum framförum. Og þegar ég tek sama kóðann, smeyg mér inn nokkrum litlum innbrotum og fæ fimm- eða tífalda hraða, þá eru þeir eins og: jæja, það er ekki sanngjarnt, við vissum nú þegar að þú værir betri. Æðislegur. Hvað er ég að tala um... kostnaðarlíkanið snýst um hvers konar kóða þú skrifar og hversu hratt hann keyrir að meðaltali í stóra samhenginu.

Andrew: Og hvernig geturðu haldið svona bindi í hausnum? Er þetta náð með meiri reynslu, eða? Hvaðan kemur slík reynsla?

Cliff: Jæja, ég fékk ekki reynslu mína á auðveldasta hátt. Ég forritaði í Assembly á sínum tíma þegar maður gat skilið hverja einustu kennslu. Það hljómar heimskulega, en síðan þá hefur Z80 leiðbeiningasettið alltaf verið í hausnum á mér, í minningunni. Ég man ekki nöfn fólks innan við mínútu eftir að hafa talað, en ég man kóða sem skrifaður var fyrir 40 árum. Það er fyndið, það lítur út eins og heilkenni "hálfviti vísindamaður'.

Hagræðingarþjálfun á lágu stigi

Andrew: Er auðveldari leið til að komast inn?

Cliff: Já og nei. Vélbúnaðurinn sem við notum öll hefur ekki breyst mikið í gegnum tíðina. Allir nota x86, að Arm snjallsímum undanskildum. Ef þú ert ekki að gera einhvers konar harðkjarna embedding, þá ertu að gera það sama. Allt í lagi, haldið áfram. Leiðbeiningarnar hafa heldur ekki breyst um aldir. Þú þarft að fara og skrifa eitthvað í Assembly. Ekki mikið, en nóg til að byrja að skilja. Þú ert að brosa, en ég er að tala algjörlega alvarlega. Þú þarft að skilja samsvörun milli tungumáls og vélbúnaðar. Eftir það þarftu að fara og skrifa smá og búa til smá leikfangaþýðanda fyrir smá leikfangamál. Leikfangslíkt þýðir að það þarf að gera það á hæfilegum tíma. Það getur verið mjög einfalt, en það verður að búa til leiðbeiningar. Athöfnin að búa til leiðbeiningar mun hjálpa þér að skilja kostnaðarlíkanið fyrir brúna á milli háþróaða kóðans sem allir skrifa og vélkóðans sem keyrir á vélbúnaðinum. Þessi bréfaskipti verða brennd inn í heilann á þeim tíma sem þýðandinn er skrifaður. Jafnvel einfaldasta þýðandann. Eftir það geturðu farið að skoða Java og þá staðreynd að merkingargjá hennar er miklu dýpri og það er miklu erfiðara að byggja brýr yfir hana. Í Java er mun erfiðara að skilja hvort brúin okkar hafi reynst góð eða slæm, hvað verður til þess að hún falli í sundur og hvað ekki. En þú þarft einhvers konar upphafspunkt þar sem þú horfir á kóðann og skilur: "já, þessi getter ætti að vera innbyggður í hvert skipti." Og svo kemur í ljós að stundum gerist þetta, fyrir utan ástandið þegar aðferðin verður of stór, og JIT byrjar að inline allt. Hægt er að spá fyrir um frammistöðu slíkra staða strax. Venjulega virka getterar vel, en svo horfir þú á stórar heitar lykkjur og áttar þig á því að það eru einhver fallköll sem fljóta þarna um sem vita ekki hvað þeir eru að gera. Þetta er vandamálið við útbreidda notkun getters, ástæðan fyrir því að þeir eru ekki innbyggðir er sú að ekki er ljóst hvort þeir eru getter. Ef þú ert með ofurlítinn kóðagrunn geturðu einfaldlega munað það og sagt síðan: þetta er getter og þetta er setter. Í stórum kóðagrunni lifir hver aðgerð sína eigin sögu, sem almennt er ekki þekkt fyrir neinn. Prófílarinn segir að við töpuðum 24% af tímanum á einhverri lykkju og til að skilja hvað þessi lykkja er að gera þurfum við að skoða hverja aðgerð inni. Það er ómögulegt að skilja þetta án þess að rannsaka virknina og það hægir verulega á skilningsferlinu. Þess vegna nota ég ekki getters og setjara, ég er kominn á nýtt stig!
Hvar á að fá kostnaðarlíkanið? Jæja, þú getur auðvitað lesið eitthvað... En ég held að besta leiðin sé að bregðast við. Að búa til lítinn þýðanda mun vera besta leiðin til að skilja kostnaðarlíkanið og passa það inn í þitt eigið haus. Lítill þýðandi sem hentar vel til að forrita örbylgjuofn er verkefni fyrir byrjendur. Jæja, ég meina, ef þú hefur nú þegar forritunarkunnáttu, þá ætti það að vera nóg. Allt þetta eins og að flokka streng sem þú hefur sem einhvers konar algebru tjáningu, draga leiðbeiningar fyrir stærðfræðilegar aðgerðir þaðan í réttri röð, taka rétt gildi úr skrám - allt er þetta gert í einu. Og á meðan þú gerir það verður það innprentað í heilann. Ég held að allir viti hvað þýðandi gerir. Og þetta mun gefa skilning á kostnaðarlíkaninu.

Hagnýt dæmi um aukna frammistöðu

Andrew: Hvað annað ættir þú að borga eftirtekt til þegar unnið er að framleiðni?

Cliff: Gagnauppbygging. Við the vegur, já, ég hef ekki kennt þessa tíma í langan tíma... Flugeldaskóli. Það var gaman en það krafðist mikillar fyrirhafnar og ég á líka líf! Allt í lagi. Svo, í einum af stóru og áhugaverðu tímunum, „Hvert fer frammistaða þín,“ gaf ég nemendum dæmi: tvö og hálft gígabæt af fintech gögnum var lesið úr CSV skrá og síðan þurftu þeir að reikna út fjölda seldra vara . Regluleg gögn um merkjamarkaðinn. UDP pökkum breytt í textasnið síðan á áttunda áratugnum. Chicago Mercantile Exchange - alls konar hlutir eins og smjör, maís, sojabaunir, svoleiðis hlutir. Nauðsynlegt var að telja þessar vörur, fjölda viðskipta, meðalmagn hreyfingar fjármuna og vara osfrv. Þetta er frekar einföld viðskiptastærðfræði: finndu vörukóðann (það er 70-1 stafir í kjötkássatöflunni), fáðu upphæðina, bættu því við eitt af viðskiptasettunum, bættu við magni, bættu við gildi og nokkrum öðrum hlutum. Mjög einföld stærðfræði. Leikfangsútfærslan var mjög einföld: allt er í skrá, ég les skrána og fer í gegnum hana, skipti einstökum færslum í Java strengi, leitaði að nauðsynlegum hlutum í þeim og bæti þeim saman í samræmi við stærðfræðina sem lýst er hér að ofan. Og það virkar á litlum hraða.

Með þessari nálgun er augljóst hvað er að gerast og samhliða tölvuvinnslu mun ekki hjálpa, ekki satt? Það kemur í ljós að hægt er að ná fimmföldun á frammistöðu einfaldlega með því að velja rétt gagnaskipulag. Og þetta kemur jafnvel reyndum forriturum á óvart! Í mínu sérstöku tilviki var bragðið að þú ættir ekki að gera minnisúthlutun í heitri lykkju. Jæja, þetta er ekki allur sannleikurinn, en almennt séð - þú ættir ekki að auðkenna „einu sinni í X“ þegar X er nógu stórt. Þegar X er tvö og hálft gígabæt, ættirðu ekki að úthluta neinu „einu sinni á staf“ eða „einu sinni á línu“ eða „einu sinni á sviði“, neitt svoleiðis. Þetta er þar sem tímanum er varið. Hvernig virkar þetta jafnvel? Ímyndaðu þér að ég hringi String.split() eða BufferedReader.readLine(). Readline gerir streng úr setti bæta sem komu yfir netið, einu sinni fyrir hverja línu, fyrir hverja af hundruðum milljóna lína. Ég tek þessa línu, flokka hana og henda henni. Af hverju er ég að henda því - jæja, ég hef þegar unnið það, það er allt. Svo, fyrir hvert bæti sem lesið er af þessum 2.7G, verða tveir stafir skrifaðir í línuna, það er þegar 5.4G, og ég þarf þá ekki fyrir neitt frekar, svo þeim er hent. Ef þú horfir á minnisbandbreiddina þá hleðum við 2.7G sem fer í gegnum minni og minnisbus í örgjörvann og þá er tvisvar sinnum meira sent á línuna sem liggur í minni og allt þetta slitnar þegar hver ný lína er búin til. En ég þarf að lesa það, vélbúnaðurinn les hann, jafnvel þótt allt sé slitið seinna meir. Og ég verð að skrifa það niður vegna þess að ég bjó til línu og skyndiminni eru full - skyndiminni rúmar ekki 2.7G. Svo, fyrir hvert bæti sem ég les, les ég tvö bæti í viðbót og skrifa tvö bæti í viðbót, og á endanum eru þau með 4:1 hlutfallið - í þessu hlutfalli erum við að sóa minnisbandbreidd. Og þá kemur í ljós að ef ég geri það String.split() – þetta er ekki í síðasta sinn sem ég geri þetta, það gætu verið 6-7 vellir í viðbót. Svo klassíski kóðinn að lesa CSV og flokka strengina leiðir til sóunar á minni bandbreidd um það bil 14:1 miðað við það sem þú vilt raunverulega hafa. Ef þú hendir þessu vali geturðu fengið fimmfalda hraðaupphlaup.

Og það er ekki svo erfitt. Ef þú horfir á kóðann frá réttu sjónarhorni verður þetta allt frekar einfalt þegar þú áttar þig á vandamálinu. Þú ættir ekki að hætta alveg að úthluta minni: eina vandamálið er að þú úthlutar einhverju og það deyr strax og í leiðinni brennir það mikilvægri auðlind, sem í þessu tilfelli er minnisbandbreidd. Og allt þetta leiðir til lækkunar á framleiðni. Á x86 þarftu venjulega að brenna örgjörvalotur virkan, en hér brenndir þú allt minni miklu fyrr. Lausnin er að draga úr losunarmagni. 
Hinn hluti vandans er sá að ef þú keyrir profilerinn þegar minnisröndin klárast, rétt þegar það gerist, þá ertu venjulega að bíða eftir að skyndiminni komi aftur því hann er fullur af rusli sem þú varst að framleiða, allar þessar línur. Þess vegna verður sérhver hleðsla eða verslunaraðgerð hæg, vegna þess að þau leiða til skyndiminnimissis - allt skyndiminni er orðið hægt og bíður þess að sorp fari frá því. Þess vegna mun prófunarmaðurinn bara sýna hlýjan tilviljunarkennd hávaða sem er smurður um alla lykkjuna - það verður engin sérstök heit kennsla eða staðsetning í kóðanum. Aðeins hávaði. Og ef þú horfir á GC loturnar, þá eru þær allar Young Generation og ofurhröð - míkrósekúndur eða millisekúndur að hámarki. Enda deyr öll þessi minning samstundis. Þú úthlutar milljörðum gígabæta, og hann klippir þá, og sker þá, og sker þá aftur. Allt þetta gerist mjög fljótt. Það kemur í ljós að það eru ódýrir GC hringrásir, hlýr hávaði á öllu lotunni, en við viljum fá 5x hraða. Á þessari stundu ætti eitthvað að lokast í hausnum á þér og hljóma: "af hverju er þetta?!" Yfirflæði minnisræma birtist ekki í klassíska kembiforritinu; þú þarft að keyra vélbúnaðarframmistöðuteljarann ​​og sjá hann sjálfur og beint. En þetta er ekki hægt að gruna beint út frá þessum þremur einkennum. Þriðja einkennin er þegar þú horfir á það sem þú undirstrikar, spyrð prófílstjórann og hann svarar: „Þú gerðir milljarð raða, en GC virkaði ókeypis. Um leið og þetta gerist áttarðu þig á því að þú hefur búið til of marga hluti og brennt upp alla minnisbrautina. Það er leið til að átta sig á þessu, en það er ekki augljóst. 

Vandamálið er í gagnauppbyggingunni: beina uppbyggingin sem liggur að baki öllu sem gerist, hún er of stór, hún er 2.7G á disknum, svo það er mjög óæskilegt að gera afrit af þessu - þú vilt hlaða það strax úr netbætabuffi. inn í skrárnar, til að lesa-skrifa ekki í línuna fram og til baka fimm sinnum. Því miður gefur Java þér ekki slíkt bókasafn sem hluta af JDK sjálfgefið. En þetta er léttvægt, ekki satt? Í meginatriðum eru þetta 5-10 línur af kóða sem verða notaðar til að útfæra þinn eigin biðminni strengjahleðslutæki, sem endurtekur hegðun strengjaflokksins, á meðan hann er umbúðir utan um undirliggjandi bæta biðminni. Fyrir vikið kemur í ljós að þú ert að vinna nánast eins og með strengi, en í raun eru vísar á biðminni að færast þangað og hrábætin eru hvergi afrituð og þar með eru sömu biðminni endurnýttir aftur og aftur, og stýrikerfið er fús til að taka á sjálfan þig hlutina sem það er hannað fyrir, eins og falinn tvöfaldur-bufferingu á þessum bætabuffum, og þú ert ekki lengur að mala í gegnum endalausan straum af óþarfa gögnum. Við the vegur, skilurðu að þegar unnið er með GC er tryggt að hver minnisúthlutun sé ekki sýnileg örgjörvanum eftir síðustu GC lotuna? Þess vegna getur allt þetta ómögulega verið í skyndiminni og þá á sér stað 100% tryggð missi. Þegar unnið er með bendili, á x86, tekur það 1-2 klukkulotur að draga skrá úr minni, og um leið og þetta gerist borgar þú, borgar, borgar, því minnið er allt á NÍU skyndiminni – og þetta er kostnaður við minnisúthlutun. Raunverulegt verðmæti.

Með öðrum orðum, gagnaskipulag er það erfiðasta að breyta. Og þegar þú áttar þig á því að þú hefur valið ranga gagnauppbyggingu sem mun drepa árangur seinna meir, þá er yfirleitt mikið verk fyrir höndum, en ef þú gerir það ekki mun hlutirnir versna. Fyrst af öllu þarftu að hugsa um gagnaskipulag, þetta er mikilvægt. Aðalkostnaðurinn hér fellur á feita gagnabyggingu, sem byrjað er að nota í stílnum „Ég afritaði gagnagerð X inn í gagnagerð Y vegna þess að mér líkar betur við lögun Y. En afritunaraðgerðin (sem virðist ódýr) sóar í raun minnisbandbreidd og það er þar sem allur sóun á framkvæmdartíma er grafinn. Ef ég er með risastóran streng af JSON og ég vil breyta honum í uppbyggt DOM-tré af POJO eða eitthvað, mun aðgerðin við að flokka þann streng og byggja upp POJO, og síðan fá aðgang að POJO aftur síðar, hafa í för með sér óþarfa kostnað - það er ekki ódýrt. Nema ef þú hleypur um POJOs miklu oftar en þú hleypur í kringum streng. Í staðinn geturðu reynt að afkóða strenginn og draga aðeins það sem þú þarft þaðan, án þess að breyta því í neinn POJO. Ef allt þetta gerist á leið þar sem hámarksafköst er krafist, engin POJOs fyrir þig, þú þarft einhvern veginn að grafa beint í línuna.

Af hverju að búa til þitt eigið forritunarmál

Andrew: Þú sagðir að til að skilja kostnaðarlíkanið þarftu að skrifa þitt eigið litla tungumál...

Cliff: Ekki tungumál, heldur þýðandi. Tungumál og þýðandi eru tveir ólíkir hlutir. Mikilvægasti munurinn er í höfðinu á þér. 

Andrew: Við the vegur, eftir því sem ég best veit ertu að gera tilraunir með að búa til þín eigin tungumál. Til hvers?

Cliff: Af því að ég get! Ég er hálfgerður eftirlaun, svo þetta er áhugamálið mitt. Ég hef verið að innleiða tungumál annarra allt mitt líf. Ég vann líka mikið í kóðunarstílnum mínum. Og líka vegna þess að ég sé vandamál á öðrum tungumálum. Ég sé að það eru betri leiðir til að gera kunnuglega hluti. Og ég myndi nota þá. Ég er bara þreytt á að sjá vandamál í sjálfum mér, í Java, í Python, á hvaða tungumáli sem er. Ég skrifa núna í React Native, JavaScript og Elm sem áhugamál sem snýst ekki um starfslok, heldur um virka vinnu. Ég skrifa líka í Python og mun líklegast halda áfram að vinna að vélanámi fyrir Java bakenda. Það eru mörg vinsæl tungumál og þau hafa öll áhugaverða eiginleika. Allir eru góðir á sinn hátt og þú getur reynt að koma öllum þessum eiginleikum saman. Svo ég er að kynna mér hluti sem vekja áhuga minn, hegðun tungumálsins, að reyna að koma með sanngjarna merkingarfræði. Og hingað til hef ég náð árangri! Í augnablikinu er ég að berjast við minnismerkingarfræði, því ég vil hafa það eins og í C og Java, og fá sterkt minnislíkan og minnismerkingarfræði fyrir álag og geymslur. Á sama tíma skaltu hafa sjálfvirka gerð ályktunar eins og í Haskell. Hérna er ég að reyna að blanda Haskell-eins tegundarályktun við minnisvinnu í bæði C og Java. Þetta er það sem ég hef verið að gera síðustu 2-3 mánuði til dæmis.

Andrew: Ef þú byggir upp tungumál sem tekur betri hliðar frá öðrum tungumálum, heldurðu að einhver muni gera hið gagnstæða: taka hugmyndir þínar og nota þær?

Cliff: Þetta er nákvæmlega hvernig ný tungumál birtast! Af hverju er Java svipað C? Vegna þess að C var með góða setningafræði sem allir skildu og Java var innblásin af þessari setningafræði, bætti við tegundaöryggi, fylkismörkum, GC, og þeir bættu líka sumt frá C. Þeir bættu við sínu eigin. En þeir voru innblásnir frekar mikið, ekki satt? Allir standa á herðum risanna sem komu á undan þér - þannig verða framfarir.

Andrew: Eins og ég skil það mun tungumálið þitt vera minnið öruggt. Hefurðu hugsað þér að útfæra eitthvað eins og lánatékka frá Rust? Hefurðu horft á hann, hvað finnst þér um hann?

Cliff: Jæja, ég hef skrifað C í aldanna rás, með öllu þessu malloc og ókeypis, og handvirkt stjórnað líftímanum. Þú veist, 90-95% af handstýrðum líftíma hefur sömu uppbyggingu. Og það er mjög, mjög sárt að gera það handvirkt. Ég myndi vilja að þýðandinn segði þér einfaldlega hvað er að gerast þar og hverju þú náðir með aðgerðum þínum. Fyrir suma hluti, lána afgreiðslumaður gerir þetta út úr kassanum. Og það ætti sjálfkrafa að birta upplýsingar, skilja allt og ekki einu sinni íþyngja mér með því að koma þessum skilningi á framfæri. Það verður að gera að minnsta kosti staðbundna flóttagreiningu, og aðeins ef það mistekst, þá þarf það að bæta við tegundaskýringum sem munu lýsa líftíma - og slíkt kerfi er miklu flóknara en lánatafl, eða raunar hvaða minnistöf sem fyrir er. Valið á milli „allt er í lagi“ og „ég skil ekki neitt“ - nei, það hlýtur að vera eitthvað betra. 
Svo, sem einhver sem hefur skrifað mikið af kóða í C, þá held ég að það sé mikilvægast að hafa stuðning við sjálfvirka líftímastýringu. Ég er líka leiður á því hversu mikið Java notar minni og helsta kvörtunin er GC. Þegar þú úthlutar minni í Java færðu ekki minni sem var staðbundið í síðustu GC lotu til baka. Þetta er ekki raunin í tungumálum með nákvæmari minnisstjórnun. Ef þú hringir í malloc færðu strax minnið sem var venjulega bara notað. Venjulega gerirðu tímabundna hluti með minni og skilar því strax aftur. Og það fer strax aftur í malloc laugina og næsta malloc hringrás dregur það út aftur. Þess vegna minnkar raunveruleg minnisnotkun niður í mengi lifandi hluta á tilteknum tíma, auk leka. Og ef allt lekur ekki á algjörlega ósæmilegan hátt, endar megnið af minninu í skyndiminni og örgjörvanum og það virkar hratt. En krefst mikillar handvirkrar minnisstjórnunar með malloc og ókeypis kölluðu í réttri röð, á réttum stað. Ryð sjálft ræður við þetta rétt og gefur í mörgum tilfellum enn betri afköst, þar sem minnisnotkun er þrengd niður í aðeins núverandi útreikninga - öfugt við að bíða eftir næstu GC lotu til að losa um minni. Fyrir vikið fengum við mjög áhugaverða leið til að bæta árangur. Og nokkuð öflugt - ég meina, ég gerði slíka hluti við vinnslu gagna fyrir fintech, og þetta gerði mér kleift að ná um það bil fimm sinnum hraða. Það er frekar mikil uppörvun, sérstaklega í heimi þar sem örgjörvar verða ekki hraðari og við erum enn að bíða eftir endurbótum.

Ferill árangursverkfræðings

Andrew: Mig langar líka að spyrjast fyrir um störf almennt. Þú komst upp á sjónarsviðið með JIT starfi þínu hjá HotSpot og fluttir síðan til Azul, sem er einnig JVM fyrirtæki. En við vorum þegar að vinna meira í vélbúnaði en hugbúnaði. Og svo skiptu þeir skyndilega yfir í Big Data og Machine Learning og síðan yfir í svikauppgötvun. Hvernig gerðist þetta? Þetta eru mjög ólík þróunarsvið.

Cliff: Ég hef verið að forrita í nokkuð langan tíma og hef náð að taka fullt af mismunandi námskeiðum. Og þegar fólk segir: „ó, þú ert sá sem gerðir JIT fyrir Java!“, þá er það alltaf fyndið. En áður var ég að vinna að klón af PostScript - tungumálinu sem Apple notaði einu sinni fyrir leysiprentara sína. Og áður en ég gerði útfærslu á Forth tungumálinu. Ég held að sameiginlega þemað fyrir mig sé verkfæraþróun. Allt mitt líf hef ég verið að búa til verkfæri sem annað fólk skrifar flott forritin sín með. En ég tók líka þátt í þróun stýrikerfa, rekla, kjarnakembiforrita, tungumála fyrir stýrikerfisþróun, sem byrjaði léttvægt, en varð með tímanum flóknari og flóknari. En meginviðfangsefnið er samt þróun verkfæra. Stór hluti af lífi mínu fór á milli Azul og Sun, og það var um Java. En þegar ég kom inn í Big Data og Machine Learning, setti ég flotta hattinn aftur á mig og sagði: „Ó, nú erum við með óléttvæg vandamál, og það er margt áhugavert í gangi og fólk að gera hluti. Þetta er frábær þróunarleið sem þarf að fara.

Já, ég elska dreifða tölvuvinnslu. Fyrsta starf mitt var sem nemandi í C, í auglýsingaverkefni. Þetta var dreifð tölva á Zilog Z80 flísum sem safnaði gögnum fyrir hliðrænan OCR, framleidd með raunverulegum hliðstæðum greiningartæki. Þetta var flott og algjörlega klikkað umræðuefni. En það voru vandamál, einhver hluti var ekki þekktur rétt þannig að þú þurftir að taka út mynd og sýna aðila sem gat lesið með augunum og sagt frá því sem hann sagði og þess vegna voru störf með gögn, og þessi störf höfðu sitt eigið tungumál. Það var bakendi sem afgreiddi þetta allt - Z80s keyrðu samhliða vt100 útstöðvum í gangi - einn á mann og það var samhliða forritunarlíkan á Z80. Sumt sameiginlegt minni sem allir Z80-bílar deila innan stjörnustillingar; Bakplaninu var einnig deilt og helmingur vinnsluminnisins var deilt innan netsins og annar helmingurinn var einkarekinn eða fór í eitthvað annað. Merkingarríkt flókið samhliða dreifð kerfi með sameiginlegu... hálfdeilt minni. Hvenær var þetta... ég man ekki einu sinni, einhvers staðar um miðjan níunda áratuginn. Alveg langt síðan. 
Já, við skulum gera ráð fyrir að 30 ár séu nokkuð langt síðan. Vandamál tengd dreifðri tölvunotkun hafa verið til í nokkuð langan tíma; fólk hefur lengi átt í stríði við Beowulf-þyrpingar. Slíkir klasar líta út eins og... Til dæmis: það er Ethernet og hraðvirki x86 er tengdur við þetta Ethernet, og nú viltu fá falsað sameiginlegt minni, því enginn gat gert dreifða tölvukóðun þá, það var of erfitt og þess vegna var falsað deilt minni með verndarminnissíðum á x86, og ef þú skrifaðir á þessa síðu, þá sögðum við öðrum örgjörvum að ef þeir fá aðgang að sama samnýtta minni þyrfti að hlaða það frá þér, og þar með eitthvað eins og samskiptareglur til að styðja skyndiminni coherence birtist og hugbúnaður fyrir þetta. Áhugavert hugtak. Raunverulega vandamálið var auðvitað eitthvað annað. Allt þetta virkaði, en þú fékkst fljótt frammistöðuvandamál, því enginn skildi frammistöðulíkönin á nógu góðu stigi - hvaða minnisaðgangsmynstur voru til staðar, hvernig á að ganga úr skugga um að hnútarnir pinguðu ekki endalaust hver annan o.s.frv.

Það sem ég komst að í H2O er að það eru verktaki sjálfir sem eru ábyrgir fyrir því að ákvarða hvar hliðstæður eru falin og hvar ekki. Ég fann upp kóðunarlíkan sem gerði það auðvelt og einfalt að skrifa afkastamikinn kóða. En það er erfitt að skrifa hægfara kóða, það mun líta illa út. Þú þarft alvarlega að reyna að skrifa hægan kóða, þú verður að nota óhefðbundnar aðferðir. Bremsukóðinn sést við fyrstu sýn. Þar af leiðandi skrifar þú venjulega kóða sem keyrir hratt, en þú verður að finna út hvað á að gera ef um er að ræða sameiginlegt minni. Allt er þetta bundið við stór fylki og hegðunin þar er svipuð og óstöðug stór fylki samhliða Java. Ég meina, ímyndaðu þér að tveir þræðir skrifi í samhliða fylki, annar þeirra vinnur og hinn tapar því, og þú veist ekki hver er hver. Ef þeir eru ekki sveiflukenndir, þá getur pöntunin verið hvað sem þú vilt - og þetta virkar mjög vel. Fólki er mjög sama um röð aðgerða, það setur óstöðugt á rétta staði og býst við minnistengdum frammistöðuvandamálum á réttum stöðum. Annars myndu þeir einfaldlega skrifa kóða í formi lykkja frá 1 til N, þar sem N er einhverjar trilljónir, í von um að öll flókin tilvik verði sjálfkrafa samsíða - og það virkar ekki þar. En í H2O er þetta hvorki Java né Scala; þú getur talið það „Java mínus mínus“ ef þú vilt. Þetta er mjög skýr forritunarstíll og er svipað og að skrifa einfaldan C eða Java kóða með lykkjum og fylkjum. En á sama tíma er hægt að vinna úr minni í terabætum. Ég nota enn H2O. Ég nota það af og til í mismunandi verkefnum - og það er enn það hraðasta, tugum sinnum hraðar en keppinautarnir. Ef þú ert að gera Big Data með dálkagögnum, þá er mjög erfitt að slá H2O.

Tæknilegar áskoranir

Andrew: Hver hefur verið stærsta áskorunin þín á öllum þínum ferli?

Cliff: Erum við að ræða tæknilega eða ótæknilega hluta málsins? Ég myndi segja að stærstu áskoranirnar séu ekki tæknilegar. 
Hvað varðar tæknilegar áskoranir. Ég sigraði þá einfaldlega. Ég veit ekki einu sinni hver sá stærsti var, en það voru nokkrir ansi áhugaverðir sem tóku talsverðan tíma, andlega baráttu. Þegar ég fór á Sun var ég viss um að ég myndi gera hraðvirkan þýðanda og hópur eldri borgara sagði sem svar að ég myndi aldrei ná árangri. En ég fór þessa leið, skrifaði þýðanda niður á skráarúthlutunaraðilann og það var frekar hratt. Það var eins hratt og nútíma C1, en úthlutunartækið var miklu hægara þá, og eftir á að hyggja var þetta mikið vandamál með uppbyggingu gagna. Ég þurfti það til að skrifa grafískan skráaúthlutunaraðila og ég skildi ekki vandamálið milli tjáningarhæfileika kóða og hraða, sem var til á þeim tíma og var mjög mikilvægt. Það kom í ljós að gagnauppbyggingin fer venjulega yfir skyndiminni stærð á x86s þess tíma, og þess vegna, ef ég gerði ráð fyrir að skráarúthlutunartækið myndi vinna út 5-10 prósent af heildar jitter tíma, þá reyndist það í raun og veru vera 50 prósent.

Eftir því sem tíminn leið varð þýðandinn hreinni og skilvirkari, hætti að búa til hræðilegan kóða í fleiri tilfellum og afköst fóru í auknum mæli að líkjast því sem C þýðandinn framleiðir. Nema auðvitað þú skrifar eitthvað vitleysu sem jafnvel C flýtir ekki fyrir. . Ef þú skrifar kóða eins og C færðu frammistöðu eins og C í fleiri tilfellum. Og því lengra sem þú fórst, því oftar sem þú fékkst kóða sem féll einkennalaust saman við stig C, skráarúthlutunartækið byrjaði að líta út eins og eitthvað heill... óháð því hvort kóðinn þinn keyrir hratt eða hægt. Ég hélt áfram að vinna að úthlutunaraðilanum til að gera það betra val. Hann varð hægari og hægari en gaf alltaf betri og betri frammistöðu í þeim tilfellum sem enginn annar réð við. Ég gæti kafað inn í skráarúthlutunaraðila, grafið þar mánaðarvinnu og allt í einu byrjaði allur kóðinn að keyra 5% hraðar. Þetta gerðist aftur og aftur og skráarúthlutunarmaðurinn varð að einhverju listaverki - allir elskuðu það eða hötuðu það og fólk úr akademíunni spurði spurninga um efnið "af hverju er allt gert svona", af hverju ekki línuskönnun, og hver er munurinn. Svarið er enn það sama: úthlutunartæki sem byggir á línuritslitun auk mjög varkárrar vinnu með biðminniskóðann jafngildir sigurvopni, besta samsetningin sem enginn getur sigrað. Og þetta er frekar óljóst. Allt annað sem þýðandinn gerir þar eru nokkuð vel rannsakaðir hlutir, þó þeir hafi líka verið færðir á listastigið. Ég gerði alltaf hluti sem áttu að breyta þýðandanum í listaverk. En ekkert af þessu var neitt óvenjulegt - nema skráarúthlutunarmaðurinn. Galdurinn er að fara varlega skera niður undir álagi og, ef þetta gerist (ég get útskýrt nánar ef áhugi er fyrir), þýðir þetta að þú getur sett inn árásargjarnari, án þess að eiga á hættu að falla um hnökra í frammistöðuáætluninni. Í þá daga var fullt af þýðendum í fullri stærð, hengdir með kúlur og flautur, sem voru með skráaúthlutunaraðila, en enginn annar gat gert það.

Vandamálið er að ef þú bætir við aðferðum sem eru háðar innfóðrun, stækkar og stækkar innfóðrunarsvæðið, þá fer safnið af notuðum gildum samstundis fram úr fjölda skráa og þú verður að klippa þau. Mikilvæga stigið kemur venjulega þegar úthlutunaraðilinn gefst upp og einn góður frambjóðandi fyrir leka er annars virði, þú munt selja venjulega villta hluti. Gildi innfóðrunar hér er að þú tapar hluta af kostnaði, kostnaður fyrir að hringja og vista, þú getur séð gildin inni og getur hagrætt þeim frekar. Kostnaðurinn við innfóðrun er sá að mikill fjöldi lifandi gilda myndast og ef skráarúthlutunin þín brennur meira en nauðsynlegt er taparðu strax. Þess vegna eiga flestir úthlutunaraðilar við vandamál: þegar innfóðrun fer yfir ákveðna línu, byrjar allt í heiminum að skera niður og framleiðni er hægt að skola niður í klósettið. Þeir sem innleiða þýðandann bæta við nokkrum heuristics: til dæmis að hætta að setja inn fóðrun, byrja með nógu stórri stærð, þar sem úthlutun eyðileggur allt. Svona myndast kink í frammistöðugrafinu - þú inline, inline, frammistaðan vex hægt - og svo uppsveifla! – það dettur niður eins og snöggur tjakkur vegna þess að þú fóðraðir of mikið. Svona virkaði allt fyrir tilkomu Java. Java krefst miklu meiri inlining, svo ég þurfti að gera úthlutunartækið mitt mun árásargjarnara þannig að það jafnast út frekar en að hrynja, og ef þú innlínir of mikið, þá byrjar það að hella niður, en svo kemur "no more spilling" augnablikið samt. Þetta er áhugaverð athugun og hún kom mér bara upp úr engu, ekki augljós, en hún skilaði sér vel. Ég tók upp árásargjarna inlining og það fór með mig á staði þar sem Java og C frammistaða vinna hlið við hlið. Þeir eru mjög nálægt - ég get skrifað Java kóða sem er umtalsvert hraðari en C kóða og svoleiðis, en að meðaltali, í stóru samhenginu, eru þeir nokkurn veginn sambærilegir. Ég held að hluti af þessum kostum sé skráarúthlutunaraðilinn, sem gerir mér kleift að setja inn eins heimskulega og mögulegt er. Ég setti bara allt sem ég sé. Spurningin hér er hvort úthlutunartækið virki vel, hvort niðurstaðan sé skynsamlega vinnandi kóða. Þetta var mikil áskorun: að skilja þetta allt og láta það virka.

Smá um skráaúthlutun og fjölkjarna

Vladimir: Vandamál eins og úthlutun skráa virðast vera einhvers konar eilíft, endalaust umræðuefni. Ég velti því fyrir mér hvort það hafi einhvern tíma verið hugmynd sem þótti vænleg og síðan misheppnuð í framkvæmd?

Cliff: Svo sannarlega! Skráarúthlutun er svæði þar sem þú reynir að finna einhverja heuristic til að leysa NP-fullkomið vandamál. Og þú getur aldrei náð fullkominni lausn, ekki satt? Þetta er einfaldlega ómögulegt. Sjáðu, Ahead of Time samantekt - hún virkar líka illa. Samtalið hér snýst um nokkur meðalmál. Um dæmigerða frammistöðu, þannig að þú getur farið og mælt eitthvað sem þú heldur að sé góður dæmigerður árangur - þegar allt kemur til alls ertu að vinna að því að bæta hann! Úthlutun skráa snýst um frammistöðu. Þegar þú ert með fyrstu frumgerðina virkar hún og málar það sem þarf, gjörningavinnan hefst. Þú þarft að læra að mæla vel. Hvers vegna er það mikilvægt? Ef þú ert með skýr gögn geturðu skoðað mismunandi svæði og séð: já, það hjálpaði hér, en það var þar sem allt brast! Nokkrar góðar hugmyndir koma upp, þú bætir við nýjum heuristics og allt í einu fer allt að virka aðeins betur að meðaltali. Eða það byrjar ekki. Ég var með fullt af málum þar sem við vorum að berjast fyrir fimm prósenta frammistöðu sem aðgreindi þróun okkar frá fyrri úthlutunaraðila. Og í hvert skipti sem það lítur svona út: einhvers staðar vinnurðu, einhvers staðar taparðu. Ef þú hefur góð frammistöðugreiningartæki geturðu fundið týndu hugmyndirnar og skilið hvers vegna þær mistakast. Kannski er það þess virði að láta allt vera eins og það er, eða kannski taka alvarlegri leið til að fínstilla, eða fara út og laga eitthvað annað. Það er fullt af hlutum! Ég gerði þetta flotta hakk, en ég þarf líka þennan, og þennan og þennan - og heildarsamsetning þeirra gefur nokkrar endurbætur. Og einfarar geta mistekist. Þetta er eðli frammistöðuvinnu á NP-fullkomnum vandamálum.

Vladimir: Maður fær á tilfinninguna að hlutir eins og að mála í úthlutunartækjum séu vandamál sem þegar hafi verið leyst. Jæja, það er ákveðið fyrir þig, miðað við það sem þú ert að segja, svo er það jafnvel þess virði þá...

Cliff: Það er ekki leyst sem slíkt. Það ert þú sem verður að breyta því í "leyst". Það eru erfið vandamál og þau þarf að leysa. Þegar þessu er lokið er kominn tími til að vinna að framleiðni. Þú þarft að nálgast þessa vinnu í samræmi við það - gerðu viðmið, safnaðu mælingum, útskýrðu aðstæður þegar, þegar þú fórst aftur í fyrri útgáfu, byrjaði gamla hakkið þitt að virka aftur (eða öfugt, hætti). Og ekki gefast upp fyrr en þú hefur náð einhverju. Eins og ég sagði þegar, ef það eru flottar hugmyndir sem virkuðu ekki, en á sviði úthlutunar á hugmyndaskrám er það um það bil endalaust. Þú getur til dæmis lesið vísindarit. Þó nú sé þetta svæði farið að hreyfast mun hægar og orðið skýrara en í æsku. Hins vegar eru ótal margir sem starfa á þessu sviði og allar þeirra hugmyndir eru þess virði að prófa, þær bíða allar í vændum. Og þú getur ekki sagt hversu góð þau eru nema þú prófir þau. Hversu vel samþættast þeir við allt annað í úthlutunaraðilanum þínum, vegna þess að úthlutunaraðili gerir margt og sumar hugmyndir í þínum sérstaka úthlutunaraðila munu ekki virka, en í öðrum úthlutunaraðila munu þeir auðveldlega. Helsta leiðin til að vinna fyrir úthlutunaraðilann er að draga hæga dótið út fyrir aðalbrautina og þvinga það til að skipta sér eftir mörkum hægu leiðanna. Svo ef þú vilt keyra GC, farðu hægu leiðina, afhagaðu, hentu undanþágu, allt það dót - þú veist að þessir hlutir eru tiltölulega sjaldgæfir. Og þeir eru mjög sjaldgæfir, athugaði ég. Þú vinnur aukavinnu og það fjarlægir mikið af hömlunum á þessum hægu slóðum, en það skiptir ekki öllu máli því þær eru hægar og sjaldan ferðaðar. Til dæmis núllbending - það gerist aldrei, ekki satt? Þú þarft að hafa nokkrar leiðir fyrir mismunandi hluti, en þeir ættu ekki að trufla þann aðal. 

Vladimir: Hvað finnst þér um fjölkjarna, þegar það eru þúsundir kjarna í einu? Er þetta gagnlegur hlutur?

Cliff: Velgengni GPU sýnir að það er mjög gagnlegt!

Vladimir: Þeir eru frekar sérhæfðir. Hvað með almenna örgjörva?

Cliff: Jæja, það var viðskiptamódel Azul. Svarið kom aftur á tímum þegar fólk elskaði virkilega fyrirsjáanlega frammistöðu. Það var erfitt að skrifa samhliða kóða þá. H2O kóðunarlíkanið er mjög skalanlegt, en það er ekki almennt líkan. Kannski aðeins almennari en þegar GPU er notað. Erum við að tala um hversu flókið það er að þróa slíkt eða flókið að nota það? Til dæmis kenndi Azul mér áhugaverða lexíu, frekar óljósa: lítil skyndiminni eru eðlileg. 

Stærsta áskorunin í lífinu

Vladimir: Hvað með ótæknilegar áskoranir?

Cliff: Stærsta áskorunin var að vera ekki... góður og góður við fólk. Og fyrir vikið lenti ég stöðugt í miklum átökum. Þeir þar sem ég vissi að hlutirnir voru að fara úrskeiðis, en vissu ekki hvernig ég átti að halda áfram með þessi vandamál og réðu ekki við þau. Mörg langtímavandamál, sem stóðu í áratugi, komu upp með þessum hætti. Sú staðreynd að Java er með C1 og C2 þýðendur er bein afleiðing af þessu. Sú staðreynd að það var engin fjölþrepa samantekt í Java í tíu ár í röð er líka bein afleiðing. Það er augljóst að við þurftum slíkt kerfi en það er ekki augljóst hvers vegna það var ekki til. Ég átti í vandræðum með einn verkfræðing... eða hóp af verkfræðingum. Einu sinni, þegar ég byrjaði að vinna hjá Sun, var ég... Allt í lagi, ekki bara þá, ég hef yfirleitt alltaf mína skoðun á öllu. Og ég hélt að það væri satt að þú gætir bara tekið þennan sannleika þinn og sagt hann beint út. Sérstaklega þar sem ég hafði átakanlega rétt fyrir mér oftast. Og ef þér líkar ekki þessi nálgun ... sérstaklega ef þú hefur augljóslega rangt fyrir þér og gerir vitleysu ... Almennt séð gætu fáir þolað þetta samskiptaform. Þó sumir gætu, eins og ég. Ég hef byggt allt mitt líf á verðleikareglum. Ef þú sýnir mér eitthvað rangt mun ég strax snúa mér við og segja: þú sagðir bull. Á sama tíma biðst ég auðvitað afsökunar og allt það, ég mun taka eftir ágætum, ef einhver er, og grípa til annarra réttar aðgerða. Aftur á móti hef ég átakanlega rétt fyrir mér um átakanlega stórt hlutfall af heildartímanum. Og það virkar ekki mjög vel í samskiptum við fólk. Ég er ekki að reyna að vera góður, en ég spyr spurningarinnar hreint út. „Þetta mun aldrei virka, því einn, tveir og þrír. Og þeir voru eins og, "Ó!" Það voru aðrar afleiðingar sem líklega var betra að hunsa: til dæmis þær sem leiddu til skilnaðar við konuna mína og tíu ára þunglyndis eftir það.

Áskorun er barátta við fólk, með skynjun þess á því hvað þú getur eða getur ekki gert, hvað er mikilvægt og hvað ekki. Það voru margar áskoranir varðandi kóðunarstíl. Ég skrifa enn mikið af kóða og í þá daga þurfti ég meira að segja að hægja á mér vegna þess að ég var að gera of mörg samhliða verkefni og gera þau illa í stað þess að einbeita mér að einu. Þegar ég lít til baka skrifaði ég hálfan kóðann fyrir Java JIT skipunina, C2 skipunina. Næstfljótasti kóðarinn skrifaði helmingi hægar, sá næsti helmingi hægari og það var veldisfallslækkun. Sjöundi aðilinn í þessari röð var mjög, mjög hægur - það gerist alltaf! Ég snerti mikið af kóða. Ég skoðaði hver skrifaði hvað, undantekningarlaust starði ég á kóðann þeirra, fór yfir hvern þeirra og hélt samt áfram að skrifa meira sjálfur en nokkur þeirra. Þessi nálgun virkar ekki mjög vel með fólki. Sumum líkar þetta ekki. Og þegar þeir ráða ekki við það byrja alls kyns kvartanir. Til dæmis var mér einu sinni sagt að hætta að kóða vegna þess að ég var að skrifa of mikinn kóða og það var að stofna liðinu í hættu, og þetta hljómaði allt eins og brandari fyrir mér: gaur, ef restin af liðinu hverfur og ég held áfram að skrifa kóða, þú Mun bara missa hálft lið. Á hinn bóginn, ef ég held áfram að skrifa kóða og þú missir helminginn af liðinu, þá hljómar það eins og mjög slæm stjórnun. Ég hugsaði eiginlega aldrei um það, talaði aldrei um það, en þetta var samt einhvers staðar í hausnum á mér. Hugsunin snerist í bakið á mér: "Eruð þið öll að grínast?" Svo, stærsta vandamálið var ég og samskipti mín við fólk. Nú skil ég sjálfan mig miklu betur, ég var liðsstjóri fyrir forritara í langan tíma, og núna segi ég fólki beint: þú veist, ég er sá sem ég er og þú verður að eiga við mig - er það í lagi ef ég stend hér? Og þegar þeir fóru að takast á við það, virkaði allt. Reyndar er ég hvorki slæmur né góður, ég hef enga slæma ásetning eða eigingirni, þetta er bara kjarni minn og ég þarf einhvern veginn að lifa með því.

Andrew: Nýlega fóru allir að tala um sjálfsvitund fyrir introverta og mjúka færni almennt. Hvað geturðu sagt um þetta?

Cliff: Já, það var innsýn og lexía sem ég lærði af skilnaði mínum frá konu minni. Það sem ég lærði af skilnaðinum var að skilja sjálfan mig. Þannig fór ég að skilja annað fólk. Skildu hvernig þessi samskipti virka. Þetta leiddi til uppgötvana hvað eftir annað. Það var meðvitund um hver ég er og hvað ég er fulltrúi. Hvað er ég að gera: annað hvort er ég upptekinn af verkefninu, eða ég er að forðast átök, eða eitthvað annað - og þetta stig sjálfsvitundar hjálpar virkilega til að halda sjálfri mér í stjórn. Eftir þetta gengur allt miklu auðveldara. Eitt sem ég uppgötvaði ekki aðeins hjá sjálfum mér, heldur einnig hjá öðrum forriturum, er vanhæfni til að orða hugsanir þegar þú ert í tilfinningalegu álagi. Til dæmis, þú situr þarna að kóða, í flæðisástandi, og þá koma þeir hlaupandi til þín og byrja að öskra í hysteric að eitthvað sé bilað og nú verði gripið til öfgafullra aðgerða gegn þér. Og þú getur ekki sagt orð vegna þess að þú ert í tilfinningalegu álagi. Hin áunnina þekking gerir þér kleift að undirbúa þig fyrir þetta augnablik, lifa hana af og halda áfram í hörfaáætlun, eftir það geturðu gert eitthvað. Svo já, þegar þú byrjar að átta þig á því hvernig þetta virkar allt, þá er þetta risastór lífsbreytandi atburður. 
Sjálfur fann ég ekki réttu orðin, en ég mundi eftir röð aðgerða. Málið er að þessi viðbrögð eru jafnmikil líkamleg og þau eru munnleg og þú þarft pláss. Slíkt rými, í Zen skilningi. Þetta er nákvæmlega það sem þarf að útskýra og stíga svo strax til hliðar - hreinlega líkamlega stíga í burtu. Þegar ég þegi munnlega get ég unnið úr ástandinu tilfinningalega. Þegar adrenalínið berst til heila þíns, skiptir þig yfir í bardaga- eða flugstillingu geturðu ekki lengur sagt neitt, nei - nú ertu hálfviti, hrífandi verkfræðingur, ófær um að bregðast almennilega við eða jafnvel stöðva árásina, og árásarmaðurinn er frjáls að ráðast aftur og aftur. Þú verður fyrst að verða þú sjálfur aftur, ná tökum á þér, komast út úr „bardaga eða flugi“ hamnum.

Og til þess þurfum við munnlegt rými. Bara laust pláss. Ef þú segir eitthvað, þá geturðu sagt nákvæmlega það, og farið síðan og fundið "pláss" fyrir sjálfan þig: farðu í göngutúr í garðinum, læstu þig inni í sturtu - það skiptir ekki máli. Aðalatriðið er að aftengjast tímabundið frá þeim aðstæðum. Um leið og þú slekkur á þér í að minnsta kosti nokkrar sekúndur kemur stjórnin aftur, þú byrjar að hugsa edrú. „Allt í lagi, ég er ekki einhver hálfviti, ég geri ekki heimskulega hluti, ég er frekar gagnleg manneskja. Þegar þér hefur tekist að sannfæra sjálfan þig er kominn tími til að halda áfram á næsta stig: að skilja hvað gerðist. Það var ráðist á þig, árásin kom þaðan sem þú bjóst ekki við henni, þetta var óheiðarlegt, viðbjóðslegt fyrirsát. Þetta er slæmt. Næsta skref er að skilja hvers vegna árásarmaðurinn þurfti þetta. Í alvöru af hverju? Kannski vegna þess að hann er sjálfur reiður? Af hverju er hann reiður? Til dæmis vegna þess að hann klúðraði sjálfum sér og getur ekki tekið ábyrgð? Þetta er leiðin til að meðhöndla vandlega allt ástandið. En þetta krefst svigrúms, munnlegt rými. Fyrsta skrefið er að rjúfa munnleg samskipti. Forðastu umræður með orðum. Hættaðu því, farðu í burtu eins fljótt og auðið er. Ef þetta er símtal skaltu bara leggja á - þetta er kunnátta sem ég lærði af samskiptum við fyrrverandi konu mína. Ef samtalið gengur ekki neitt, segðu bara „bless“ og leggðu á. Hinum megin á símanum: "bla bla bla", þú svarar: "já, bless!" og leggja á. Þú hættir bara samtalinu. Fimm mínútum síðar, þegar skynsamleg hugsun kemur aftur til þín, hefur þú kólnað aðeins, það verður hægt að hugsa um allt, hvað gerðist og hvað mun gerast næst. Og byrjaðu að móta hugsi svar, frekar en að bregðast bara við af tilfinningum. Fyrir mig var byltingin í sjálfsvitund einmitt sú staðreynd að ef um tilfinningalega streitu er að ræða get ég ekki talað. Að komast út úr þessu ástandi, hugsa og skipuleggja hvernig eigi að bregðast við og bæta fyrir vandamál - þetta eru réttu skrefin í málinu þegar þú getur ekki talað. Auðveldasta leiðin er að hlaupa frá þeim aðstæðum sem tilfinningalegt álag gerir vart við sig og hætta einfaldlega að taka þátt í þessu álagi. Eftir það verðurðu fær um að hugsa, þegar þú getur hugsað verður þú fær um að tala o.s.frv.

Við the vegur, fyrir dómi, reynir andstæðingurinn að gera þér þetta - nú er ljóst hvers vegna. Vegna þess að hann hefur getu til að bæla þig niður í það ástand að þú getur ekki einu sinni borið fram nafnið þitt, til dæmis. Í mjög raunverulegum skilningi muntu ekki geta talað. Ef þetta kemur fyrir þig, og ef þú veist að þú munt finna þig á stað þar sem munnlegar bardagar geisa, á stað eins og dómstólum, þá geturðu komið með lögfræðinginn þinn. Lögfræðingurinn mun standa upp fyrir þig og stöðva munnlega árásina, og mun gera það á fullkomlega löglegan hátt, og týnda Zen-rýmið mun snúa aftur til þín. Til dæmis þurfti ég að hringja í fjölskylduna mína nokkrum sinnum, dómarinn var frekar vingjarnlegur yfir þessu, en andstæðingurinn öskraði og öskraði á mig, ég náði ekki einu sinni orði. Í þessum tilfellum hentar mér best að nota sáttasemjara. Sáttasemjarinn stöðvar allan þennan þrýsting sem streymir yfir þig í samfelldum straumi, þú finnur hið nauðsynlega Zen-rými og þar með kemur hæfileikinn til að tala aftur. Þetta er heilt þekkingarsvið þar sem það er mikið að rannsaka, margt að uppgötva innra með sjálfum sér og allt þetta breytist í stefnumótandi ákvarðanir á háu stigi sem eru mismunandi fyrir mismunandi fólk. Sumt fólk á ekki við vandamálin sem lýst er hér að ofan; venjulega hefur fólk sem er atvinnusölufólk ekki þau. Allt þetta fólk sem hefur lífsviðurværi sitt með orðum - frægir söngvarar, skáld, trúarleiðtogar og stjórnmálamenn, það hefur alltaf eitthvað að segja. Þeir eiga ekki við slík vandamál að stríða, en ég.

Andrew: Það var... óvænt. Frábært, við höfum nú þegar talað mikið saman og það er kominn tími til að ljúka þessu viðtali. Við munum örugglega hittast á ráðstefnunni og munum geta haldið þessum viðræðum áfram. Sjáumst á Hydra!

Þú getur haldið áfram samtali þínu við Cliff á Hydra 2019 ráðstefnunni sem haldin verður 11. – 12. júlí 2019 í St. Pétursborg. Hann mun koma með skýrslu „Azul Hardware Transactional Memory reynslan“. Hægt er að kaupa miða á opinberu heimasíðunni.

Heimild: www.habr.com

Bæta við athugasemd