Cliff Click β Cratus-eko CTO (IoT sentsoreak prozesuak hobetzeko), hainbat startupren (Rocket Realtime School, Neurensic eta H2O.ai barne) sortzailea eta sortzailea izan ziren hainbat irteera arrakastatsurekin. Cliffek 15 urterekin idatzi zuen bere lehen konpilatzailea (Pascal TRS Z-80rako)! Javan (Nodoen Itsasoa IR) C2-n egindako lanagatik da ezaguna. Konpilatzaile honek munduari erakutsi zion JIT-k kalitate handiko kodea ekoitzi zezakeela, eta hori izan zen Java software-plataforma moderno nagusietako bat izan zen agertzearen faktoreetako bat. Ondoren, Cliff-ek Azul Systems-i lagundu zion 864 nukleoko mainframe bat eraikitzen Java software hutsarekin, GC etenaldiak onartzen zituen 500 gigabyte-ko pila batean 10 milisegundoren barruan. Oro har, Cliff-ek JVMren alderdi guztiak lantzea lortu zuen.
Habrapost hau Cliff-i egindako elkarrizketa bikaina da. Honako gai hauei buruz hitz egingo dugu:
- Behe-mailako optimizazioetara pasatzea
- Nola egin refactoring handi bat
- Kostu eredua
- Behe-mailako optimizazio prestakuntza
- Errendimendua hobetzeko adibide praktikoak
- Zergatik sortu zure programazio-lengoaia
- Errendimenduko ingeniari karrera
- Erronka teknikoak
- Erregistroen esleipenari eta nukleo anitzei buruz apur bat
- Bizitzako erronkarik handiena
Elkarrizketa honako hauek egiten dute:
- Andrei Satarin Amazon Web Services-en eskutik. Bere ibilbidean, proiektu guztiz ezberdinetan lan egitea lortu zuen: Yandex-en NewSQL banatutako datu-basea probatu zituen, Kaspersky Lab-en hodeia detektatzeko sistema, Mail.ru-n jokalari anitzeko joko bat eta Deutsche Bank-en dibisen prezioak kalkulatzeko zerbitzua. Eskala handiko backend eta sistema banatuak probatzeko interesa.
- Vladimir Sitnikov Netcracker-etik. Hamar urteko lana NetCracker OS-en errendimenduan eta eskalagarritasunean, telekomunikazio-operadoreek sareko eta sareko ekipoen kudeaketa-prozesuak automatizatzeko erabiltzen duten softwarea. Java eta Oracle Database errendimendu-arazoetan interesatzen zaizu. PostgreSQL JDBC kontrolatzaile ofizialean dozena bat errendimendu hobekuntza baino gehiagoren egilea.
Behe-mailako optimizazioetara pasatzea
Andrew: Izen handia zara JIT konpilazioaren, Javaren eta, oro har, performance lanaren munduan, ezta?
Itsaslabarra: Hala da!
Andrew: Has gaitezen performance-lanari buruzko galdera orokor batzuekin. Zer deritzozu PUZ mailan lan egitea bezalako goi-mailako eta behe-mailako optimizazioen arteko aukerari buruz?
Itsaslabarra: Bai, hemen dena sinplea da. Koderik azkarrena inoiz exekutatzen ez dena da. Hori dela eta, maila altu batetik hasi behar da beti, algoritmoak lantzea. O idazkera hobeak O idazkera okerragoa gaindituko du, konstante nahiko handi batzuek esku hartzen ez badute behintzat. Maila baxuko gauzak azkenak dira. Normalean, zure pilaren gainerakoa nahikoa ondo optimizatu baduzu eta oraindik gauza interesgarri batzuk geratzen badira, maila baxua da. Baina nola hasi goi mailatik? Nola dakizu goi-mailako lan nahikoa egin dela? Tira... inola ere ez. Ez dago prest egindako errezetarik. Arazoa ulertu behar duzu, zer egingo duzun erabaki (etorkizunean alferrikako pausorik ez egiteko) eta gero profilera deskubritu dezakezu, zerbait erabilgarria esan dezakeena. Noizbait, zu zeu konturatzen zara beharrezkoak ez diren gauzak kendu dituzula eta baxu-mailako doikuntza batzuk egiteko garaia dela. Zalantzarik gabe, arte mota berezi bat da. Jende asko dago alferrikako gauzak egiten, baina hain azkar mugitzen ez den produktibitateaz kezkatzeko astirik. Baina hau galdera argi eta garbi sortzen den arte. Normalean denboraren %99 inori ez zaio egiten dudana axola, inori axola ez zaion bide kritikoan gauza garrantzitsu bat etortzen den unera arte. Eta hemen denak haserretzen hasten zaituzte "zergatik ez zen primeran funtzionatu hasiera-hasieratik". Oro har, beti dago zer hobetu errendimenduan. Baina % 99an ez duzu biderik! Zerbait funtzionatzen saiatzen ari zara eta prozesuan zer den garrantzitsua asmatzen duzu. Ezin duzu inoiz aldez aurretik jakin pieza honek perfektua izan behar duela, beraz, egia esan, denetan perfektua izan behar duzu. Baina hau ezinezkoa da eta ez duzu egiten. Beti dago gauza asko konpontzeko, eta hori guztiz normala da.
Nola egin refactoring handi bat
Andrew: Nola lan egiten duzu emanaldi batean? Hau zeharkako arazoa da. Adibidez, lehendik dauden funtzionalitate askoren elkargunetik sortzen diren arazoak landu behar izan al dituzu inoiz?
Itsaslabarra: Saihesten saiatzen naiz. Badakit errendimendua arazo bat izango dela, pentsatzen dut kodetzen hasi aurretik, batez ere datu egiturekin. Baina askotan hori guztia beranduago deskubritzen duzu. Eta gero muturreko neurrietara joan eta nik "idatzi eta konkistatu" deitzen dudana egin behar duzu: nahikoa pieza handi bat hartu behar duzu. Kode batzuk berridatzi beharko dira, errendimendu-arazoengatik edo beste zerbaitengatik. Kodea berridazteko arrazoia edozein dela ere, ia beti hobe da pieza handiago bat berridaztea pieza txikiago bat baino. Momentu honetan, denak beldurrez dardarka hasten dira: "Ene Jainkoa, ezin duzu hainbeste kode ukitu!" Baina, egia esan, ikuspegi honek ia beti askoz hobeto funtzionatzen du. Berehala arazo handi bat hartu behar duzu, haren inguruan zirkulu handi bat marraztu eta esan: zirkulu barruan dagoen guztia berridatziko dut. Ertza ordezkatu behar den barruan dagoen edukia baino askoz txikiagoa da. Eta mugen mugaketa horrek barruko lana primeran egiteko aukera ematen badizu, eskuak aske dituzu, egin nahi duzuna. Arazoa ulertu ondoren, berridazketa prozesua askoz errazagoa da, beraz, mokadu handi bat!
Aldi berean, berridazketa handi bat egiten duzunean eta errendimendua arazo bat izango dela konturatzen zarenean, berehala has zaitezke horretaz kezkatzen. Hau normalean gauza sinple bihurtzen da "ez kopiatu datuak, kudeatu datuak ahalik eta errazen, egin txikiak". Berridazketa handietan, errendimendua hobetzeko modu estandarrak daude. Eta ia beti datuen inguruan ibiltzen dira.
Kostu eredua
Andrew: Podcastetako batean produktibitatearen testuinguruan kostu ereduei buruz hitz egin zenuen. Azal al dezakezu zer esan nahi duzun honekin?
Itsaslabarra: Zalantzarik gabe. Prozesadorearen errendimendua oso garrantzitsua zen garai batean jaio nintzen. Eta aro hau berriro itzultzen da - patua ez da ironiarik gabea. Zortzi biteko makinen garaian hasi nintzen bizitzen; nire lehen ordenagailuak 256 byterekin funtzionatzen zuen. Zehazki byte. Dena oso txikia zen. Argibideak zenbatu behar ziren, eta programazio-lengoaiaren pilara igotzen hasi ginen heinean, lengoaiek gero eta gehiago hartzen zuten. Assembler zegoen, ondoren Basic, gero C eta C-k xehetasun asko zaindu zituen, hala nola erregistroen esleipena eta instrukzioen hautaketa. Baina dena nahiko argi zegoen han, eta aldagai baten instantzia baten erakuslea egiten banuen, orduan karga lortuko nuke, eta instrukzio honen kostua ezagutzen da. Hardwareak makina-ziklo kopuru jakin bat sortzen du, beraz, gauza ezberdinen exekuzio-abiadura kalkulatu daiteke exekutatzen ari zaren argibide guztiak batuz besterik gabe. Konparazio/proba/adar/dei/karga/denda bakoitza gehitu liteke eta esan liteke: hori da zuretzat exekuzio denbora. Errendimendua hobetzen lan egitean, zalantzarik gabe, erreparatuko diozu zer zenbaki dagozkion ziklo bero txikiei.
Baina Java, Python eta antzeko gauzetara aldatu bezain laster, oso azkar aldentzen zara behe-mailako hardwaretik. Zein da Javan getter bati deitzeak? HotSpot-en JIT zuzena bada , kargatuko da, baina hau egin ez badu, funtzio dei bat izango da. Deia begizta bero batean dagoenez, begizta horretako gainerako optimizazio guztiak baliogabetuko ditu. Beraz, benetako kostua askoz handiagoa izango da. Eta berehala galtzen duzu kode zati bati begiratzeko gaitasuna eta ulertzen exekutatu beharko genukeela prozesadorearen erlojuaren abiadurari, memoriari eta erabilitako cacheari dagokionez. Hori guztia interesgarri bihurtzen da benetan emanaldian sartzen bazara.
Orain hamarkada batean prozesadorearen abiadura ia handitu ez den egoera batean aurkitzen gara. Garai zaharrak itzuli dira! Jada ezin duzu fidatu hari bakarreko errendimendu onarekin. Baina bat-batean konputazio paraleloan sartzen bazara, izugarri zaila da, denek James Bond bezala begiratzen zaituzte. Hemen hamar aldiz azelerazioa gertatu ohi da norbaitek zerbait nahastu duen lekuetan. Aldiberekotasunak lan handia eskatzen du. XNUMX aldiz bizkortze hori lortzeko, kostu eredua ulertu behar duzu. Zer eta zenbat balio du? Eta horretarako, mihia azpiko hardwarean nola egokitzen den ulertu behar duzu.
Martin Thompsonek hitz bikaina aukeratu zuen bere blogerako ! Hardwareak zer egingo duen ulertu behar duzu, nola egingo duen zehazki eta zergatik egiten duen lehenik. Hau erabiliz, nahiko erraza da instrukzioak zenbatzen eta exekuzio-denbora nora doan jakitea. Formazio egokia ez baduzu, katu beltz baten bila zabiltza gela ilun batean. Errendimendua optimizatzen ari den jendea ikusten dut denbora guztian, zer demontre egiten ari diren ideiarik ez dutenak. Asko sufritzen dute eta ez dute aurrerapen handirik ematen. Eta kode bera hartzen dudanean, hack txiki pare bat sartu eta bost edo hamar aldiz bizkortzea lortzen dudanean, honelakoak dira: tira, hori ez da bidezkoa, jada bagenekien hobea zinela. Harrigarria. Zertaz ari naiz... kostu-eredua zer nolako kodea idazten duzun eta batez beste zein azkar exekutatzen den irudi orokorrean datza.
Andrew: Eta nola gorde dezakezu halako bolumen bat buruan? Esperientzia gehiagorekin lortzen da hori, edo? Nondik dator horrelako esperientzia?
Itsaslabarra: Tira, ez nuen nire esperientzia modurik errazenean lortu. Asanbladan programatu nuen instrukzio bakoitza uler zenituen garaian. Ergelkeria dirudi, baina harrezkero Z80 instrukzio multzoa beti geratu zait buruan, oroimenean. Ez ditut gogoan jendearen izenak hitz egin eta minutu batean, baina duela 40 urte idatzitako kodea gogoratzen dut. Dibertigarria da, sindrome bat dirudi"'.
Behe-mailako optimizazio prestakuntza
Andrew: Ba al dago modu errazagoa sartzeko?
Itsaslabarra: Bai eta ez. Denok erabiltzen dugun hardwarea ez da horrenbeste aldatu denborarekin. Denek x86 erabiltzen dute, Arm telefonoak izan ezik. Hardcore integrazio motaren bat egiten ez baduzu, gauza bera egiten ari zara. Ados, hurrengoa. Argibideak ere ez dira aldatu mendeetan zehar. Batzarrean zerbait idatzi behar duzu. Ez asko, baina ulertzen hasteko nahikoa. Irribarre egiten ari zara, baina guztiz serio ari naiz. Hizkuntzaren eta hardwarearen arteko korrespondentzia ulertu behar duzu. Horren ondoren, pixka bat idatzi eta jostailu-konpilatzaile txiki bat egin behar duzu jostailu-hizkuntza txiki baterako. Jostailu-antzekoak esan nahi du arrazoizko denbora-tarte batean egin behar dela. Oso erraza izan daiteke, baina argibideak sortu behar ditu. Instrukzio bat sortzeak denek idazten duten goi-mailako kodearen eta hardwarean exekutatzen den makina-kodearen arteko zubiaren kostu-eredua ulertzen lagunduko dizu. Korrespondentzia hori garunean erreko da konpilatzailea idazten den unean. Nahiz eta konpilatzaile errazena. Horren ostean, Java-ra eta bere amildegi semantikoa askoz sakonagoa dela aztertzen has zaitezke, eta askoz zailagoa da haren gainean zubiak eraikitzea. Javan, askoz zailagoa da ulertzea gure zubia ona edo txarra izan den, zerk erortzea eragingo duen eta zer ez. Baina abiapuntu moduko bat behar duzu kodea begiratu eta ulertzen duzun: "bai, getter hau aldi bakoitzean sartu behar da". Eta orduan gertatzen da batzuetan hori gertatzen dela, metodoa handiegia bihurtzen den egoera izan ezik, eta JIT dena sartzen hasten da. Halako lekuen errendimendua berehala aurreikus daiteke. Normalean getter-ek ondo funtzionatzen dute, baina gero begizta bero handiei erreparatzen diezu eta konturatzen zara hor inguruan funtzio-dei batzuk flotatzen ari direla, zer egiten ari diren ez dakitenak. Hau da getter-en erabilera hedatuaren arazoa, inlinea ez egotearen arrazoia getter diren ala ez ez dagoela argi. Kode-oinarri oso txikia baduzu, gogoratu eta gero esan dezakezu: hau getter bat da, eta hau setter bat da. Kode-oinarri handi batean, funtzio bakoitzak bere historia bizi du, eta hori, oro har, inork ez du ezagutzen. Profilatzaileak dio denboraren %24 galdu dugula begizta batzuetan eta begizta hori zertan ari den ulertzeko, barruko funtzio bakoitza aztertu behar dugu. Ezinezkoa da hori ulertzea funtzioa aztertu gabe, eta horrek ulermen-prozesua larri moteltzen du. Horregatik ez dut getter eta setter erabiltzen, maila berri batera iritsi naiz!
Non lortu kostu eredua? Tira, zerbait irakur dezakezu, noski... Baina nik uste dut modurik onena jokatzea dela. Konpiladore txiki bat egitea izango da kostu eredua ulertzeko eta zure buruan egokitzeko modurik onena. Mikrouhin-labea programatzeko egokia litzatekeen konpilatzaile txiki bat hasiberrientzako zeregina da. Beno, esan nahi dut, dagoeneko programazio gaitasunak badituzu, nahikoa izan beharko litzateke. Gauza hauek guztiak adierazpen aljebraiko moduko bat bezala duzun kate bat analizatzea, eragiketa matematikoetarako instrukzioak hortik ordena egokian ateratzea, erregistroetatik balio zuzenak hartzea - ββhori guztia aldi berean egiten da. Eta egiten duzun bitartean, zure garunean inprimatuta egongo da. Uste dut denek dakiela konpilatzaile batek zer egiten duen. Eta horrek kostu eredua ulertuko du.
Errendimendua hobetzeko adibide praktikoak
Andrew: Zer gehiagori erreparatu behar zaio produktibitatea lantzerakoan?
Itsaslabarra: Datuen egiturak. Bide batez, bai, aspaldi ez ditut klase hauek ematen... . Dibertigarria izan zen, baina esfortzu handia eskatzen zuen, eta bizitza ere badut! ADOS. Beraz, klase handi eta interesgarrietako batean, βNora doa zure errendimenduaβ, adibide bat jarri nien ikasleei: CSV fitxategi batetik bi gigabyte eta erdi fintech datu irakurri ziren eta ondoren saldutako produktu kopurua kalkulatu behar izan zuten. . Tiken merkatuaren ohiko datuak. 70eko hamarkadatik testu formatura bihurtutako UDP paketeak. Chicago Mercantile Exchange - gurina, artoa, soja eta horrelakoak bezalako gauza guztiak. Produktu horiek, transakzio kopurua, funtsen eta ondasunen batez besteko mugimenduaren bolumena, etab. Merkataritza-matematika nahiko erraza da: aurkitu produktuaren kodea (hash taulan 1-2 karaktere dira), lortu zenbatekoa, gehitu merkataritza-multzo batean, gehitu bolumena, gehitu balioa eta beste gauza pare bat. Matematika oso sinplea. Jostailuen ezarpena oso erraza izan zen: dena fitxategi batean dago, fitxategia irakurri eta hortik mugitzen naiz, banakako erregistroak Java kateetan banatuz, horietan beharrezkoak diren gauzak bilatu eta goian deskribatutako matematikaren arabera batu. Eta abiadura baxuan funtzionatzen du.
Planteamendu honekin, nabaria da zer gertatzen ari den, eta konputazio paraleloak ez du lagunduko, ezta? Bihurtzen da errendimenduaren bost aldiz handitzea datu-egitura egokiak aukeratuz besterik gabe lor daitekeela. Eta honek esperientziadun programatzaileak ere harritzen ditu! Nire kasuan, trikimailua zen ez duzula memoria-esleipenik egin behar begizta bero batean. Beno, hau ez da egia osoa, baina, oro har, ez zenuke nabarmendu behar "X-en behin" X nahikoa handia denean. X bi gigabyte eta erdikoa denean, ez zenuke ezer esleitu behar "letra bakoitzeko", edo "lerro bakoitzeko behin", edo "eremu bakoitzeko behin", horrelakorik. Hor pasatzen da denbora. Nola funtzionatzen du honek ere? Imajinatu ni dei bat egiten String.split() edo BufferedReader.readLine(). Readline saretik etorritako byte multzo batetik kate bat egiten du, lerro bakoitzeko behin, ehunka milioi lerro bakoitzeko. Lerro hau hartu, analizatu eta bota egiten dut. Zergatik botatzen dut - tira, dagoeneko prozesatu dut, hori da guztia. Beraz, 2.7G hauetatik irakurritako byte bakoitzeko, bi karaktere idatziko dira lerroan, hau da, dagoeneko 5.4G, eta ez ditut ezer gehiagorako behar, beraz, bota egiten dira. Memoriaren banda-zabalerari erreparatuz gero, prozesadorean memoria eta memoria-busetik igarotzen den 2.7G kargatzen dugu, eta gero bi aldiz gehiago bidaltzen da memorian dagoen lerrora, eta hori guztia apurtzen da lerro berri bakoitza sortzen denean. Baina irakurri behar dut, hardwareak irakurtzen du, nahiz eta gero dena urratuta egon. Eta idatzi egin behar dut lerro bat sortu dudalako eta cacheak beteta daudelako - cacheak ezin du 2.7G-ra egokitu. Beraz, irakurtzen dudan byte bakoitzeko, bi byte gehiago irakurtzen ditut eta bi byte gehiago idazten ditut, eta azkenean 4:1 erlazioa dute; proportzio honetan memoria banda zabalera alferrik galtzen ari gara. Eta gero hori egiten badut String.split() β Ez da hau egiten dudan azken aldia, baliteke barruan beste 6-7 eremu egon daitezkeela. Beraz, CSV irakurtzeko eta gero kateak analizatzeko kode klasikoak 14:1 inguruko memoria-banda zabalera alferrik galtzea eragiten du benetan eduki nahiko zenukeenarekiko. Hautapen hauek botatzen badituzu, bost aldiz bizkortzea lor dezakezu.
Eta ez da hain zaila. Kodea angelu egokitik begiratuz gero, dena nahiko sinplea bihurtzen da arazoaz konturatzen zarenean. Ez zenuke memoria esleitzeari erabat utzi behar: arazo bakarra zerbait esleitu eta berehala hiltzen dela da, eta bidean baliabide garrantzitsu bat erretzen duela, hau da, kasu honetan, memoriaren banda zabalera. Eta horrek guztiak produktibitatearen jaitsiera dakar. x86-n normalean prozesadorearen zikloak aktiboki erre behar dituzu, baina hemen askoz lehenago erre zenituen memoria guztia. Irtenbidea isurketa-kopurua murriztea da.
Arazoaren beste zatia zera da: profilera exekutatzen baduzu memoria marra agortzen denean, gertatzen den unean, normalean cachea itzultzeko zain zaude, sortu berri duzun zaborrez beteta dagoelako, lerro horiek guztiak. Hori dela eta, karga edo biltegiko eragiketa bakoitza motel bihurtzen da, cache hutsak eragiten baititu - cache osoa moteldu egin da, zaborra noiz utziko zain. Hori dela eta, profiler-ak ausazko zarata epela erakutsiko du begizta osoan zehar zikinduta; ez da inolako instrukzio berorik edo lekurik egongo kodean. Zarata bakarrik. Eta GC zikloei erreparatuz gero, Belaunaldi Gazteak eta oso azkarrak dira - mikrosegundoak edo milisegundoak gehienez. Azken finean, oroimen hori guztia berehala hiltzen da. Mila milioi gigabyte esleitzen dituzu, eta berak moztu, eta moztu, eta berriro moztu. Hau guztia oso azkar gertatzen da. Ematen du GC ziklo merkeak daudela, zarata beroa ziklo osoan zehar, baina 5 aldiz bizkortzea lortu nahi dugu. Momentu honetan, zerbait itxi beharko litzateke zure buruan eta soinua: "zergatik da hau?!" Memoria-zerrenda gainezkatzea ez da arazte klasikoan bistaratzen; hardwarearen errendimenduaren kontagailuaren arazketa exekutatu eta zuk zeuk eta zuzenean ikusi behar duzu. Baina hori ezin da zuzenean susmatu hiru sintoma hauetatik. Hirugarren sintoma azpimarratzen duzunari begiratzen diozunean da, profilatzaileari galdetu eta hark erantzuten dio: "Mila milioi errenkada egin zenituen, baina GCk doan funtzionatu zuen". Hori gertatu bezain laster, konturatzen zara objektu gehiegi sortu eta memoriaren bide osoa erre duzula. Hori asmatzeko modu bat dago, baina ez da agerikoa.
Arazoa datu-egituran dago: gertatzen den guztiaren azpian dagoen egitura biluzia, handiegia da, 2.7G-koa da diskoan, beraz, gauza honen kopia bat egitea oso desiragarria da - sareko byte-bufferetik berehala kargatu nahi duzu. erregistroetan sartu, lerroan atzera eta aurrera bost aldiz ez irakurtzeko-idazteko. Zoritxarrez, Javak ez dizu halako liburutegirik ematen JDK-aren zati gisa lehenespenez. Baina hau hutsala da, ezta? Funtsean, 5-10 kode-lerro dira, zure buffer-eko kate-kargatzailea ezartzeko erabiliko direnak, kate klasearen portaera errepikatzen duena, azpiko byte-buffer-aren bilgarri gisa. Ondorioz, ia kateekin bezala lan egiten ari zarela ematen du, baina, egia esan, buffer-erakusleak hor mugitzen ari dira, eta byte gordinak ez dira inon kopiatzen, eta horrela buffer berdinak behin eta berriro berrerabiltzen dira, eta sistema eragilea pozik dago diseinatuta dauden gauzak bere gain hartzen dituelako, hala nola byte-buffer hauen ezkutuko buffer bikoitza, eta jada ez zara alferrikako datu-korronte amaigabean artezketa egiten ari. Bide batez, ulertzen al duzu GCrekin lan egiten duzunean, memoria-esleipen bakoitza azken GC zikloaren ondoren prozesadoreak ikusgai ez izatea bermatuta dagoela? Hori dela eta, hori guztia ezin daiteke cachean egon, eta orduan % 100ean bermatutako hutsegite bat gertatzen da. Erakusle batekin lan egiten denean, x86-n, erregistro bat memoriatik kentzeak 1-2 erloju-ziklo behar ditu, eta hori gertatu bezain laster, ordaindu, ordaindu, ordaindu, memoria guztia piztuta dagoelako. β eta hau memoria esleitzearen kostua da. Balio erreala.
Beste era batera esanda, datuen egiturak dira aldatzeko zailena. Eta gerora errendimendua hilko duen datu-egitura oker bat aukeratu duzula konturatzen zarenean, normalean lan asko dago egiteko, baina ez baduzu, gauzak okerrera egingo dute. Lehenik eta behin, datu-egiturei buruz pentsatu behar duzu, hau garrantzitsua da. Hemen kostu nagusia datu-egitur gantzetan dago, "X datu-egitura Y datu-egituran kopiatu dut Y-ren forma hobeto gustatzen zaidalako" estiloan erabiltzen hasi direnak. Baina kopia eragiketak (merkea dirudiena) benetan memoria-banda zabalera xahutzen du eta hor lurperatzen da alferrik galtzen den exekuzio denbora guztia. JSON kate erraldoi bat badut eta POJOen DOM zuhaitz egituratu batean bihurtu nahi badut edo zerbait, kate hori analizatu eta POJO eraikitzeko eragiketak, eta gero POJOra berriro atzitzeak, alferrikako kostua izango du. ez merkea. POJOen inguruan ibiltzen bazara soka baten inguruan baino askoz maizago ibiltzen bazara izan ezik. Eskuz kanpo, katea deszifratzen eta hortik behar duzuna bakarrik ateratzen saia zaitezke, inongo POJO bihurtu gabe. Hau guztia errendimendu maximoa behar den bide batean gertatzen bada, POJOrik ez zuretzat, nolabait zuzen-zuzenean sartu behar duzu lerroan.
Zergatik sortu zure programazio-lengoaia
Andrew: Esan duzu kostu eredua ulertzeko, zure hizkuntza txikia idatzi behar duzula...
Itsaslabarra: Ez hizkuntza bat, konpilatzailea baizik. Hizkuntza bat eta konpilatzailea bi gauza ezberdin dira. Desberdintasun garrantzitsuena zure buruan dago.
Andrew: Bide batez, nik dakidala, zure hizkuntzak sortzen esperimentatzen ari zara. Zertarako?
Itsaslabarra: Ahal dudalako! Erdi erretiratuta nago, beraz, hau da nire zaletasuna. Besteen hizkuntzak inplementatzen aritu naiz bizitza osoan. Nire kodeketa estiloa ere asko landu nuen. Eta beste hizkuntzetan arazoak ikusten ditudalako ere bai. Gauza ezagunak egiteko modu hobeak daudela ikusten dut. Eta erabiliko nituzke. Nazkatuta nago arazoak neure baitan ikusteaz, Javan, Pythonen, beste edozein hizkuntzatan. Orain React Native, JavaScript eta Elm-en idazten dut erretiroa ez den zaletasun gisa, lan aktiboari buruzkoa baizik. Python-en ere idazten dut eta, ziurrenik, Java backendetarako ikaskuntza automatikoan lanean jarraituko dut. Hizkuntza ezagun asko daude eta guztiek ezaugarri interesgarriak dituzte. Bakoitza bere erara ona da eta ezaugarri horiek guztiak bateratzen saia zaitezke. Beraz, interesatzen zaizkidan gauzak aztertzen ari naiz, hizkuntzaren jokabidea, zentzuzko semantika asmatu nahian. Eta orain arte lortzen ari naiz! Momentu honetan memoriaren semantikarekin borrokan ari naiz, C eta Javan bezala izan nahi dudalako, eta memoria eredu sendoa eta memoria semantika karga eta biltegietarako. Aldi berean, inferentzia mota automatikoa izan Haskell-en bezala. Hemen, Haskell motako inferentzia nahasten saiatzen ari naiz memoria lanarekin C eta Javan. Hau da azken 2-3 hilabete hauetan egiten ari naizena, adibidez.
Andrew: Beste hizkuntzetatik alderdi hobeak hartzen dituen hizkuntza eraikitzen baduzu, uste duzu norbaitek kontrakoa egingo duela: zure ideiak hartu eta erabili?
Itsaslabarra: Honela agertzen dira hizkuntza berriak! Zergatik da Java C-ren antzekoa? C-k denek ulertzen zuten sintaxi ona zuelako eta Java sintaxi horretan inspiratu zelako, motaren segurtasuna, array-en mugak egiaztatzea, GC gehituz, eta C-tik gauza batzuk ere hobetu zituzten. Bereak gehitu zituzten. Baina asko inspiratu ziren, ezta? Guztiak zure aurretik etorri ziren erraldoien sorbaldetan daude, horrela egiten da aurrera.
Andrew: Nik ulertzen dudanez, zure hizkuntza memoria segurua izango da. Pentsatu al duzu Rust-en maileguan egiaztatzailea bezalako zerbait ezartzea? Begiratu al diozu, zer iruditzen zaizu?
Itsaslabarra: Beno, aspalditik nabil C idazten, mallok eta dohainik guzti honekin, eta bizitza osoa eskuz kudeatzen. Badakizu, eskuz kontrolatutako bizitzaren % 90-95ak egitura bera du. Eta oso-oso mingarria da eskuz egitea. Nahi nuke konpilatzaileak zer gertatzen ari den eta zure ekintzekin zer lortu duzun esatea besterik gabe. Zenbait gauzatarako, maileguan egiaztatzaileak hau kutxatik kanpo egiten du. Eta automatikoki informazioa bistaratu beharko luke, dena ulertu eta ulermen hori aurkezteaz ere ez nau zamatu. Gutxienez ihes-analisi lokala egin behar du, eta huts egiten badu bakarrik, orduan bizitza-denbora deskribatuko duten motako oharpenak gehitu behar ditu, eta eskema hori mailegu-zuzentzaile bat baino askoz konplexuagoa da, edo, hain zuzen ere, lehendik dagoen memoria-zuzentzaile bat baino. "Dena ondo dago" eta "Ez dut ezer ulertzen" artean aukeratzea - ββez, zerbait hobea izan behar da.
Beraz, C-n kode asko idatzi duen pertsona gisa, uste dut bizitza osorako kontrol automatikoaren euskarria izatea dela garrantzitsuena. Nazkatuta nago Javak memoria zenbat erabiltzen duen eta kexa nagusia GC da. Javan memoria esleitzen duzunean, ez duzu berreskuratuko azken GC zikloan lokala zen memoria. Ez da hori gertatzen memoria kudeaketa zehatzagoa duten hizkuntzetan. Malloc-i deitzen badiozu, berehala lortuko duzu erabili berri zen memoria. Normalean memoriarekin aldi baterako gauza batzuk egiten dituzu eta berehala itzultzen dituzu. Eta berehala itzultzen da malloc igerilekura, eta hurrengo malloc zikloak berriro ateratzen du. Hori dela eta, benetako memoriaren erabilera une jakin bateko objektu bizidunen multzora murrizten da, gehi ihesak. Eta dena ez bada modu guztiz indezentean filtratzen, memoria gehiena cacheetan eta prozesadorean amaitzen da, eta azkar funtzionatzen du. Baina eskuzko memoria-kudeaketa asko eskatzen du malloc-ekin eta doan deitu ordena egokian, leku egokian. Herdoilak modu egokian kudeatu dezake bere kabuz eta, kasu askotan, are errendimendu hobea ematen du, memoria-kontsumoa uneko konputaziora murrizten baita, memoria askatzeko hurrengo GC zikloaren zain egotearen aurrean. Ondorioz, errendimendua hobetzeko modu oso interesgarria lortu dugu. Eta nahiko indartsua - esan nahi dut, Fintech-erako datuak prozesatzen ditudanean horrelako gauzak egin nituen, eta horrek bost aldiz inguruko bizkortzea ahalbidetu zidan. Hori nahiko bultzada handia da, batez ere prozesadoreak azkarragoak ez diren eta hobekuntzaren zain gauden mundu honetan.
Errendimenduko ingeniari karrera
Andrew: Orokorrean lanbideei buruz ere galdetu nahiko nuke. HotSpot-en egindako JIT lanarekin protagonismoa lortu zenuen eta, ondoren, Azulera joan zinen, hau ere JVM enpresa bat dena. Baina jada gehiago ari ginen lanean hardwarean softwarean baino. Eta, bat-batean, Big Data eta Machine Learningera aldatu ziren, eta gero iruzurra detektatzeko. Nola gertatu da hau? Garapen eremu oso desberdinak dira.
Itsaslabarra: Denbora dezente daramat programatzen eta klase ezberdin asko hartzea lortu dut. Eta jendeak esaten duenean: βoh, zu zara Javarako JIT egin duzuna!β, beti da barregarria. Baina hori baino lehen, PostScript-en klon batean ari nintzen lanean, Applek garai batean bere laser inprimagailuetarako erabiltzen zuen hizkuntzan. Eta aurretik Forth hizkuntzaren inplementazio bat egin nuen. Niretzat ohiko gaia tresnaren garapena dela uste dut. Bizitza osoan besteek beren programa politak idazteko tresnak egiten aritu naiz. Baina sistema eragileak, kontrolatzaileak, kernel-mailako araztaileak, OS garapenerako hizkuntzak garatzen ere parte hartu nuen, hutsala hasi zen, baina denborarekin gero eta konplexuagoa bihurtu zen. Baina gai nagusia tresnen garapena da oraindik. Nire bizitzaren zati handi bat Azul eta Sun artean igaro zen, eta Javari buruzkoa zen. Baina Big Data eta Machine Learning-ean sartu nintzenean, nire txano dotorea berriro jarri eta esan nuen: "Oh, orain arazo ez-huts bat dugu, eta gauza interesgarri asko gertatzen ari dira eta jendea gauzak egiten". Hau garapen bide bikaina da.
Bai, asko gustatzen zait informatika banatua. Nire lehen lana C ikasle gisa izan zen, publizitate proiektu batean. Hau Zilog Z80 txipetan banatu zen OCR analogikorako datuak biltzen zituena, benetako analizatzaile analogiko batek ekoitzitakoa. Gai polita eta guztiz eroa zen. Baina arazoak zeuden, zatiren bat ez zen behar bezala ezagutzen, beraz, argazki bat atera eta jada begiekin irakurri eta esaten zuena jakinarazi zezakeen pertsona bati erakutsi behar zenion, eta, beraz, datuekin lanpostuak zeuden, eta lan hauek. bere hizkuntza zuten. Hori guztia prozesatzen zuen backend bat zegoen - Z80s paraleloan exekutatzen ziren vt100 terminalekin exekutatzen ziren - pertsona bakoitzeko bat, eta Z80n programazio eredu paralelo bat zegoen. Z80 guztiek izar konfigurazio batean partekatzen duten memoria zati komun bat; Atzeko planoa ere partekatu zen, eta RAMaren erdia sarearen barruan partekatzen zen, eta beste erdia pribatua zen edo beste zerbaitetara joaten zen. Banatutako sistema paralelo eta konplexu esanguratsu bat, partekatutako... erdi partekatutako memoria duena. Noiz izan zen hau... Ez dut gogoratzen ere egin, nonbait 80ko hamarkadaren erdialdean. Aspaldi dezente.
Bai, demagun 30 urte duela dezente dela. Informatika banatuarekin lotutako arazoak aspaldidanik existitzen dira; jendea aspalditik dago gerran. -klusterrak. Horrelako klusterrek itxura dute... Adibidez: Ethernet dago eta zure x86 azkarra Ethernet honetara konektatuta dago, eta orain memoria partekatu faltsua lortu nahi duzu, orduan inork ezin zuelako informatika banatutako kodeketa egin, oso zaila zen eta, beraz, ez zegoen. partekatutako memoria faltsua zen x86-n babes-memoria-orriekin, eta orri honetara idatzi bazenuen, beste prozesadoreei esan genien partekatutako memoria bera sartzen badute, zugandik kargatu beharko litzatekeela, eta, beraz, laguntzarako protokolo baten antzeko zerbait. cache koherentzia agertu zen eta horretarako softwarea. Kontzeptu interesgarria. Benetako arazoa, noski, beste zerbait zen. Horrek guztiak funtzionatu zuen, baina azkar lortu zenituen errendimendu-arazoak, inork ez baitzituen ulertzen errendimendu-ereduak nahikoa maila onean - zer memoria-sarbide-eredu zeuden, nola ziurtatu nodoek elkarri ping etengabe egiten ez zutela, etab.
H2O-n asmatu dudana da garatzaileek beraiek direla paralelismoa non ezkutatzen den eta non ez den zehazteaz arduratzen direnak. Errendimendu handiko kodea idaztea erraz eta erraz egiten zuen kodeketa-eredu bat asmatu nuen. Baina exekutatzen den kodea motela idaztea zaila da, itxura txarra izango du. Kode motela idazten serio saiatu behar duzu, metodo ez-estandarrak erabili beharko dituzu. Balazta-kodea lehen begiratuan ikusten da. Ondorioz, normalean azkar exekutatzen den kodea idazten duzu, baina memoria partekatuaren kasuan zer egin behar duzun asmatu behar duzu. Hori guztia matrize handiei lotuta dago eta hango portaera Java paraleloan dauden array handi ez-hegazkorraren antzekoa da. Esan nahi dut, imajinatu bi hari matrize paralelo batean idazten dutela, horietako batek irabazten duela, eta besteak, horren arabera, galtzen duela, eta ez dakizu zein den zein den. Lurrunkorrak ez badira, ordena nahi duzuna izan daiteke eta honek oso ondo funtzionatzen du. Jendeari oso axola zaio eragiketen ordena, lurrunkorrak leku egokietan jartzen ditu eta memoriarekin lotutako errendimendu arazoak leku egokietan espero ditu. Bestela, 1-tik N-ra arteko begiztetan kodea idatziko lukete, non N bilioi batzuk diren, kasu konplexu guztiak automatikoki paralelo bihurtuko direlakoan, eta ez du funtzionatzen. Baina H2O-n hau ez da Java ez Scala; nahi izanez gero, "Java minus minus" har dezakezu. Oso programazio estilo argia da eta C edo Java kode sinpleak begizta eta arrayekin idaztearen antzekoa da. Baina, aldi berean, memoria terabytetan prozesatu daiteke. H2O erabiltzen dut oraindik. Noizean behin erabiltzen dut proiektu ezberdinetan, eta oraindik ere gauzarik azkarrena da, lehiakideek baino dozenaka aldiz azkarragoa. Big Data zutabe-datuekin egiten ari bazara, oso zaila da H2O gainditzea.
Erronka teknikoak
Andrew: Zein izan da zure ibilbide osoan zure erronkarik handiena?
Itsaslabarra: Gaiaren atal teknikoa edo ez-teknikoa eztabaidatzen ari gara? Erronka handienak ez direla teknikoak esango nuke.
Erronka teknikoei dagokienez. Besterik gabe, garaitu ditut. Ez dakit zein zen handiena, baina bazeuden nahiko interesgarriak, denbora dezente behar zutenak, buruko borroka. Sunera joan nintzenean, ziur nengoen konpilatzaile azkar bat egingo nuela, eta adineko mordo batek erantzunez esan zuen ez nuela inoiz lortuko. Baina bide hau jarraitu nuen, konpiladore bat idatzi nuen erregistro-esleitzailean, eta nahiko azkarra izan zen. C1 modernoa bezain azkarra zen, baina esleitzailea askoz motelagoa zen orduan, eta atzera begira datuen egitura arazo handia zen. Erregistro esleitzaile grafiko bat idazteko behar nuen eta ez nuen ulertzen kodearen adierazkortasunaren eta abiaduraren arteko dilema, garai hartan zegoen eta oso garrantzitsua zena. Datu-egiturak normalean garai hartako x86s-en cache-tamaina gainditzen duela, eta, beraz, hasiera batean erregistro-esleitzaileak jitter denbora osoaren ehuneko 5-10 funtzionatuko zuela suposatzen banuen, orduan errealitatean izan zen. ehuneko 50.
Denborak aurrera egin ahala, konpilatzailea garbiagoa eta eraginkorragoa bihurtu zen, kode ikaragarria sortzeari utzi zion kasu gehiagotan, eta errendimendua gero eta gehiago hasi zen C konpiladore batek sortzen duenaren antza hartzen. Jakina, C-k ere bizkortzen ez dituen txorakeriak idatzi ezean. . C bezalako kodea idazten baduzu, C bezalako errendimendua lortuko duzu kasu gehiagotan. Eta zenbat eta urrunago joan, orduan eta maizago lortzen zenuen asintotikoki C mailarekin bat zetorren kodea, erregistro-esleitzailea zerbait osatua dirudi... zure kodea azkar ala motel dabilen kontuan hartu gabe. Esleitzailean lanean jarraitu nuen aukeraketa hobeak egiteko. Gero eta motelagoa zen, baina gero eta errendimendu hobea ematen zuen beste inork aurre egin ezin zuen kasuetan. Erregistro esleitzaile batean murgildu, hilabeteko lana bertan lurperatu eta bat-batean kode osoa %5 azkarrago exekutatzen hasiko zen. Hau behin eta berriz gertatu zen eta erregistro-esleitzailea artelan bat bihurtu zen - denek maite zuten edo gorrotatu zuten, eta akademiako jendeak galderak egin zituen "zergatik egiten da dena horrela", zergatik ez. , eta zein da aldea. Erantzuna berdina da oraindik: grafikoen kolorean oinarritutako esleitzaile bat eta buffer kodearekin oso lan zaindua garaipenaren arma baten parekoa da, inork garaitu ezin duen konbinazio onena. Eta hori ez da agerikoa den gauza bat. Konpilatzaileak bertan egiten duen beste guztia aski ongi aztertutako gauzak dira, nahiz eta arte mailara eraman diren. Konpilatzailea artelan bihurtu behar zuten gauzak egiten nituen beti. Baina hau ez zen ezer apartekoa izan, erregistro esleitzailea izan ezik. Kontuz ibiltzea da trikimailua kargapean eta, hori gertatzen bada (zehatzago azaldu dezaket interesa izanez gero), horrek esan nahi du modu oldarkorragoan sar zaitezkeela, errendimendu-egutegian kinka bat erortzeko arriskurik gabe. Garai haietan, eskala osoko konpilatzaile mordoa zeuden, baubles eta txistuekin zintzilik, erregistro-esleitzaileak zituztenak, baina beste inork ezin zuen egin.
Arazoa da inlining-aren menpe dauden metodoak gehitzen badituzu, inlining eremua handituz eta handituz, erabilitako balioen multzoak berehala gainditzen du erregistro kopurua eta moztu egin behar dituzu. Maila kritikoa normalean esleitzaileak amore ematen duenean etortzen da, eta isuri baterako hautagai on batek beste bat balio du, oro har basatiak salduko dituzu. Hemen sartzearen balioa gainkostuen zati bat galtzen duzula da, deitzeagatik eta gordetzeagatik, barneko balioak ikus ditzakezu eta gehiago optimiza ditzakezu. Inlinearen kostua zuzeneko balio kopuru handia sortzen dela da, eta zure erregistro-esleitzailea behar baino gehiago erretzen bada, berehala galtzen duzu. Hori dela eta, esleitzaile gehienek arazo bat dute: inlining-ak marra jakin bat zeharkatzen duenean, munduko guztia murrizten hasten da eta produktibitatea komunera bota daiteke. Konpilatzailea inplementatzen dutenek heuristiko batzuk gehitzen dituzte: adibidez, inlining-a gelditzea, tamaina nahiko handi batekin hasita, esleipenek dena hondatuko baitute. Horrela sortzen da errendimendu grafikoan kink bat - zu lerroan, lerroan, errendimendua poliki-poliki hazten da - eta gero boom! β jack bizkor bat bezala erortzen da, gehiegi lerrokatu duzulako. Horrela funtzionatu zuen dena Javaren etorrera baino lehen. Java-k askoz ere inlining gehiago behar du, beraz, nire esleitzailea askoz oldarkorragoa egin behar izan dut, huts egin beharrean berdindu dadin, eta gehiegi sartzen bazara, isuri egiten hasten da, baina gero "ez isuri gehiago" momentua iristen da. Behaketa interesgarria da eta ezerezetik etorri zait, ez da agerikoa, baina ondo ordaindu du. Inlining oldarkorra hartu nuen eta Java eta C performanceak elkarren ondoan lan egiten duten lekuetara eraman ninduen. Oso hurbil daude - C kodea eta horrelako gauzak baino askoz azkarragoa den Java kodea idatz dezaket, baina, batez beste, gauzen irudi handian, gutxi gorabehera konparagarriak dira. Uste dut meritu horren zati bat erregistroaren esleitzailea dela, eta horrek ahal bezain ergelen sartzeko aukera ematen dit. Ikusten dudan guztia lerrokatzen dut. Hemen galdera da esleitzaileak ondo funtzionatzen duen, emaitza modu adimentsuan funtzionatzen duen kodea ote den. Erronka handia zen hau: hau guztia ulertzea eta funtzionatzea.
Erregistroen esleipenari eta nukleo anitzei buruz apur bat
Vladimir: Erregistroen esleipena bezalako arazoek betiko gai moduko bat dirudite. Galdetzen diot ea inoiz egon ote den itxaropentsua zirudien eta gero praktikan huts egin zuen ideiarik?
Itsaslabarra: Noski! Erregistroaren esleipena NP-konpleta arazo bat konpontzeko heuristika batzuk aurkitzen saiatzen zaren eremu bat da. Eta ezin duzu inoiz irtenbide perfekturik lortu, ezta? Hau besterik gabe ezinezkoa da. Begira, Ahead of Time bildumak ere gaizki funtzionatzen du. Hemengo elkarrizketa bataz besteko kasu batzuei buruzkoa da. Errendimendu tipikoari buruz, errendimendu tipiko ona dela uste duzun zerbait neurtu dezakezu, azken finean, hori hobetzeko lanean ari zara! Erregistratu esleipena errendimenduari buruzko gaia da. Behin lehenengo prototipoa edukita, behar dena funtzionatu eta margotzen du, performance lanak hasten dira. Ondo neurtzen ikasi behar duzu. Zergatik da garrantzitsua? Datu argiak badituzu, arlo desberdinak begiratu eta ikusi: bai, hemen lagundu du, baina hor hautsi da dena! Ideia on batzuk sortzen dira, heuristiko berriak gehitzen dituzu eta bat-batean dena apur bat hobeto hasten da funtzionatzen batez beste. Edo ez da hasten. Kasu pila bat izan nituen, non gure garapena aurreko esleitzailetik bereizten zuen ehuneko bosteko errendimenduaren alde borrokatzen ari ginen. Eta itxura den bakoitzean: nonbait irabazi, nonbait galtzen. Errendimendua aztertzeko tresna onak badituzu, galtzen diren ideiak aurki ditzakezu eta zergatik huts egiten duten ulertu. Agian merezi du dena bere horretan uzteak, edo beharbada doikuntzarako ikuspegi serioago bat hartzea, edo kalera atera eta beste zerbait konpontzea. Gauza pila bat da! Hack zoragarri hau egin nuen, baina hau ere behar dut, eta hau eta hau, eta haien konbinazio osoak hobekuntza batzuk ematen ditu. Eta bakartiek huts egin dezakete. Hau da errendimendu-lanaren izaera NP-complete arazoetan.
Vladimir: Esleitzaileetan margotzea bezalako gauzak dagoeneko konponduta dagoen arazoa direla sentitzen du. Tira, zuretzat erabakita dago, esaten ari zarenaren arabera, beraz, merezi al du orduan...
Itsaslabarra: Ez da horrela konpontzen. Zu zara "konpondu" bihurtu behar duzuna. Arazo zailak daude eta konpondu egin behar dira. Hori eginda, produktibitatea lantzeko garaia da. Horren arabera ekin behar diozu lan honi: erreferentziak egin, neurketak bildu, aurreko bertsiora itzultzean zure hack zaharra berriro funtzionatzen hasi zenean (edo alderantziz gelditu zen) egoerak azaldu. Eta ez etsi zerbait lortu arte. Esan bezala, funtzionatu ez duten ideia politak badaude, baina ideien erregistroen esleipenaren arloan gutxi gorabehera amaigabea da. Esaterako, argitalpen zientifikoak irakur ditzakezu. Nahiz eta orain eremu hau askoz astiroago mugitzen hasi eta gaztetan baino argiago geratu den. Hala ere, ezin konta ahala jende dago alor honetan lanean eta euren ideia guztiek probatzea merezi dute, guztiak zain daude hegaletan. Eta ezin duzu esan zein onak diren probatu ezean. Zein ondo integratzen diren zure esleitzaileko beste guztiarekin, esleitzaile batek gauza asko egiten dituelako eta ideia batzuk ez dira funtzionatuko zure esleitzaile zehatz batean, baina beste esleitzaile batean erraz egingo dute. Esleitzailearentzat irabazteko modu nagusia gauza motelak bide nagusitik kanpo ateratzea eta bide motelen mugetan zatitzera behartzea da. Beraz, GC bat exekutatu nahi baduzu, hartu bide motela, desoptimizatu, bota salbuespen bat, gauza horiek guztiak - badakizu gauza hauek nahiko arraroak direla. Eta oso arraroak dira, egiaztatu nuen. Lan gehigarria egiten duzu eta bide motel hauetan murrizketa asko kentzen ditu, baina ez du axola motelak eta gutxitan ibiltzen direlako. Adibidez, erakusle nulu bat - ez da inoiz gertatzen, ezta? Gauza ezberdinetarako hainbat bide izan behar dituzu, baina ez dute nagusiarekin oztopatu behar.
Vladimir: Zer iruditzen zaizu multinukleoei buruz, aldi berean milaka nukleo daudenean? Hau gauza erabilgarria al da?
Itsaslabarra: GPUren arrakastak nahiko erabilgarria dela erakusten du!
Vladimir: Nahiko espezializatuak dira. Zer gertatzen da helburu orokorreko prozesadoreekin?
Itsaslabarra: Tira, hori zen Azulen negozio eredua. Erantzuna jendeak errendimendu aurreikusgarria benetan maite zuen garai batean itzuli zen. Kode paraleloa idaztea zaila zen orduan. H2O kodetze eredua oso eskalagarria da, baina ez da helburu orokorreko eredua. Agian, GPU bat erabiltzean baino apur bat orokorragoa. Horrelako gauza bat garatzearen konplexutasunaz edo erabiltzearen konplexuaz ari al gara? Adibidez, Azulek ikasgai interesgarri bat eman zidan, agerikoa ez dena: cache txikiak normalak dira.
Bizitzako erronkarik handiena
Vladimir: Eta erronka ez-teknikoak?
Itsaslabarra: Erronka handiena ez izatea zen... jendearekin jatorra eta atsegina. Eta ondorioz, etengabe aurkitzen nintzen egoera gatazkatsuetan. Gauzak gaizki zihoazela banekienak, baina ez nekien arazo haiekin aurrera nola egin eta ezin izan nituen kudeatu. Epe luzerako arazo asko, hamarkadetan irauten zutenak, horrela sortu ziren. Javak C1 eta C2 konpiladoreak izatea horren ondorio zuzena da. Hamar urtez jarraian Javan maila anitzeko konpilaziorik egon ez izana ere ondorio zuzena da. Bistakoa da halako sistema bat behar genuela, baina ez da agerikoa zergatik ez zen existitzen. Arazoak izan nituen ingeniari batekin... edo ingeniari talde batekin. Garai batean, Eguzkitan lanean hasi nintzenean,... Ados, ez orduan bakarrik, orokorrean beti daukat nire iritzia guztiaren inguruan. Eta uste nuen egia zela zure egia hau hartu eta buru-belarri kontatu dezakezula. Batez ere arrazoi harrigarria nuen gehienetan. Eta planteamendu hau gustatzen ez bazaizu... batez ere, jakina, oker zaudela eta zentzugabekeriak egiten badituzu... Orokorrean, jende gutxik onartuko luke komunikazio modu hau. Batzuk ahal izan arren, ni bezala. Nire bizitza osoa printzipio meritokratikoetan eraiki dut. Zerbait gaizki erakusten badidazu, berehala itzuliko naiz eta esango dut: zentzugabekeria esan duzu. Aldi berean, noski, barkamena eskatzen dizut eta hori guztia, merezimenduak kontuan hartuko ditut, halakorik balego, eta bestelako ekintza zuzenak hartuko ditut. Bestalde, arrazoi izugarria dut denbora osoaren portzentaje izugarri handi bati buruz. Eta ez da oso ondo funtzionatzen jendearekin harremanetan. Ez naiz atsegina izaten saiatzen, baina galdera zuzen egiten ari naiz. "Honek ez du inoiz funtzionatuko, bat, bi eta hiru delako". Eta esan zuten: "Oh!" Beste ondorio batzuk izan ziren ziurrenik alde batera uzteko hobeak zirenak: adibidez, nire emaztearekin dibortziatu eta handik hamar urteko depresioa ekarri zutenak.
Erronka jendearekin borroka bat da, zer egin dezakezun ala ezin duzuenaren pertzepzioarekin, zer den garrantzitsua eta zer ez. Kodetze estiloari buruzko erronka asko zeuden. Oraindik kode asko idazten dut, eta garai haietan moteldu ere egin behar izan nuen, zeregin paralelo gehiegi egiten eta gaizki egiten nituelako, batean zentratu beharrean. Atzera begira, Java JIT komandoaren kodearen erdia idatzi nuen, C2 komandoa. Hurrengo kodetzaile azkarrenak erdi motel idatzi zuen, hurrengoak erdi motel, eta beherakada esponentziala izan zen. Ilara honetako zazpigarren pertsona oso-oso motela izan zen - hori beti gertatzen da! Kode asko ukitu nituen. Zeinek idatzi zuen begiratu nion, salbuespenik gabe, haien kodeari so egin nion, bakoitzari errepasoa eman eta, hala ere, neronek baino gehiago idazten jarraitu nuen. Ikuspegi honek ez du oso ondo funtzionatzen jendearekin. Batzuei ez zaie hau gustatzen. Eta hori kudeatu ezin dutenean, era guztietako kexak hasten dira. Esaterako, behin esan zidaten kodetzeari uzteko, kode gehiegi idazten ari nintzelako eta taldea arriskuan jartzen ari nintzelako, eta dena txantxa bat iruditu zitzaidan: lagun, gainerako taldea desagertzen bada eta nik kodea idazten jarraitzen badut, zuk Talde erdiak bakarrik galduko ditugu. Bestalde, kodea idazten jarraitzen badut eta talde erdia galtzen baduzu, hori oso kudeaketa txarra dirudi. Inoiz ez nuen benetan horretaz pentsatu, ez nuen sekula horretaz hitz egin, baina oraindik nire buruan zegoen nonbait. Pentsamenduak bueltaka ari zitzaizkidan buruan: "Denok txantxetan ari al zarete?" Beraz, arazo handiena ni eta jendearekin nuen harremana izan zen. Orain askoz hobeto ulertzen dut nire burua, denbora luzez programatzaileen taldeko buru izan nintzen, eta orain jendeari zuzenean esaten diot: badakizu, ni naizena naiz, eta nirekin egin beharko duzu aurre - ondo dago zutik banaiz. hemen? Eta horri aurre egiten hasi zirenean, denak funtzionatu zuen. Izan ere, ez naiz ez txarra ez ona, ez dut asmo txarrik edo asmo berekoirik, nire esentzia besterik ez da, eta horrekin bizi behar dut nolabait.
Andrew: Duela gutxi denak barnekoentzako autokontzientziaz eta, oro har, gaitasun bigunez hitz egiten hasi ziren. Zer esan dezakezu honetaz?
Itsaslabarra: Bai, hori izan zen nire emaztearekin dibortziotik ikasi nuen ikuspegia eta ikasgaia. Dibortziotik ikasi nuena nire burua ulertzea izan zen. Horrela hasi nintzen beste jendea ulertzen. Interakzio honek nola funtzionatzen duen ulertzea. Honek aurkikuntzak bata bestearen atzetik ekarri zituen. Ni nor naizen eta zer ordezkatzen dudanaren kontzientzia zegoen. Zer egiten ari naiz: edo zereginarekin arduratuta nago, edo gatazkak saihesten ari naiz, edo beste zerbait - eta autokontzientzia maila horrek benetan laguntzen du neure burua kontrolpean izaten. Horren ondoren dena askoz errazagoa da. Neure baitan ez ezik, beste programatzaile batzuengan ere aurkitu dudan gauza bat estres emozional batean zaudenean pentsamenduak hitzez adierazteko ezintasuna da. Adibidez, hor eserita zaude kodetzen, fluxu-egoeran, eta gero korrika etortzen dira zuregana eta garrasi egiten hasten dira histerikan zerbait hautsita dagoela eta orain muturreko neurriak hartuko direla zure aurka. Eta ezin duzu hitzik esan estres emozional batean zaudelako. Lortutako ezagutzak une honetarako prestatzeko, bizirauteko eta erretiro-plan batera pasatzeko aukera ematen dizu, ondoren zerbait egin dezakezu. Beraz, bai, dena nola funtzionatzen duen konturatzen hasten zarenean, bizitza aldatzen duen gertaera izugarria da.
Nik neuk ez nituen hitz egokiak aurkitu, baina ekintzen segida gogoratu nuen. Kontua da erreakzio hori ahozkoa bezain fisikoa dela, eta espazioa behar duzula. Halako espazioa, Zen zentzuan. Horixe da zehatz-mehatz azaldu behar dena, eta gero berehala alde batera utzi - fisikoki bakarrik aldendu. Ahoz isilik geratzen naizenean, egoera emozionalki prozesatu dezaket. Adrenalina burmuinera iristen den heinean, borroka edo hegaldi modura aldatzen zaitu, ezin duzu ezer esan, ez - orain idiota zara, ingeniari azotatzailea, erantzun duin bat emateko edo erasoa geldiarazteko gai ez zara, eta erasotzailea aske da. behin eta berriro erasotzeko. Lehenik eta behin berriro zeure burua bihurtu behar duzu, kontrola berreskuratu, "borroka edo hegaldi" modutik atera.
Eta horretarako hitzezko espazioa behar dugu. Espazio librea besterik ez. Zerbait esaten baduzu, orduan zehatz-mehatz hori esan dezakezu, eta gero joan eta benetan "espazioa" aurkitzeko: joan parkean paseatzera, dutxan giltzapetu - berdin dio. Gauza nagusia egoera horretatik aldi baterako deskonektatzea da. Gutxienez segundo batzuk itzali bezain pronto, kontrola itzultzen da, soil pentsatzen hasten zara. "Ongi da, ez naiz ergel moduko bat, ez dut ergelkeriarik egiten, nahiko pertsona erabilgarria naiz". Zure burua konbentzitzeko gai izan ondoren, hurrengo fasera pasatzeko garaia da: gertatutakoa ulertzea. Erasoa egin zintuzten, erasoa espero ez zenuen lekutik etorri zen, segada petrala eta zital bat izan zen. Hau txarra da. Hurrengo urratsa erasotzaileak hau zergatik behar zuen ulertzea da. Benetan, zergatik? Agian bera haserre dagoelako? Zergatik dago erotuta? Adibidez, bere burua izorratu duelako eta ezin duelako erantzukizunik onartu? Hau da egoera osoa arretaz kudeatzeko modua. Baina horrek maniobrarako tartea eskatzen du, hitzezko espazioa. Lehen urratsa hitzezko kontaktua haustea da. Saihestu hitzekin eztabaida. Utzi, alde egin ahalik eta azkarren. Telefono-elkarrizketa bat bada, zintzilikatu besterik ez - nire emazte ohiarekin komunikatzean ikasi nuen trebetasuna da. Elkarrizketa ez bada inon ondo ateratzen, esan "agur" eta zintzilikatu. Telefonoaren bestaldetik: βbla bla blaβ, erantzun duzu: βbai, agur!β. eta zintzilikatu. Elkarrizketa amaitu besterik ez duzu. Bost minutu geroago, zentzuz pentsatzeko gaitasuna itzultzen zaizunean, pixka bat hoztu zara, dena, gertatutakoa eta gero gertatuko dena pentsatzea posible egiten da. Eta hasi erantzun pentsakor bat formulatzen, emozioz erreakzionatu beharrean. Niretzat, autokontzientzian aurrerapena izan zen, hain zuzen ere, estres emozionalaren kasuan ezin dudala hitz egin. Egoera horretatik ateratzea, arazoak nola erantzun eta konpentsatu pentsatu eta planifikatzea - ββpauso egokiak dira hitz egin ezin duzun kasuan. Modurik errazena estres emozionala agertzen den egoeratik ihes egitea eta estres horretan parte hartzeari uztea da. Horren ondoren pentsatzeko gai bihurtzen zara, pentsa dezakezunean, hitz egiteko gai bihurtzen zara, etab.
Bide batez, epaitegian, aurkako abokatua hau egiten saiatzen da - orain argi dago zergatik. Zure izena ahoskatu ere ezin duzulako egoera batera zapaltzeko gaitasuna duelako, adibidez. Oso zentzu errealean, ezin izango duzu hitz egin. Hau gertatzen bazaizu, eta badakizu zure burua ahozko borrokak astintzen diren leku batean aurkituko zarela, auzitegia bezalako leku batean, orduan zure abokatuarekin etor zaitezke. Abokatua zure alde egingo du eta hitzezko erasoa geldituko da, eta modu guztiz legezkoan egingo du, eta galdutako Zen espazioa itzuliko zaizu. Esaterako, nire familiari deitu behar izan nion pare bat aldiz, epailea nahiko adeitsua zen honen inguruan, baina kontrako abokatuak garrasi eta oihu egin zidan, ezin nuen hitz bat ere egin ertzean. Kasu hauetan, bitartekari bat erabiltzeak funtzionatzen du onena. Bitartekariak etengabeko korronte batean isurtzen ari zaizun presio hori geldiarazten du, beharrezko Zen espazioa aurkitzen duzu, eta horrekin hitz egiteko gaitasuna itzultzen da. Ezagutza-esparru oso bat da, zeinetan asko dago ikasteko, asko deskubritu zure baitan, eta hori guztia pertsona ezberdinentzat desberdinak diren goi mailako erabaki estrategikoetan bihurtzen da. Pertsona batzuek ez dituzte goian azaldutako arazoak; normalean, salmenta profesionalak diren pertsonek ez dituzte. Hitzekin bizimodua egiten duten pertsona guzti hauek -kantari ospetsuak, poetak, buruzagi erlijiosoak eta politikariak- beti dute zer esanik. Ez dute halako arazorik, baina nik bai.
Andrew: Ezustekoa izan zen. Primeran, dagoeneko asko hitz egin dugu eta elkarrizketa hau bukatzeko garaia da. Zalantzarik gabe, biltzarrean elkartuko gara eta elkarrizketa honekin jarraitu ahal izango dugu. Hydran ikusiko gara!
Cliff-ekin hizketan jarrai dezakezu Hydra 2019 konferentzian, 11ko uztailaren 12tik 2019ra San Petersburgon ospatuko dena. Txosten batekin etorriko da . Sarrerak eros daitezke .
Iturria: www.habr.com