Cliff Cliff — CTO o Cratus (synwyryddion IoT ar gyfer gwella prosesau), sylfaenydd a chyd-sylfaenydd nifer o fusnesau newydd (gan gynnwys Rocket Realtime School, Neurensic a H2O.ai) gyda sawl allanfa lwyddiannus. Ysgrifennodd Cliff ei gasglwr cyntaf yn 15 oed (Pascal ar gyfer y TRS Z-80)! Mae'n fwyaf adnabyddus am ei waith ar C2 yn Java (the Sea of ​​Nodes IR). Dangosodd y casglwr hwn i'r byd y gallai JIT gynhyrchu cod o ansawdd uchel, a oedd yn un o'r ffactorau yn ymddangosiad Java fel un o'r prif lwyfannau meddalwedd modern. Yna helpodd Cliff Azul Systems i adeiladu prif ffrâm 864-craidd gyda meddalwedd Java pur a oedd yn cefnogi seibiannau GC ar domen 500-gigabeit o fewn 10 milieiliad. Yn gyffredinol, llwyddodd Cliff i weithio ar bob agwedd ar y JVM.

 
Mae'r habrapost hwn yn gyfweliad gwych gyda Cliff. Byddwn yn siarad ar y pynciau canlynol:

• Pontio i optimeiddiadau lefel isel
• Sut i wneud ailffactorio mawr
• Model cost
• Hyfforddiant optimeiddio lefel isel
• Enghreifftiau ymarferol o wella perfformiad
• Pam creu eich iaith raglennu eich hun
• Gyrfa Peiriannydd Perfformiad
• Heriau Technegol
• Ychydig am ddyrannu cofrestrau ac aml-greiddiau
• Yr her fwyaf mewn bywyd

Cynhelir y cyfweliad gan:

• Andrey Satarin gan Amazon Web Services. Yn ei yrfa, llwyddodd i weithio mewn prosiectau hollol wahanol: profodd gronfa ddata ddosbarthedig NewSQL yn Yandex, system canfod cwmwl yn Kaspersky Lab, gêm aml-chwaraewr yn Mail.ru a gwasanaeth ar gyfer cyfrifo prisiau cyfnewid tramor yn Deutsche Bank. Diddordeb mewn profi systemau backend a gwasgaredig ar raddfa fawr.
• Vladimir Sitnikov oddi wrth Netcracker. Deng mlynedd o waith ar berfformiad a scalability NetCracker OS, meddalwedd a ddefnyddir gan weithredwyr telathrebu i awtomeiddio prosesau rheoli offer rhwydwaith a rhwydwaith. Diddordeb mewn materion perfformiad Java a Chronfa Ddata Oracle. Awdur mwy na dwsin o welliannau perfformiad yn yrrwr swyddogol PostgreSQL JDBC.

Pontio i optimeiddiadau lefel isel

Andrew: Rydych chi'n enw mawr ym myd llunio JIT, Java, a gwaith perfformio yn gyffredinol, iawn? 

Clogwyn: Mae fel yna!

Andrew: Gadewch i ni ddechrau gyda rhai cwestiynau cyffredinol am waith perfformio. Beth ydych chi'n ei feddwl am y dewis rhwng optimeiddiadau lefel uchel a lefel isel fel gweithio ar lefel CPU?

Clogwyn: Ydy, mae popeth yn syml yma. Y cod cyflymaf yw'r un nad yw byth yn rhedeg. Felly, mae angen i chi bob amser ddechrau o lefel uchel, gweithio ar algorithmau. Bydd gwell O nodiant yn curo nodiant O gwaeth, oni bai fod rhai cysonion digon mawr yn ymyrryd. Mae pethau lefel isel yn mynd ddiwethaf. Yn nodweddiadol, os ydych chi wedi optimeiddio gweddill eich pentwr yn ddigon da a bod rhai pethau diddorol ar ôl o hyd, mae hynny'n lefel isel. Ond sut i ddechrau o lefel uchel? Sut ydych chi'n gwybod bod digon o waith lefel uchel wedi'i wneud? Wel... dim ffordd. Nid oes unrhyw ryseitiau parod. Mae angen i chi ddeall y broblem, penderfynu beth rydych chi'n mynd i'w wneud (er mwyn peidio â chymryd camau diangen yn y dyfodol) ac yna gallwch chi ddadorchuddio'r proffiliwr, a all ddweud rhywbeth defnyddiol. Ar ryw adeg, rydych chi'ch hun yn sylweddoli eich bod chi wedi cael gwared ar bethau diangen ac mae'n bryd gwneud rhywfaint o fireinio lefel isel. Mae hyn yn bendant yn fath arbennig o gelf. Mae yna lawer o bobl yn gwneud pethau diangen, ond yn symud mor gyflym fel nad oes ganddyn nhw amser i boeni am gynhyrchiant. Ond dyma nes i'r cwestiwn godi'n blwmp ac yn blaen. Fel arfer 99% o'r amser does neb yn malio beth dwi'n ei wneud, tan yr eiliad pan ddaw peth pwysig ymlaen ar y llwybr tyngedfennol nad oes neb yn malio amdano. Ac yma mae pawb yn dechrau swnian arnoch chi ynglŷn â “pam na weithiodd yn berffaith o’r cychwyn cyntaf.” Yn gyffredinol, mae rhywbeth i'w wella bob amser mewn perfformiad. Ond 99% o'r amser nid oes gennych unrhyw arweiniad! Rydych chi'n ceisio gwneud i rywbeth weithio ac yn y broses rydych chi'n darganfod beth sy'n bwysig. Ni allwch byth wybod ymlaen llaw bod angen i'r darn hwn fod yn berffaith, felly, mewn gwirionedd, mae'n rhaid i chi fod yn berffaith ym mhopeth. Ond mae hyn yn amhosibl ac nid ydych chi'n ei wneud. Mae yna bob amser lawer o bethau i'w trwsio - ac mae hynny'n gwbl normal.

Sut i wneud ailffactorio mawr

Andrew: Sut ydych chi'n gweithio ar berfformiad? Mae hon yn broblem drawsbynciol. Er enghraifft, a ydych chi erioed wedi gorfod gweithio ar broblemau sy'n deillio o groestoriad llawer o swyddogaethau presennol?

Clogwyn: ceisiaf ei osgoi. Os gwn y bydd perfformiad yn broblem, meddyliaf am y peth cyn i mi ddechrau codio, yn enwedig gyda strwythurau data. Ond yn aml rydych chi'n darganfod hyn i gyd yn nes ymlaen. Ac yna mae'n rhaid i chi fynd i fesurau eithafol a gwneud yr hyn rydw i'n ei alw'n “ailysgrifennu a gorchfygu”: mae angen cydio mewn darn digon mawr. Bydd yn rhaid ailysgrifennu peth o'r cod o hyd oherwydd problemau perfformiad neu rywbeth arall. Beth bynnag yw'r rheswm dros ailysgrifennu cod, mae bron bob amser yn well ailysgrifennu darn mwy na darn llai. Ar hyn o bryd, mae pawb yn dechrau crynu ag ofn: “O fy Nuw, ni allwch gyffwrdd â chymaint o god!” Ond mewn gwirionedd, mae'r dull hwn bron bob amser yn gweithio'n llawer gwell. Mae angen i chi ymgymryd â phroblem fawr ar unwaith, tynnu cylch mawr o'i chwmpas a dweud: Byddaf yn ailysgrifennu popeth y tu mewn i'r cylch. Mae'r ffin yn llawer llai na'r cynnwys y tu mewn iddo y mae angen ei ddisodli. Ac os yw ffiniau o'r fath yn caniatáu ichi wneud y gwaith y tu mewn yn berffaith, mae'ch dwylo'n rhydd, gwnewch yr hyn rydych chi ei eisiau. Unwaith y byddwch chi'n deall y broblem, mae'r broses ailysgrifennu yn llawer haws, felly cymerwch damaid mawr!
Ar yr un pryd, pan fyddwch chi'n ailysgrifennu'n fawr ac yn sylweddoli bod perfformiad yn mynd i fod yn broblem, gallwch chi ddechrau poeni amdano ar unwaith. Mae hyn fel arfer yn troi’n bethau syml fel “peidiwch â chopïo data, rheoli data mor syml â phosibl, gwnewch bethau bach.” Mewn ailysgrifennu mawr, mae yna ffyrdd safonol o wella perfformiad. Ac maen nhw bron bob amser yn troi o gwmpas data.

Model cost

Andrew: Yn un o'r podlediadau buoch yn sôn am fodelau cost yng nghyd-destun cynhyrchiant. Allwch chi egluro beth oeddech chi'n ei olygu wrth hyn?

Clogwyn: Yn sicr. Cefais fy ngeni mewn cyfnod pan oedd perfformiad prosesydd yn hynod bwysig. Ac mae'r cyfnod hwn yn dychwelyd eto - nid yw tynged heb eironi. Dechreuais fyw yn nyddiau peiriannau wyth did; roedd fy nghyfrifiadur cyntaf yn gweithio gyda 256 beit. Yn union beit. Roedd popeth yn fach iawn. Roedd yn rhaid cyfri cyfarwyddiadau, ac wrth i ni ddechrau symud i fyny'r stac iaith rhaglennu, roedd yr ieithoedd yn cymryd mwy a mwy. Roedd Assembler, yna Basic, yna C, ac C yn gofalu am lawer o'r manylion, fel dyrannu cofrestr a dewis cyfarwyddiadau. Ond roedd popeth yn eithaf clir yno, a phe bawn yn cyfeirio at enghraifft o newidyn, yna byddwn yn cael llwyth, ac mae cost y cyfarwyddyd hwn yn hysbys. Mae'r caledwedd yn cynhyrchu nifer benodol o gylchoedd peiriant, felly gellir cyfrifo cyflymder gweithredu gwahanol bethau yn syml trwy adio'r holl gyfarwyddiadau rydych chi'n mynd i'w rhedeg. Gellid adio pob cymhariaeth/prawf/cangen/galwad/llwyth/storfa a dweud: dyna'r amser gweithredu i chi. Wrth weithio ar wella perfformiad, byddwch yn bendant yn talu sylw i ba niferoedd sy'n cyfateb i gylchoedd poeth bach. 
Ond cyn gynted ag y byddwch chi'n newid i Java, Python a phethau tebyg, byddwch chi'n symud i ffwrdd yn gyflym iawn o galedwedd lefel isel. Beth yw cost galw derbyniwr yn Java? Os yw JIT yn HotSpot yn gywir leiniog, bydd yn llwytho, ond os na wnaeth hyn, bydd yn alwad swyddogaeth. Gan fod yr alwad ar ddolen boeth, bydd yn diystyru'r holl optimeiddiadau eraill yn y ddolen honno. Felly, bydd y gost wirioneddol yn llawer uwch. A byddwch yn colli'r gallu ar unwaith i edrych ar ddarn o god a deall y dylem ei weithredu o ran cyflymder cloc prosesydd, cof a storfa a ddefnyddir. Mae hyn i gyd yn dod yn ddiddorol dim ond os ydych chi wir yn mynd i mewn i'r perfformiad.
Nawr rydyn ni'n cael ein hunain mewn sefyllfa lle nad yw cyflymder proseswyr prin wedi cynyddu ers degawd. Mae'r hen ddyddiau yn ôl! Ni allwch ddibynnu ar berfformiad un edau da mwyach. Ond os byddwch chi'n mynd i mewn i gyfrifiadura cyfochrog yn sydyn, mae'n anhygoel o anodd, mae pawb yn edrych arnoch chi fel James Bond. Mae cyflymiadau deg gwaith yma fel arfer yn digwydd mewn mannau lle mae rhywun wedi gwneud llanast o rywbeth. Mae arian cyfred yn gofyn am lawer o waith. I gael y cyflymder XNUMXx hwnnw, mae angen i chi ddeall y model cost. Beth a faint mae'n ei gostio? Ac i wneud hyn, mae angen i chi ddeall sut mae'r tafod yn ffitio ar y caledwedd sylfaenol.
Dewisodd Martin Thompson air gwych ar gyfer ei flog Cydymdeimlad Mecanyddol! Mae angen i chi ddeall beth mae'r caledwedd yn mynd i'w wneud, sut yn union y bydd yn ei wneud, a pham ei fod yn gwneud yr hyn y mae'n ei wneud yn y lle cyntaf. Gan ddefnyddio hyn, mae'n weddol hawdd dechrau cyfrif cyfarwyddiadau a darganfod i ble mae'r amser gweithredu yn mynd. Os nad oes gennych yr hyfforddiant priodol, rydych chi'n chwilio am gath ddu mewn ystafell dywyll. Rwy'n gweld pobl yn optimeiddio perfformiad drwy'r amser sydd heb unrhyw syniad beth maen nhw'n ei wneud. Maent yn dioddef llawer ac nid ydynt yn gwneud llawer o gynnydd. A phan fyddaf yn cymryd yr un darn o god, llithro mewn cwpl o haciau bach a chael cyflymiad pum neu ddeg gwaith, maen nhw fel: wel, nid yw hynny'n deg, roeddem eisoes yn gwybod eich bod chi'n well. Rhyfeddol. Am beth ydw i'n siarad ... mae'r model cost yn ymwneud â pha fath o god rydych chi'n ei ysgrifennu a pha mor gyflym y mae'n rhedeg ar gyfartaledd yn y darlun mawr.

Andrew: A pha fodd y gellwch gadw y fath gyfrol yn eich pen ? A gyflawnir hyn gyda mwy o brofiad, neu? O ble mae profiad o'r fath yn dod?

Clogwyn: Wel, ni chefais fy mhrofiad yn y ffordd hawsaf. Fe wnes i raglennu yn y Cynulliad yn ôl yn y dyddiau pan allech chi ddeall pob cyfarwyddyd unigol. Mae'n swnio'n dwp, ond ers hynny mae'r set gyfarwyddiadau Z80 bob amser wedi aros yn fy mhen, yn fy nghof. Dydw i ddim yn cofio enwau pobl o fewn munud i siarad, ond rwy'n cofio cod a ysgrifennwyd 40 mlynedd yn ôl. Mae'n ddoniol, mae'n edrych fel syndrom "gwyddonydd idiot'.

Hyfforddiant optimeiddio lefel isel

Andrew: A oes ffordd haws o fynd i mewn?

Clogwyn: Ydw a nac ydw. Nid yw'r caledwedd rydyn ni i gyd yn ei ddefnyddio wedi newid cymaint â hynny dros amser. Mae pawb yn defnyddio x86, ac eithrio ffonau smart Arm. Os nad ydych chi'n gwneud rhyw fath o wreiddio craidd caled, rydych chi'n gwneud yr un peth. Iawn, nesaf. Nid yw'r cyfarwyddiadau ychwaith wedi newid ers canrifoedd. Mae angen ichi fynd i ysgrifennu rhywbeth yn y Cynulliad. Dim llawer, ond digon i ddechrau deall. Rydych chi'n gwenu, ond rydw i'n siarad o ddifrif. Mae angen i chi ddeall y gyfatebiaeth rhwng iaith a chaledwedd. Ar ôl hynny mae angen i chi fynd i ysgrifennu ychydig a gwneud compiler tegan bach ar gyfer iaith tegan bach. Mae tebyg i degan yn golygu bod angen ei wneud mewn cyfnod rhesymol o amser. Gall fod yn hynod syml, ond rhaid iddo gynhyrchu cyfarwyddiadau. Bydd y weithred o gynhyrchu cyfarwyddyd yn eich helpu i ddeall y model cost ar gyfer y bont rhwng y cod lefel uchel y mae pawb yn ei ysgrifennu a'r cod peiriant sy'n rhedeg ar y caledwedd. Bydd yr ohebiaeth hon yn cael ei llosgi i'r ymennydd ar yr adeg y caiff y casglwr ei ysgrifennu. Hyd yn oed y casglwr symlaf. Ar ôl hynny, gallwch chi ddechrau edrych ar Java a'r ffaith bod ei chasm semantig yn llawer dyfnach, ac mae'n llawer anoddach adeiladu pontydd drosto. Yn Java, mae'n llawer anoddach deall a drodd ein pont yn dda neu'n ddrwg, beth fydd yn achosi iddi ddisgyn a beth na fydd. Ond mae angen rhyw fath o fan cychwyn arnoch chi lle rydych chi'n edrych ar y cod ac yn deall: “ie, dylai'r cyrchwr hwn gael ei leinio bob tro.” Ac yna mae'n ymddangos bod hyn yn digwydd weithiau, ac eithrio'r sefyllfa pan fydd y dull yn mynd yn rhy fawr, ac mae'r JIT yn dechrau inlining popeth. Gellir rhagweld perfformiad lleoedd o'r fath ar unwaith. Fel arfer mae ceyrwyr yn gweithio'n dda, ond yna rydych chi'n edrych ar ddolenni poeth mawr ac yn sylweddoli bod rhai galwadau swyddogaeth yn arnofio o gwmpas yno nad ydyn nhw'n gwybod beth maen nhw'n ei wneud. Dyma'r broblem gyda'r defnydd eang o getters, y rheswm pam nad ydynt wedi'u inlinio yw nad yw'n glir a ydynt yn getter. Os oes gennych chi sylfaen cod hynod fach, gallwch chi ei gofio ac yna dweud: mae hwn yn godwr, ac mae hwn yn setter. Mewn sylfaen cod mawr, mae pob swyddogaeth yn byw ei hanes ei hun, nad yw, yn gyffredinol, yn hysbys i unrhyw un. Mae'r proffiliwr yn dweud ein bod wedi colli 24% o'r amser ar ryw ddolen ac i ddeall beth mae'r ddolen hon yn ei wneud, mae angen inni edrych ar bob swyddogaeth y tu mewn. Mae'n amhosibl deall hyn heb astudio'r swyddogaeth, ac mae hyn yn arafu'r broses ddeall yn ddifrifol. Dyna pam dwi ddim yn defnyddio getters a setters, dwi wedi cyrraedd lefel newydd!
Ble i gael y model cost? Wel, gallwch chi ddarllen rhywbeth, wrth gwrs... Ond dwi'n meddwl mai'r ffordd orau yw gweithredu. Gwneud casglwr bach fydd y ffordd orau o ddeall y model cost a'i ffitio yn eich pen eich hun. Tasg i ddechreuwr yw casglwr bach a fyddai'n addas ar gyfer rhaglennu microdon. Wel, rwy'n golygu, os oes gennych chi sgiliau rhaglennu eisoes, yna dylai hynny fod yn ddigon. Mae'r holl bethau hyn fel dosrannu llinyn sydd gennych fel rhyw fath o fynegiant algebraidd, tynnu cyfarwyddiadau ar gyfer gweithrediadau mathemategol oddi yno yn y drefn gywir, cymryd y gwerthoedd cywir o gofrestrau - gwneir hyn i gyd ar unwaith. Ac wrth i chi ei wneud, bydd yn cael ei argraffu yn eich ymennydd. Rwy'n credu bod pawb yn gwybod beth mae casglwr yn ei wneud. A bydd hyn yn rhoi dealltwriaeth o'r model cost.

Enghreifftiau ymarferol o wella perfformiad

Andrew: Beth arall y dylech chi roi sylw iddo wrth weithio ar gynhyrchiant?

Clogwyn: Strwythurau data. Gyda llaw, ydw, nid wyf wedi dysgu'r dosbarthiadau hyn ers amser maith... Ysgol Roced. Roedd yn hwyl, ond roedd angen llawer o ymdrech, ac mae gen i fywyd hefyd! IAWN. Felly, yn un o'r dosbarthiadau mawr a diddorol, “I ble mae'ch perfformiad yn mynd,” rhoddais enghraifft i fyfyrwyr: darllenwyd dau gigabeit a hanner o ddata fintech o ffeil CSV ac yna bu'n rhaid iddynt gyfrifo nifer y cynhyrchion a werthwyd. . Data marchnad ticio rheolaidd. Pecynnau CDU wedi'u trosi i fformat testun ers y 70au. Chicago Mercantile Exchange - pob math o bethau fel menyn, corn, ffa soia, pethau felly. Roedd angen cyfrif y cynhyrchion hyn, nifer y trafodion, cyfaint symud arian a nwyddau ar gyfartaledd, ac ati. Mae'n fathemateg fasnachu eithaf syml: dewch o hyd i'r cod cynnyrch (dyna 1-2 nod yn y tabl hash), cael y swm, ei ychwanegu at un o'r setiau masnach, ychwanegu cyfaint, ychwanegu gwerth, a chwpl o bethau eraill. Mathemateg syml iawn. Roedd gweithredu'r tegan yn syml iawn: mae popeth mewn ffeil, darllenais y ffeil a symudais drwyddi, gan rannu cofnodion unigol yn llinynnau Java, chwilio am y pethau angenrheidiol ynddynt a'u hadio yn ôl y fathemateg a ddisgrifir uchod. Ac mae'n gweithio ar rai cyflymder isel.

Gyda'r dull hwn, mae'n amlwg beth sy'n digwydd, ac ni fydd cyfrifiadura cyfochrog yn helpu, iawn? Mae'n ymddangos y gellir cyflawni cynnydd pum gwaith mewn perfformiad yn syml trwy ddewis y strwythurau data cywir. Ac mae hyn yn synnu rhaglenwyr profiadol hyd yn oed! Yn fy achos penodol i, y tric oedd na ddylech wneud dyraniadau cof mewn dolen boeth. Wel, nid dyma'r gwir i gyd, ond yn gyffredinol - ni ddylech amlygu “unwaith yn X” pan fydd X yn ddigon mawr. Pan fydd X yn ddau gigabeit a hanner, ni ddylech ddyrannu unrhyw beth “unwaith y llythyren”, neu “unwaith y llinell”, neu “unwaith y cae”, unrhyw beth felly. Dyma lle treulir amser. Sut mae hyn hyd yn oed yn gweithio? Dychmygwch fi'n gwneud galwad String.split() neu BufferedReader.readLine(). Readline yn gwneud llinyn o set o beit a ddaeth dros y rhwydwaith, unwaith ar gyfer pob llinell, ar gyfer pob un o'r cannoedd o filiynau o linellau. Rwy'n cymryd y llinell hon, yn ei dosrannu ac yn ei thaflu i ffwrdd. Pam ydw i'n ei daflu i ffwrdd - wel, rydw i eisoes wedi ei brosesu, dyna i gyd. Felly, ar gyfer pob beit a ddarllenir o'r 2.7G hyn, bydd dau gymeriad yn cael eu hysgrifennu yn y llinell, hynny yw, eisoes yn 5.4G, ac nid oes eu hangen arnaf am ddim pellach, felly cânt eu taflu. Os edrychwch ar y lled band cof, rydyn ni'n llwytho 2.7G sy'n mynd trwy'r cof a'r bws cof yn y prosesydd, ac yna mae dwywaith cymaint yn cael ei anfon at y llinell sy'n gorwedd yn y cof, ac mae hyn i gyd yn cael ei dwyllo pan fydd pob llinell newydd yn cael ei chreu. Ond mae angen i mi ei ddarllen, mae'r caledwedd yn ei ddarllen, hyd yn oed os yw popeth yn cael ei dwyllo'n ddiweddarach. Ac mae'n rhaid i mi ei ysgrifennu i lawr oherwydd fe wnes i greu llinell ac mae'r caches yn llawn - ni all y cache gynnwys 2.7G. Felly, am bob beit a ddarllenais, rwy'n darllen dau beit arall ac yn ysgrifennu dau beit arall, ac yn y diwedd mae ganddyn nhw gymhareb 4:1 - yn y gymhareb hon rydyn ni'n gwastraffu lled band cof. Ac yna mae'n troi allan os gwnaf String.split() – nid dyma’r tro olaf i mi wneud hyn, efallai bod 6-7 maes arall y tu mewn. Felly mae'r cod clasurol o ddarllen CSV ac yna dosrannu'r tannau yn arwain at wastraff lled band cof o tua 14:1 o'i gymharu â'r hyn yr hoffech chi ei gael mewn gwirionedd. Os byddwch chi'n taflu'r dewisiadau hyn i ffwrdd, gallwch chi gael cyflymiad pum gwaith.

Ac nid yw mor anodd â hynny. Os edrychwch ar y cod o'r ongl sgwâr, daw'r cyfan yn eithaf syml ar ôl i chi sylweddoli'r broblem. Ni ddylech roi'r gorau i ddyrannu cof yn gyfan gwbl: yr unig broblem yw eich bod chi'n dyrannu rhywbeth ac mae'n marw ar unwaith, ac ar hyd y ffordd mae'n llosgi adnodd pwysig, sef lled band cof yn yr achos hwn. Ac mae hyn i gyd yn arwain at ostyngiad mewn cynhyrchiant. Ar x86 fel arfer mae angen i chi losgi cylchoedd prosesydd yn weithredol, ond yma fe wnaethoch chi losgi'r holl gof yn llawer cynharach. Yr ateb yw lleihau faint o ollwng. 
Rhan arall y broblem yw, os ydych chi'n rhedeg y proffiliwr pan fydd y streipen gof yn dod i ben, yn union pan fydd yn digwydd, rydych chi fel arfer yn aros i'r storfa ddod yn ôl oherwydd ei fod yn llawn sbwriel rydych chi newydd ei gynhyrchu, yr holl linellau hynny. Felly, mae pob llwyth neu weithrediad storfa yn dod yn araf, oherwydd eu bod yn arwain at fethiannau cache - mae'r storfa gyfan wedi dod yn araf, gan aros i garbage ei adael. Felly, bydd y proffiliwr yn dangos sŵn cynnes ar hap wedi'i daenu trwy'r ddolen gyfan - ni fydd unrhyw gyfarwyddyd poeth ar wahân na lle yn y cod. Dim ond sŵn. Ac os edrychwch ar y cylchoedd GC, maen nhw i gyd yn Genhedlaeth Ifanc ac yn hynod gyflym - uchafswm microeiliadau neu milieiliadau. Wedi'r cyfan, mae'r holl atgof hwn yn marw ar unwaith. Rydych chi'n dyrannu biliynau o gigabeit, ac mae'n eu torri, ac yn eu torri, ac yn eu torri eto. Mae hyn i gyd yn digwydd yn gyflym iawn. Mae'n ymddangos bod cylchoedd GC rhad, sŵn cynnes ar hyd y cylch cyfan, ond rydym am gael cyflymiad 5x. Ar hyn o bryd, dylai rhywbeth gau yn eich pen a swnio: “pam hyn?!” Nid yw gorlif stribed cof yn cael ei arddangos yn y dadfygiwr clasurol; mae angen i chi redeg y dadfygiwr cownter perfformiad caledwedd a'i weld eich hun ac yn uniongyrchol. Ond ni ellir amau ​​​​hyn yn uniongyrchol o'r tri symptom hyn. Y trydydd symptom yw pan edrychwch ar yr hyn rydych chi'n ei amlygu, gofynnwch i'r proffiliwr, ac mae'n ateb: "Fe wnaethoch chi biliwn o resi, ond gweithiodd y GC am ddim." Cyn gynted ag y bydd hyn yn digwydd, rydych chi'n sylweddoli eich bod wedi creu gormod o wrthrychau ac wedi llosgi'r lôn gof gyfan. Mae yna ffordd i ddarganfod hyn, ond nid yw'n amlwg. 

Mae'r broblem yn y strwythur data: y strwythur moel sy'n sail i bopeth sy'n digwydd, mae'n rhy fawr, mae'n 2.7G ar ddisg, felly mae gwneud copi o'r peth hwn yn annymunol iawn - rydych chi am ei lwytho o glustogfa beit y rhwydwaith ar unwaith. i mewn i'r cofrestri, rhag darllen-ysgrifenu i'r llinell yn ol ac yn mlaen bum gwaith. Yn anffodus, nid yw Java yn rhoi llyfrgell o'r fath i chi fel rhan o'r JDK yn ddiofyn. Ond mae hyn yn ddibwys, iawn? Yn y bôn, mae'r rhain yn 5-10 llinell o god a fydd yn cael eu defnyddio i weithredu eich llwythwr llinyn clustogog eich hun, sy'n ailadrodd ymddygiad y dosbarth llinynnol, tra'n lapio o amgylch y byffer beit sylfaenol. O ganlyniad, mae'n ymddangos eich bod yn gweithio bron fel pe bai gyda llinynnau, ond mewn gwirionedd mae awgrymiadau at y byffer yn symud yno, ac nid yw'r bytes amrwd yn cael eu copïo yn unman, ac felly mae'r un byfferau yn cael eu hailddefnyddio dro ar ôl tro, a mae'r system weithredu'n hapus i gymryd arnoch chi'ch hun y pethau y mae wedi'u cynllunio ar eu cyfer, fel byffro dwbl cudd o'r byfferau beit hyn, ac nid ydych chi bellach yn malu trwy lif diddiwedd o ddata diangen. Gyda llaw, a ydych chi'n deall, wrth weithio gyda GC, y gellir gwarantu na fydd pob dyraniad cof yn weladwy i'r prosesydd ar ôl y cylch GC diwethaf? Felly, ni all hyn i gyd fod yn y storfa, ac yna mae methiant gwarantedig 100% yn digwydd. Wrth weithio gyda phwyntydd, ar x86, mae tynnu cofrestr o'r cof yn cymryd 1-2 gylchred cloc, a chyn gynted ag y bydd hyn yn digwydd, rydych chi'n talu, yn talu, yn talu, oherwydd bod y cof i gyd ymlaen NAw celc – a dyma gost dyrannu cof. Gwerth go iawn.

Mewn geiriau eraill, strwythurau data yw'r peth anoddaf i'w newid. Ac ar ôl i chi sylweddoli eich bod wedi dewis y strwythur data anghywir a fydd yn lladd perfformiad yn nes ymlaen, fel arfer mae llawer o waith i'w wneud, ond os na wnewch chi, bydd pethau'n gwaethygu. Yn gyntaf oll, mae angen ichi feddwl am strwythurau data, mae hyn yn bwysig. Mae’r brif gost yma yn disgyn ar strwythurau data braster, sy’n dechrau cael eu defnyddio yn arddull “Copïais strwythur data X i strwythur data Y oherwydd rwy’n hoffi siâp Y yn well.” Ond mae'r gweithrediad copi (sy'n ymddangos yn rhad) mewn gwirionedd yn gwastraffu lled band cof a dyna lle mae'r holl amser gweithredu a wastraffwyd wedi'i gladdu. Os oes gen i linyn enfawr o JSON ac rydw i eisiau ei droi'n goeden DOM strwythuredig o POJOs neu rywbeth, bydd gweithrediad dosrannu'r llinyn hwnnw ac adeiladu'r POJO, ac yna cyrchu'r POJO eto yn ddiweddarach, yn arwain at gost ddiangen - mae'n ddim yn rhad. Ac eithrio os ydych chi'n rhedeg o gwmpas POJOs yn llawer amlach nag yr ydych chi'n rhedeg o amgylch llinyn. Heb law, gallwch yn lle hynny geisio dadgryptio'r llinyn a thynnu'r hyn sydd ei angen arnoch yn unig oddi yno, heb ei droi'n unrhyw POJO. Os bydd hyn i gyd yn digwydd ar lwybr y mae angen y perfformiad mwyaf ohono, dim POJOs i chi, mae angen i chi rywsut gloddio i'r llinell yn uniongyrchol.

Pam creu eich iaith raglennu eich hun

Andrew: Dywedasoch, er mwyn deall y model cost, bod angen i chi ysgrifennu eich iaith fach eich hun ...

Clogwyn: Nid iaith, ond casglwr. Mae iaith a chasglydd yn ddau beth gwahanol. Mae'r gwahaniaeth pwysicaf yn eich pen. 

Andrew: Gyda llaw, hyd y gwn i, rydych chi'n arbrofi gyda chreu eich ieithoedd eich hun. Am beth?

Clogwyn: Achos dw i'n gallu! Rwy'n lled-ymddeol, felly dyma fy hobi. Rydw i wedi bod yn gweithredu ieithoedd pobl eraill ar hyd fy oes. Fe wnes i hefyd weithio llawer ar fy arddull codio. A hefyd oherwydd fy mod yn gweld problemau mewn ieithoedd eraill. Gwelaf fod ffyrdd gwell o wneud pethau cyfarwydd. A byddwn yn eu defnyddio. Dwi jest wedi blino gweld problemau yn fy hun, yn Java, yn Python, mewn unrhyw iaith arall. Rwyf bellach yn ysgrifennu yn React Native, JavaScript a Elm fel hobi nad yw'n ymwneud ag ymddeol, ond am waith egnïol. Rwyf hefyd yn ysgrifennu yn Python ac, yn fwyaf tebygol, byddaf yn parhau i weithio ar ddysgu peirianyddol ar gyfer backends Java. Mae yna lawer o ieithoedd poblogaidd ac mae ganddyn nhw i gyd nodweddion diddorol. Mae pawb yn dda yn eu ffordd eu hunain a gallwch geisio dod â'r holl nodweddion hyn at ei gilydd. Felly, dwi'n astudio pethau sydd o ddiddordeb i mi, ymddygiad iaith, ceisio meddwl am semanteg resymol. A hyd yn hyn dwi'n llwyddo! Ar hyn o bryd rydw i'n cael trafferth gyda semanteg cof, oherwydd rydw i eisiau ei gael fel yn C a Java, a chael model cof cryf a semanteg cof ar gyfer llwythi a storfeydd. Ar yr un pryd, cael casgliad math awtomatig fel yn Haskell. Yma, rwy'n ceisio cymysgu casgliad tebyg i Haskell â gwaith cof yn C a Java. Dyma beth rydw i wedi bod yn ei wneud am y 2-3 mis diwethaf, er enghraifft.

Andrew: Os ydych chi'n adeiladu iaith sy'n cymryd agweddau gwell o ieithoedd eraill, ydych chi'n meddwl y bydd rhywun yn gwneud y gwrthwyneb: cymerwch eich syniadau a defnyddiwch nhw?

Clogwyn: Dyma'n union sut mae ieithoedd newydd yn ymddangos! Pam mae Java yn debyg i C? Oherwydd bod gan C gystrawen dda yr oedd pawb yn ei deall ac ysbrydolwyd Java gan y gystrawen hon, gan ychwanegu diogelwch teip, gwirio ffiniau arae, GC, ac fe wnaethant hefyd wella rhai pethau o C. Fe wnaethon nhw ychwanegu rhai eu hunain. Ond cawsant eu hysbrydoli cryn dipyn, iawn? Mae pawb yn sefyll ar ysgwyddau'r cewri a ddaeth o'ch blaen - dyna sut y gwneir cynnydd.

Andrew: Yn ôl yr hyn a ddeallaf, bydd eich iaith yn gof yn ddiogel. Ydych chi wedi meddwl am weithredu rhywbeth fel gwiriwr benthyciadau gan Rust? Ydych chi wedi edrych arno, beth ydych chi'n ei feddwl ohono?

Clogwyn: Wel, rydw i wedi bod yn ysgrifennu C ers oesoedd, gyda hyn i gyd malloc ac am ddim, ac yn rheoli'r oes â llaw. Rydych chi'n gwybod, mae gan 90-95% o amser bywyd a reolir â llaw yr un strwythur. Ac mae'n boenus iawn, iawn i'w wneud â llaw. Hoffwn i'r casglwr ddweud wrthych beth sy'n digwydd yno a beth wnaethoch chi ei gyflawni gyda'ch gweithredoedd. Ar gyfer rhai pethau, mae gwiriwr benthyg yn gwneud hyn allan o'r bocs. A dylai arddangos gwybodaeth yn awtomatig, deall popeth, a pheidio â rhoi'r baich hwn arnaf hyd yn oed. Rhaid iddo wneud dadansoddiad dianc lleol o leiaf, a dim ond os bydd yn methu, yna mae angen iddo ychwanegu anodiadau math a fydd yn disgrifio oes - ac mae cynllun o'r fath yn llawer mwy cymhleth na gwiriwr benthyg, neu yn wir unrhyw wiriwr cof presennol. Mae’r dewis rhwng “popeth yn iawn” a “dwi ddim yn deall dim byd” – na, mae’n rhaid bod rhywbeth gwell. 
Felly, fel rhywun sydd wedi ysgrifennu llawer o god yn C, rwy’n meddwl mai cael cymorth ar gyfer rheolaeth oes awtomatig yw’r peth pwysicaf. Rwyf hefyd wedi cael llond bol ar faint mae Java yn defnyddio cof a'r brif gŵyn yw'r GC. Pan fyddwch yn dyrannu cof yn Java, ni fyddwch yn cael y cof a oedd yn lleol yn y cylch GC diwethaf yn ôl. Nid yw hyn yn wir mewn ieithoedd â rheolaeth cof mwy manwl gywir. Os byddwch yn ffonio malloc, byddwch yn syth yn cael y cof a oedd yn cael ei ddefnyddio fel arfer yn unig. Fel arfer rydych chi'n gwneud rhai pethau dros dro gyda'r cof ac yn ei ddychwelyd yn ôl ar unwaith. Ac mae'n dychwelyd ar unwaith i'r pwll malloc, ac mae'r cylch malloc nesaf yn ei dynnu allan eto. Felly, mae defnydd gwirioneddol o gof yn cael ei leihau i'r set o wrthrychau byw ar amser penodol, ynghyd â gollyngiadau. Ac os nad yw popeth yn gollwng mewn ffordd gwbl anweddus, mae'r rhan fwyaf o'r cof yn dod i ben mewn caches a'r prosesydd, ac mae'n gweithio'n gyflym. Ond mae angen llawer o reoli cof â llaw gyda malloc a rhad ac am ddim o'r enw yn y drefn gywir, yn y lle iawn. Gall rhwd drin hyn yn iawn ar ei ben ei hun, ac mewn llawer o achosion yn rhoi perfformiad hyd yn oed yn well, gan fod defnydd cof yn cael ei leihau i lawr i'r cyfrifiant presennol - yn hytrach nag aros am y cylch GC nesaf i ryddhau cof. O ganlyniad, cawsom ffordd ddiddorol iawn o wella perfformiad. Ac yn eithaf pwerus - dwi'n golygu, fe wnes i bethau o'r fath wrth brosesu data ar gyfer fintech, ac fe wnaeth hyn fy ngalluogi i gael cyflymiad o tua phum gwaith. Mae hynny'n hwb eithaf mawr, yn enwedig mewn byd lle nad yw proseswyr yn mynd yn gyflymach ac rydym yn dal i aros am welliannau.

Gyrfa Peiriannydd Perfformiad

Andrew: Hoffwn hefyd holi o gwmpas am yrfaoedd yn gyffredinol. Daethoch i amlygrwydd gyda'ch gwaith JIT yn HotSpot ac yna symud i Azul, sydd hefyd yn gwmni JVM. Ond roeddem eisoes yn gweithio mwy ar galedwedd na meddalwedd. Ac yna fe wnaethon nhw newid yn sydyn i Big Data a Machine Learning, ac yna i ganfod twyll. Sut digwyddodd hyn? Mae'r rhain yn feysydd datblygu gwahanol iawn.

Clogwyn: Rydw i wedi bod yn rhaglennu ers amser maith ac wedi llwyddo i gymryd llawer o ddosbarthiadau gwahanol. A phan fydd pobl yn dweud: “O, chi yw'r un wnaeth JIT i Java!”, mae bob amser yn ddoniol. Ond cyn hynny, roeddwn i'n gweithio ar glôn o PostScript - yr iaith a ddefnyddiodd Apple ar un adeg ar gyfer ei argraffwyr laser. A chyn hynny gwneuthum weithrediad o'r iaith Forth. Rwy'n meddwl mai'r thema gyffredin i mi yw datblygu offer. Ar hyd fy oes rwyf wedi bod yn gwneud offer y mae pobl eraill yn ysgrifennu eu rhaglenni cŵl â nhw. Ond roeddwn hefyd yn ymwneud â datblygu systemau gweithredu, gyrwyr, dadfygwyr lefel cnewyllyn, ieithoedd ar gyfer datblygu OS, a ddechreuodd yn ddibwys, ond daeth yn fwy a mwy cymhleth dros amser. Ond y prif bwnc o hyd yw datblygu offer. Aeth rhan fawr o fy mywyd rhwng Azul a Sun, ac roedd yn ymwneud â Java. Ond pan es i i mewn i Big Data a Machine Learning, rhoddais fy het ffansi yn ôl ymlaen a dweud, “O, nawr mae gennym ni broblem nad yw’n ddibwys, ac mae llawer o bethau diddorol yn digwydd a phobl yn gwneud pethau.” Mae hwn yn llwybr datblygu gwych i'w gymryd.

Ydw, dwi'n hoff iawn o gyfrifiadura dosranedig. Fy swydd gyntaf oedd fel myfyriwr yn C, ar brosiect hysbysebu. Dosbarthwyd hwn yn gyfrifiadura ar sglodion Zilog Z80 a gasglodd ddata ar gyfer analog OCR, a gynhyrchwyd gan ddadansoddwr analog go iawn. Roedd yn bwnc cŵl a hollol wallgof. Ond roedd problemau, ni adnabuwyd rhyw ran yn gywir, felly bu’n rhaid ichi dynnu llun a’i ddangos i berson a oedd eisoes yn gallu darllen â’i lygaid ac adrodd yr hyn a ddywedodd, ac felly roedd swyddi gyda data, a’r swyddi hyn roedd ganddynt eu hiaith eu hunain. Roedd yna gefnlen a oedd yn prosesu hyn i gyd - Z80s yn rhedeg ochr yn ochr â therfynellau vt100 yn rhedeg - un y pen, ac roedd model rhaglennu cyfochrog ar y Z80. Rhywfaint o gof cyffredin a rennir gan bob Z80s o fewn cyfluniad seren; Rhannwyd y backplane hefyd, a rhannwyd hanner yr RAM o fewn y rhwydwaith, ac roedd hanner arall yn breifat neu'n mynd i rywbeth arall. System ddosbarthedig gyfochrog ystyrlon gymhleth gyda chof a rennir... wedi'i rannu. Pryd oedd hyn... Ni allaf hyd yn oed gofio, rhywle yng nghanol yr 80au. Amser maith yn ôl. 
Ie, gadewch i ni dybio bod 30 mlynedd yn amser eithaf maith yn ôl. Mae problemau sy'n ymwneud â chyfrifiadura dosranedig wedi bodoli ers cryn amser; mae pobl wedi bod yn rhyfela ers amser maith. Beowulf-clystyrau. Mae clystyrau o'r fath yn edrych fel ... Er enghraifft: mae Ethernet ac mae eich x86 cyflym wedi'i gysylltu â'r Ethernet hwn, a nawr rydych chi am gael cof a rennir ffug, oherwydd ni allai unrhyw un wneud codio cyfrifiadura dosranedig bryd hynny, roedd yn rhy anodd ac felly yno yn gof a rennir ffug gyda thudalennau cof amddiffyn ar x86, a phe baech yn ysgrifennu at y dudalen hon, yna dywedasom wrth broseswyr eraill, os ydynt yn cyrchu'r un cof a rennir, byddai angen ei lwytho oddi wrthych, ac felly rhywbeth fel protocol ar gyfer cefnogi ymddangosodd cydlyniad cache a meddalwedd ar gyfer hyn. Cysyniad diddorol. Y broblem wirioneddol, wrth gwrs, oedd rhywbeth arall. Gweithiodd hyn i gyd, ond fe gawsoch chi broblemau perfformiad yn gyflym, oherwydd nid oedd neb yn deall y modelau perfformiad ar lefel ddigon da - pa batrymau mynediad cof oedd yno, sut i sicrhau nad oedd y nodau'n pingio'i gilydd yn ddiddiwedd, ac ati.

Yr hyn a feddyliais yn H2O yw mai'r datblygwyr eu hunain sy'n gyfrifol am benderfynu lle mae cyfochrogrwydd wedi'i guddio a lle nad yw. Lluniais fodel codio a oedd yn gwneud ysgrifennu cod perfformiad uchel yn hawdd ac yn syml. Ond mae ysgrifennu cod sy'n rhedeg yn araf yn anodd, bydd yn edrych yn wael. Mae angen i chi geisio ysgrifennu cod araf o ddifrif, bydd yn rhaid i chi ddefnyddio dulliau ansafonol. Mae'r cod brecio i'w weld ar yr olwg gyntaf. O ganlyniad, rydych chi fel arfer yn ysgrifennu cod sy'n rhedeg yn gyflym, ond mae'n rhaid i chi ddarganfod beth i'w wneud yn achos cof a rennir. Mae hyn i gyd ynghlwm wrth araeau mawr ac mae'r ymddygiad yno yn debyg i araeau mawr anweddol mewn Java cyfochrog. Hynny yw, dychmygwch fod dwy edefyn yn ysgrifennu at arae gyfochrog, mae un ohonyn nhw'n ennill, a'r llall, yn unol â hynny, yn colli, ac nid ydych chi'n gwybod pa un yw pa un. Os nad ydynt yn gyfnewidiol, yna gall y gorchymyn fod yn beth bynnag y dymunwch - ac mae hyn yn gweithio'n dda iawn. Mae pobl wir yn poeni am drefn llawdriniaethau, maen nhw'n rhoi anweddol yn y lleoedd iawn, ac maen nhw'n disgwyl problemau perfformiad sy'n gysylltiedig â'r cof yn y lleoedd iawn. Fel arall, byddent yn ysgrifennu cod ar ffurf dolenni o 1 i N, lle mae N yn rhai triliynau, yn y gobaith y bydd pob achos cymhleth yn dod yn gyfochrog yn awtomatig - ac nid yw'n gweithio yno. Ond yn H2O nid yw hwn yn Java na Scala; gallwch ei ystyried yn “Java minws” os dymunwch. Mae hon yn arddull rhaglennu glir iawn ac mae'n debyg i ysgrifennu cod C neu Java syml gyda dolenni ac araeau. Ond ar yr un pryd, gellir prosesu cof mewn terabytes. Rwy'n dal i ddefnyddio H2O. Rwy'n ei ddefnyddio o bryd i'w gilydd mewn gwahanol brosiectau - a dyma'r peth cyflymaf o hyd, dwsinau o weithiau'n gyflymach na'i gystadleuwyr. Os ydych chi'n gwneud Data Mawr gyda data colofnol, mae'n anodd iawn curo H2O.

Heriau Technegol

Andrew: Beth fu eich her fwyaf yn eich gyrfa gyfan?

Clogwyn: A ydym yn trafod rhan dechnegol neu annhechnegol y mater? Byddwn yn dweud nad yw'r heriau mwyaf yn rhai technegol. 
O ran heriau technegol. Yn syml, fe wnes i eu trechu. Dydw i ddim hyd yn oed yn gwybod beth oedd yr un mwyaf, ond roedd rhai eithaf diddorol a gymerodd dipyn o amser, brwydr feddyliol. Pan es i i Sun, roeddwn yn siŵr y byddwn yn gwneud casglwr cyflym, a dywedodd criw o bobl hŷn mewn ymateb na fyddwn byth yn llwyddo. Ond yr wyf yn dilyn y llwybr hwn, ysgrifennu casglwr i lawr at y dyrannwr gofrestr, ac roedd yn eithaf cyflym. Roedd mor gyflym â C1 modern, ond roedd y dyraniad yn llawer arafach bryd hynny, ac wrth edrych yn ôl roedd yn broblem strwythur data mawr. Roeddwn i ei angen i ysgrifennu dyranwr cofrestr graffigol ac nid oeddwn yn deall y cyfyng-gyngor rhwng mynegiannol cod a chyflymder, a oedd yn bodoli yn y cyfnod hwnnw ac a oedd yn bwysig iawn. Daeth i'r amlwg bod y strwythur data fel arfer yn fwy na maint y storfa ar x86s o'r amser hwnnw, ac felly, pe bawn i'n tybio i ddechrau y byddai dyranwr y gofrestr yn cyfrifo 5-10 y cant o gyfanswm yr amser jitter, yna mewn gwirionedd roedd yn troi allan i fod. 50 y cant.

Wrth i amser fynd yn ei flaen, daeth y casglwr yn lanach ac yn fwy effeithlon, rhoddodd y gorau i gynhyrchu cod ofnadwy mewn mwy o achosion, a dechreuodd perfformiad fwyfwy ymdebygu i'r hyn y mae casglwr C yn ei gynhyrchu. Oni bai, wrth gwrs, eich bod yn ysgrifennu rhywfaint o crap nad yw hyd yn oed C yn cyflymu. . Os byddwch chi'n ysgrifennu cod fel C, fe gewch chi berfformiad fel C mewn mwy o achosion. A pho bellaf yr aethoch, y mwyaf aml y cawsoch god a oedd yn cyd-fynd yn asymptotig â lefel C, dechreuodd dyranwr y gofrestr edrych fel rhywbeth cyflawn ... p'un a yw'ch cod yn rhedeg yn gyflym neu'n araf. Fe wnes i barhau i weithio ar y dyraniad i'w wneud yn well dewisiadau. Daeth yn arafach ac yn arafach, ond rhoddodd berfformiad gwell a gwell mewn achosion lle na allai neb arall ymdopi. Gallwn blymio i mewn i ddyranwr cofrestr, claddu mis o waith yno, ac yn sydyn byddai'r cod cyfan yn dechrau gweithredu 5% yn gyflymach. Digwyddodd hyn dro ar ôl tro a daeth dyranwr y gofrestr yn dipyn o waith celf - roedd pawb yn ei garu neu'n ei gasáu, a gofynnodd pobl o'r academi gwestiynau ar y testun “pam mae popeth yn cael ei wneud fel hyn”, pam lai. sgan llinell, a beth yw'r gwahaniaeth. Mae'r ateb yn dal i fod yr un fath: mae dyrannwr yn seiliedig ar liwio graff ynghyd â gwaith gofalus iawn gyda'r cod byffer yn hafal i arf buddugoliaeth, y cyfuniad gorau na all neb ei drechu. Ac mae hyn yn beth braidd yn anamlwg. Mae popeth arall y mae'r casglwr yn ei wneud yno yn bethau sydd wedi'u hastudio'n weddol dda, er eu bod hefyd wedi'u dwyn i lefel celf. Roeddwn bob amser yn gwneud pethau a oedd i fod i droi'r casglwr yn waith celf. Ond nid oedd dim o hyn yn ddim hynod - heblaw am ddyranwr y gofrestr. Y tric yw bod yn ofalus Torri lawr o dan lwyth ac, os bydd hyn yn digwydd (gallaf esbonio'n fanylach os oes gennych ddiddordeb), mae hyn yn golygu y gallwch chi fewnlinio'n fwy ymosodol, heb y risg o ddisgyn dros dro yn amserlen y perfformiad. Yn y dyddiau hynny, roedd yna griw o gasglwyr ar raddfa lawn, wedi'u hongian â baubles a chwibanau, a oedd â dyraniadau cofrestr, ond ni allai neb arall ei wneud.

Y broblem yw, os ydych chi'n ychwanegu dulliau sy'n destun inlining, cynyddu a chynyddu'r ardal inlining, mae'r set o werthoedd a ddefnyddir ar unwaith yn fwy na nifer y cofrestrau, a rhaid ichi eu torri. Daw'r lefel hollbwysig fel arfer pan fydd y dyrannwr yn rhoi'r gorau iddi, ac mae un ymgeisydd da ar gyfer gollyngiad yn werth un arall, byddwch yn gwerthu rhai pethau gwyllt yn gyffredinol. Gwerth inlining yma yw eich bod yn colli rhan o'r gorbenion, uwchben ar gyfer galw ac arbed, gallwch weld y gwerthoedd y tu mewn a gall eu optimeiddio ymhellach. Cost inlining yw bod nifer fawr o werthoedd byw yn cael eu ffurfio, ac os bydd eich dyrannwr cofrestr yn llosgi i fyny yn fwy na'r angen, byddwch yn colli ar unwaith. Felly, mae gan y rhan fwyaf o ddyranwyr broblem: pan fydd inlining yn croesi llinell benodol, mae popeth yn y byd yn dechrau cael ei dorri i lawr a gellir fflysio cynhyrchiant i lawr y toiled. Mae'r rhai sy'n gweithredu'r casglwr yn ychwanegu rhai heuristics: er enghraifft, i roi'r gorau i inlining, gan ddechrau gyda rhai maint digon mawr, gan y bydd dyraniadau yn difetha popeth. Dyma sut mae kink yn y graff perfformiad yn cael ei ffurfio - rydych chi mewn llinell, mewn llinell, mae'r perfformiad yn tyfu'n araf - ac yna'n ffyniant! – mae'n syrthio i lawr fel jac cyflym oherwydd eich bod wedi leinio gormod. Dyma sut roedd popeth yn gweithio cyn dyfodiad Java. Mae angen llawer mwy o fewnlinio ar Java, felly roedd yn rhaid i mi wneud fy nyraniad yn llawer mwy ymosodol fel ei fod yn gwastatáu yn hytrach na damweiniau, ac os ydych chi'n mewnlinio gormod, mae'n dechrau sarnu, ond yna mae'r foment “dim mwy o arllwys” yn dal i ddod. Mae hwn yn arsylwad diddorol a daeth i mi allan o unman, ddim yn amlwg, ond fe dalodd ar ei ganfed. Dechreuais inlinio ymosodol ac aeth â mi i leoedd lle mae perfformiad Java a C yn gweithio ochr yn ochr. Maen nhw'n agos iawn - gallaf ysgrifennu cod Java sy'n sylweddol gyflymach na chod C a phethau felly, ond ar gyfartaledd, yn y darlun mawr o bethau, maen nhw'n gymharol debyg. Rwy'n meddwl mai rhan o'r teilyngdod hwn yw'r dyraniad cofrestr, sy'n fy ngalluogi i fewnleinio mor wirion â phosibl. Fi jyst inline popeth a welaf. Y cwestiwn yma yw a yw'r dyrannwr yn gweithio'n dda, a yw'r canlyniad yn gweithio'n ddeallus cod. Roedd hon yn her fawr: deall hyn i gyd a gwneud iddo weithio.

Ychydig am ddyrannu cofrestrau ac aml-greiddiau

Vladimir: Mae problemau fel dyrannu cofrestr yn ymddangos fel rhyw fath o bwnc tragwyddol, diddiwedd. Tybed a fu erioed syniad a oedd yn ymddangos yn addawol ac yna wedi methu yn ymarferol?

Clogwyn: Yn sicr! Mae dyrannu cofrestr yn faes lle rydych chi'n ceisio dod o hyd i rai hewristeg i ddatrys problem gyflawn NP. Ac ni allwch chi byth gyflawni ateb perffaith, iawn? Mae hyn yn syml amhosibl. Edrychwch, crynhoad Ymlaen Llaw - mae hefyd yn gweithio'n wael. Mae'r sgwrs yma yn ymwneud â rhai achosion cyffredin. Ynglŷn â pherfformiad nodweddiadol, felly gallwch chi fynd i fesur rhywbeth rydych chi'n meddwl sy'n berfformiad nodweddiadol da - wedi'r cyfan, rydych chi'n gweithio i'w wella! Mae dyrannu cofrestr yn bwnc sy'n ymwneud â pherfformiad. Unwaith y bydd gennych y prototeip cyntaf, mae'n gweithio ac yn paentio'r hyn sydd ei angen, mae'r gwaith perfformio yn dechrau. Mae angen i chi ddysgu sut i fesur yn dda. Pam ei fod yn bwysig? Os oes gennych chi ddata clir, gallwch chi edrych ar wahanol feysydd a gweld: ie, fe helpodd yma, ond dyna lle torrodd popeth! Mae rhai syniadau da yn codi, rydych chi'n ychwanegu heuristics newydd ac yn sydyn mae popeth yn dechrau gweithio ychydig yn well ar gyfartaledd. Neu nid yw'n dechrau. Roedd gen i griw o achosion lle'r oeddem ni'n ymladd am y perfformiad o bump y cant a oedd yn gwahaniaethu ein datblygiad o'r dyraniad blaenorol. A phob tro mae'n edrych fel hyn: rhywle rydych chi'n ei ennill, rhywle rydych chi'n ei golli. Os oes gennych offer dadansoddi perfformiad da, gallwch ddod o hyd i'r syniadau coll a deall pam eu bod yn methu. Efallai ei bod yn werth gadael popeth fel y mae, neu efallai cymryd agwedd fwy difrifol at fireinio, neu fynd allan a thrwsio rhywbeth arall. Mae'n griw cyfan o bethau! Fe wnes i'r darn hwn o oer, ond mae angen yr un hon arnaf hefyd, a'r un hwn, a'r un hwn - ac mae eu cyfuniad cyfan yn rhoi rhai gwelliannau. A gall loners fethu. Dyma natur gwaith perfformiad ar broblemau NP-cyflawn.

Vladimir: Mae un yn cael y teimlad bod pethau fel peintio mewn dyrannwyr yn broblem sydd eisoes wedi'i datrys. Wel, mae wedi'i benderfynu i chi, a barnu yn ôl yr hyn rydych chi'n ei ddweud, felly a yw hyd yn oed yn werth chweil felly...

Clogwyn: Nid yw'n cael ei ddatrys fel y cyfryw. Chi sy'n gorfod ei droi'n “ddatrys”. Mae problemau anodd ac mae angen eu datrys. Unwaith y gwneir hyn, mae'n bryd gweithio ar gynhyrchiant. Mae angen i chi fynd i'r afael â'r gwaith hwn yn unol â hynny - gwnewch feincnodau, casglu metrigau, egluro sefyllfaoedd pan, pan wnaethoch chi ddychwelyd i fersiwn flaenorol, y dechreuodd eich hen hac weithio eto (neu i'r gwrthwyneb, wedi'i stopio). A pheidiwch â rhoi'r gorau iddi nes i chi gyflawni rhywbeth. Fel y dywedais eisoes, os oes syniadau cŵl na weithiodd, ond ym maes dyrannu cyweiriau syniadau mae bron yn ddiddiwedd. Gallwch, er enghraifft, ddarllen cyhoeddiadau gwyddonol. Er yn awr mae'r maes hwn wedi dechrau symud yn llawer arafach ac wedi dod yn fwy amlwg nag yn ei ieuenctid. Fodd bynnag, mae yna lawer o bobl yn gweithio yn y maes hwn ac mae eu holl syniadau yn werth rhoi cynnig arnynt, maent i gyd yn aros yn yr adenydd. Ac ni allwch ddweud pa mor dda ydyn nhw oni bai eich bod chi'n rhoi cynnig arnyn nhw. Pa mor dda y maent yn integreiddio â phopeth arall yn eich dyranwr, oherwydd mae dyrannwr yn gwneud llawer o bethau, ac ni fydd rhai syniadau yn eich dyranwr penodol yn gweithio, ond mewn dyrannwr arall byddant yn hawdd. Y brif ffordd i ennill ar gyfer y dyranwr yw tynnu'r stwff araf y tu allan i'r prif lwybr a'i orfodi i hollti ar hyd ffiniau'r llwybrau araf. Felly os ydych chi eisiau rhedeg GC, cymerwch y llwybr araf, anoptimeiddio, taflu eithriad, yr holl bethau hynny - rydych chi'n gwybod bod y pethau hyn yn gymharol brin. Ac maent yn wirioneddol brin, gwiriais. Rydych chi'n gwneud gwaith ychwanegol ac mae'n dileu llawer o'r cyfyngiadau ar y llwybrau araf hyn, ond does dim ots mewn gwirionedd oherwydd maen nhw'n araf ac yn anaml yn teithio. Er enghraifft, pwyntydd null - nid yw byth yn digwydd, iawn? Mae angen i chi gael sawl llwybr ar gyfer gwahanol bethau, ond ni ddylent ymyrryd â'r prif un. 

Vladimir: Beth ydych chi'n ei feddwl am aml-greiddiau, pan fo miloedd o greiddiau ar unwaith? A yw hyn yn beth defnyddiol?

Clogwyn: Mae llwyddiant y GPU yn dangos ei fod yn eithaf defnyddiol!

Vladimir: Maent yn eithaf arbenigol. Beth am broseswyr pwrpas cyffredinol?

Clogwyn: Wel, dyna oedd model busnes Azul. Daeth yr ateb yn ôl mewn cyfnod pan oedd pobl wrth eu bodd â pherfformiad rhagweladwy. Roedd yn anodd ysgrifennu cod cyfochrog bryd hynny. Mae model codio H2O yn raddadwy iawn, ond nid yw'n fodel pwrpas cyffredinol. Efallai ychydig yn fwy cyffredinol nag wrth ddefnyddio GPU. A ydym yn sôn am gymhlethdod datblygu’r fath beth neu gymhlethdod ei ddefnyddio? Er enghraifft, dysgodd Azul wers ddiddorol i mi, un braidd nad yw'n amlwg: mae caches bach yn normal. 

Yr her fwyaf mewn bywyd

Vladimir: Beth am heriau annhechnegol?

Clogwyn: Yr her fwyaf oedd peidio â bod yn garedig ac yn neis i bobl. Ac o ganlyniad, cefais fy hun yn gyson mewn sefyllfaoedd hynod o wrthdaro. Y rhai lle roeddwn i'n gwybod bod pethau'n mynd o chwith, ond ddim yn gwybod sut i symud ymlaen gyda'r problemau hynny ac yn methu â'u trin. Cododd llawer o broblemau hirdymor, a barhaodd am ddegawdau, fel hyn. Mae'r ffaith bod gan Java gasglwyr C1 a C2 yn ganlyniad uniongyrchol i hyn. Mae'r ffaith na fu unrhyw gasgliad aml-lefel yn Java am ddeng mlynedd yn olynol hefyd yn ganlyniad uniongyrchol. Mae’n amlwg bod angen system o’r fath arnom, ond nid yw’n amlwg pam nad oedd yn bodoli. Cefais broblemau gydag un peiriannydd... neu grŵp o beirianwyr. Un tro, pan ddechreuais weithio yn Sun, roeddwn i'n... Iawn, nid yn unig wedyn, yn gyffredinol mae gen i fy marn fy hun ar bopeth. Ac roeddwn i'n meddwl ei fod yn wir y gallech chi gymryd y gwir hwn o'ch un chi a'i ddweud yn uniongyrchol. Yn enwedig gan fy mod yn syfrdanol o gywir y rhan fwyaf o'r amser. Ac os nad ydych chi'n hoffi'r dull hwn ... yn enwedig os ydych chi'n amlwg yn anghywir ac yn gwneud nonsens... Yn gyffredinol, ychydig o bobl allai oddef y math hwn o gyfathrebu. Er y gallai rhai, fel fi. Rwyf wedi adeiladu fy oes gyfan ar egwyddorion teilyngdod. Os dangoswch rywbeth o'i le i mi, trof ar unwaith a dweud: dywedasoch nonsens. Ar yr un pryd, wrth gwrs, ymddiheuraf a hynny i gyd, byddaf yn nodi’r rhinweddau, os o gwbl, ac yn cymryd camau cywir eraill. Ar y llaw arall, rwy'n syfrdanol o gywir am ganran syfrdanol o fawr o gyfanswm yr amser. Ac nid yw'n gweithio'n dda iawn mewn perthynas â phobl. Dydw i ddim yn ceisio bod yn neis, ond rwy'n gofyn y cwestiwn yn blwmp ac yn blaen. “Ni fydd hyn byth yn gweithio, oherwydd un, dau a thri.” Ac roedden nhw fel, "O!" Roedd canlyniadau eraill a oedd yn ôl pob tebyg yn well eu hanwybyddu: er enghraifft, y rhai a arweiniodd at ysgariad oddi wrth fy ngwraig a deng mlynedd o iselder ar ôl hynny.

Mae her yn frwydr gyda phobl, gyda'u canfyddiad o'r hyn y gallwch chi neu na allwch ei wneud, beth sy'n bwysig a beth sydd ddim. Roedd llawer o heriau ynghylch arddull codio. Rwy'n dal i ysgrifennu llawer o god, ac yn y dyddiau hynny roedd yn rhaid i mi hyd yn oed arafu oherwydd fy mod yn gwneud gormod o dasgau cyfochrog ac yn eu gwneud yn wael, yn lle canolbwyntio ar un. Wrth edrych yn ôl, ysgrifennais hanner y cod ar gyfer y gorchymyn Java JIT, y gorchymyn C2. Ysgrifennodd y codydd cyflymaf nesaf hanner mor araf, yr hanner nesaf mor araf, ac roedd yn ddirywiad esbonyddol. Roedd y seithfed person yn y rhes hon yn araf iawn, iawn - mae hynny bob amser yn digwydd! Fe wnes i gyffwrdd â llawer o god. Edrychais ar bwy ysgrifennodd beth, yn ddieithriad, syllu ar eu cod, adolygu pob un ohonynt, a pharhau i ysgrifennu mwy fy hun nag unrhyw un ohonynt o hyd. Nid yw'r dull hwn yn gweithio'n dda iawn gyda phobl. Nid yw rhai pobl yn hoffi hyn. A phan na allant ei drin, mae pob math o gwynion yn dechrau. Er enghraifft, dywedwyd wrthyf unwaith am roi'r gorau i godio oherwydd fy mod yn ysgrifennu gormod o god ac roedd yn peryglu'r tîm, ac roedd y cyfan yn swnio fel jôc i mi: dude, os yw gweddill y tîm yn diflannu ac rwy'n dal i ysgrifennu cod, byddwch Dim ond hanner timau fydd yn eu colli. Ar y llaw arall, os ydw i'n dal i ysgrifennu cod a'ch bod chi'n colli hanner y tîm, mae hynny'n swnio fel rheolaeth wael iawn. Wnes i erioed feddwl am y peth mewn gwirionedd, byth yn siarad amdano, ond roedd yn dal i fod rhywle yn fy mhen. Roedd y meddwl yn troelli yng nghefn fy meddwl: “Ydych chi i gyd yn fy ngharfu i?” Felly, y broblem fwyaf oedd fi a fy mherthynas â phobl. Nawr rwy'n deall fy hun yn llawer gwell, roeddwn i'n arweinydd tîm ar gyfer rhaglenwyr am amser hir, ac yn awr rwy'n dweud yn uniongyrchol wrth bobl: rydych chi'n gwybod, fi yw pwy ydw i, a bydd yn rhaid i chi ddelio â mi - a yw'n iawn os byddaf yn sefyll yma? A phan ddechreuon nhw ddelio ag e, fe weithiodd popeth. Yn wir, nid wyf yn ddrwg nac yn dda, nid oes gennyf unrhyw fwriadau drwg na dyheadau hunanol, fy hanfod yn unig ydyw, ac mae angen i mi fyw gydag ef rywsut.

Andrew: Yn ddiweddar, dechreuodd pawb siarad am hunanymwybyddiaeth ar gyfer mewnblyg, a sgiliau meddal yn gyffredinol. Beth allwch chi ei ddweud am hyn?

Clogwyn: Ie, dyna oedd y mewnwelediad a'r wers a ddysgais o fy ysgariad gan fy ngwraig. Yr hyn a ddysgais o'r ysgariad oedd deall fy hun. Dyma sut y dechreuais ddeall pobl eraill. Deall sut mae'r rhyngweithio hwn yn gweithio. Arweiniodd hyn at ddarganfyddiadau un ar ôl y llall. Roedd yna ymwybyddiaeth o bwy ydw i a beth rydw i'n ei gynrychioli. Beth ydw i'n ei wneud: naill ai rydw i'n ymddiddori yn y dasg, neu rydw i'n osgoi gwrthdaro, neu rywbeth arall - ac mae'r lefel hon o hunanymwybyddiaeth wir yn helpu i gadw fy hun mewn rheolaeth. Ar ôl hyn mae popeth yn mynd yn llawer haws. Un peth a ddarganfyddais nid yn unig ynof fy hun, ond hefyd mewn rhaglenwyr eraill yw'r anallu i eirioli meddyliau pan fyddwch mewn cyflwr o straen emosiynol. Er enghraifft, rydych chi'n eistedd yno yn codio, mewn cyflwr o lif, ac yna maen nhw'n dod yn rhedeg atoch chi ac yn dechrau sgrechian mewn hysterics bod rhywbeth wedi torri a nawr bydd mesurau eithafol yn cael eu cymryd yn eich erbyn. Ac ni allwch ddweud gair oherwydd eich bod mewn cyflwr o straen emosiynol. Mae'r wybodaeth a gafwyd yn caniatáu ichi baratoi ar gyfer y foment hon, ei goroesi a symud ymlaen i gynllun encilio, ac ar ôl hynny gallwch chi wneud rhywbeth. Felly ydy, pan fyddwch chi'n dechrau sylweddoli sut mae'r cyfan yn gweithio, mae'n ddigwyddiad enfawr sy'n newid bywyd. 
Ni allwn i fy hun ddod o hyd i'r geiriau cywir, ond cofiais y dilyniant o weithredoedd. Y pwynt yw bod yr adwaith hwn yn gymaint o gorfforol ag ydyw ar lafar, ac mae angen gofod arnoch. Gofod o'r fath, yn yr ystyr Zen. Dyma'n union beth sydd angen ei esbonio, ac yna camwch o'r neilltu ar unwaith - camwch i ffwrdd yn gorfforol yn unig. Pan fyddaf yn aros yn dawel ar lafar, gallaf brosesu'r sefyllfa yn emosiynol. Wrth i'r adrenalin gyrraedd eich ymennydd, eich newid i ymladd neu ddull hedfan, ni allwch ddweud dim mwyach, na - nawr rydych chi'n idiot, yn beiriannydd chwipio, yn analluog i ymateb gweddus neu hyd yn oed yn atal yr ymosodiad, ac mae'r ymosodwr yn rhydd i ymosod dro ar ôl tro. Rhaid i chi ddod yn chi'ch hun eto yn gyntaf, adennill rheolaeth, mynd allan o'r modd “ymladd neu hedfan”.

Ac ar gyfer hyn mae angen gofod llafar. Dim ond lle am ddim. Os ydych chi'n dweud unrhyw beth o gwbl, yna gallwch chi ddweud yn union hynny, ac yna ewch i ddod o hyd i "le" i chi'ch hun: ewch am dro yn y parc, clowch eich hun yn y gawod - does dim ots. Y prif beth yw datgysylltu dros dro o'r sefyllfa honno. Cyn gynted ag y byddwch chi'n diffodd am o leiaf ychydig eiliadau, mae'r rheolaeth yn dychwelyd, rydych chi'n dechrau meddwl yn sobr. “Iawn, dydw i ddim yn rhyw fath o idiot, dydw i ddim yn gwneud pethau gwirion, rwy’n berson eithaf defnyddiol.” Unwaith y byddwch wedi gallu argyhoeddi eich hun, mae'n bryd symud ymlaen i'r cam nesaf: deall beth ddigwyddodd. Ymosodwyd arnoch chi, daeth yr ymosodiad o le nad oeddech chi'n ei ddisgwyl, roedd yn ambush anonest, ffiaidd. Mae hyn yn ddrwg. Y cam nesaf yw deall pam roedd angen hyn ar yr ymosodwr. Mewn gwirionedd, pam? Efallai oherwydd ei fod ef ei hun yn gandryll? Pam ei fod yn wallgof? Er enghraifft, oherwydd ei fod yn sgriwio i fyny ei hun ac ni all dderbyn cyfrifoldeb? Dyma'r ffordd i drin y sefyllfa gyfan yn ofalus. Ond mae hyn yn gofyn am le i symud, gofod geiriol. Y cam cyntaf un yw torri cyswllt llafar i ffwrdd. Osgoi trafodaeth gyda geiriau. Canslo, cerddwch i ffwrdd cyn gynted â phosibl. Os mai sgwrs ffôn yw hi, rhowch y ffôn i lawr - dyma sgil a ddysgais wrth gyfathrebu â fy nghyn-wraig. Os nad yw'r sgwrs yn mynd yn unman da, dim ond dweud "hwyl fawr" a rhoi'r ffôn i lawr. O ochr arall y ffôn: “blah blah blah”, rydych chi'n ateb: “ie, bye!” a hongian i fyny. Rydych chi'n dod â'r sgwrs i ben. Bum munud yn ddiweddarach, pan fydd y gallu i feddwl yn synhwyrol yn dychwelyd atoch, rydych chi wedi oeri ychydig, mae'n dod yn bosibl meddwl am bopeth, beth ddigwyddodd a beth fydd yn digwydd nesaf. A dechreuwch ffurfio ymateb meddylgar, yn hytrach na dim ond ymateb allan o emosiwn. I mi, y datblygiad arloesol mewn hunanymwybyddiaeth yn union oedd y ffaith na allaf siarad rhag ofn y bydd straen emosiynol. Mynd allan o'r cyflwr hwn, meddwl a chynllunio sut i ymateb a gwneud iawn am broblemau - dyma'r camau cywir yn yr achos pan na allwch siarad. Y ffordd hawsaf yw rhedeg i ffwrdd o'r sefyllfa lle mae straen emosiynol yn amlygu ei hun a rhoi'r gorau i gymryd rhan yn y straen hwn. Ar ôl hynny rydych chi'n dod yn gallu meddwl, pan fyddwch chi'n gallu meddwl, rydych chi'n dod yn gallu siarad, ac ati.

Gyda llaw, yn y llys, mae'r cyfreithiwr sy'n gwrthwynebu yn ceisio gwneud hyn i chi - nawr mae'n amlwg pam. Oherwydd bod ganddo'r gallu i'ch atal chi i'r fath gyflwr na allwch chi hyd yn oed ynganu'ch enw, er enghraifft. Mewn ystyr real iawn, ni fyddwch yn gallu siarad. Os bydd hyn yn digwydd i chi, ac os ydych chi'n gwybod y byddwch chi'n cael eich hun mewn man lle mae brwydrau geiriol yn gynddeiriog, mewn lle fel llys, yna gallwch chi ddod gyda'ch cyfreithiwr. Bydd y cyfreithiwr yn sefyll ar eich rhan ac yn atal yr ymosodiad geiriol, a bydd yn ei wneud mewn ffordd gwbl gyfreithiol, a bydd y gofod Zen coll yn dychwelyd atoch chi. Er enghraifft, roedd yn rhaid i mi ffonio fy nheulu cwpl o weithiau, roedd y barnwr yn eithaf cyfeillgar am hyn, ond sgrechiodd y cyfreithiwr oedd yn gwrthwynebu a gweiddi arnaf, ni allwn hyd yn oed gael gair yn ymylol. Yn yr achosion hyn, mae defnyddio cyfryngwr yn gweithio orau i mi. Mae'r cyfryngwr yn atal yr holl bwysau hwn sy'n arllwys arnoch chi mewn nant barhaus, fe welwch y gofod Zen angenrheidiol, a chyda hynny mae'r gallu i siarad yn dychwelyd. Mae hwn yn faes gwybodaeth cyfan lle mae llawer i'w astudio, llawer i'w ddarganfod ynoch chi'ch hun, ac mae hyn i gyd yn troi'n benderfyniadau strategol lefel uchel sy'n wahanol i wahanol bobl. Nid oes gan rai pobl y problemau a ddisgrifir uchod; fel arfer, nid oes gan bobl sy'n werthwyr proffesiynol rai. Yr holl bobl hyn sy'n gwneud eu bywoliaeth gyda geiriau - cantorion enwog, beirdd, arweinwyr crefyddol a gwleidyddion, mae ganddyn nhw bob amser rywbeth i'w ddweud. Nid oes ganddynt broblemau o'r fath, ond mae gennyf fi.

Andrew: Roedd yn... annisgwyl. Gwych, rydyn ni wedi siarad llawer yn barod ac mae'n bryd dod â'r cyfweliad hwn i ben. Byddwn yn bendant yn cyfarfod yn y gynhadledd a byddwn yn gallu parhau â'r ddeialog hon. Welwn ni chi yn Hydra!

Gallwch barhau â'ch sgwrs gyda Cliff yng nghynhadledd Hydra 2019, a gynhelir ar Orffennaf 11-12, 2019 yn St Petersburg. Bydd yn dod gydag adroddiad "Profiad Cof Trafodol Caledwedd Azul". Gellir prynu tocynnau ar y wefan swyddogol.

Ffynhonnell: hab.com