{"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\/sq\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java","title":{"rendered":"Nj\u00eb intervist\u00eb e madhe me Cliff Click \u2014 babai i kompilimit JIT n\u00eb Java","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Nj\u00eb intervist\u00eb e madhe me Cliff Click \u2014 babai i kompilimit JIT n\u00eb Java\" src=\"\/wp-content\/uploads\/2019\/07\/9ea9740ef74c0ae14d334482af115222.png\" style=\"display:block;margin: 0 auto;\" \/><strong>Cliff Click<\/strong> \u2014 CTO of Cratus (IoT sensors for process improvement), founder and co-founder of several startups (including Rocket Realtime School, Neurensic, and H2O.ai) with several successful exits. Cliff wrote his first compiler at the age of 15 (Pascal for TRS Z-80)! He is best known for his work on C2 in Java (the Sea of Nodes IR). This compiler demonstrated to the world that JIT can produce high-quality code, which became one of the factors in establishing Java as one of the major modern software platforms. Later, Cliff helped Azul Systems build an 864-core mainframe with software written purely in Java that supported GC pauses on a 500-gigabyte heap within 10 milliseconds. Overall, Cliff has worked on all aspects of the JVM.<br clear=\"all\"><br \/>\n\u00a0<br \/>\nThis blog post is a large interview with Cliff. We will discuss the following topics:<\/p>\n<p><\/p>\n<ul>\n<li>Transitioning to low-level optimizations<\/li>\n<li>How to conduct large refactoring<\/li>\n<li>Cost model<\/li>\n<li>Learning low-level optimizations<\/li>\n<li>Practical examples of performance improvement<\/li>\n<li>Why create your own programming language<\/li>\n<li>Career of a performance engineer<\/li>\n<li>Technical challenges<\/li>\n<li>A bit about register allocation and multithreading<\/li>\n<li>The biggest challenge in life<\/li>\n<\/ul>\n<p><\/p>\n<p>The interviewers are:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Andrey Sataryn<\/strong> from Amazon Web Services. In his career, he has worked on a variety of projects: he tested a NewSQL distributed database at Yandex, a cloud detection system at Kaspersky Lab, a multiplayer game at Mail.ru, and a currency pricing service at Deutsche Bank. He is interested in testing large-scale backend and distributed systems.<\/li>\n<li><strong>Vladimir Sitnikov<\/strong> from Netcracker. He has been working on the performance and scalability of NetCracker OS \u2014 software used by telecom operators to automate network management processes and network equipment. He is passionate about the performance issues of Java and Oracle Database. He is the author of more than a dozen performance improvements in the official PostgreSQL JDBC driver.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"perehod-k-nizkourovnevym-optimizaciyam\">Transitioning to low-level optimizations<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: You are a well-known figure in JIT compilation, in Java and performance work in general, right?\u00a0<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: That's right!<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Let's start with general questions about performance work. What do you think about the choice between high-level and low-level optimizations like working at the CPU level?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: K\u00ebtu gjith\u00e7ka \u00ebsht\u00eb e thjesht\u00eb. Kodi m\u00eb i shpejt\u00eb \u00ebsht\u00eb ai q\u00eb kurr\u00eb nuk ekzekutohet. Prandaj, gjithmon\u00eb duhet t\u00eb filloni nga nj\u00eb nivel i lart\u00eb, t\u00eb punoni mbi algoritmet. Nj\u00eb notacion O m\u00eb i mir\u00eb do t\u00eb tejkaloj\u00eb nj\u00eb notacion O m\u00eb t\u00eb dob\u00ebt, p\u00ebrve\u00e7 rastit kur nd\u00ebrhyjn\u00eb ndonj\u00ebher\u00eb disa constante mjaft t\u00eb m\u00ebdha. Gj\u00ebrat me nivel t\u00eb ul\u00ebt vijn\u00eb t\u00eb fundit. Zakonisht, n\u00ebse keni optimizuar t\u00eb gjith\u00eb shtetin tjet\u00ebr mjaft mir\u00eb dhe ende ka di\u00e7ka interesante \u2013 kjo \u00ebsht\u00eb niveli i ul\u00ebt. Por si t\u00eb filloni nga nj\u00eb nivel i lart\u00eb? Si t\u00eb dini se keni b\u00ebr\u00eb mjaft pun\u00eb n\u00eb nivel t\u00eb lart\u00eb? Epo... nuk ka m\u00ebnyra t\u00eb gatshme. Duhet t\u00eb kuptoni problemin, t\u00eb vendosni se \u00e7far\u00eb do t\u00eb b\u00ebni (p\u00ebr t\u00eb mos e b\u00ebr\u00eb hapin e panevojsh\u00ebm m\u00eb von\u00eb) dhe at\u00ebher\u00eb mund t\u00eb hapni profilerin q\u00eb mund t\u00eb thot\u00eb di\u00e7ka t\u00eb dobishme. N\u00eb nj\u00eb moment, ju vet\u00eb e kuptoni se keni hequr dor\u00eb nga gj\u00ebrat e panevojshme dhe \u00ebsht\u00eb koha t\u00eb merret me rregullimin e holl\u00eb t\u00eb nivelit t\u00eb ul\u00ebt. Kjo \u00ebsht\u00eb me siguri nj\u00eb lloj arti. Nj\u00eb mori njer\u00ebzish b\u00ebjn\u00eb gj\u00ebra t\u00eb panevojshme, por l\u00ebvizin aq shpejt saq\u00eb nuk kan\u00eb koh\u00eb t\u00eb mendojn\u00eb p\u00ebr performanc\u00ebn. Por kjo zgjat derisa \u00e7\u00ebshtja t\u00eb b\u00ebhet e r\u00ebnd\u00ebsishme. Zakonisht, 99% e koh\u00ebs askujt nuk i intereson se \u00e7far\u00eb po b\u00ebj, deri n\u00eb momentin kur nj\u00eb gj\u00eb e r\u00ebnd\u00ebsishme do t\u00eb dal\u00eb n\u00eb rrug\u00ebn kritike p\u00ebr t\u00eb cil\u00ebn dikujt i intereson. Dhe k\u00ebtu t\u00eb gjith\u00eb fillojn\u00eb t\u00eb t\u00eb tipojn\u00eb pse gjith\u00e7ka nuk po punonte perfekt q\u00eb n\u00eb fillim. N\u00eb p\u00ebrgjith\u00ebsi, gjithmon\u00eb ka di\u00e7ka p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar n\u00eb performanc\u00eb. Por 99% e koh\u00ebs nuk keni pista! Thjesht po p\u00ebrpiqeni t\u00eb b\u00ebni di\u00e7ka t\u00eb funksionoj\u00eb dhe gjat\u00eb k\u00ebsaj i kuptoni ato q\u00eb jan\u00eb thelb\u00ebsore. Kurr\u00eb nuk mund ta dini paraprakisht se ky cop\u00eb duhet t\u00eb b\u00ebhet perfekt, prandaj, n\u00eb thelb, jeni n\u00eb m\u00ebshir\u00eb t\u00eb qenit perfekt n\u00eb gjith\u00e7ka. Dhe kjo \u00ebsht\u00eb e pamundur dhe nuk b\u00ebni ashtu. Gjithmon\u00eb ka shum\u00eb gj\u00ebra p\u00ebr t'u riparuar \u2013 dhe kjo \u00ebsht\u00eb krejt normale.<\/p>\n<p><\/p>\n<h1 id=\"kak-delat-bolshoy-refaktoring\">How to conduct large refactoring<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Si punoni mbi performanc\u00ebn? Kjo \u00ebsht\u00eb nj\u00eb problem i p\u00ebrgjithsh\u00ebm. P\u00ebr shembull, a keni ndonj\u00ebher\u00eb punuar mbi problemet q\u00eb lindin nga nd\u00ebrveprimi i nj\u00eb s\u00ebr\u00eb funksionalitetesh t\u00eb ekzistuese?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Un\u00eb p\u00ebrpiqem ta shmang k\u00ebt\u00eb. N\u00ebse e di q\u00eb performanca do t\u00eb b\u00ebhet nj\u00eb problem, mendoj p\u00ebrpara se t\u00eb filloj t\u00eb kodoj, ve\u00e7an\u00ebrisht p\u00ebr strukturat e t\u00eb dh\u00ebnave. Por shpesh e zbulojm\u00eb k\u00ebt\u00eb shum\u00eb m\u00eb von\u00eb. Dhe at\u00ebher\u00eb na duhet t\u00eb marrim masa drastike dhe t\u00eb b\u00ebjm\u00eb at\u00eb q\u00eb e quaj \u00abrishkruaj dhe mbizot\u00ebro\u00bb: duhet t\u00eb kapim nj\u00eb cop\u00eb t\u00eb mjaftueshme. Nj\u00eb pjes\u00eb e kodit do t\u00eb duhet t\u00eb rishkruhet p\u00ebr shkak t\u00eb problemeve me performanc\u00ebn ose p\u00ebr ndonj\u00eb arsye tjet\u00ebr. \u00c7do arsye q\u00eb ka t\u00eb b\u00ebj\u00eb me rishkrimin e kodit, ndonj\u00ebher\u00eb \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb rishkruash nj\u00eb cop\u00eb m\u00eb t\u00eb madhe sesa nj\u00eb cop\u00eb m\u00eb t\u00eb vog\u00ebl. N\u00eb k\u00ebt\u00eb moment, t\u00eb gjith\u00eb fillojn\u00eb t\u00eb tremben: \u00abo Zot, nuk mund t\u00eb prekim kaq shum\u00eb kod!\u00bb Por, n\u00eb fakt, ky qasje funksionon shum\u00eb m\u00eb mir\u00eb n\u00eb shumic\u00ebn e rasteve. Duhet ta kap\u00ebsh nj\u00eb problem t\u00eb madh menj\u00ebher\u00eb, ta p\u00ebrshkruash at\u00eb rreth nj\u00eb rrethi t\u00eb madh dhe t\u00eb thuash: \u00e7do gj\u00eb brenda k\u00ebtij rrethi, un\u00eb do ta rishkruaj. Kufiri \u00ebsht\u00eb shum\u00eb m\u00eb i vog\u00ebl se ai p\u00ebrmbajtje brenda saj, e cila duhet t\u00eb z\u00ebvend\u00ebsohet. Dhe n\u00ebse k\u00ebt\u00eb delimitim kufijsh e b\u00ebn pun\u00ebn brenda perfekte \u2013 ke duar t\u00eb lira, b\u00ebj \u00e7far\u00eb d\u00ebshiron. Pasi e kupton problemin, procesi i rishkrimit shkon shum\u00eb m\u00eb leht\u00eb, prandaj kap nj\u00eb cop\u00eb t\u00eb madhe!<br \/>\nN\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, kur b\u00ebn rishkrimin me nj\u00eb cop\u00eb t\u00eb madhe dhe kupton se performanca do t\u00eb b\u00ebhet nj\u00eb problem, mund t\u00eb fillosh menj\u00ebher\u00eb t\u00eb shqet\u00ebsohesh p\u00ebr t\u00eb. Normalisht, kjo shnd\u00ebrrohet n\u00eb gj\u00ebra t\u00eb thjeshta si \u00abmos e kopjo t\u00eb dh\u00ebnat, menaxho t\u00eb dh\u00ebnat sa m\u00eb thjesht\u00eb, b\u00ebj ato m\u00eb t\u00eb vogla\u00bb. N\u00eb rishkrime t\u00eb m\u00ebdha, ka m\u00ebnyra standarde p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar performanc\u00ebn. Dhe ato pothuajse gjithmon\u00eb rrotullohen rreth t\u00eb dh\u00ebnave.<\/p>\n<p><\/p>\n<h1 id=\"model-stoimosti\">Cost model<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: N\u00eb nj\u00eb nga podkcastet, keni folur p\u00ebr modelet e kostos n\u00eb kontekstin e performanc\u00ebs. Mund t\u00eb shpjegoni se \u00e7far\u00eb kishte t\u00eb b\u00ebj\u00eb me k\u00ebt\u00eb?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Sigurisht. Un\u00eb kam lindur n\u00eb nj\u00eb epok\u00eb kur performanca e procesorit ishte jasht\u00ebzakonisht e r\u00ebnd\u00ebsishme. Dhe kjo epok\u00eb po kthehet p\u00ebrs\u00ebri \u2013 fati nuk \u00ebsht\u00eb pa ironin\u00eb e tij. Kam filluar t\u00eb jetoj n\u00eb koh\u00ebt e makinave tet\u00ebbit\u00ebshe, kompjuteri im i par\u00eb punonte me 256 byte. Pik\u00ebrisht byte. \u00c7do gj\u00eb ishte shum\u00eb e vog\u00ebl. Duhej t\u00eb num\u00ebroja instrukcionet dhe sapo filluam t\u00eb avancohemi lart n\u00eb piramid\u00ebn e gjuh\u00ebve t\u00eb programimit, gjuh\u00ebt merrnin p\u00ebrsip\u00ebr gjithnj\u00eb e m\u00eb shum\u00eb. Kishim Assembler, pastaj Basic, pastaj C, dhe C merrte p\u00ebrsip\u00ebr pun\u00ebn me shum\u00eb detaje, si p\u00ebr shembull menaxhimi i regjistrave dhe zgjedhja e instrukcioneve. Por atje gjith\u00e7ka ishte mjaft e kuptueshme dhe n\u00ebse un\u00eb b\u00ebja nj\u00eb tregues n\u00eb nj\u00eb instanc\u00eb variable, do t\u00eb merrja nj\u00eb ngarkes\u00eb, dhe kostoja e k\u00ebtij instrukcioni \u00ebsht\u00eb e njohur. Hardueri jep nj\u00eb num\u00ebr t\u00eb njohur ciklesh mahnit\u00ebs, k\u00ebshtu q\u00eb shpejt\u00ebsia e ekzekutimit t\u00eb gj\u00ebrave t\u00eb ndryshme mund t\u00eb llogaritet thjesht duke p\u00ebrmbledhur t\u00eb gjitha instrukcionet q\u00eb po planifikon t\u00eb ekzekutosh. \u00c7do krahasim\/testim\/filim\/thirrje\/ngarkes\u00eb\/ruajtje mund t\u00eb p\u00ebrmblidhet dhe t\u00eb thuhet: ja koha e ekzekutimit. Duke u marr\u00eb me p\u00ebrmir\u00ebsimin e performanc\u00ebs, patjet\u00ebr q\u00eb do t'i shikosh numrat q\u00eb p\u00ebrkojn\u00eb me ciklet e ngrohta t\u00eb vogla.\u00a0<br \/>\nPor sapo kalon n\u00eb Java, Python dhe gj\u00ebra t\u00eb ngjashme, shum\u00eb shpejt largohet nga hardueri i nivelit t\u00eb ul\u00ebt. Cila \u00ebsht\u00eb kostoja e thirrjes s\u00eb getter-it n\u00eb Java? N\u00ebse JIT n\u00eb HotSpot e ka b\u00ebr\u00eb gjith\u00e7ka si\u00e7 duhet <noindex><a rel=\"nofollow\" href=\"https:\/\/wiki.openjdk.java.net\/display\/HotSpot\/Inlining\">n\u00eb linj t\u00eb drejtp\u00ebrdrejt\u00eb<\/a><\/noindex>, kjo do t\u00eb jet\u00eb ngarkes\u00eb, por, n\u00ebse ai nuk e b\u00ebri \u2013 kjo do t\u00eb jet\u00eb nj\u00eb thirrje funksioni. Pasiq\u00eb thirrja \u00ebsht\u00eb n\u00eb nj\u00eb cik\u00ebl t\u00eb ngroht\u00eb, ajo do t\u00eb anuloj\u00eb t\u00eb gjitha optimizimet e tjera n\u00eb k\u00ebt\u00eb cik\u00ebl. Prandaj, kostoja reale do t\u00eb jet\u00eb shum\u00eb m\u00eb e madhe. Dhe menj\u00ebher\u00eb humbet aft\u00ebsin\u00eb p\u00ebr t\u00eb par\u00eb nj\u00eb cop\u00eb kod dhe t\u00eb kuptosh se sa vlen ta ekzekutosh at\u00eb n\u00eb terma t\u00eb frekuenc\u00ebs s\u00eb procesorit, memories p\u00ebrdorur dhe caches. T\u00eb gjitha k\u00ebto b\u00ebhen interesante vet\u00ebm n\u00ebse do t\u00eb futesh thell\u00eb n\u00eb performanc\u00eb.<br \/>\nTani jemi n\u00eb nj\u00eb situat\u00eb ku shpejt\u00ebsit\u00eb e procesor\u00ebve nuk kan\u00eb pasur rritje p\u00ebr m\u00eb shum\u00eb se nj\u00eb dekad\u00eb. Koha e vjet\u00ebr po kthehet! Nuk mund t\u00eb shqet\u00ebsoheni m\u00eb p\u00ebr performanc\u00ebn e mir\u00eb t\u00eb nj\u00eb nj\u00ebsie. Por, n\u00ebse papritmas merret me llogaritjet paralele \u2013 \u00ebsht\u00eb gjithmon\u00eb e komplikuar, t\u00eb gjith\u00eb t\u00eb shikojn\u00eb si James Bond. Shpejt\u00ebsit\u00eb dhjet\u00ebfishohet zakonisht ndodhin n\u00eb ato vende ku dikush ka humbur di\u00e7ka. Paraleliteti k\u00ebrkon shum\u00eb pun\u00eb. P\u00ebr t\u00eb arritur at\u00eb dhjet\u00ebfishim t\u00eb shpejt\u00ebsis\u00eb, duhet t\u00eb kuptohet modeli i kostos. \u00c7far\u00eb dhe sa kushton. Dhe p\u00ebr k\u00ebt\u00eb, duhet t\u00eb kuptohet se si gjuha p\u00ebrputhet me harduerin n\u00eb dispozita.<br \/>\nMartin Thompson ka gjetur nj\u00eb fjal\u00eb t\u00eb shk\u00eblqyer p\u00ebr blogun e tij <noindex><a rel=\"nofollow\" href=\"https:\/\/mechanical-sympathy.blogspot.com\/\">Simpatia Mekanike<\/a><\/noindex>! Duhet t\u00eb kuptohet se \u00e7far\u00eb do t\u00eb b\u00ebj\u00eb hardueri, si do ta b\u00ebj\u00eb dhe pse e b\u00ebn at\u00eb q\u00eb b\u00ebn. Duke e p\u00ebrdorur k\u00ebt\u00eb, \u00ebsht\u00eb mjaft e leht\u00eb t\u00eb fillosh t\u00eb num\u00ebrosh instruktionet dhe t\u00eb zbulohet se ku po shkon koha e ekzekutimit. N\u00ebse nuk ke p\u00ebrgatitjen p\u00ebrkat\u00ebse, thjesht je duke k\u00ebrkuar nj\u00eb mace t\u00eb zez\u00eb n\u00eb nj\u00eb dhom\u00eb t\u00eb err\u00ebt. Un\u00eb vazhdimisht shoh njer\u00ebz q\u00eb optimizojn\u00eb performanc\u00ebn, ndon\u00ebse ata nuk kan\u00eb as nj\u00eb ide se \u00e7far\u00eb po b\u00ebjn\u00eb. Ata kan\u00eb shum\u00eb vuajtje dhe nuk po e arrijn\u00eb ndonj\u00ebher\u00eb q\u00ebllimin. Kur un\u00eb marr t\u00eb nj\u00ebjtin cop\u00eb kod, vendos atje disa hacks t\u00eb vogla dhe arrij kat\u00ebrfishim ose dhjet\u00ebfishim t\u00eb shpejt\u00ebsis\u00eb, ata thon\u00eb: mir\u00eb, kjo nuk \u00ebsht\u00eb e ndershme, ne e dinim se ishe m\u00eb i mir\u00eb. Ma\u00e7kullisht. \u00c7far\u00eb po flas\u2026 modeli i kostos \u00ebsht\u00eb p\u00ebr at\u00eb q\u00eb kodin e shkruan dhe si funksionon n\u00eb mes nj\u00eb pamjeje t\u00eb p\u00ebrgjithshme.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Dhe si t\u00eb mbash nj\u00eb v\u00ebllim t\u00eb till\u00eb n\u00eb mendje? Kjo arrihet p\u00ebrmes shum\u00eb p\u00ebrvoj\u00ebs, apo? Ku sigurohet nj\u00eb p\u00ebrvoj\u00eb e till\u00eb?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Mir\u00eb, p\u00ebrvoja ime ka ardhur n\u00eb nj\u00eb m\u00ebnyr\u00eb jo t\u00eb leht\u00eb. Kam programuar n\u00eb Assembler n\u00eb ato koh\u00eb kur mund t\u00eb kuptohej \u00e7do instruktion i ve\u00e7ant\u00eb. Kjo duket e \u00e7uditshme, por q\u00eb nga ajo koh\u00eb kam nj\u00eb grup instruktionesh Z80 q\u00eb m\u00eb kan\u00eb mbetur gjithmon\u00eb n\u00eb mendje. Nuk kujtoj emrat e njer\u00ebzve pas nj\u00eb minute t\u00eb bised\u00ebs, por kujtoj kodin e shkruar 40 vjet m\u00eb par\u00eb. Qesharake, kjo duket si sindromi i \"<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\">mendjes s\u00eb \u00e7mendur<\/a><\/noindex>\u00bb.<\/p>\n<p><\/p>\n<h1 id=\"obuchenie-nizkourovnevym-optimizaciyam\">Learning low-level optimizations<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: A ka ndonj\u00eb m\u00ebnyr\u00eb m\u00eb t\u00eb thjesht\u00eb p\u00ebr t\u00eb hyr\u00eb n\u00eb k\u00ebt\u00eb fush\u00eb?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Po, dhe jo. Hardueri p\u00ebr t\u00eb cilin t\u00eb gjith\u00eb ne p\u00ebrdorim, gjat\u00eb k\u00ebsaj kohe nuk ka ndryshuar shum\u00eb. T\u00eb gjith\u00eb p\u00ebrdorin x86, p\u00ebrve\u00e7 smartphone-ve q\u00eb p\u00ebrdorin Arm. N\u00ebse nuk merresh me ndonj\u00eb embedim t\u00eb fort\u00eb, ke t\u00eb nj\u00ebjt\u00ebn gj\u00eb. Mir\u00eb, m\u00eb tutje. Instruksionet gjithashtu nuk kan\u00eb ndryshuar p\u00ebr shekuj. Duhet t\u00eb shkosh dhe t\u00eb shkruash di\u00e7ka n\u00eb Assembler. Pak, por mjaftuesh\u00ebm p\u00ebr t\u00eb filluar t\u00eb kuptohet. Ju buz\u00ebqeshni, por un\u00eb flas gjithmon\u00eb seriozisht. Duhet t\u00eb kuptosh p\u00ebrputhjen mes gjuh\u00ebs dhe harduerit. Pas k\u00ebsaj, duhet t\u00eb shkosh, t\u00eb shkruash pak dhe t\u00eb b\u00ebsh nj\u00eb kompilator t\u00eb vog\u00ebl p\u00ebr nj\u00eb gjuh\u00eb t\u00eb vog\u00ebl. \"I vog\u00ebl\" do t\u00eb thot\u00eb se duhet ta b\u00ebsh at\u00eb brenda nj\u00eb koh\u00eb t\u00eb arsyeshme. Ai mund t\u00eb jet\u00eb shum\u00eb i thjesht\u00eb, por duhet t\u00eb gjeneroj\u00eb instruksione. Akti i gjenerimit t\u00eb instruksionit do t\u00eb lejoj\u00eb t\u00eb kuptohet modeli i koston p\u00ebr ur\u00ebn mes kodit t\u00eb nivelit t\u00eb lart\u00eb, n\u00eb t\u00eb cilin t\u00eb gjith\u00eb shkruajn\u00eb, dhe kodit t\u00eb makin\u00ebs, i cili ekzekutohet n\u00eb harduer. Kjo p\u00ebrputhje do t\u00eb thellohet n\u00eb mendjet e njer\u00ebzve n\u00eb momentin e shkruarjes s\u00eb kompilatorit. Edhe t\u00eb kompilatorit m\u00eb t\u00eb thjesht\u00eb. Pas k\u00ebsaj, mund t\u00eb fillosh t\u00eb shikosh Java dhe se sa e thell\u00eb \u00ebsht\u00eb hendeku semantik dhe p\u00ebr t\u00eb nd\u00ebrtuar ura mbi t\u00eb, \u00ebsht\u00eb shum\u00eb m\u00eb e komplikuar. N\u00eb Java \u00ebsht\u00eb shum\u00eb m\u00eb e v\u00ebshtir\u00eb t\u00eb kuptosh n\u00ebse ura jon\u00eb \u00ebsht\u00eb e mir\u00eb apo e keqe, \u00e7far\u00eb do ta b\u00ebj\u00eb at\u00eb t\u00eb shembet dhe \u00e7far\u00eb jo. Por t\u00eb duhet nj\u00eb pik\u00eb nis\u00ebse, kur shikon kodin dhe kupton: \"Ah, ky getter duhet t\u00eb linj\u00ebzohet \u00e7do her\u00eb\". M\u00eb pas del se ndonj\u00ebher\u00eb ndodh, p\u00ebrve\u00e7 rasteve kur metodi b\u00ebhet shum\u00eb i madh dhe JIT fillon t\u00eb linj\u00ebzoj\u00eb gjith\u00e7ka. Performanca e k\u00ebtyre vendeve mund t\u00eb parashikohet menj\u00ebher\u00eb. Zakonisht gettaret punojn\u00eb mir\u00eb, por pastaj shikon ciklet e m\u00ebdha t\u00eb nxehta dhe kupton se ka thirrje funksionesh q\u00eb nuk e din\u00eb se \u00e7far\u00eb b\u00ebjn\u00eb. Kjo \u00ebsht\u00eb problemi me p\u00ebrdorimin universalisht t\u00eb gettareve, arsyeja pse ato nuk linj\u00ebzohen - nuk \u00ebsht\u00eb e qart\u00eb se a \u00ebsht\u00eb ky nj\u00eb getter. N\u00ebse ke nj\u00eb baz\u00eb t\u00eb kodit shum\u00eb t\u00eb vog\u00ebl, mund ta mbash mend at\u00eb dhe m\u00eb pas t\u00eb thuash: ja, ky \u00ebsht\u00eb nj\u00eb getter, dhe ky \u00ebsht\u00eb nj\u00eb setter. N\u00eb nj\u00eb baz\u00eb t\u00eb madhe t\u00eb kodit, \u00e7do funksion jeton historin\u00eb e vet, t\u00eb cil\u00ebn askush, n\u00eb p\u00ebrgjith\u00ebsi, nuk e di. Profili tregon se kemi humbur 24% t\u00eb koh\u00ebs n\u00eb ndonj\u00eb cik\u00ebl dhe p\u00ebr t\u00eb kuptuar se \u00e7far\u00eb b\u00ebn ky cik\u00ebl, duhet t\u00eb shikosh \u00e7do funksion brenda. Nuk \u00ebsht\u00eb e mundur t\u00eb kuptohet kjo, pa studiuar funksionin, dhe kjo e ngadal\u00ebson seriozisht procesin e kuptimit. Prandaj un\u00eb nuk p\u00ebrdor geter\u00eb e seter\u00eb, un\u00eb kam arritur n\u00eb nj\u00eb nivel t\u00eb ri!<br \/>\nSi te pyet se ku ta gjej modelin e kostos? Po, mund t\u00eb lexosh di\u00e7ka, sigurisht... Por mendoj se m\u00ebnyra m\u00eb e mir\u00eb \u00ebsht\u00eb t\u00eb veprosh. T\u00eb krijosh nj\u00eb kompilator t\u00eb vog\u00ebl dhe kjo do t\u00eb jet\u00eb m\u00ebnyra m\u00eb e mir\u00eb p\u00ebr ta kuptuar modelin e kostos dhe ta vendos\u00ebsh at\u00eb n\u00eb kok\u00ebn e tua. Nj\u00eb kompilator i vog\u00ebl q\u00eb do t\u00eb ishte i dobish\u00ebm p\u00ebr programimin e mikroval\u00ebs - kjo \u00ebsht\u00eb nj\u00eb detyr\u00eb p\u00ebr fillestar\u00ebt. E di q\u00eb n\u00ebse tashm\u00eb ke aft\u00ebsi programimi, duhet t\u00eb mjaftojn\u00eb. T\u00eb gjitha k\u00ebto gj\u00ebra si shfryt\u00ebzimi i nj\u00eb vargu q\u00eb do t\u00eb jet\u00eb ndonj\u00eb shprehje algjebrike, nxjerrja e udh\u00ebzimeve p\u00ebr operacionet matematikore n\u00eb rendin e duhur, marrja e vlerave t\u00eb sakta nga regjistrat - gjith\u00e7ka b\u00ebhet leht\u00eb. Dhe sa her\u00eb q\u00eb b\u00ebn k\u00ebt\u00eb, do t\u00eb mbetet n\u00eb mendje. Mendoj se t\u00eb gjith\u00eb e din\u00eb se \u00e7far\u00eb b\u00ebn nj\u00eb kompilator. Dhe kjo do t\u00eb sjell\u00eb kuptimin e modelit t\u00eb kostos.<\/p>\n<p><\/p>\n<h1 id=\"prakticheskie-primery-uluchsheniya-proizvoditelnosti\">Practical examples of performance improvement<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: \u00c7far\u00eb tjet\u00ebr duhet t\u00eb v\u00ebm\u00eb re gjat\u00eb pun\u00ebs mbi performanc\u00ebn?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Strukturat e t\u00eb dh\u00ebnave. P\u00ebr t\u00eb v\u00ebrtet\u00eb, un\u00eb nuk kam mbajtur k\u00ebto lekcioni prej nj\u00eb kohe t\u00eb gjat\u00eb... <noindex>Rocket School<\/noindex>. Ishte arg\u00ebtuese, por k\u00ebrkonte shum\u00eb p\u00ebrpjekje, dhe un\u00eb kam nj\u00eb jet\u00eb gjithashtu! Mir\u00eb, k\u00ebshtu q\u00eb, n\u00eb nj\u00ebr\u00ebn nga m\u00ebsimet m\u00eb t\u00eb m\u00ebdha dhe interesante, \"Ku shkon performanca juaj\", iu dhash\u00eb student\u00ebve nj\u00eb shembull: dy e gjysm\u00eb gigabajt t\u00eb dh\u00ebnash fintech lexoheshin nga nj\u00eb skedar CSV dhe m\u00eb pas duhej t\u00eb llogaritej numri i produkteve t\u00eb shitura. T\u00eb dh\u00ebna t\u00eb rregullta tregtare. Paketa UDP, t\u00eb transformuara n\u00eb format tekstual, q\u00eb nga vitet '70. Chicago Mercantile Exchange - gj\u00ebra si nafta, misri, soja dhe t\u00eb ngjashme. Duhej t\u00eb llogaritnim k\u00ebto produkte, numrin e transaksioneve, volumin mesatar t\u00eb qarkullimit t\u00eb fondeve dhe mallrave, etj. Kjo \u00ebsht\u00eb matematik\u00eb tregtare mjaft e thjesht\u00eb: gjej kodin e produktit (k\u00ebto jan\u00eb 1-2 simbole n\u00eb nj\u00eb tabel\u00eb hesh), merr shum\u00ebn, shto n\u00eb nj\u00eb nga grupe t\u00eb transaksioneve, shto volumet, shto kostot dhe disa gj\u00ebra t\u00eb tjera. Matematik\u00eb shum\u00eb e thjesht\u00eb. Implementimi i lodhsh\u00ebm ishte mjaft i drejtp\u00ebrdrejt\u00eb: gjith\u00e7ka ndodhte n\u00eb nj\u00eb skedar, lexoja skedarin dhe l\u00ebvizja p\u00ebrmes tij, duke ndar\u00eb regjistrat n\u00eb vargje Java, duke k\u00ebrkuar n\u00eb to gj\u00ebrat e nevojshme dhe duke i shtuar sipas matematik\u00ebs s\u00eb p\u00ebrshkruar m\u00eb sip\u00ebr. Dhe kjo funksiononte me nj\u00eb shpejt\u00ebsi t\u00eb vog\u00ebl. <\/p>\n<p><\/p>\n<p>Me k\u00ebt\u00eb qasje, gjith\u00e7ka \u00ebsht\u00eb e qart\u00eb se \u00e7far\u00eb po ndodh, dhe llogarit\u00eb paralele k\u00ebtu nuk ndihmojn\u00eb, e drejta? Doli q\u00eb rritja pes\u00ebfish e performanc\u00ebs mund t\u00eb arrihet thjesht duke zgjedhur struktura t\u00eb duhura t\u00eb t\u00eb dh\u00ebnave. Dhe kjo e befason edhe programuesit m\u00eb t\u00eb p\u00ebrvojsh\u00ebm! N\u00eb rastin tim konkret, fokusi ishte q\u00eb nuk duhet t\u00eb b\u00ebsh ndarje memorie n\u00eb ciklin e nxeht\u00eb. Po, kjo nuk \u00ebsht\u00eb e gjith\u00eb e v\u00ebrteta, por n\u00eb p\u00ebrgjith\u00ebsi - nuk duhet t\u00eb ndash 'n\u00eb \u00e7do X', kur X \u00ebsht\u00eb mjaft i madh. Kur X \u00ebsht\u00eb dy e gjysm\u00eb gigabajt, nuk duhet t\u00eb ndash asgj\u00eb 'n\u00eb \u00e7do let\u00ebr', ose 'n\u00eb \u00e7do rresht', ose 'n\u00eb \u00e7do fush\u00eb', asgj\u00eb t\u00eb till\u00eb. Pik\u00ebrisht k\u00ebtu shpenzohet koha. Si funksionon kjo n\u00eb t\u00eb v\u00ebrtet\u00eb? Imagjinoni se un\u00eb b\u00ebj nj\u00eb thirrje <code>String.split()<\/code> ose <code>BufferedReader.readLine()<\/code>. <code>Readline<\/code> b\u00ebn nj\u00eb varg nga nj\u00eb grup bajtok\u00ebsh q\u00eb vijn\u00eb p\u00ebrmes rrjetit, nj\u00eb her\u00eb p\u00ebr \u00e7do varg, p\u00ebr secilin nga qindra miliona vargjeve. Un\u00eb e marr k\u00ebt\u00eb varg, e analizoj dhe e hedh. Pse e hedh - mir\u00eb, un\u00eb e kam p\u00ebrpunuar at\u00eb, mbaroi. Pra, p\u00ebr \u00e7do bajt q\u00eb lexoj nga k\u00ebto 2.7G, do t\u00eb shkruhen dy simbole n\u00eb varg, dmth tashm\u00eb 5.4G, dhe ato m\u00eb tej nuk m\u00eb duhen p\u00ebr asgj\u00eb, ndaj hidhen. N\u00ebse shikojm\u00eb kapacitetin e memorjes, ne ngarkojm\u00eb 2.7G, q\u00eb kalojn\u00eb p\u00ebrmes memories dhe busit t\u00eb memories n\u00eb procesor, dhe m\u00eb pas dy her\u00eb m\u00eb shum\u00eb d\u00ebrgohen n\u00eb vargun q\u00eb \u00ebsht\u00eb n\u00eb memorje, dhe e gjith\u00eb kjo p\u00ebrplaset kur krijohet \u00e7do varg i ri. Por un\u00eb duhet ta lexoj at\u00eb, hardueri e lexon at\u00eb, edhe n\u00ebse pastaj gjith\u00e7ka do t\u00eb p\u00ebrpunohet. Dhe duhet ta shkruaj, sepse kam krijuar nj\u00eb varg dhe caches jan\u00eb mbushur \u2013 cache nuk mund ta akomodoj\u00eb 2.7G. Pra, p\u00ebr \u00e7do bajt t\u00eb lexuar lexoj edhe dy bajte shtes\u00eb dhe shkruaj dy bajte shtes\u00eb, dhe n\u00eb fund ata kan\u00eb nj\u00eb raport 4:1 \u2013 n\u00eb k\u00ebt\u00eb raport ne harxhojm\u00eb pa efekt kapacitetin e memories. Dhe m\u00eb pas del se n\u00ebse b\u00ebj <code>String.split()<\/code> \u2013 e b\u00ebj k\u00ebt\u00eb shum\u00eb her\u00eb, brenda mund t\u00eb ken\u00eb edhe 6-7 fusha t\u00eb tjera. Prandaj, kodi klasik p\u00ebr leximin e CSV duke pasuar analiz\u00ebn e vargjeve \u00e7on n\u00eb humbje t\u00eb kapacitetit t\u00eb memories n\u00eb rreth 14:1 n\u00eb krahasim me at\u00eb q\u00eb do t\u00eb d\u00ebshironit realisht t\u00eb kishit. N\u00ebse heqim k\u00ebto ndarje, at\u00ebher\u00eb mund t\u00eb arrijm\u00eb nj\u00eb p\u00ebrshpejtim pes\u00ebfish. <\/p>\n<p><\/p>\n<p>Dhe kjo nuk \u00ebsht\u00eb ndonj\u00eb gj\u00eb tejet e komplikuar. N\u00ebse e shihni kodin nga k\u00ebndv\u00ebshtrimi i duhur, gjith\u00e7ka b\u00ebhet mjaft e thjesht\u00eb, sapo ta kuptoni esencialin e problemit. Nuk duhet aspak t\u00eb ndaloni dh\u00ebnien e memories: problemi \u00ebsht\u00eb se po i jepni di\u00e7ka dhe ajo vdes menj\u00ebher\u00eb, duke shpenzuar nj\u00eb burim t\u00eb r\u00ebnd\u00ebsish\u00ebm, i cili n\u00eb k\u00ebt\u00eb rast \u00ebsht\u00eb kapaciteti i memories. Dhe e gjith\u00eb kjo rezulton n\u00eb nj\u00eb r\u00ebnie t\u00eb performanc\u00ebs. N\u00eb x86 zakonisht duhet t\u00eb digjni me akt t\u00eb procesorit, nd\u00ebrsa k\u00ebtu keni djegur t\u00eb gjith\u00eb memories p\u00ebrpara s\u00eb pritur. Zgjidhja \u00ebsht\u00eb t\u00eb reduktoni numrin e alokimeve.\u00a0<br \/>\nNj\u00eb tjet\u00ebr pjes\u00eb e problemit \u00ebsht\u00eb se, n\u00ebse e aktivizoni profiler-in kur \u00ebsht\u00eb p\u00ebrfunduar banda e memories, pik\u00ebrisht n\u00eb momentin kur ndodh, zakonisht prisni q\u00eb cache t\u00eb rikthehet, sepse \u00ebsht\u00eb plot me plehra q\u00eb sapo keni prodhuar, me t\u00eb gjitha k\u00ebto rreshta. Prandaj, \u00e7do operacion load ose store b\u00ebhet i ngadalsh\u00ebm, sepse ato sjellin humbje n\u00eb cache \u2013 e gjith\u00eb cache ka ulet ngadal\u00eb, duke pritur q\u00eb plehrat t\u00eb dalin. Prandaj, profiler-i do t\u00eb tregoj\u00eb vet\u00ebm nj\u00eb zhurm\u00eb t\u00eb ngroht\u00eb rast\u00ebsore, t\u00eb shtrir\u00eb p\u00ebrgjat\u00eb gjith\u00e7kaje \u2013 nuk do t\u00eb ket\u00eb ndonj\u00eb urdh\u00ebr t\u00eb ve\u00e7ant\u00eb t\u00eb nxeht\u00eb ose vend n\u00eb kod. Vet\u00ebm zhurm\u00eb. Dhe n\u00ebse shihni ciklet GC, ato do t\u00eb jen\u00eb t\u00eb gjitha p\u00ebr Generacionin e Ri dhe shum\u00eb t\u00eb shpejta \u2013 mikrosekuonda ose milisekonda maksimumi. Sepse e gjith\u00eb kjo memory vdes menj\u00ebher\u00eb. Ju alokoni miliarda gigabajt, dhe ai i shkurton, dhe i shkurton, dhe p\u00ebrs\u00ebri i shkurton. E gjith\u00eb kjo ndodh shum\u00eb shpejt. Pra, ka cikle t\u00eb lira GC, zhurm\u00eb t\u00eb ngroht\u00eb p\u00ebrgjat\u00eb gjith\u00e7kaje, por ne duam t\u00eb arrijm\u00eb nj\u00eb p\u00ebrshpejtim 5-fish. N\u00eb k\u00ebt\u00eb moment di\u00e7ka duhet t\u00eb lidhet n\u00eb mendjen tuaj dhe t\u00eb d\u00ebgjoj\u00eb: \u2018pse k\u00ebshtu?!\u2019. Teqja e rripit t\u00eb memories nuk shfaqet n\u00eb debugger-in klasik, duhet t\u00eb aktivizoni debugger-in e shifruesve t\u00eb harduerit e t\u00eb performance dhe ta shihni at\u00eb vet\u00eb dhe drejtp\u00ebrdrejt. Ndryshe, mund t\u00eb dyshoni p\u00ebr k\u00ebt\u00eb nga k\u00ebto tri simptoma. Simptoma e tret\u00eb \u00ebsht\u00eb kur shihni at\u00eb q\u00eb alokoni, pyesni profiler-in, dhe ai p\u00ebrgjigjet: \u2018Ju keni b\u00ebr\u00eb miliard\u00eb rreshta, por GC ka vepruar falas\u2019. Sapo ndodh kjo, e kuptoni se keni krijuar shum\u00eb objekte dhe keni djegur t\u00eb gjith\u00eb shiritin e memories. Ka nj\u00eb m\u00ebnyr\u00eb p\u00ebr ta zbuluar k\u00ebt\u00eb, por nuk \u00ebsht\u00eb e qart\u00eb.\u00a0<\/p>\n<p><\/p>\n<p>Problemi \u00ebsht\u00eb n\u00eb struktur\u00ebn e t\u00eb dh\u00ebnave: struktura e holl\u00eb, q\u00eb q\u00ebndron pas gjith\u00e7kaje, \u00ebsht\u00eb shum\u00eb e madhe, \u00ebsht\u00eb 2.7G n\u00eb disk, prandaj t\u00eb b\u00ebsh nj\u00eb kopje t\u00eb k\u00ebsaj gj\u00ebje \u00ebsht\u00eb shum\u00eb e pad\u00ebshirueshme \u2013 d\u00ebshiron ta ngarkosh direkt nga bufri i bytes n\u00eb regjistrat, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos lexosh-shkruash n\u00eb varg \u00e7do her\u00eb pes\u00eb her\u00eb. Fatkeq\u00ebsisht, Java, n\u00eb m\u00ebnyr\u00eb t\u00eb paracaktuar, nuk t\u00eb jep nj\u00eb bibliotek\u00eb t\u00eb till\u00eb si pjes\u00eb e JDK. Por kjo \u00ebsht\u00eb thjesht, apo jo? N\u00eb thelb, jan\u00eb 5-10 rreshta kodi q\u00eb do t\u00eb shkojn\u00eb p\u00ebr implementimin e nj\u00eb ngarkuesi t\u00eb vet, i cili p\u00ebrs\u00ebrit sjelljen e klas\u00ebs s\u00eb vargjeve, duke qen\u00eb nj\u00eb mb\u00ebshtjell\u00ebs mbi bufret e bytes n\u00eb nivelin e posht\u00ebm. Si rezultat, rezulton se punon pothuajse si me vargje, por n\u00eb t\u00eb v\u00ebrtet\u00eb, aty l\u00ebvizin treguesit n\u00eb buf\u00ebr, dhe bytes e pap\u00ebrpunuara nuk kopjohen askund, dhe k\u00ebshtu rip\u00ebrdoren t\u00eb nj\u00ebjtat bufe, her\u00eb pas here, dhe sistemi operacional \u00ebsht\u00eb i lumtur t\u00eb marr\u00eb p\u00ebrsip\u00ebr gj\u00ebrat p\u00ebr t\u00eb cilat \u00ebsht\u00eb e destinuar, si\u00e7 \u00ebsht\u00eb dyfishimi i paduksh\u00ebm i k\u00ebtyre bufreve t\u00eb bytes, nd\u00ebrsa ti vet\u00eb nuk merresh m\u00eb me nj\u00eb rrjedh\u00eb t\u00eb pafund t\u00eb t\u00eb dh\u00ebnave t\u00eb panevojshme. P\u00ebr rastin, ju e kuptoni, gjat\u00eb pun\u00ebs me GC garanton q\u00eb \u00e7do ndarje e memories nuk do t\u00eb shihet nga procesori pas ciklit t\u00eb fundit t\u00eb GC? Prandaj, e gjith\u00eb kjo nuk mund t\u00eb jet\u00eb n\u00eb cache, dhe m\u00eb pas ndodh nj\u00eb humbje e garantuar 100%. Gjat\u00eb pun\u00ebs me nj\u00eb tregues, n\u00eb x86, t\u00eb lexosh nj\u00eb regjist\u00ebr nga memoria merr 1-2 cikle, dhe sa her\u00eb q\u00eb ndodh kjo, ti paguan, paguan, paguan, sepse e gjith\u00eb memoria \u00ebsht\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Cache_inclusion_policy\">NINE caches<\/a><\/noindex> \u2013 dhe kjo \u00ebsht\u00eb kostumi i ndarjes s\u00eb memories. Kostumi i v\u00ebrtet\u00eb.<\/p>\n<p><\/p>\n<p>Me th\u00ebn\u00eb, strukturat e t\u00eb dh\u00ebnave jan\u00eb ato q\u00eb \u00ebsht\u00eb m\u00eb e v\u00ebshtir\u00eb t\u00eb ndryshosh. Dhe sapo kuptoni se keni zgjedhur struktur\u00ebn e gabuar t\u00eb t\u00eb dh\u00ebnave q\u00eb m\u00eb von\u00eb do t\u00eb d\u00ebmtoj\u00eb performanc\u00ebn, zakonisht k\u00ebrkohet nj\u00eb pun\u00eb e madhe p\u00ebr t'u rikthyer, por n\u00ebse nuk e b\u00ebni k\u00ebt\u00eb, situata do t\u00eb p\u00ebrkeq\u00ebsohet. S\u00eb pari, duhet t\u00eb mendoni p\u00ebr strukturat e t\u00eb dh\u00ebnave, kjo \u00ebsht\u00eb e r\u00ebnd\u00ebsishme. Kostoja kryesore k\u00ebtu bie mbi strukturat e m\u00ebdha t\u00eb t\u00eb dh\u00ebnave, t\u00eb cilat fillojn\u00eb t\u00eb p\u00ebrdoren n\u00eb stilin 'un\u00eb kopjova struktur\u00ebn e t\u00eb dh\u00ebnave X n\u00eb struktur\u00ebn e t\u00eb dh\u00ebnave Y, sepse Y m\u00eb p\u00eblqen m\u00eb shum\u00eb n\u00eb form\u00eb'. Por operacioni i kopjimit (i cili duket i lir\u00eb) n\u00eb t\u00eb v\u00ebrtet\u00eb shpenzon hap\u00ebsir\u00ebn n\u00eb kujtes\u00eb dhe k\u00ebtu \u00ebsht\u00eb ku humbet gjith\u00e7ka n\u00eb koh\u00eb ekzekutimi. N\u00ebse kam nj\u00eb varg t\u00eb madh me JSON dhe dua ta shnd\u00ebrroj at\u00eb n\u00eb nj\u00eb pem\u00eb DOM t\u00eb strukturuar nga POJO ose di\u00e7ka e till\u00eb, operacioni i analizimit t\u00eb k\u00ebtij vargu dhe nd\u00ebrtimi t\u00eb POJO dhe m\u00eb pas nj\u00eb shfryt\u00ebzim t\u00eb ri t\u00eb POJO n\u00eb vazhdim do t\u00eb kthehen n\u00eb nj\u00eb kosto shtes\u00eb - nj\u00eb gj\u00eb e shtrenjt\u00eb. Me p\u00ebrjashtim t\u00eb rastit kur do t\u00eb l\u00ebvizni p\u00ebrmes POJO shum\u00eb m\u00eb shpesh sesa p\u00ebrmes vargut. N\u00eb vend t\u00eb k\u00ebsaj, mund t\u00eb provoni t\u00eb deshifroni vargun dhe t\u00eb nxirrni vet\u00ebm at\u00eb q\u00eb ju nevojitet, pa e shnd\u00ebrruar n\u00eb asnj\u00eb POJO. N\u00ebse e gjith\u00eb kjo ndodh n\u00eb nj\u00eb rrug\u00eb, nga e cila k\u00ebrkohet performanca maksimale, asnj\u00eb POJO - duhet t\u00eb hidhni diku drejt vargut.<\/p>\n<p><\/p>\n<h1 id=\"zachem-sozdavat-svoy-yazyk-programmirovaniya\">Why create your own programming language<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Ju that\u00eb se p\u00ebr t\u00eb kuptuar modelin e kostos, duhet t\u00eb shkruani nj\u00eb gjuh\u00eb t\u00eb vog\u00ebl\u2026<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Jo nj\u00eb gjuh\u00eb, por nj\u00eb kompilator. Gjuha dhe kompileri jan\u00eb gj\u00ebra t\u00eb ndryshme. Dallimi m\u00eb i r\u00ebnd\u00ebsish\u00ebm \u00ebsht\u00eb n\u00eb mendjen tuaj.\u00a0<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: P\u00ebrsa i p\u00ebrket, sa di un\u00eb, po eksperimentoni me krijimin e gjuh\u00ebve tuaja. Pse?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Sepse mundem! Jam gjysm\u00eb n\u00eb pension, k\u00ebshtu q\u00eb kjo \u00ebsht\u00eb hobiu im. Kam realizuar gjuh\u00eb t\u00eb huaja gjat\u00eb gjith\u00eb jet\u00ebs sime. Kam punuar shum\u00eb edhe mbi stilin e kodimit. Po ashtu, shoh probleme n\u00eb gjuh\u00ebt e tjera. Shoh se ka m\u00ebnyra m\u00eb t\u00eb mira p\u00ebr t\u00eb b\u00ebr\u00eb gj\u00ebra t\u00eb zakonshme. Dhe do t'i shfryt\u00ebzoja ato. Thjesht jam i lodhur nga problemet n\u00eb vetvete, n\u00eb Java, n\u00eb Python, n\u00eb \u00e7do gjuh\u00eb tjet\u00ebr. Tani po shkruaj n\u00eb React Native, JavaScript dhe Elm si nj\u00eb hob, i cili nuk ka t\u00eb b\u00ebj\u00eb me pensionin, por me pun\u00eb aktive. Po ashtu shkruaj edhe n\u00eb Python dhe ndoshta do t\u00eb vazhdoj t\u00eb punoj mbi m\u00ebsimin e makinerive p\u00ebr backend-et Java. Ka shum\u00eb gjuh\u00eb t\u00eb njohura dhe secila ka ve\u00e7orit\u00eb e saj interesante. \u00c7do nj\u00ebra \u00ebsht\u00eb e mir\u00eb p\u00ebr di\u00e7ka dhe mund t\u00eb provosh t\u00eb bashkosh t\u00eb gjitha k\u00ebto karakteristika. Pra, merrem me studimin e gj\u00ebrave interesante p\u00ebr mua, sjelljes s\u00eb gjuh\u00ebs, p\u00ebrpiqem t\u00eb shpik nj\u00eb semantik\u00eb t\u00eb arsyeshme. Deri tani po arrij! Aktualisht po luftoj me semantik\u00ebn e memories, sepse d\u00ebshiroj ta kem si n\u00eb C dhe Java, dhe t\u00eb kem nj\u00eb model t\u00eb fort\u00eb memorje dhe semantik\u00eb p\u00ebr ngarkesat dhe dyqanet. Pas k\u00ebsaj, t\u00eb kem automatikisht nxjerrjen e tipave si n\u00eb Haskell. K\u00ebshtu, po p\u00ebrpiqem t\u00eb p\u00ebrziej nxjerrjen e tipave t\u00eb ngjashme me Haskell me nj\u00eb memorie q\u00eb punon si n\u00eb C dhe Java. K\u00ebt\u00eb e kam b\u00ebr\u00eb p\u00ebr 2-3 muajt e fundit, p\u00ebr shembull.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: N\u00ebse po nd\u00ebrtoni nj\u00eb gjuh\u00eb q\u00eb merr aspektet m\u00eb t\u00eb mira nga gjuh\u00eb t\u00eb tjera, keni menduar ndonj\u00ebher\u00eb se dikush do t\u00eb b\u00ebj\u00eb t\u00eb kund\u00ebrt\u00ebn: do t\u00eb marr\u00eb idet\u00eb tuaja dhe do t'i p\u00ebrdor\u00eb p\u00ebr vete?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Ky \u00ebsht\u00eb m\u00ebnyra se si lindin gjuh\u00ebt e reja! Pse Java \u00ebsht\u00eb e ngjashme me C? Sepse C kishte nj\u00eb sintaks\u00eb t\u00eb mir\u00eb, q\u00eb t\u00eb gjith\u00eb e kuptonin dhe Java u frym\u00ebzua nga kjo sintaks\u00eb, duke shtuar aty sigurin\u00eb e tipit, kontrollin e kufijve t\u00eb masivave, GC, dhe p\u00ebrmir\u00ebsuan disa gj\u00ebra nga C. Ata shtuan t\u00eb tyret. Por ata ishin shum\u00eb t\u00eb frym\u00ebzuar, apo jo? T\u00eb gjith\u00eb q\u00ebndrojn\u00eb mbi supet e gjigant\u00ebve q\u00eb ishin para teje \u2013 k\u00ebshtu b\u00ebhet progresi.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Sa kuptoj, gjuha juaj do t\u00eb jet\u00eb e sigurt n\u00eb lidhje me p\u00ebrdorimin e memories. Keni menduar t\u00eb realizoni di\u00e7ka si borrow checker nga Rust? E keni par\u00eb at\u00eb, si ju duket?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Kam, un\u00eb kam shkruar n\u00eb C p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb, me gjith\u00eb k\u00ebto malloc dhe free, dhe menaxhoj manualisht koh\u00ebzgjatjen. E dini, 90-95% e menaxhimit manual t\u00eb koh\u00ebzgjatjes ka nj\u00eb struktur\u00eb t\u00eb nj\u00ebjt\u00eb. Dhe \u00ebsht\u00eb shum\u00eb, shum\u00eb e dhimbshme t\u00eb merresh me k\u00ebt\u00eb manualisht. Do t\u00eb doja q\u00eb kompajleri thjesht t\u00eb tregonte se \u00e7far\u00eb ndodh dhe \u00e7far\u00eb arrin me veprimet e tua. P\u00ebr disa gj\u00ebra, borrow checker e b\u00ebn k\u00ebt\u00eb automatikisht. Dhe ai duhet gjithashtu t\u00eb nxjerr\u00eb automatikisht informacione, t\u00eb kuptoj\u00eb gjith\u00e7ka dhe madje t\u00eb mos m\u00eb ngarkoj\u00eb me detyr\u00ebn e shpjegimit t\u00eb atij kuptimi. Ai duhet t\u00eb b\u00ebj\u00eb t\u00eb pakt\u00ebn nj\u00eb analiz\u00eb lokale t\u00eb arratisjes, dhe vet\u00ebm n\u00ebse nuk ia del, at\u00ebher\u00eb duhet t\u00eb shtosh annotationet e tipeve q\u00eb do t\u00eb p\u00ebrshkruanin koh\u00ebzgjatjen \u2013 dhe nj\u00eb skem\u00eb e till\u00eb \u00ebsht\u00eb shum\u00eb m\u00eb e komplikuar se borrow checker, ose ndonj\u00eb checker t\u00eb ekzistuesh\u00ebm t\u00eb memories. Zgjedhja mes 'gjith\u00e7ka \u00ebsht\u00eb n\u00eb rregull' dhe 'nuk kuptova asgj\u00eb' \u2013 jo, duhet t\u00eb ket\u00eb di\u00e7ka m\u00eb t\u00eb mir\u00eb.\u00a0<br \/>\nPrandaj, si nj\u00eb person q\u00eb ka shkruar shum\u00eb kod n\u00eb C, mendoj se mb\u00ebshtetja p\u00ebr menaxhimin automatik t\u00eb jet\u00ebs s\u00eb resurseve \u00ebsht\u00eb gj\u00ebja m\u00eb e r\u00ebnd\u00ebsishme. Gjithashtu, m\u00eb ka irrituar sa shum\u00eb Java p\u00ebrdor memorie, dhe ankesa kryesore \u00ebsht\u00eb n\u00eb GC. Kur alokoni memorie n\u00eb Java, memoria q\u00eb ka qen\u00eb lokale n\u00eb ciklin e fundit t\u00eb GC nuk kthehet. N\u00eb gjuh\u00ebt me menaxhim m\u00eb t\u00eb sakt\u00eb t\u00eb memorjes, kjo nuk ndodh. N\u00ebse th\u00ebrrisni malloc, merrni menj\u00ebher\u00eb memorie q\u00eb zakonisht sapo \u00ebsht\u00eb p\u00ebrdorur. Zakonisht, ju b\u00ebni disa gj\u00ebra t\u00eb p\u00ebrkohshme me memorien dhe menj\u00ebher\u00eb e ktheni at\u00eb. Dhe ajo kthehet menj\u00ebher\u00eb p\u00ebrs\u00ebri n\u00eb pool-in e malloc, dhe cikli i ardhsh\u00ebm i malloc e nxjerr at\u00eb jasht\u00eb p\u00ebrs\u00ebri. Prandaj, p\u00ebrdorimi i v\u00ebrtet\u00eb i memorjes ul\u00ebt n\u00eb setin e objekteve t\u00eb gjall\u00eb n\u00eb nj\u00eb moment t\u00eb caktuar, plus rrjedhjet. Dhe n\u00ebse nuk keni rrjedhje n\u00eb nj\u00eb m\u00ebnyr\u00eb krejt t\u00eb pap\u00ebrshtatshme, pjesa m\u00eb e madhe e memorjes mbetet n\u00eb cache dhe procesor\u00eb, dhe kjo punon shpejt. Por k\u00ebrkon shum\u00eb menaxhim manual t\u00eb memorjes me malloc dhe free, t\u00eb th\u00ebrritura n\u00eb rendin e duhur, n\u00eb vendin e duhur. Rust mund ta menaxhoj\u00eb k\u00ebt\u00eb vet\u00eb si\u00e7 duhet dhe n\u00eb shum\u00eb raste ofron madje m\u00eb shum\u00eb performanc\u00eb, pasi p\u00ebrdorimi i memorjes zvog\u00eblohet vet\u00ebm n\u00eb llogaritjet aktuale \u2013 n\u00eb vend t\u00eb pritjes p\u00ebr ciklin e ardhsh\u00ebm t\u00eb GC, i cili do t\u00eb liroj\u00eb memorien. N\u00eb fund, arrit\u00ebm nj\u00eb m\u00ebnyr\u00eb shum\u00eb interesante p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar performanc\u00ebn. Dhe mjaft t\u00eb fuqishme \u2013 n\u00eb kuptimin, kam punuar me k\u00ebto gj\u00ebra n\u00eb p\u00ebrpunimin e t\u00eb dh\u00ebnave p\u00ebr fintech, dhe kjo ka ofruar nj\u00eb p\u00ebrparim rreth pes\u00eb her\u00eb. Ky \u00ebsht\u00eb nj\u00eb p\u00ebrparim i madh, sidomos n\u00eb bot\u00ebn ku procesor\u00ebt nuk po b\u00ebhen m\u00eb t\u00eb shpejt\u00eb, dhe ne ende vazhdojm\u00eb t\u00eb presim p\u00ebrmir\u00ebsime.<\/p>\n<p><\/p>\n<h1 id=\"karera-performans-inzhenera\">Career of a performance engineer<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Gjithashtu, do t\u00eb doja t\u00eb pyesja p\u00ebr karrier\u00ebn n\u00eb p\u00ebrgjith\u00ebsi. Keni q\u00ebn\u00eb t\u00eb njohur p\u00ebr pun\u00ebn tuaj n\u00eb JIT n\u00eb HotSpot, e m\u00eb pas u sistemuat n\u00eb Azul \u2013 dhe kjo \u00ebsht\u00eb gjithashtu nj\u00eb kompani JVM. Por tani m\u00eb shum\u00eb jeni marr\u00eb me harduerin se sa me softuerin. M\u00eb pas, papritur u kaluat n\u00eb Big Data dhe Machine Learning, e m\u00eb pas n\u00eb zbulimin e mashtrimeve. Si ndodhi kjo? K\u00ebto jan\u00eb fusha shum\u00eb t\u00eb ndryshme t\u00eb zhvillimit.<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Kam un\u00eb kam b\u00ebr\u00eb programim p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb dhe kam pasur mund\u00ebsi t\u00eb merrem me aktivitete shum\u00eb t\u00eb ndryshme. Dhe kur njer\u00ebzit thon\u00eb: \u00abO, ti je ai q\u00eb b\u00ebri JIT p\u00ebr Java!\u00bb, gjithmon\u00eb \u00ebsht\u00eb arg\u00ebtuese. Por p\u00ebrpara se t\u00eb lidhesha me k\u00ebt\u00eb, kam punuar mbi nj\u00eb klon t\u00eb PostScript, gjuh\u00ebs q\u00eb Apple e p\u00ebrdorte dikur p\u00ebr printer\u00ebt e saj lazer. Para k\u00ebsaj, kam realizuar gjuh\u00ebn Forth. Mendoj se tema kryesore p\u00ebr mua \u00ebsht\u00eb zhvillimi i mjeteve. Gjat\u00eb gjith\u00eb jet\u00ebs time, kam krijuar mjete me t\u00eb cilat njer\u00ebzit e tjer\u00eb shkruajn\u00eb programet e tyre t\u00eb shk\u00eblqyera. Por kam qen\u00eb i angazhuar edhe n\u00eb zhvillimin e sistemeve operative, drejtuesve, debugger-it t\u00eb nivelit t\u00eb b\u00ebrtham\u00ebs, gjuh\u00ebve p\u00ebr zhvillimin e OS-ve, t\u00eb cilat filluan thjesht, por me kalimin e koh\u00ebs u b\u00ebheshin gjithnj\u00eb e m\u00eb t\u00eb nd\u00ebrlikuara. Por tema kryesore, ndon\u00ebse, mbetet zhvillimi i mjeteve. Nj\u00eb pjes\u00eb e madhe e jet\u00ebs time ka kaluar midis Azul dhe Sun, dhe ajo kishte t\u00eb b\u00ebj\u00eb me Java. Por kur fillova t\u00eb merrem me Big Data dhe Machine Learning, e veshja p\u00ebrs\u00ebri kapelen time t\u00eb ve\u00e7ant\u00eb dhe thash\u00eb: \u00abAh, tani kemi nj\u00eb problem t\u00eb r\u00ebnd\u00ebsish\u00ebm, dhe k\u00ebtu po ndodhin shum\u00eb gj\u00ebra interesante dhe njer\u00ebz q\u00eb b\u00ebjn\u00eb di\u00e7ka\u00bb. Ky \u00ebsht\u00eb nj\u00eb rrug\u00eb e shk\u00eblqyer p\u00ebr t'u zhvilluar, e cila ia vlen t\u00eb ecet. <\/p>\n<p><\/p>\n<p>Po, gjat\u00eb jet\u00ebs time kam pasur nj\u00eb pasion t\u00eb madh p\u00ebr llogarit\u00eb e shp\u00ebrndara. Puna ime e par\u00eb ishte gjat\u00eb student\u00ebve, duke punuar me C p\u00ebr nj\u00eb projekt reklamash. Kjo ishin llogari t\u00eb shp\u00ebrndara n\u00eb \u00e7ipat Zilog Z80, t\u00eb cil\u00ebt mbledhin t\u00eb dh\u00ebna p\u00ebr njohjen optike t\u00eb tekstit, duke u kryer nga nj\u00eb analizues analogjik. Ishte nj\u00eb tem\u00eb e mrekullueshme dhe krejt e \u00e7uditshme. Megjithat\u00eb, kishte probleme, ndonj\u00eb pjes\u00eb nuk interpretohej si\u00e7 duhej, prandaj ishte e nevojshme q\u00eb t\u00eb merrnim imazhin dhe t'ia tregonim nj\u00eb njeriu q\u00eb e kishte lexuar me syt\u00eb e tij dhe q\u00eb informonte se \u00e7far\u00eb thoshte teksti, dhe k\u00ebshtu kishte pun\u00eb me t\u00eb dh\u00ebna, dhe k\u00ebto pun\u00eb kishin gjuh\u00ebn e tyre. Kishte nj\u00eb backend q\u00eb e p\u00ebrpunonte gjith\u00e7ka \u2013 Z80 q\u00eb punonin paralelisht me terminalet vt100 \u2013 nj\u00eb p\u00ebr \u00e7do person, dhe kishte nj\u00eb model programimi paralel n\u00eb Z80. Nj\u00eb pjes\u00eb e p\u00ebrbashk\u00ebt memorie q\u00eb ndante t\u00eb gjitha Z80 brenda nj\u00eb konfigurimi t\u00eb tipit \u201cyll\u201d; ndarja e backplane dhe gjysma e RAM-it ndante brenda rrjetit, dhe gjysma tjet\u00ebr ishte private ose shkonte diku tjet\u00ebr. Nj\u00eb sistem paralel dhe t\u00eb shp\u00ebrndar\u00eb mjaft kompleks me memorie t\u00eb\u2026 gjysm\u00eb t\u00eb ndar\u00eb. Kur u ndodhi\u2026 Nuk e mbaj mend sakt\u00ebsisht, diku n\u00eb mes t\u00eb viteve 80. Mjaft koh\u00eb m\u00eb par\u00eb.\u00a0<br \/>\nPo, le t\u00eb themi se 30 vjet jan\u00eb mjaft koh\u00eb m\u00eb par\u00eb. Problemet q\u00eb lidhen me llogarit\u00eb e shp\u00ebrndara ekzistojn\u00eb prej nj\u00eb kohe t\u00eb konsiderueshme, njer\u00ebzit p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb kan\u00eb luftuar me to. <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>-klasteret. K\u00ebto klastere duken si... P.sh.: ka Ethernet dhe procesori yt i shpejt\u00eb x86 \u00ebsht\u00eb lidhur me k\u00ebt\u00eb Ethernet, dhe tani d\u00ebshiron t\u00eb marr\u00ebsh memorien e p\u00ebrbashk\u00ebt fake, sepse askush nuk mund t\u00eb merrej me kodimin e llogaritjeve t\u00eb shp\u00ebrndara, ishte shum\u00eb e komplikuar dhe p\u00ebr k\u00ebt\u00eb arsye kishte memorien e p\u00ebrbashk\u00ebt fake me mbrojtjen e faqeve t\u00eb memories n\u00eb x86, dhe n\u00ebse shkruaje n\u00eb k\u00ebt\u00eb faqe, ne u thoshim procesor\u00ebve t\u00eb tjer\u00eb q\u00eb n\u00ebse ata do t\u00eb kishin qasje n\u00eb t\u00eb nj\u00ebjt\u00ebn memorie t\u00eb p\u00ebrbashk\u00ebt, do t\u00eb duhej ta ngarkonin nga ti, dhe k\u00ebshtu lindi di\u00e7ka si nj\u00eb protokoll mb\u00ebshtetje p\u00ebr koherenc\u00ebn e caches dhe software p\u00ebr k\u00ebt\u00eb. Nj\u00eb koncept interesant. Problemi i v\u00ebrtet\u00eb, natyrisht, ishte ndryshe. E gjith\u00eb kjo funksiononte, por ti shpejt kishe probleme me performanc\u00ebn, sepse askush nuk e kuptonte modelin e performanc\u00ebs n\u00eb nj\u00eb nivel t\u00eb mjaftuesh\u00ebm t\u00eb mir\u00eb \u2013 cilat ishin ato modele t\u00eb qasjes n\u00eb memorie, si t\u00eb b\u00ebje q\u00eb nodet t\u00eb mos pingonin pafund nj\u00ebra-tjetr\u00ebn, etj. <\/p>\n<p><\/p>\n<p>N\u00eb H2O kam menduar k\u00ebshtu: zhvilluesit vet\u00eb jan\u00eb p\u00ebrgjegj\u00ebs p\u00ebr t\u00eb p\u00ebrcaktuar se ku \u00ebsht\u00eb paralelizmi dhe ku nuk ka. Kam krijuar nj\u00eb model kodimi q\u00eb e b\u00ebn t\u00eb leht\u00eb dhe t\u00eb thjesht\u00eb shkruajn\u00eb kod me performanc\u00eb t\u00eb lart\u00eb. Nd\u00ebrsa t\u00eb shkruash kod q\u00eb punon ngadal\u00eb \u00ebsht\u00eb e v\u00ebshtir\u00eb; ai do t\u00eb duket keq. Duhet t\u00eb p\u00ebrpiqesh seriozisht p\u00ebr t\u00eb shkruar kod t\u00eb ngadalsh\u00ebm, do t\u00eb duhet t\u00eb p\u00ebrdor\u00ebsh metoda t\u00eb natyrshme. Kodi q\u00eb pengon \u00ebsht\u00eb i duksh\u00ebm q\u00eb n\u00eb shikim t\u00eb par\u00eb. Si pasoj\u00eb, zakonisht shkruhet kod q\u00eb punon shpejt, por ju duhen t\u00eb kuptoni se \u00e7far\u00eb t\u00eb b\u00ebni n\u00eb rast t\u00eb memories s\u00eb ndar\u00eb. T\u00eb gjitha k\u00ebto jan\u00eb t\u00eb lidhura me masa t\u00eb m\u00ebdha dhe sjellja aty \u00ebsht\u00eb e ngjashme me masat e m\u00ebdha jo volatile n\u00eb Java paralel. P\u00ebr shembull, imagjinoni se dy rrjedha shkruajn\u00eb n\u00eb nj\u00eb mas\u00eb paralel, nj\u00ebra fiton dhe tjetra, p\u00ebrkat\u00ebsisht, humbet, dhe nuk dini se cila \u00ebsht\u00eb cila. N\u00ebse ato nuk jan\u00eb volatile, rendi mund t\u00eb jet\u00eb \u00e7far\u00ebdo - dhe kjo funksionon me t\u00eb v\u00ebrtet\u00eb mir\u00eb. Njer\u00ebzit v\u00ebrtet\u00eb shqet\u00ebsohen p\u00ebr rendin e operacioneve, ata rendisin si\u00e7 duhet volatile dhe n\u00eb vendet e duhura presin probleme me performanc\u00ebn q\u00eb lidhen me memorien. N\u00eb t\u00eb kund\u00ebrt, ata do t\u00eb shkruanin thjesht kod si cikle nga 1 n\u00eb N, ku N \u00ebsht\u00eb disa triliona, duke shpresuar se t\u00eb gjitha rastet komplekse do t\u00eb b\u00ebhen automatikisht t\u00eb paralelizuara - dhe atje kjo nuk funksionon. Por n\u00eb H2O nuk \u00ebsht\u00eb as Java dhe as Scala, mund ta quani k\u00ebt\u00eb \"Java minus minus\" n\u00ebse d\u00ebshironi. Ky \u00ebsht\u00eb nj\u00eb stil programimi shum\u00eb i kuptuesh\u00ebm dhe \u00ebsht\u00eb i ngjash\u00ebm me shkruarjen e kodit t\u00eb thjesht\u00eb n\u00eb C ose Java me cikle dhe masa. Por, edhe k\u00ebsaj mund t\u00eb trajtojm\u00eb terabajt\u00eb memorjeje. Un\u00eb ende p\u00ebrdor H2O. Her\u00eb pas here e p\u00ebrdor n\u00eb projekte t\u00eb ndryshme - dhe ajo ende \u00ebsht\u00eb gj\u00ebja m\u00eb e shpejt\u00eb, me dhjet\u00ebra her\u00eb p\u00ebrpara konkurrent\u00ebve. N\u00ebse po b\u00ebni Big Data me t\u00eb dh\u00ebna kolonore, \u00ebsht\u00eb shum\u00eb e v\u00ebshtir\u00eb t\u00eb kaloni H2O.<\/p>\n<p><\/p>\n<h1 id=\"tehnicheskie-chellenzhi\">Technical challenges<\/h1>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Cila ka qen\u00eb sfida m\u00eb e madhe gjat\u00eb gjith\u00eb karrier\u00ebs suaj?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Po diskutojm\u00eb pjes\u00ebn teknike apo jo teknike t\u00eb \u00e7\u00ebshtjes? Do t\u00eb thoja, sfidat m\u00eb t\u00eb m\u00ebdha jan\u00eb ato jo teknike.\u00a0<br \/>\nSa ndihmuar n\u00eb sfidat teknike. Un\u00eb thjesht i kam mposhtur ato. Nuk e di se cila ka qen\u00eb m\u00eb e madhja, por kishte disa mjaft interesante q\u00eb mor\u00ebn shum\u00eb koh\u00eb dhe luft\u00eb mendore. Kur shkova n\u00eb Sun, isha i sigurt se do t\u00eb b\u00ebja nj\u00eb kompilator t\u00eb shpejt\u00eb, nd\u00ebrsa nj\u00eb grup senior\u00ebsh n\u00eb p\u00ebrgjigje thoshin se nuk do t\u00eb mundja kurr\u00eb. Por un\u00eb vazhdova n\u00eb k\u00ebt\u00eb rrug\u00eb, shkrova nj\u00eb kompilator deri n\u00eb alokimin e regjistrave dhe ishte mjaft i shpejt\u00eb. Ai ishte aq i shpejt\u00eb sa kompajleri modern C1, por at\u00ebher\u00eb alokatori ishte shum\u00eb m\u00eb i ngadalt\u00eb, dhe duke e par\u00eb pas, kjo ishte nj\u00eb problem q\u00eb kishte nj\u00eb struktur\u00eb t\u00eb madhe t\u00eb dh\u00ebnash. M\u00eb nevojitej p\u00ebr t\u00eb shkruar nj\u00eb alokator grafik regjistrash dhe nuk e kuptoja dilem\u00ebn nd\u00ebrmjet shprehshm\u00ebris\u00eb s\u00eb kodit dhe shpejt\u00ebsis\u00eb, e cila ekzistonte at\u00ebher\u00eb dhe ishte shum\u00eb e r\u00ebnd\u00ebsishme. Doli q\u00eb struktura e t\u00eb dh\u00ebnave zakonisht e tejkalonte madh\u00ebsin\u00eb e cache-it n\u00eb x86-t\u00eb e asaj kohe dhe prandaj, n\u00ebse fillimisht supozova se alokatori i regjistrave do t\u00eb punonte 5-10 p\u00ebr qind t\u00eb gjith\u00eb koh\u00ebs s\u00eb jitimit, n\u00eb realitet kjo rezultoi n\u00eb 50 p\u00ebr qind. <\/p>\n<p><\/p>\n<p>Koha kalonte, kompajleri po b\u00ebhej gjithnj\u00eb e m\u00eb i qart\u00eb dhe produktiv, ndaloi s\u00eb gjeneruari kod t\u00eb tmerrsh\u00ebm m\u00eb shpesh, dhe performanca filloi t\u00eb ngjaj\u00eb m\u00eb shum\u00eb me at\u00eb q\u00eb jep kompajleri C. N\u00ebse, sigurisht, nuk po shkruaje ndonj\u00eb gj\u00eb t\u00eb keqe, q\u00eb madje as C nuk e p\u00ebrshpejton. N\u00ebse shkruan kod si n\u00eb C, merr performanc\u00eb si n\u00eb C n\u00eb shum\u00eb m\u00eb shum\u00eb raste. Dhe sa m\u00eb shum\u00eb kalonte koha, aq m\u00eb shpesh del kodi, asimptotikisht p\u00ebrputh\u00ebs me nivelin C, alokatori i regjistrave filloi t\u00eb ngjaj\u00eb me di\u00e7ka t\u00eb p\u00ebrfunduar\u2026 pavar\u00ebsisht n\u00ebse kodi yt punon shpejt apo ngadal\u00eb. Un\u00eb vazhdoja t\u00eb punoja mbi alokatorin p\u00ebr ta b\u00ebr\u00eb at\u00eb q\u00eb t\u00eb b\u00ebnte alokime m\u00eb t\u00eb mira. Ai po b\u00ebhej gjithnj\u00eb e m\u00eb i ngadalt\u00eb, por po siguronte performanc\u00eb gjithnj\u00eb e m\u00eb t\u00eb mir\u00eb n\u00eb ato raste kur askush tjet\u00ebr nuk arrinte. Munda t\u00eb zhytem n\u00eb alokatorin e regjistrave, t\u00eb thelloj nj\u00eb muaj pun\u00eb atje, dhe papritmas i gjith\u00eb kodi fillonte t\u00eb ekzekutohej 5% m\u00eb shpejt. Kjo ndodhte her\u00eb pas here dhe alokatori i regjistrave u b\u00eb di\u00e7ka si nj\u00eb vep\u00ebr arti \u2013 t\u00eb gjith\u00eb e donin apo e urrejnin at\u00eb, dhe njer\u00ebzit nga akademia b\u00ebnin pyetje si \"p\u00ebrse gjith\u00e7ka b\u00ebhet pik\u00ebrisht k\u00ebshtu\", pse jo <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Register_allocation#Linear_Scan\">skanimi linear<\/a><\/noindex>, dhe si ndryshon ajo. P\u00ebrt\u00ebritja \u00ebsht\u00eb e nj\u00ebjt\u00eb: nj\u00eb alokator i bazuar n\u00eb ngjyrosjen e grafit plus nj\u00eb menaxhim shum\u00eb t\u00eb kujdessh\u00ebm t\u00eb kodit tampon i barabart\u00eb me nj\u00eb arm\u00eb fitoreje, kombinimi m\u00eb i mir\u00eb q\u00eb askush nuk mund ta mposht. Dhe kjo \u00ebsht\u00eb nj\u00eb gj\u00eb mjaft e papritur. T\u00eb gjitha gj\u00ebrat e tjera q\u00eb b\u00ebn kompiler \u00ebsht\u00eb mjaft t\u00eb njohura, megjithat\u00eb jan\u00eb \u00e7uar n\u00eb nj\u00eb nivel arti. Un\u00eb gjithmon\u00eb kam b\u00ebr\u00eb gj\u00ebra q\u00eb duhet t\u00eb kthenin kompilerin n\u00eb nj\u00eb vep\u00ebr arti. Por asgj\u00eb nga k\u00ebto nuk ishte di\u00e7ka jasht\u00ebzakonisht t\u00eb jashtme \u2013 p\u00ebrve\u00e7 alokatorit t\u00eb regjistrave. Truku \u00ebsht\u00eb se duhet t\u00eb jesh shum\u00eb i kujdessh\u00ebm <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Register_allocation\">t\u00eb pres\u00ebsh<\/a><\/noindex> n\u00eb ngarkes\u00eb dhe, n\u00ebse ndodh kjo (mund t\u00eb shpjegoj m\u00eb holl\u00ebsisht, n\u00ebse \u00ebsht\u00eb e interesuar), kjo do t\u00eb thot\u00eb se mund t\u00eb in-line m\u00eb agresivisht, pa rrezik t\u00eb kalosh p\u00ebrtej thyerjes s\u00eb grafikut t\u00eb performanc\u00ebs. N\u00eb ato koh\u00eb ka pasur shum\u00eb kompiler\u00eb t\u00eb plot\u00eb, t\u00eb mbushur me zbukurime dhe rrotulla, n\u00eb t\u00eb cilat kishte alokator\u00eb regjistrash, por askush tjet\u00ebr nuk mundi ta b\u00ebj\u00eb m\u00eb. <\/p>\n<p><\/p>\n<p>Problemi \u00ebsht\u00eb se, n\u00ebse shton metodat q\u00eb n\u00ebnshkruhen p\u00ebr inlining, duke rritur vazhdimisht fush\u00ebn e inlining, grupi i vlerave t\u00eb p\u00ebrdorura menj\u00ebher\u00eb tejkalon numrin e regjistrave, dhe duhet t\u00eb spillohet. Niveli kritik zakonisht ndodh kur alokatori dor\u00ebzohet, dhe nj\u00eb kandidat i mir\u00eb p\u00ebr spilling vlen aq sa nj\u00eb tjet\u00ebr, dhe spillon disa gj\u00ebra krejt\u00ebsisht t\u00eb \u00e7mendura. Vlera e inlining \u00ebsht\u00eb se humbasin nj\u00eb pjes\u00eb t\u00eb overhead-it, overhead-it t\u00eb thirrjes dhe ruajtjes, mund t\u00eb shoh\u00ebsh vlerat brenda dhe mund t'i optimizosh m\u00eb tej. Kostumi i inlining \u00ebsht\u00eb se krijohet nj\u00eb num\u00ebr i madh i vlerave aktive, dhe n\u00ebse alokatori yt i regjistrave spillon m\u00eb shum\u00eb se sa duhet, humb menj\u00ebher\u00eb. Prandaj, shumica e alokator\u00ebve kan\u00eb nj\u00eb problem: kur inlining kalon nj\u00eb pik\u00eb t\u00eb caktuar, fillon t\u00eb spillohet gjith\u00e7ka dhe performanca mund t\u00eb bjer\u00eb n\u00eb uj\u00eb t\u00eb ndotur. Ata q\u00eb realizojn\u00eb nj\u00eb kompilator shtojn\u00eb disa heuristika: p\u00ebr shembull, p\u00ebr t\u00eb ndaluar inlining, duke filluar nga nj\u00eb madh\u00ebsi mjaft e madhe, pasi alokimet e shkat\u00ebrrojn\u00eb gjith\u00e7ka. K\u00ebshtu krijohet nj\u00eb thyerje n\u00eb grafikun e performanc\u00ebs \u2013 ke inlinuar, inlinuar, performanca rritet ngadal\u00eb \u2013 dhe pastaj hop! \u2013 bie posht\u00eb me nj\u00eb kthes\u00eb t\u00eb shpejt\u00eb, sepse ke inlinuar shum\u00eb. K\u00ebshtu ka ndodhur deri n\u00eb ardhjen e Java. Java k\u00ebrkon shum\u00eb m\u00eb tep\u00ebr inlining, prandaj m\u00eb \u00ebsht\u00eb dashur t\u00eb b\u00ebj alokatorin tim m\u00eb agresiv, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb rregullohej dhe t\u00eb mos binte, dhe n\u00ebse ke inlinuar shum\u00eb \u2013 ai fillon t\u00eb spillohet, por m\u00eb von\u00eb gjithsesi vjen nj\u00eb moment kur 'nuk ka m\u00eb spilling'. Kjo \u00ebsht\u00eb nj\u00eb v\u00ebzhgim interesant dhe m\u00eb erdhi thjesht nga asgj\u00eb, e paqart\u00eb, por e mir\u00ebpaguar. M\u00eb ndoqi inlining agresiv dhe kjo m\u00eb \u00e7oi n\u00eb vende ku performanca e Java dhe C shkon krahas. Ato jan\u00eb me t\u00eb v\u00ebrtet\u00eb t\u00eb af\u00ebrta \u2013 mund t\u00eb shkruaj kod n\u00eb Java q\u00eb do t\u00eb jet\u00eb shum\u00eb m\u00eb i shpejt\u00eb se kodi n\u00eb C dhe k\u00ebshtu me radh\u00eb, por n\u00eb t\u00eb mesme, n\u00eb pamjen e madhe t\u00eb gj\u00ebrave, ato jan\u00eb af\u00ebrsisht t\u00eb krahasueshme. Mendoj se pjesa e k\u00ebtij meriti \u00ebsht\u00eb alokatori i regjistrave, i cili m\u00eb lejon t\u00eb inlinoj n\u00eb m\u00ebnyr\u00eb maksimalisht t\u00eb thjesht\u00eb. Un\u00eb thjesht inlinoj gjith\u00e7ka q\u00eb shoh. Pyetja k\u00ebtu \u00ebsht\u00eb n\u00ebse alokatori punon mir\u00eb, n\u00ebse rezultati \u00ebsht\u00eb nj\u00eb kod funkcional. Ky ka qen\u00eb nj\u00eb sfid\u00eb e madhe: t\u00eb kuptoj gjith\u00e7ka k\u00ebt\u00eb dhe ta b\u00ebj at\u00eb t\u00eb funksionoj\u00eb.<\/p>\n<p><\/p>\n<h1 id=\"nemnogo-pro-allokaciyu-registrov-i-mnogoyadernost\">A bit about register allocation and multithreading<\/h1>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Problemet si alokimi i regjistrave duket nj\u00eb tem\u00eb e pafund. A \u00ebsht\u00eb ndodhur ndonj\u00ebher\u00eb q\u00eb nj\u00eb ide t\u00eb duket premtuese, por m\u00eb pas t\u00eb d\u00ebshtoj\u00eb n\u00eb praktik\u00eb?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Sigurisht! Alokimi i regjistrave \u00ebsht\u00eb nj\u00eb fush\u00eb ku p\u00ebr t\u00eb zgjidhur nj\u00eb problem NP-t\u00eb plot\u00eb, p\u00ebrpiqesh t\u00eb gjesh disa heuristika. Dhe asnj\u00ebher\u00eb nuk mund t\u00eb arrish nj\u00eb zgjidhje perfekte, apo jo? \u00cbsht\u00eb thjesht e pamundur. Shihni, kompaktimi i Paraprakisht \u2013 ai gjithashtu punon keq. Biseda k\u00ebtu \u00ebsht\u00eb p\u00ebr raste t\u00eb zakonshme. P\u00ebr performanc\u00ebn tipike, k\u00ebshtu q\u00eb mund t\u00eb shkosh dhe t\u00eb mat\u00ebsh di\u00e7ka q\u00eb mendon se \u00ebsht\u00eb nj\u00eb performanc\u00eb tipike e mir\u00eb \u2013 p\u00ebrfundimisht, ti po punon p\u00ebr ta p\u00ebrmir\u00ebsuar at\u00eb! Alokimi i regjistrave \u00ebsht\u00eb nj\u00eb tem\u00eb krejt\u00ebsisht e dedikuar performanc\u00ebs. Sapo t\u00eb kesh prototipin e par\u00eb, ai funksionon dhe ngjyros at\u00eb q\u00eb duhet, fillon puna p\u00ebr performanc\u00ebn. Duhet t\u00eb m\u00ebsosh t\u00eb matesh mir\u00eb. Pse \u00ebsht\u00eb kaq e r\u00ebnd\u00ebsishme? N\u00ebse ka t\u00eb dh\u00ebna t\u00eb qarta, mund t\u00eb shoh\u00ebsh pjes\u00eb t\u00eb ndryshme dhe t\u00eb shoh\u00ebsh: aha, kjo ndihmoi k\u00ebtu, por aty gj\u00ebrat shkuan keq! Shfaqen disa ide t\u00eb mira, shton nj\u00eb heuristik t\u00eb re dhe papritmas gjith\u00e7ka fillon t\u00eb funksionoj\u00eb pak m\u00eb mir\u00eb mesatarisht. Ose ndoshta jo. Kam pasur shum\u00eb raste kur kemi luftuar p\u00ebr pes\u00eb p\u00ebrqind t\u00eb performanc\u00ebs q\u00eb e ndan\u00eb zhvillimin ton\u00eb nga alokatori i m\u00ebparsh\u00ebm. Dhe \u00e7do her\u00eb duket k\u00ebshtu: diku fitove, diku humbe. N\u00ebse ke mjete t\u00eb mira p\u00ebr analiz\u00ebn e performanc\u00ebs, mund t\u00eb gjesh idet\u00eb q\u00eb humbin dhe t\u00eb kuptosh pse ato humbin. Ndoshta ia vlen t\u00eb l\u00ebsh gjith\u00e7ka si\u00e7 \u00ebsht\u00eb, ose ndoshta t\u00eb merresh seriozisht me p\u00ebrshtatjen fine, ose t\u00eb shkosh dhe t\u00eb rregullosh di\u00e7ka tjet\u00ebr. Kjo \u00ebsht\u00eb nj\u00eb shum\u00ebllojshm\u00ebri e madhe! Kam b\u00ebr\u00eb k\u00ebt\u00eb haks t\u00eb mrekulluesh\u00ebm, por m\u00eb nevojitet edhe ky, ky, dhe ky \u2013 dhe gjithashtu kombinimi i tyre jep disa p\u00ebrmir\u00ebsime. Nd\u00ebrsa t\u00eb vetmet mund t\u00eb d\u00ebshtojn\u00eb. Kjo \u00ebsht\u00eb natyra e pun\u00ebs n\u00eb problemet NP-t\u00eb plot\u00eb t\u00eb performanc\u00ebs.<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Duke par\u00eb situat\u00ebn, duket se gj\u00ebrat si ngjyrimi n\u00eb alokator\u00ebt jan\u00eb nj\u00eb problem tashm\u00eb i zgjidhur. Pra, p\u00ebr ju t\u00eb zgjidhur, gjykuar nga ajo q\u00eb thoni, at\u00ebher\u00eb a ka ndonj\u00eb kuptim\u2026<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Ajo nuk \u00ebsht\u00eb zgjidhur si e till\u00eb. Ti duhet ta kthesh at\u00eb n\u00eb \u00abt\u00eb zgjidhur\u00bb. Ka detyra t\u00eb v\u00ebshtira dhe ato duhen zgjidhur. Kur kjo \u00ebsht\u00eb b\u00ebr\u00eb, vjen koha p\u00ebr t\u00eb punuar mbi performanc\u00ebn. Kjo pun\u00eb duhet t\u00eb merret seriozisht \u2013 t\u00eb kryhen benchmark, t\u00eb mblidhen metrika, t\u00eb shpjegohen situatat kur rikthimi n\u00eb versionin e m\u00ebparsh\u00ebm b\u00ebn q\u00eb haku yt i vjet\u00ebr t\u00eb filloj\u00eb t\u00eb funksionoj\u00eb p\u00ebrs\u00ebri (apo anasjelltas, t\u00eb ndaloj\u00eb). Dhe mos u dor\u00ebzo derisa t\u00eb arrish di\u00e7ka. Si\u00e7 kam th\u00ebn\u00eb, n\u00ebse ide t\u00eb shk\u00eblqyera q\u00eb nuk funksionuan, por n\u00eb fush\u00ebn e alokimit t\u00eb regjistrave ka ide pothuajse t\u00eb pafund. Mund, p\u00ebr shembull, t\u00eb lexosh publikime shkencore. Megjithat\u00eb, tani kjo fush\u00eb ka filluar t\u00eb l\u00ebviz\u00eb m\u00eb ngadal\u00eb dhe \u00ebsht\u00eb b\u00ebr\u00eb m\u00eb e qart\u00eb se n\u00eb dit\u00ebt e saj t\u00eb reja. Megjithat\u00eb, n\u00eb k\u00ebt\u00eb fush\u00eb punon nj\u00eb pafund\u00ebsi njer\u00ebzish dhe t\u00eb gjitha idet\u00eb e tyre meritojn\u00eb t\u00eb provohen, t\u00eb gjith\u00eb po presin momentin e tyre. Dhe ti nuk mund t\u00eb thua sa t\u00eb mira jan\u00eb ato, n\u00ebse nuk provon. Sa mir\u00eb integrohen me gjith\u00e7ka tjet\u00ebr n\u00eb alokuesin t\u00ebnd, sepse alokuesi b\u00ebn shum\u00eb gj\u00ebra, dhe disa ide n\u00eb alokuesin t\u00ebnd specifik nuk do t\u00eb funksionojn\u00eb, nd\u00ebrsa n\u00eb nj\u00eb alokues tjet\u00ebr \u2013 leht\u00ebsisht. M\u00ebnyra primare e fitores p\u00ebr alokuesin \u00ebsht\u00eb t\u00eb nxjerr\u00eb gj\u00ebrat e ngadalta jasht\u00eb rrug\u00ebs kryesore dhe t\u00eb detyruar t\u00eb b\u00ebj\u00eb ndarje p\u00ebrgjat\u00eb kufijve t\u00eb rrug\u00ebve t\u00eb ngadalta. Prandaj, n\u00ebse d\u00ebshiron t\u00eb nis\u00ebsh GC, t\u00eb shkosh n\u00eb rrug\u00ebn e ngadalshme, t\u00eb deoptimizohesh, t\u00eb hedh\u00ebsh nj\u00eb p\u00ebrjashtim, gjith\u00e7ka n\u00eb at\u00eb frym\u00eb \u2013 di se k\u00ebto gj\u00ebra jan\u00eb relativisht t\u00eb rralla. Dhe ato jan\u00eb v\u00ebrtet t\u00eb rralla, e kam provuar. B\u00ebn pun\u00eb shtes\u00eb dhe p\u00ebr k\u00ebt\u00eb arsye eliminon shum\u00eb kufizime n\u00eb k\u00ebto rrug\u00eb t\u00eb ngadalta, por kjo nuk \u00ebsht\u00eb shum\u00eb e r\u00ebnd\u00ebsishme, sepse ato jan\u00eb t\u00eb ngadalta dhe rrall\u00eb shihen. P\u00ebr shembull, treguesi zero \u2013 ai kurr\u00eb nuk ndodh, apo jo? Duhet t\u00eb kesh disa rrug\u00eb p\u00ebr gj\u00ebra t\u00eb ndryshme, por ato nuk duhet t\u00eb p\u00ebrzihen n\u00eb t\u00eb par\u00ebn.\u00a0<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: \u00c7far\u00eb mendoni p\u00ebr shum\u00ebnuk\u00ebsin\u00eb, kur ka mij\u00ebra b\u00ebrthama? A \u00ebsht\u00eb nj\u00eb gj\u00eb e dobishme?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Suksesi i GPU tregon se \u00ebsht\u00eb mjaft i dobish\u00ebm!<\/p>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: Ata jan\u00eb mjaft t\u00eb specializuar. E \u00e7far\u00eb p\u00ebr procesor\u00ebt e p\u00ebrgjithsh\u00ebm?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: E, kjo ishte modeli i biznesit t\u00eb Azul. P\u00ebrgjigjja erdhi n\u00eb nj\u00eb epok\u00eb kur njer\u00ebzit e donin shum\u00eb performanc\u00ebn e parashikueshme. At\u00ebher\u00eb ishte e v\u00ebshtir\u00eb t\u00eb shkruaje kod paralel. Modeli i kodimit H2O shkall\u00ebzohet mir\u00eb, por nuk \u00ebsht\u00eb nj\u00eb model me q\u00ebllim t\u00eb p\u00ebrgjithsh\u00ebm. Ndryshe nga ai q\u00eb p\u00ebrdor GPU-n\u00eb. Po flasim p\u00ebr kompleksitetin e zhvillimit t\u00eb nj\u00eb gj\u00ebje t\u00eb till\u00eb apo p\u00ebr kompleksitetin e p\u00ebrdorimit t\u00eb saj? P\u00ebr shembull, nj\u00eb m\u00ebsim interesant m\u00eb jep Azul, mjaft i paduksh\u00ebm: caches t\u00eb vogla jan\u00eb t\u00eb pranueshme.\u00a0<\/p>\n<p><\/p>\n<h1 id=\"samyy-bolshoy-chellenzh-v-zhizni\">The biggest challenge in life<\/h1>\n<p><\/p>\n<p><strong>Vladimir<\/strong>: \u00c7far\u00eb p\u00ebr sfidat jo teknike?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Sfida m\u00eb e madhe ishte t\u00eb mos isha... i mir\u00eb dhe i dashur me njer\u00ebzit. Dhe si pasoj\u00eb, un\u00eb u gjenda vazhdimisht n\u00eb situata ekstremisht konfliktuale. Situata ku dija se \u00e7do gj\u00eb po shkonte keq, por nuk dija si t\u00eb ecja p\u00ebrpara n\u00eb zgjidhjen e k\u00ebtyre problemeve dhe nuk mund t\u00eb merresha me to. Mjaft probleme t\u00eb vazhdueshme, q\u00eb zgjat\u00ebn gjat\u00eb dhjet\u00ebra vjet\u00ebve, u shfaq\u00ebn sakt\u00ebsisht n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb. E v\u00ebrteta q\u00eb n\u00eb Java ka kompilator\u00eb C1 dhe C2 \u00ebsht\u00eb nj\u00eb pasoj\u00eb e drejtp\u00ebrdrejt\u00eb e k\u00ebsaj. Fakti q\u00eb n\u00eb Java p\u00ebr nj\u00eb dekad\u00eb nuk kishte kompilim shum\u00eb-niveli \u00ebsht\u00eb gjithashtu nj\u00eb pasoj\u00eb e drejtp\u00ebrdrejt\u00eb. Sigurisht, na duhej nj\u00eb sistem i till\u00eb, por nuk \u00ebsht\u00eb e qart\u00eb pse nuk kishte. Kam pasur probleme me nj\u00eb inxhinier... ose grup inxhinier\u00ebsh. Disa koh\u00eb m\u00eb par\u00eb, kur fillova pun\u00ebn n\u00eb Sun, isha... Mir\u00eb, jo vet\u00ebm at\u00ebher\u00eb, kam gjithmon\u00eb nj\u00eb mendim p\u00ebr gjith\u00e7ka. Dhe e mendoja se \u00ebsht\u00eb nj\u00eb e v\u00ebrtet\u00eb q\u00eb mund t\u00eb marr\u00ebsh k\u00ebt\u00eb t\u00eb v\u00ebrtet\u00eb time dhe ta tregosh hapur. P\u00ebr m\u00eb tep\u00ebr, isha shokuesh\u00ebm i sakt\u00eb pjes\u00ebn m\u00eb t\u00eb madhe t\u00eb koh\u00ebs. Dhe n\u00ebse nj\u00eb qasje e till\u00eb nuk t\u00eb p\u00eblqen... sidomos n\u00ebse \u00ebsht\u00eb e qart\u00eb q\u00eb je n\u00eb gabim dhe po b\u00ebn gj\u00ebra t\u00eb padobishme... N\u00eb p\u00ebrgjith\u00ebsi, shum\u00eb pak njer\u00ebz mund t\u00eb p\u00ebrballonin nj\u00eb form\u00eb komunikimi t\u00eb till\u00eb me toleranc\u00eb. Megjithat\u00eb disa mundeshin, p\u00ebr shembull, un\u00eb. E kam nd\u00ebrtuar t\u00ebr\u00eb jet\u00ebn time mbi parimet meritokratike. N\u00ebse m\u00eb tregon di\u00e7ka t\u00eb gabuar, un\u00eb menj\u00ebher\u00eb do t\u00eb kthehem dhe do t\u00eb them: ke th\u00ebn\u00eb nj\u00eb budallall\u00ebk. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, sigurisht, k\u00ebrkoj falje dhe gj\u00ebra t\u00eb tjera t\u00eb tilla, do t\u00eb theksoj meritat, n\u00ebse ka ndonj\u00eb q\u00eb ekziston, dhe do t\u00eb b\u00ebj veprime t\u00eb tjera t\u00eb duhura. Nga ana tjet\u00ebr, un\u00eb jam shokuesh\u00ebm i sakt\u00eb nj\u00eb p\u00ebrqindje shokuesh\u00ebm t\u00eb madhe t\u00eb koh\u00ebs s\u00eb p\u00ebrgjithshme. Dhe kjo nuk funksionon shum\u00eb mir\u00eb n\u00eb marr\u00ebdh\u00ebnie me njer\u00ebzit. Un\u00eb nuk p\u00ebrpiqem t\u00eb jem i k\u00ebndsh\u00ebm, por e b\u00ebj \u00e7\u00ebshtjen t\u00eb qart\u00eb. \u201cKjo nuk do t\u00eb funksionoj\u00eb kurr\u00eb, sepse nj\u00eb, dy dhe tre\u201d. Dhe ata jan\u00eb si: \u201cOh!\u201d. Kishin edhe pasoja t\u00eb tjera, t\u00eb cilat ndoshta do ishte m\u00eb mir\u00eb t\u2019i kalonim: p\u00ebr shembull, ato q\u00eb \u00e7uan n\u00eb divorcin nga bashk\u00ebshortja dhe dhjet\u00eb vjet depresion pas k\u00ebsaj.<\/p>\n<p><\/p>\n<p>Sfida \u00ebsht\u00eb nj\u00eb betej\u00eb me njer\u00ebzit, me perceptimin e tyre p\u00ebr at\u00eb q\u00eb ti mund ose nuk mund t\u00eb b\u00ebsh, \u00e7far\u00eb \u00ebsht\u00eb e r\u00ebnd\u00ebsishme dhe \u00e7far\u00eb nuk \u00ebsht\u00eb. Ka pasur shum\u00eb sfida p\u00ebr stilin e kodimit. Un\u00eb akoma shkruaj shum\u00eb kod, dhe n\u00eb ato koh\u00ebra m\u00eb duhej madje t\u00eb ngadal\u00ebsohesha, sepse b\u00ebja shum\u00eb detyra paralelisht dhe i b\u00ebja ato keq, n\u00eb vend q\u00eb t\u00eb fokusoja n\u00eb nj\u00ebr\u00ebn e vetme. Kur e shoh pas, kam shkruar gjysm\u00ebn e kodit t\u00eb ekipit Java JIT, ekipit C2. Programuesi tjet\u00ebr m\u00eb i shpejt\u00eb shkruante me gjysm\u00eb m\u00eb ngadal\u00eb, ai pas tij - akoma m\u00eb ngadal\u00eb dhe kjo ishte nj\u00eb r\u00ebnie eksponenciale. Personi i shtat\u00eb n\u00eb k\u00ebt\u00eb rresht ishte shum\u00eb, shum\u00eb ngadal\u00eb - k\u00ebshtu ka ndodhur gjithmon\u00eb! Un\u00eb e kam prekur nj\u00eb s\u00ebr\u00eb kodi. Kam par\u00eb se kush shkruan \u00e7far\u00eb, pa p\u00ebrjashtim, e kam par\u00eb kodin e tyre, kam b\u00ebr\u00eb rishikime p\u00ebr secilin prej tyre, dhe akoma kam vazhduar t\u00eb shkruaj m\u00eb shum\u00eb se \u00e7do njeri tjet\u00ebr. Me njer\u00ebzit ky qasje nuk funksionon shum\u00eb mir\u00eb. Disa nuk e p\u00eblqejn\u00eb at\u00eb. Dhe kur ata nuk jan\u00eb n\u00eb gjendje t\u00eb p\u00ebrballen me k\u00ebt\u00eb, fillojn\u00eb t\u00eb gjitha llojet e ankesave. P\u00ebr shembull, nj\u00eb her\u00eb m\u00eb than\u00eb t\u00eb ndaloj\u00eb s\u00eb shkruari kod, sepse shkruaj tep\u00ebr shum\u00eb kod, dhe kjo rrezikon ekipin, dhe p\u00ebr mua e gjith\u00eb kjo ting\u00ebllonte si nj\u00eb shaka: \u00e7una, n\u00ebse e gjith\u00eb pjesa tjet\u00ebr e ekipit zhduket, dhe un\u00eb vazhdoj t\u00eb shkruaj kod, do t\u00eb humbni vet\u00ebm gjysm\u00ebn e ekipit. Nga ana tjet\u00ebr, n\u00ebse un\u00eb vazhdoj t\u00eb shkruaj kod dhe ju humbni gjysm\u00ebn e ekipit - kjo ting\u00ebllon si menaxhim shum\u00eb i keq. Un\u00eb kurr\u00eb nuk kam menduar shum\u00eb p\u00ebr k\u00ebt\u00eb, kurr\u00eb nuk kam folur p\u00ebr k\u00ebt\u00eb, por gjithsesi ka qen\u00eb diku n\u00eb mendjen time. N\u00eb thell\u00ebsi t\u00eb mendjeve tona, kishte nj\u00eb mendim: 'A po humoroni?'. Pra, problemi m\u00eb i madh isha un\u00eb dhe marr\u00ebdh\u00ebniet e mia me njer\u00ebzit. Tani e kuptoj veten shum\u00eb m\u00eb mir\u00eb, kam qen\u00eb udh\u00ebheq\u00ebs ekipi p\u00ebr programuesit p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb, dhe tani u them njer\u00ebzve t\u00eb tjer\u00eb: e di, jam k\u00ebshtu si\u00e7 jam, dhe do t\u00eb duhet t\u00eb p\u00ebrballeni me mua - a \u00ebsht\u00eb n\u00eb rregull n\u00ebse q\u00ebndroj k\u00ebtu? Dhe kur ata filluan t\u00eb p\u00ebrballen me k\u00ebt\u00eb, gjith\u00e7ka funksionoi. Sepse, n\u00eb fakt, nuk jam as i keq, as i mir\u00eb, nuk kam ndonj\u00eb q\u00ebllim t\u00eb keq ose ambicie egoiste, kjo \u00ebsht\u00eb thjesht natyra ime dhe duhet t\u00eb jetojm\u00eb me k\u00ebt\u00eb.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: S\u00eb fundmi, t\u00eb gjith\u00eb filluan t\u00eb flasin p\u00ebr vet\u00ebdijen p\u00ebr introvert\u00ebt, dhe n\u00eb p\u00ebrgjith\u00ebsi p\u00ebr aft\u00ebsit\u00eb e buta. \u00c7far\u00eb mund t\u00eb thuhet p\u00ebr k\u00ebt\u00eb?<\/p>\n<p><\/p>\n<p><strong>Cliff<\/strong>: Po, ishte nj\u00eb kuptim dhe nj\u00eb m\u00ebsim q\u00eb nxora nga divorcimi me gruan. Ajo q\u00eb nxora nga divorci \u00ebsht\u00eb kuptimi i vetes. K\u00ebshtu fillova t\u00eb kuptoj edhe t\u00eb tjer\u00ebt. P\u00ebr t\u00eb kuptuar se si funksionon kjo nd\u00ebrveprimin. Kjo solli zbulime pas zbulimeve. Filloi t\u00eb kuptohet kush jam dhe \u00e7far\u00eb p\u00ebrfaq\u00ebsoj. \u00c7far\u00eb po b\u00ebj: a jam i shqet\u00ebsuar p\u00ebr detyr\u00ebn, a po shmang konfliktin, apo di\u00e7ka tjet\u00ebr \u2013 dhe nj\u00eb nivel i till\u00eb vet\u00ebdijesimi n\u00eb t\u00eb v\u00ebrtet\u00eb ndihmon t\u00eb mbash veten n\u00ebn kontroll. Pas k\u00ebsaj, gjith\u00e7ka shkon m\u00eb leht\u00eb. Nj\u00eb gj\u00eb q\u00eb kam zbuluar jo vet\u00ebm te vetja, por edhe te programuesit e tjer\u00eb \u2013 pamund\u00ebsia p\u00ebr t\u00eb verbalizuar mendimet kur je n\u00eb nj\u00eb gjendje stresi emocional. P\u00ebr shembull, po kodifikon dhe je n\u00eb nj\u00eb gjendje fluksi, dhe papritmas vijn\u00eb dhe fillojn\u00eb t\u00eb ul\u00ebrasin n\u00eb panik se di\u00e7ka \u00ebsht\u00eb prishur, dhe tani do t\u00eb t\u00eb shqyrtojn\u00eb masa ekstreme. Dhe nuk mund t\u00eb thuash asnj\u00eb fjal\u00eb, sepse je n\u00eb nj\u00eb gjendje stresi emocional. Njohurit\u00eb e fituara t\u00eb lejojn\u00eb t\u00eb p\u00ebrgatitesh p\u00ebr at\u00eb moment, ta kalosh dhe t\u00eb kalosh n\u00eb nj\u00eb plan t\u00eb t\u00ebrheqjes, pas s\u00eb cil\u00ebs mund t\u00eb b\u00ebsh di\u00e7ka. Pra, po, kur fillon t\u00eb kuptosh se si funksionon e gjith\u00eb kjo \u2013 \u00ebsht\u00eb nj\u00eb ngjarje e madhe, q\u00eb ndryshon jet\u00ebn.\u00a0<br \/>\nUn\u00eb vet\u00eb nuk arrita t\u00eb gjej fjal\u00ebt e duhura, por mbajta mend radhitjen e veprimeve. Thelbi \u00ebsht\u00eb se kjo reagim \u00ebsht\u00eb aq fizik sa \u00ebsht\u00eb verbalisht, dhe t\u00eb duhet hap\u00ebsir\u00eb. Nj\u00eb hap\u00ebsir\u00eb e till\u00eb, n\u00eb kuptimin zen. Pik\u00ebrisht k\u00ebt\u00eb duhet t\u00eb shpjegosh, dhe pastaj menj\u00ebher\u00eb t\u00eb t\u00ebrhiqesh n\u00eb an\u00eb \u2013 fizikisht t\u00eb t\u00ebrhiqesh. Kur hesht fizikisht, mund t\u00eb p\u00ebrballosh situat\u00ebn n\u00eb pjes\u00ebn e emocioneve. Nd\u00ebrsa adrenalina arrin n\u00eb tru, t\u00eb kalon n\u00eb modin <\/p>\n<p><\/p>\n<p>Dhe kjo k\u00ebrkon nj\u00eb hap\u00ebsir\u00eb verbale. Thjesht nj\u00eb hap\u00ebsir\u00eb t\u00eb lir\u00eb. N\u00ebse do flas\u00ebsh p\u00ebr ndonj\u00eb gj\u00eb, mund t\u00eb thua k\u00ebt\u00eb dhe pastaj t\u00eb shkosh dhe realisht t\u00eb gjesh \"hap\u00ebsir\u00ebn\": t\u00eb shkosh p\u00ebr nj\u00eb sh\u00ebtitje n\u00eb park, t\u00eb mbyllesh n\u00eb dush \u2013 nuk ka r\u00ebnd\u00ebsi. E r\u00ebnd\u00ebsishme \u00ebsht\u00eb t\u00eb shk\u00ebputesh p\u00ebrkoh\u00ebsisht nga ajo situat\u00eb. Sa her\u00eb q\u00eb t\u00eb shk\u00ebputesh p\u00ebr disa sekonda, kontrolli kthehet, fillon t\u00eb mendosh qart\u00eb. \"Mir\u00eb, nuk jam ndonj\u00eb idiot, nuk po b\u00ebj gj\u00ebra mendjelehta, jam nj\u00eb njeri mjaft i dobish\u00ebm\". Sa her\u00eb q\u00eb ke arritur ta bind\u00ebsh veten, \u00ebsht\u00eb koha t\u00eb kalosh n\u00eb hapin tjet\u00ebr: t\u00eb kuptosh se \u00e7far\u00eb ndodhi. Ti u sulmua, sulmi erdhi nga nj\u00eb vend ku nuk e kishe pritur, ishte nj\u00eb kurth i pabes\u00eb e t\u00eb ul\u00ebt. Kjo \u00ebsht\u00eb e keqe. Hapi tjet\u00ebr \u2013 t\u00eb kuptosh se p\u00ebrse sulmuesi e kishte t\u00eb domosdoshme k\u00ebt\u00eb. Me t\u00eb v\u00ebrtet\u00eb, p\u00ebrse? Ndoshta sepse ai vet\u00eb ishte n\u00eb zem\u00ebrim? Pse ai \u00ebsht\u00eb n\u00eb zem\u00ebrim? P\u00ebr shembull, ndoshta sepse ai d\u00ebshtoi dhe nuk mund t\u00eb pranoj\u00eb p\u00ebrgjegj\u00ebsin\u00eb? Ky \u00ebsht\u00eb m\u00ebnyra e duhur p\u00ebr t\u00eb trajtuar situat\u00ebn me kujdes. Por p\u00ebr k\u00ebt\u00eb, nevojitet nj\u00eb hap\u00ebsir\u00eb manovrimi, nj\u00eb hap\u00ebsir\u00eb verbale. Hapi i par\u00eb m\u00eb i r\u00ebnd\u00ebsish\u00ebm \u2013 t\u00eb prish\u00ebsh kontaktin verbal. T\u00eb largohemi nga diskutimi me fjal\u00eb. Ta anashkalosh at\u00eb, t\u00eb ik\u00ebsh sa m\u00eb shpejt. N\u00ebse \u00ebsht\u00eb nj\u00eb bised\u00eb telefonike \u2013 thjesht vendos telefonin \u2013 ky \u00ebsht\u00eb nj\u00eb aft\u00ebsi q\u00eb e kam fituar nga komunikimi me ish-gruan. N\u00ebse biseda nuk sjell asgj\u00eb t\u00eb mir\u00eb, thjesht thuaj \"mirupafshim\" dhe vendos telefonin. Nga ana tjet\u00ebr e linj\u00ebs: \"bla-bla-bla\", ti p\u00ebrgjigjesh: \"po, mirupafshim!\" dhe e vendos telefonin. Thjesht nd\u00ebrpres bised\u00ebn. P\u00ebs\u00eb minuta m\u00eb von\u00eb, kur t\u00eb kthehet aft\u00ebsia p\u00ebr t\u00eb menduar qart\u00eb, ti je pak m\u00eb i qet\u00eb, \u00ebsht\u00eb e mundur t\u00eb mendosh p\u00ebr at\u00eb q\u00eb ndodhi dhe \u00e7far\u00eb do ndodh\u00eb m\u00eb pas. Dhe t\u00eb fillosh t\u00eb formosh nj\u00eb p\u00ebrgjigje t\u00eb menduar, dhe jo thjesht t\u00eb reagosh emocionalisht. P\u00eb p\u00ebr mua, nj\u00eb p\u00ebrparim n\u00eb vet\u00ebdijesimin ka qen\u00eb pik\u00ebrisht se n\u00eb rast stresi emocional, un\u00eb nuk mund t\u00eb flas. T\u00eb dal\u00ebsh nga ky gjendje, t\u00eb mendosh dhe t\u00eb planifikosh m\u00ebnyr\u00ebn si t\u00eb p\u00ebrgjigjesh dhe si t\u00eb kompensosh problemet \u2013 k\u00ebto jan\u00eb hapat e duhur kur nuk mund t\u00eb flas\u00ebsh. M\u00ebnyra m\u00eb e thjesht\u00eb \u2013 t\u00eb ik\u00ebsh nga situata n\u00eb t\u00eb cil\u00ebn shfaqet stresi emocional dhe thjesht t\u00eb ndalosh t\u00eb marr\u00ebsh pjes\u00eb n\u00eb at\u00eb stres. Pas k\u00ebsaj, ti fiton aft\u00ebsin\u00eb t\u00eb mendosh, kur mund t\u00eb mendosh, ke mund\u00ebsin\u00eb t\u00eb flas\u00ebsh, dhe k\u00ebshtu me radh\u00eb.<\/p>\n<p><\/p>\n<p>A thua, n\u00eb gjyq avokati i pal\u00ebs tjet\u00ebr p\u00ebrpiqet t\u00eb t\u00eb b\u00ebj\u00eb k\u00ebt\u00eb \u2013 tani \u00ebsht\u00eb e qart\u00eb pse. Sepse ai ka mund\u00ebsin\u00eb t\u00eb t\u00eb shtyp\u00eb deri n\u00eb nj\u00eb gjendje ku nuk mund as t\u00eb thuash emrin t\u00ebnd, p\u00ebr shembull. N\u00eb kuptimin m\u00eb t\u00eb drejtp\u00ebrdrejt\u00eb, nuk do t\u00eb mundesh t\u00eb flas\u00ebsh. N\u00ebse kjo po t\u00eb ndodh dhe n\u00ebse e di se do t\u00eb jesh n\u00eb nj\u00eb vend ku fjal\u00ebt b\u00ebhen luft\u00eb, n\u00eb nj\u00eb vend si gjykata, at\u00ebher\u00eb mund t\u00eb shkosh me avokatin t\u00ebnd. Avokati do t\u00eb t\u00eb mbroj\u00eb dhe do t\u00eb ndaloj\u00eb sulmin verbal, dhe do ta b\u00ebj\u00eb k\u00ebt\u00eb n\u00eb nj\u00eb m\u00ebnyr\u00eb krejt\u00ebsisht ligjore, dhe do t\u00eb rikthesh hap\u00ebsir\u00ebn t\u00ebnde zen t\u00eb humbur. P\u00ebr shembull, mua m\u00eb \u00ebsht\u00eb dashur disa her\u00eb t\u00eb telefonoj familjen, gjyqtari \u00ebsht\u00eb marr\u00eb me k\u00ebt\u00eb mjaft miq\u00ebsisht, por avokati i pal\u00ebs tjet\u00ebr vazhdonte t\u00eb m\u00eb kritikonin me z\u00eb t\u00eb lart\u00eb, nuk mundesha as t\u00eb nd\u00ebrhyja. N\u00eb raste t\u00eb tilla, m\u00ebnyra m\u00eb e mir\u00eb p\u00ebr mua \u00ebsht\u00eb p\u00ebrdorimi i nj\u00eb nd\u00ebrmjet\u00ebsi. Nd\u00ebrmjet\u00ebsi ndalon gjith\u00eb k\u00ebt\u00eb presion, q\u00eb t\u00eb del me nj\u00eb fluks t\u00eb vazhduesh\u00ebm, ti zbulon hap\u00ebsir\u00ebn e nevojshme zen, dhe me t\u00eb rikthehet aft\u00ebsia p\u00ebr t\u00eb folur. Kjo \u00ebsht\u00eb nj\u00eb fush\u00eb e t\u00ebr\u00eb njohurish, n\u00eb t\u00eb cil\u00ebn duhet t\u00eb m\u00ebsosh shum\u00eb, t\u00eb zbulohet shum\u00eb n\u00eb brend\u00ebsi, dhe gjith\u00e7ka kjo shnd\u00ebrrohet n\u00eb vendime strategjike t\u00eb niveleve t\u00eb larta, t\u00eb ndryshme p\u00ebr njer\u00ebz t\u00eb ndrysh\u00ebm. Disa njer\u00ebz nuk e kan\u00eb k\u00ebt\u00eb problem t\u00eb p\u00ebrshkruar m\u00eb lart, zakonisht, ata nuk e kan\u00eb ata q\u00eb profesionist\u00ebt e shitjeve. T\u00eb gjith\u00eb ata njer\u00ebz q\u00eb fitojn\u00eb jetes\u00ebn me fjal\u00eb \u2013 k\u00ebng\u00ebtar\u00eb t\u00eb njohur, poet\u00eb, figura t\u00eb besimit dhe politikan\u00eb, ata gjithmon\u00eb kan\u00eb di\u00e7ka p\u00ebr t\u00eb th\u00ebn\u00eb. Ata nuk kan\u00eb k\u00ebto probleme, nd\u00ebrsa un\u00eb i kam.<\/p>\n<p><\/p>\n<p><strong>Andrey<\/strong>: Ishte\u2026 befasuese. Po, ne kemi biseduar mjaft dhe \u00ebsht\u00eb koha ta mbyllim k\u00ebt\u00eb intervist\u00eb. Ne patjet\u00ebr do t\u00eb takohemi n\u00eb konferenc\u00eb dhe do t\u00eb mund t\u00eb vazhdojm\u00eb k\u00ebt\u00eb dialog. Takohuni n\u00eb Hydra!<\/p>\n<p><\/p>\n<blockquote><p>Mund t\u00eb vazhdohet biseda me Kliffin n\u00eb konferenc\u00ebn Hydra 2019, e cila do t\u00eb mbahet m\u00eb 11-12 korrik 2019 n\u00eb Sh\u00ebn Petersburg. Ai do t\u00eb vij\u00eb me nj\u00eb prezantim <noindex><a rel=\"nofollow\" href=\"https:\/\/hydraconf.com\/2019\/talks\/2jix5mst7iduyp9linqhfj\/?utm_source=habr&amp;utm_medium=45871\">\u00abP\u00ebrvoja e Memorjes Transactionale t\u00eb Pajisjeve Azul\u00bb<\/a><\/noindex>. Biletat mund t\u00eb blihen <noindex><a rel=\"nofollow\" href=\"https:\/\/hydraconf.ru\/?utm_source=habr&amp;utm_medium=458718\">n\u00eb faqen zyrtare<\/a><\/noindex>.<\/p><\/blockquote>\n<p>Burimi: <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.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u043b\u0438\u0444\u0444 \u041a\u043b\u0438\u043a \u2014.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\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\/sq\/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\udd47Intervista e madhe me Kliff Click \u2013 babai i JIT compilimit n\u00eb Java | ProHoster","description":"Kliff Click \u00ebsht\u00eb.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/bolshoe-intervyu-s-kliffom-klikom-ottsom-jit-kompilyatsii-v-java","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","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\/sq\/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\/sq\/wp-json\/wp\/v2\/posts\/35851","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=35851"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/35851\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=35851"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=35851"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=35851"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}