Cliff Click — Cratus-ийн CTO (үйл явцыг сайжруулах IoT мэдрэгч), хэд хэдэн стартапыг (Rocket Realtime School, Neurensic болон H2O.ai зэрэг) үүсгэн байгуулагч, хамтран үүсгэн байгуулагч, хэд хэдэн амжилттай гарсан. Клифф 15 настайдаа анхны эмхэтгэлээ бичжээ (TRS Z-80-д зориулсан Паскаль)! Тэрээр Java дахь C2 (The Sea of ​​Nodes IR) дээр бүтээлээрээ алдартай. Энэхүү хөрвүүлэгч нь JIT нь өндөр чанартай код гаргаж чаддаг болохыг дэлхий нийтэд харуулсан нь Java программыг орчин үеийн програм хангамжийн үндсэн платформуудын нэг болгон бий болгох нэг хүчин зүйл болсон юм. Дараа нь Cliff Azul Systems-д 864 миллисекундэд 500 гигабайтын зайд GC-ийн түр зогсолтыг дэмждэг цэвэр Java программ хангамж бүхий 10 цөмт үндсэн фрэйм ​​бүтээхэд тусалсан. Ерөнхийдөө Клифф JVM-ийн бүх тал дээр ажиллаж чадсан.

 
Энэхүү habrapost бол Клиффтэй хийсэн гайхалтай ярилцлага юм. Бид дараах сэдвээр ярилцах болно.

• Доод түвшний оновчлол руу шилжих
• Том рефакторинг хэрхэн хийх вэ
• Зардлын загвар
• Доод түвшний оновчлолын сургалт
• Гүйцэтгэлийг сайжруулах практик жишээ
• Яагаад өөрийн програмчлалын хэлийг бий болгох вэ?
• Гүйцэтгэлийн инженерийн карьер
• Техникийн сорилтууд
• Бүртгэлийн хуваарилалт, олон цөмийн талаар бага зэрэг
• Амьдралын хамгийн том сорилт

Ярилцлагыг дараах хүмүүс явуулна.

• Андрей Сатарин Amazon Web Services-ээс. Тэрээр карьерынхаа туршид огт өөр төслүүдэд ажиллаж чадсан: Yandex дахь NewSQL тархсан мэдээллийн сан, Касперскийн лабораторийн үүл илрүүлэх систем, Mail.ru дахь олон тоглогчийн тоглоом, Дойче Банк дахь валютын үнийг тооцоолох үйлчилгээг туршиж үзсэн. Том хэмжээний backend болон тархсан системийг турших сонирхолтой.
• Владимир Ситников Netcracker-аас. Сүлжээний болон сүлжээний тоног төхөөрөмжийн удирдлагын үйл явцыг автоматжуулахад харилцаа холбооны операторуудын ашигладаг NetCracker OS-ийн гүйцэтгэл, өргөтгөх чадвар дээр арван жил ажилласан. Java болон Oracle мэдээллийн сангийн гүйцэтгэлийн асуудлыг сонирхож байна. PostgreSQL JDBC албан ёсны драйверын арав гаруй гүйцэтгэлийн сайжруулалтын зохиогч.

Доод түвшний оновчлол руу шилжих

Андрей: Та JIT эмхэтгэл, Java, ерөнхийдөө гүйцэтгэлийн ажлын талаар дэлхийд алдартай хүн шүү дээ? 

Хадан цохио: Ийм л байна!

Андрей: Гүйцэтгэлийн ажлын талаархи ерөнхий асуултуудаас эхэлье. CPU-ийн түвшинд ажиллах гэх мэт дээд түвшний болон доод түвшний оновчлолын сонголтын талаар та юу гэж бодож байна вэ?

Хадан цохио: Тийм ээ, энд бүх зүйл энгийн. Хамгийн хурдан код бол хэзээ ч ажилладаггүй код юм. Тиймээс та үргэлж өндөр түвшнээс эхэлж, алгоритм дээр ажиллах хэрэгтэй. Зарим хангалттай том тогтмолууд хөндлөнгөөс оролцохгүй бол илүү сайн O тэмдэглэгээ нь муу O тэмдэглэгээг ялна. Доод түвшний зүйлс хамгийн сүүлд явдаг. Ер нь, хэрэв та стекийнхээ үлдсэн хэсгийг хангалттай оновчтой болгосон бөгөөд сонирхолтой зүйл үлдсэн бол энэ нь бага түвшин юм. Гэхдээ өндөр түвшнээс яаж эхлэх вэ? Хангалттай өндөр түвшний ажил хийгдсэн гэдгийг та яаж мэдэх вэ? За... арга ч үгүй. Бэлэн жор байхгүй. Та асуудлыг ойлгож, юу хийхээ шийдэх хэрэгтэй (ирээдүйд шаардлагагүй алхам хийхгүйн тулд), дараа нь та ашигтай зүйл хэлж чадах профайлыг нээж чадна. Хэзээ нэгэн цагт та шаардлагагүй зүйлсээс ангижирч, доод түвшний нарийн тохируулга хийх цаг болсныг та өөрөө ойлгож байна. Энэ бол мэдээж урлагийн онцгой төрөл юм. Олон хүмүүс хэрэгцээгүй зүйл хийдэг боловч маш хурдан хөдөлж, бүтээмжийн талаар санаа зовох цаг байхгүй. Гэхдээ энэ нь шууд асуулт гарч ирэх хүртэл юм. Ихэвчлэн 99% нь хэнд ч хамаагүй чухал зүйл гарч ирэх хүртэл миний юу хийх нь хэнд ч хамаагүй байдаг. Эндээс хүн бүр "Яагаад эхнээсээ тийм ч сайн ажиллаагүй юм бэ" гэж гонгинож байна. Ерөнхийдөө гүйцэтгэлийг сайжруулах зүйл үргэлж байдаг. Гэхдээ 99% нь танд тэргүүлэгч байдаггүй! Та зүгээр л ямар нэг зүйлийг ажил хэрэг болгох гэж оролдож байгаа бөгөөд энэ явцад та юу чухал болохыг олж мэдэх болно. Энэ хэсэг төгс байх ёстой гэдгийг та хэзээ ч урьдчилан мэдэж чадахгүй, тиймээс та бүх зүйлд төгс байх ёстой. Гэхдээ энэ нь боломжгүй зүйл бөгөөд та үүнийг хийхгүй. Засах зүйл үргэлж олон байдаг бөгөөд энэ нь хэвийн зүйл юм.

Том рефакторинг хэрхэн хийх вэ

Андрей: Тоглолт дээр хэрхэн ажилладаг вэ? Энэ бол хөндлөн огтлолын асуудал юм. Жишээлбэл, та одоо байгаа олон функцүүдийн уулзвараас үүссэн асуудлууд дээр ажиллах шаардлагатай байсан уу?

Хадан цохио: Би үүнээс зайлсхийхийг хичээдэг. Хэрэв би гүйцэтгэлтэй холбоотой асуудал гарна гэдгийг мэдэж байгаа бол код бичиж эхлэхээсээ өмнө, ялангуяа өгөгдлийн бүтцэд энэ талаар боддог. Гэхдээ ихэнхдээ та энэ бүхнийг хожим нь олж мэддэг. Дараа нь та туйлын арга хэмжээ авч, миний "дахин бичиж, байлдан дагуулах" гэж нэрлэдэг зүйлийг хийх хэрэгтэй: та хангалттай том хэсгийг авах хэрэгтэй. Гүйцэтгэлийн асуудал эсвэл өөр зүйлээс болж зарим кодыг дахин бичих шаардлагатай хэвээр байх болно. Кодыг дахин бичих шалтгаан нь ямар ч байсан, жижиг хэсгийг бодвол том хэсгийг дахин бичих нь бараг үргэлж дээр байдаг. Энэ мөчид бүгд айж чичирч эхэлдэг: "Бурхан минь, чи ийм их кодонд хүрч чадахгүй!" Гэвч үнэн хэрэгтээ энэ арга бараг үргэлж илүү сайн ажилладаг. Та нэн даруй том асуудлыг шийдэж, эргэн тойрондоо том тойрог зураад: Би тойрог доторх бүх зүйлийг дахин бичих болно. Хил нь солих шаардлагатай байгаа контентоос хамаагүй бага юм. Хэрэв ийм хил хязгаар нь доторх ажлыг төгс хийх боломжийг олгодог бол таны гар чөлөөтэй, хүссэн зүйлээ хий. Асуудлыг ойлгосны дараа дахин бичих үйл явц илүү хялбар байх тул бага зэрэг хазаарай!
Үүний зэрэгцээ, та том дахин бичиж, гүйцэтгэл нь асуудал болно гэдгийг ойлгох үед та тэр даруй энэ талаар санаа зовж эхлэх боломжтой. Энэ нь ихэвчлэн "өгөгдөл хуулахгүй, өгөгдлийг аль болох хялбар удирдах, жижиг болгох" гэх мэт энгийн зүйл болж хувирдаг. Томоохон дахин бичихэд гүйцэтгэлийг сайжруулах стандарт аргууд байдаг. Мөн тэд бараг үргэлж мэдээллийн эргэн тойронд эргэлддэг.

Зардлын загвар

Андрей: Нэг подкаст дээр та бүтээмжийн хүрээнд зардлын загваруудын талаар ярьсан. Та үүгээр юу хэлэх гээд байгаагаа тайлбарлаж чадах уу?

Хадан цохио: Мэдээж. Би процессорын гүйцэтгэл туйлын чухал байсан эрин үед төрсөн. Энэ эрин дахин эргэж ирэв - хувь тавилан нь инээдэмгүй биш юм. Би найман битийн машинуудын үед амьдарч эхэлсэн; миний анхны компьютер 256 байттай ажилладаг байсан. Яг байт. Бүх зүйл маш жижиг байсан. Зааврыг тоолох шаардлагатай байсан бөгөөд бид програмчлалын хэлний стекийг дээшлүүлж эхлэх тусам хэлүүд улам бүр нэмэгдсээр байв. Ассемблер байсан, дараа нь Basic, дараа нь С, С нь регистрийн хуваарилалт, заавар сонгох гэх мэт олон нарийн ширийн зүйлийг анхаарч үзсэн. Гэхдээ тэнд бүх зүйл тодорхой байсан бөгөөд хэрэв би хувьсагчийн жишээнд заагч хийвэл ачаалал авах болно, энэ зааварчилгааны өртөг нь тодорхой болно. Техник хангамж нь тодорхой тооны машины циклийг үүсгэдэг тул янз бүрийн зүйлсийн гүйцэтгэлийн хурдыг таны ажиллуулах гэж буй бүх зааврыг нэгтгэн тооцоолж болно. Харьцуулах/туршилт/салбар/дуудлага/ачаалах/дэлгүүр бүрийг нэмээд: Энэ бол таны гүйцэтгэх хугацаа. Гүйцэтгэлийг сайжруулах талаар ажиллахдаа жижиг халуун мөчлөгт ямар тоо тохирохыг анхаарч үзэх нь дамжиггүй. 
Гэхдээ та Java, Python болон үүнтэй төстэй зүйл рүү шилжсэн даруйдаа доод түвшний техник хангамжаас маш хурдан холддог. Java хэл дээр хүлээн авагч руу залгахад ямар үнэтэй вэ? Хэрэв HotSpot дахь JIT зөв бол доторлогоотой, энэ нь ачаалах боловч хэрэв үүнийг хийгээгүй бол энэ нь функцийн дуудлага байх болно. Дуудлага нь халуун давталт дээр байгаа тул энэ давталтын бусад бүх оновчлолыг хүчингүй болгоно. Тиймээс бодит өртөг нь хамаагүй өндөр байх болно. Мөн та кодыг харах чадвараа шууд алдаж, бид үүнийг процессорын цаг, санах ой, кэшийн хувьд ашиглах ёстой гэдгийг ойлгох болно. Та үнэхээр тоглолтонд орж байж л энэ бүхэн сонирхолтой болно.
Одоо бид процессорын хурд сүүлийн арван жилийн турш бараг нэмэгдээгүй нөхцөл байдалд байна. Хуучин өдрүүд эргэн ирлээ! Та нэг урсгалтай сайн гүйцэтгэлд найдаж болохгүй. Гэхдээ хэрэв та гэнэт зэрэгцээ тооцоололд орвол энэ нь үнэхээр хэцүү, бүгд чамайг Жеймс Бонд шиг хардаг. Энд арав дахин хурдасгах нь ихэвчлэн хэн нэгэн ямар нэг зүйлийг будлиулсан газарт тохиолддог. Зэрэгцээ нь маш их хөдөлмөр шаарддаг. Энэ хурдыг XNUMX дахин нэмэгдүүлэхийн тулд зардлын загварыг ойлгох хэрэгтэй. Энэ нь юу вэ, ямар үнэтэй вэ? Үүнийг хийхийн тулд хэл нь үндсэн тоног төхөөрөмжид хэрхэн тохирохыг ойлгох хэрэгтэй.
Мартин Томпсон блогтоо гайхалтай үг сонгосон Механик симпати! Техник хангамж нь юу хийх гэж байгаа, яг яаж үүнийг хийх, яагаад юу хийдэг вэ гэдгийг ойлгох хэрэгтэй. Үүнийг ашигласнаар зааварчилгааг тоолж, гүйцэтгэх хугацаа хаашаа явж байгааг олж мэдэхэд маш хялбар байдаг. Хэрэв танд зохих сургалт байхгүй бол та харанхуй өрөөнд хар муур хайж байна. Би юу хийж байгаагаа мэдэхгүй хүмүүсийг үргэлж гүйцэтгэлээ сайжруулж байгааг харж байна. Тэд маш их зовж, ахиц дэвшил гаргахгүй байна. Би ижил кодыг авч, хэд хэдэн жижиг хакеруудыг оруулаад тав эсвэл арав дахин хурдасгахад тэд "За, энэ нь шударга бус байна, бид таныг илүү гэдгийг мэдэж байсан." Гайхалтай. Би юу яриад байна вэ... зардлын загвар нь том зургаар харахад ямар төрлийн код бичдэг, дунджаар хэр хурдан ажилладаг тухай юм.

Андрей: Тэгээд яаж ийм хэмжээний дууг толгойдоо байлгаж чадаж байна аа? Энэ нь илүү их туршлагатай байж чадсан уу, эсвэл? Ийм туршлага хаанаас ирдэг вэ?

Хадан цохио: За, би өөрийн туршлагаа тийм ч хялбар аргаар олж аваагүй. Та бүх зааварчилгааг ойлгох боломжтой байсан тэр үед би Ассемблей дээр программчилсан. Тэнэг сонсогдож байгаа ч тэр цагаас хойш Z80 зааврын иж бүрдэл миний толгойд, ой санамжинд үргэлж үлддэг. Би хүмүүсийн нэрийг нэг минутын дотор санахгүй байгаа ч 40 жилийн өмнө бичсэн кодыг санаж байна. Энэ нь инээдтэй юм, синдром шиг харагдаж байна "тэнэг эрдэмтэн".

Доод түвшний оновчлолын сургалт

Андрей: Дотогшоо орох илүү хялбар арга байна уу?

Хадан цохио: Тийм, үгүй. Бидний хэрэглэдэг техник хангамж цаг хугацааны явцад тийм ч их өөрчлөгдөөгүй. Arm ухаалаг гар утаснаас бусад нь бүгд x86 ашигладаг. Хэрэв та ямар нэгэн хатуу ширүүн суулгах ажил хийхгүй бол та мөн адил зүйлийг хийж байна. За, дараа нь. Зааварчилгаа нь олон зууны турш өөрчлөгдөөгүй. Ассемблей дээр очоод юм бичих хэрэгтэй. Их биш, гэхдээ ойлгож эхлэхэд хангалттай. Та инээмсэглэж байгаа ч би үнэхээр нухацтай ярьж байна. Та хэл, техник хангамжийн хоорондын уялдаа холбоог ойлгох хэрэгтэй. Үүний дараа та явж, бага зэрэг бичиж, бяцхан тоглоомын хэлэнд зориулж бяцхан тоглоомын эмхэтгэл хийх хэрэгтэй. Тоглоомтой төстэй гэдэг нь үүнийг боломжийн хугацаанд хийх шаардлагатай гэсэн үг юм. Энэ нь маш энгийн байж болох ч зааварчилгаа үүсгэх ёстой. Заавар үүсгэх үйлдэл нь хүн бүрийн бичсэн дээд түвшний код болон техник хангамж дээр ажилладаг машины кодыг хооронд нь холбох зардлын загварыг ойлгоход тусална. Энэ захидал эмхэтгэгчийг бичих үед тархинд шатах болно. Хамгийн энгийн хөрвүүлэгч хүртэл. Үүний дараа та Java-г судалж эхлэх бөгөөд түүний утгын ангал нь илүү гүнзгий бөгөөд түүн дээр гүүр барих нь илүү хэцүү байдаг. Жава хэл дээр манай гүүр сайн эсвэл муу болсон уу, юу нь нурж унах, юу нь болохгүйг ойлгоход илүү хэцүү байдаг. Гэхдээ танд кодыг хараад "тиймээ, энэ хүлээн авагчийг бүртгэх ёстой" гэж ойлгох эхлэлийн цэг хэрэгтэй. Дараа нь арга нь хэтэрхий том болж, JIT бүх зүйлийг оруулаад эхлэхээс бусад тохиолдолд заримдаа ийм зүйл тохиолддог. Ийм газруудын гүйцэтгэлийг шууд урьдчилан таамаглах боломжтой. Ихэвчлэн хүлээн авагчид сайн ажилладаг боловч дараа нь та том халуун гогцоонуудыг хараад, тэнд юу хийж байгаагаа мэдэхгүй зарим функцын дуудлагууд хөвж байгааг ойлгодог. Энэ нь getter-ийн өргөн хэрэглээтэй холбоотой асуудал бөгөөд яагаад доторлогддоггүй вэ гэвэл тэдгээр нь getter мөн эсэх нь тодорхойгүй байдаг. Хэрэв танд маш жижиг кодын суурь байгаа бол та үүнийг зүгээр л санаж, дараа нь: Энэ бол хүлээн авагч, энэ бол тохируулагч гэж хэлж болно. Том кодын санд функц бүр өөрийн гэсэн түүхтэй байдаг бөгөөд энэ нь ерөнхийдөө хэнд ч мэдэгддэггүй. Профайл үүсгэгч хэлэхдээ бид зарим гогцоонд 24% алдсан бөгөөд энэ гогцоо юу хийж байгааг ойлгохын тулд функц бүрийг дотор нь харах хэрэгтэй. Функцийг судлахгүйгээр үүнийг ойлгох боломжгүй бөгөөд энэ нь ойлгох үйл явцыг ноцтой удаашруулдаг. Тийм ч учраас би хүлээн авагч, тохируулагч ашигладаггүй, би шинэ түвшинд хүрсэн!
Зардлын загварыг хаанаас авах вэ? Яахав нэг юм уншиж болно л доо... Гэхдээ хамгийн сайн арга бол жүжиглэх гэж би боддог. Жижиг хөрвүүлэгч хийх нь зардлын загварыг ойлгож, өөрийн толгойд нийцүүлэх хамгийн сайн арга байх болно. Богино долгионы зуухыг програмчлахад тохиромжтой жижиг хөрвүүлэгч бол эхлэгчдэд зориулсан ажил юм. Хэрэв та програмчлалын чадвартай бол энэ нь хангалттай байх болно гэж би хэлэх гэсэн юм. Танд ямар нэгэн алгебрийн илэрхийлэл болгон байгаа мөрийг задлан шинжлэх, тэндээс математикийн үйлдлүүдийн зааварчилгааг зөв дарааллаар гаргаж авах, регистрээс зөв утгыг авах гэх мэт энэ бүгдийг нэг дор хийдэг. Тэгээд үүнийг хийж байх зуур тархинд чинь үлдэнэ. Хөрвүүлэгч юу хийдгийг хүн бүр мэддэг байх гэж бодож байна. Мөн энэ нь зардлын загварын талаар ойлголт өгөх болно.

Гүйцэтгэлийг сайжруулах практик жишээ

Андрей: Бүтээмж дээр ажиллахдаа өөр юуг анхаарах ёстой вэ?

Хадан цохио: Өгөгдлийн бүтэц. Дашрамд хэлэхэд, тийм ээ, би эдгээр хичээлүүдийг удаан хугацаанд заагаагүй ... Пуужингийн сургууль. Энэ нь хөгжилтэй байсан, гэхдээ энэ нь маш их хүчин чармайлт шаарддаг, би бас амьдралтай! БОЛЖ БАЙНА УУ. Тиймээс, "Таны гүйцэтгэл хаашаа явдаг вэ" гэсэн том бөгөөд сонирхолтой хичээлүүдийн нэг дээр би оюутнуудад жишээ өгсөн: CSV файлаас хоёр ба хагас гигабайт финтекийн өгөгдлийг уншиж, дараа нь тэд борлуулсан бүтээгдэхүүний тоог тооцоолох шаардлагатай болсон. . Хачгийн зах зээлийн тогтмол мэдээлэл. 70-аад оноос хойш UDP пакетуудыг текст формат руу хөрвүүлсэн. Чикагогийн худалдааны бирж - цөцгийн тос, эрдэнэ шиш, шар буурцаг гэх мэт бүх төрлийн зүйлс. Эдгээр бүтээгдэхүүн, гүйлгээний тоо, хөрөнгө, барааны хөдөлгөөний дундаж хэмжээ гэх мэтийг тоолох шаардлагатай байв. Энэ бол маш энгийн арилжааны математик юм: бүтээгдэхүүний кодыг олох (энэ нь хэш хүснэгтэд 1-2 тэмдэгт), дүнг олж, арилжааны багцын аль нэгэнд нэмэх, эзлэхүүн нэмэх, үнэ цэнийг нэмэх болон бусад хэд хэдэн зүйлийг хийх. Маш энгийн математик. Тоглоомын хэрэгжилт нь маш энгийн байсан: бүх зүйл файлд байгаа, би файлыг уншиж, түүгээр гүйлгэж, бие даасан бичлэгүүдийг Java мөр болгон хувааж, тэдгээрээс шаардлагатай зүйлсийг хайж, дээр дурдсан математикийн дагуу нэмж оруулав. Мөн энэ нь бага хурдтай ажилладаг.

Энэ аргын тусламжтайгаар юу болж байгаа нь ойлгомжтой бөгөөд зэрэгцээ тооцоолох нь тус болохгүй, тийм үү? Зөвхөн зөв өгөгдлийн бүтцийг сонгох замаар гүйцэтгэлийг тав дахин нэмэгдүүлэх боломжтой болж байна. Энэ нь туршлагатай програмистуудыг хүртэл гайхшруулдаг! Миний хувьд хамгийн гол заль мэх нь санах ойн хуваарилалтыг халуун давталтаар хийх ёсгүй. За, энэ бол бүхэл бүтэн үнэн биш, гэхдээ ерөнхийдөө X хангалттай том бол "X-д нэг удаа"-ыг онцолж болохгүй. X нь хоёр ба хагас гигабайт байх үед та "үсэг бүрт нэг удаа", "мөр бүрт нэг удаа", "талбарт нэг удаа" гэх мэт зүйлийг хуваарилж болохгүй. Энд цаг хугацаа зарцуулагддаг. Энэ яаж ажилладаг вэ? Намайг залгаж байна гэж төсөөлөөд үз дээ String.split() буюу BufferedReader.readLine(). Readline сүлжээгээр ирсэн олон байтаас мөр бүрт, хэдэн зуун сая мөр бүрт нэг удаа мөр хийдэг. Би энэ мөрийг аваад задлаад хаячихдаг. Би яагаад үүнийг хаяж байгаа юм бэ, би үүнийг аль хэдийн боловсруулсан, тэгээд л болоо. Тиймээс, эдгээр 2.7G-ээс уншсан байт бүрт хоёр тэмдэгт мөрөнд бичигдэх болно, өөрөөр хэлбэл аль хэдийн 5.4G, надад цаашид юу ч хэрэггүй, тиймээс тэдгээрийг хаясан. Хэрэв та санах ойн зурвасын өргөнийг харвал бид санах ой болон санах ойн автобусаар дамждаг 2.7G-ийг процессороор ачаалж, дараа нь санах ойд байрлах шугам руу хоёр дахин их хэмжээгээр илгээгддэг бөгөөд шинэ мөр бүрийг үүсгэх үед энэ бүхэн хуучирдаг. Гэхдээ би үүнийг унших хэрэгтэй, дараа нь бүх зүйл эвдэрсэн ч гэсэн техник хангамж үүнийг уншдаг. Мөн би үүнийг бичих ёстой, учир нь би мөр үүсгэсэн бөгөөд кэш дүүрсэн - кэш нь 2.7G-г багтааж чадахгүй. Тиймээс, уншсан байт бүрт би хоёр байт уншиж, хоёр байт бичдэг бөгөөд эцэст нь тэдгээр нь 4: 1 харьцаатай байдаг - энэ харьцаагаар бид санах ойн зурвасын өргөнийг дэмий үрж байна. Тэгээд дараа нь би ингэвэл тийм болж байна String.split() - Энэ бол миний сүүлчийн удаа биш, дотор нь өөр 6-7 талбар байж магадгүй юм. Тиймээс CSV-г уншиж, дараа нь мөрүүдийг задлан шинжилдэг сонгодог код нь санах ойн зурвасын өргөнийг таны хүсч буй зүйлтэй харьцуулахад ойролцоогоор 14:1-ээр алдахад хүргэдэг. Хэрэв та эдгээр сонголтыг хаявал хурдыг тав дахин нэмэгдүүлэх боломжтой.

Мөн энэ нь тийм ч хэцүү биш юм. Хэрэв та кодыг зөв өнцгөөс харвал асуудлыг ойлгосноор бүх зүйл маш энгийн болно. Та санах ойг хуваарилахаа бүрмөсөн зогсоох ёсгүй: цорын ганц асуудал бол та ямар нэг зүйлийг хуваарилахдаа тэр даруй үхэж, чухал нөөцийг шатаадаг бөгөөд энэ нь санах ойн зурвасын өргөн юм. Мөн энэ бүхэн бүтээмж буурахад хүргэдэг. X86 дээр ихэвчлэн процессорын циклийг идэвхтэй шатаах шаардлагатай байдаг, гэхдээ энд та бүх санах ойг хамаагүй эрт шатаасан. Шийдэл нь гадагшлах хэмжээг багасгах явдал юм. 
Асуудлын нөгөө хэсэг нь санах ойн зурвас дуусмагц профайл үүсгэгчийг ажиллуулбал яг ийм зүйл тохиолдоход та ихэвчлэн кэш буцаж ирэхийг хүлээж байдаг, учир нь энэ нь таны саяхан үйлдвэрлэсэн хог хаягдал, тэр бүх мөрүүдээр дүүрэн байдаг. Тиймээс, ачаалал эсвэл дэлгүүрийн ажиллагаа бүр удааширдаг, учир нь кэш алдагдахад хүргэдэг - кэш бүхэлдээ удааширч, хог хаягдлыг орхихыг хүлээж байна. Тиймээс, профайл үүсгэгч нь гогцоонд түрхсэн дулаан санамсаргүй дуу чимээг харуулах болно - кодонд тусдаа халуун заавар эсвэл газар байхгүй болно. Зөвхөн чимээ шуугиан. Хэрэв та GC циклийг харвал тэдгээр нь бүгд Залуу үеийнх бөгөөд маш хурдан - микросекунд эсвэл миллисекунд юм. Эцсийн эцэст энэ бүх дурсамж тэр даруй үхдэг. Та хэдэн тэрбум гигабайтыг хуваарилж, тэр тэднийг багасгаж, таслаж, дахин таслана. Энэ бүхэн маш хурдан болдог. Эндээс харахад хямд GC циклүүд, бүхэл бүтэн мөчлөгийн дагуу дулаан дуу чимээ байдаг, гэхдээ бид 5 дахин хурдасгахыг хүсч байна. Яг энэ мөчид таны толгойд ямар нэгэн зүйл хаагдаж, "Яагаад энэ вэ?!" Санах ойн зурвасын халилт нь сонгодог дибаг хийгч дээр харагдахгүй байгаа тул та техник хангамжийн гүйцэтгэлийн тоолуур дибаглагчийг ажиллуулж, өөрөө болон шууд харах хэрэгтэй. Гэхдээ энэ гурван шинж тэмдгээс шууд сэжиглэж болохгүй. Гурав дахь шинж тэмдэг бол та онцолсон зүйлээ хараад профайлаас асуухад тэр: "Та тэрбум эгнээ хийсэн, гэхдээ GC үнэгүй ажилласан" гэж хариулдаг. Ийм зүйл тохиолдсон даруйд та хэт олон объект үүсгэж, санах ойг бүхэлд нь шатаасан гэдгээ ойлгох болно. Үүнийг тодорхойлох арга бий, гэхдээ энэ нь тодорхойгүй байна. 

Асуудал нь өгөгдлийн бүтцэд байна: болж буй бүх зүйлийн үндэс суурь нь нүцгэн бүтэц, энэ нь хэтэрхий том, энэ нь диск дээр 2.7G байна, тиймээс энэ зүйлийг хуулбарлах нь маш их тааламжгүй зүйл юм - та үүнийг сүлжээний байт буферээс шууд ачаалахыг хүсч байна. Таван удаа нааш цааш унших-бичихгүйн тулд бүртгэл рүү оруулна. Харамсалтай нь Java нь анхдагчаар JDK-ийн нэг хэсэг болгон ийм номын сан өгдөггүй. Гэхдээ энэ бол өчүүхэн зүйл, тийм ээ? Үндсэндээ эдгээр нь 5-10 мөр код бөгөөд өөрийн буферт стринг дуудагчийг хэрэгжүүлэхэд хэрэглэгдэх ба энэ нь мөрийн ангийн үйлдлийг давтаж, харин үндсэн байт буферийн эргэн тойронд ороосон байна. Үүний үр дүнд та бараг мөртэй ажиллаж байгаа юм шиг харагдаж байна, гэхдээ үнэндээ буфер руу чиглүүлэгч заагчууд тэнд хөдөлж, түүхий байтууд хаана ч хуулахгүй, улмаар ижил буферүүд дахин дахин ашиглагдах болно. Үйлдлийн систем нь эдгээр байт буферүүдийг далд давхар буферлэх гэх мэт зориулалтын зүйлээ өөртөө авч байгаадаа баяртай байгаа бөгөөд та шаардлагагүй мэдээллийн төгсгөлгүй урсгалыг цаашид нунтаглахаа болино. Дашрамд хэлэхэд, GC-тэй ажиллахдаа сүүлийн GC циклийн дараа санах ойн хуваарилалт бүр процессорт харагдахгүй байх баталгаатай гэдгийг та ойлгож байна уу? Тиймээс, энэ бүхэн кэшэд байх боломжгүй бөгөөд дараа нь 100% баталгаатай алдах тохиолдол гардаг. Заагчтай ажиллахад x86 дээр санах ойноос регистрийг хасахад 1-2 цагийн цикл шаардлагатай бөгөөд энэ нь тохиолдсон даруйд та төлбөрөө төлж, төлж, төлдөг, учир нь санах ой нь бүгд асаалттай байдаг. ЕСӨН кэш – мөн энэ нь санах ойн хуваарилалтын зардал юм. Бодит үнэ цэнэ.

Өөрөөр хэлбэл, өгөгдлийн бүтцийг өөрчлөхөд хамгийн хэцүү зүйл юм. Нэгэнт та буруу өгөгдлийн бүтцийг сонгосон бөгөөд энэ нь дараа нь гүйцэтгэлийг сүйтгэх болно, ихэвчлэн маш их ажил хийх шаардлагатай байдаг, гэхдээ хэрэв хийхгүй бол байдал улам дордох болно. Юуны өмнө та өгөгдлийн бүтцийн талаар бодох хэрэгтэй, энэ нь чухал юм. Энд гол зардал нь "Би Y-ийн хэлбэрт илүү дуртай учраас X өгөгдлийн бүтцийг Y өгөгдлийн бүтцэд хуулсан" гэсэн хэв маягаар ашиглагдаж эхэлсэн бүдүүн өгөгдлийн бүтцэд унадаг. Гэхдээ хуулбарлах ажиллагаа (хямдхан юм шиг) санах ойн зурвасын өргөнийг дэмий үрж, үр ашиггүй зарцуулсан бүх цагийг энд л орхидог. Хэрэв надад JSON-ийн аварга мөр байгаа бөгөөд үүнийг POJO-н бүтэцтэй DOM мод болгон хувиргахыг хүсч байвал тэр мөрийг задлан шинжилж, POJO-г бүтээж, дараа нь POJO-д дахин хандах нь шаардлагагүй зардал гаргахад хүргэнэ. хямд биш. Хэрэв та POJO-г тойрон гүйхээс илүү олон удаа гүйдэг бол. Үүний оронд та стринг тайлж, ямар ч POJO болгохгүйгээр зөвхөн хэрэгтэй зүйлээ гаргаж авахыг оролдож болно. Хэрэв энэ бүхэн хамгийн их гүйцэтгэл шаардагддаг зам дээр тохиолдвол танд ямар ч POJO байхгүй бол та ямар нэгэн байдлаар шууд шугам руу ухах хэрэгтэй.

Яагаад өөрийн програмчлалын хэлийг бий болгох вэ?

Андрей: Зардлын загварыг ойлгохын тулд өөрийн гэсэн жижиг хэлээ бичих хэрэгтэй гэж та хэлсэн...

Хадан цохио: Хэл биш, хөрвүүлэгч. Хэл, хөрвүүлэгч хоёр өөр зүйл. Хамгийн чухал ялгаа нь таны толгойд байдаг. 

Андрей: Дашрамд хэлэхэд, миний мэдэж байгаагаар та өөрийн хэлийг бий болгох туршилт хийж байна. Юуны төлөө?

Хадан цохио: Би чадах учраас! Би хагас тэтгэвэрт гарсан болохоор энэ бол миний хобби. Би амьдралынхаа туршид бусдын хэлийг хэрэгжүүлсэн. Би бас өөрийн кодчилол дээр маш их ажилласан. Мөн түүнчлэн би бусад хэл дээр асуудалтай тулгардаг. Танил зүйлсийг хийх илүү сайн арга замууд байгааг би харж байна. Тэгээд би тэдгээрийг ашиглах болно. Би өөрт байгаа асуудлуудыг Java, Python, өөр ямар ч хэлээр харахаас залхаж байна. Би одоо React Native, JavaScript болон Хайлаас дээр тэтгэвэрт гарах тухай биш, харин идэвхтэй ажлын тухай хобби болгон бичдэг. Би бас Python дээр бичдэг бөгөөд магадгүй Java backends-д зориулсан машин сургалтын талаар үргэлжлүүлэн ажиллах болно. Олон алдартай хэлүүд байдаг бөгөөд тэдгээр нь бүгд сонирхолтой шинж чанартай байдаг. Хүн бүр өөр өөрийнхөөрөө сайн байдаг тул та эдгээр бүх шинж чанаруудыг нэгтгэхийг оролдож болно. Тиймээс би өөрийн сонирхсон зүйл, хэл ярианы зан үйлийг судалж, үндэслэлтэй утгыг олохыг хичээж байна. Тэгээд одоог хүртэл би амжилтанд хүрч байна! Одоогийн байдлаар би санах ойн семантиктай тэмцэж байна, учир нь би үүнийг C, Java-тэй адил байлгахыг хүсч, ачаалал, хадгалалтын хувьд хүчтэй санах ойн загвар, санах ойн семантикийг авахыг хүсч байна. Үүний зэрэгцээ Haskell шиг автомат төрлийн дүгнэлттэй байна. Энд би Хаскелл маягийн дүгнэлтийг C болон Java хэл дээрх санах ойн ажилтай холихыг оролдож байна. Сүүлийн 2-3 сар ийм л зүйл хийж байна, жишээ нь.

Андрей: Хэрэв та бусад хэлнээс илүү сайн талыг нь авдаг хэлийг бүтээх юм бол хэн нэгэн таны санааг авч, ашиглах нь эсрэгээр нь хийх болно гэж та бодож байна уу?

Хадан цохио: Шинэ хэлүүд яг ингэж гарч ирдэг! Java яагаад C-тэй төстэй вэ? Учир нь C нь хүн болгонд ойлгогдох сайн синтакстай байсан бөгөөд Java нь энэхүү синтаксаас санаа авсан бөгөөд төрөл аюулгүй байдал, массивын хязгаарыг шалгах, GC зэргийг нэмсэн бөгөөд С-ээс зарим зүйлийг сайжруулсан. Тэд өөрсдөө нэмсэн. Гэхдээ тэд маш их урам зориг авсан, тийм ээ? Хүн бүр чамаас өмнө гарч ирсэн аваргуудын мөрөн дээр зогсдог - ингэж л ахиц дэвшил гаргадаг.

Андрей: Миний ойлгож байгаагаар таны хэл санах ойд аюулгүй байх болно. Rust-аас зээлсэн шалгагч гэх мэт зүйлийг хэрэгжүүлэх талаар бодож үзсэн үү? Чи түүн рүү харсан уу, чи түүнийг юу гэж бодож байна?

Хадан цохио: За, би олон жилийн турш C хэлийг энэ бүх malloc, үнэ төлбөргүй бичиж, амьдралынхаа туршид гараар удирдаж байна. Гараар удирддаг амьдралын хугацааны 90-95% нь ижил бүтэцтэй байдаг гэдгийг та мэднэ. Мөн гараар хийх нь маш их өвддөг. Тэнд юу болж байгааг, үйлдлээрээ юунд хүрснийг эмхэтгэгч танд хэлэхийг би хүсч байна. Зарим зүйлийн хувьд зээл авах шалгагч үүнийг хайрцагнаас нь хийдэг. Мөн энэ нь мэдээллийг автоматаар харуулж, бүх зүйлийг ойлгох ёстой бөгөөд энэ ойлголтыг өгөхөд надад дарамт учруулахгүй байх ёстой. Энэ нь наад зах нь орон нутгийн зугтах дүн шинжилгээ хийх ёстой бөгөөд хэрэв энэ нь амжилтгүй болсон тохиолдолд ашиглалтын хугацааг тодорхойлсон төрлийн тэмдэглэгээг нэмэх шаардлагатай бөгөөд ийм схем нь зээлсэн шалгагч эсвэл одоо байгаа санах ой шалгагчаас хамаагүй илүү төвөгтэй юм. "Бүх зүйл сайхан" ба "Би юу ч ойлгохгүй байна" гэсэн сонголт - үгүй, илүү сайн зүйл байх ёстой. 
Тиймээс би C хэл дээр маш их код бичсэн хүний ​​хувьд насан туршийн автомат удирдлагатай байх нь хамгийн чухал зүйл гэж бодож байна. Би бас Java хэр их санах ой ашигладагаас залхсан бөгөөд гол гомдол нь GC юм. Java-д санах ойг хуваарилах үед та сүүлийн GC циклийн дотоод санах ойг буцааж авахгүй. Илүү нарийн санах ойн удирдлагатай хэлнүүдэд энэ нь тийм биш юм. Хэрэв та malloc руу залгавал ихэвчлэн ашигладаг байсан санах ойг шууд авах болно. Ихэвчлэн ой санамжтай түр зуурын зүйлийг хийж, тэр даруй буцааж өгдөг. Тэгээд тэр даруй malloc цөөрөмд буцаж ирэх ба дараагийн malloc цикл үүнийг дахин татаж авдаг. Тиймээс санах ойн бодит хэрэглээг тухайн цаг үеийн амьд объектуудын багц болгон бууруулж, алдагдуулдаг. Хэрэв бүх зүйл бүрэн зохисгүй байдлаар урсахгүй бол санах ойн ихэнх хэсэг нь кэш болон процессор руу орж, хурдан ажилладаг. Гэхдээ зөв дарааллаар, зөв ​​газартаа malloc болон үнэгүй дууддаг гарын авлагын санах ойн менежментийг маш их шаарддаг. Зэв нь өөрөө үүнийг зөв зохицуулж чаддаг бөгөөд ихэнх тохиолдолд санах ойн зарцуулалт нь зөвхөн одоогийн тооцоолол хүртэл нарийсч, дараагийн GC циклийг хүлээхээс илүүтэйгээр илүү сайн гүйцэтгэлийг өгдөг. Үүний үр дүнд бид гүйцэтгэлийг сайжруулах маш сонирхолтой арга замыг олж авсан. Мөн нэлээд хүчирхэг - би финтекийн өгөгдлийг боловсруулахдаа ийм зүйлийг хийсэн бөгөөд энэ нь надад тав орчим удаа хурдасгах боломжийг олгосон. Энэ нь ялангуяа процессорууд хурдацтай ажиллахгүй байгаа бөгөөд бид сайжруулалтыг хүлээж байгаа дэлхийд маш том түлхэц юм.

Гүйцэтгэлийн инженерийн карьер

Андрей: Би бас ерөнхийдөө карьерын талаар асуумаар байна. Та HotSpot дахь JIT-ийн ажлаараа нэр хүндтэй болж, дараа нь JVM компани болох Azul руу нүүсэн. Гэхдээ бид аль хэдийн програм хангамж гэхээсээ илүү техник хангамж дээр ажиллаж байсан. Тэгээд тэд гэнэт Big Data болон Machine Learning руу шилжиж, дараа нь залилан илрүүлэх арга руу шилжсэн. Энэ яаж болсон бэ? Эдгээр нь хөгжлийн тэс өөр чиглэлүүд юм.

Хадан цохио: Би нэлээд удаан хугацааны турш программчилж байсан бөгөөд олон төрлийн хичээлд сууж чадсан. Хүмүүс: "Өө, та Java-д зориулж JIT хийсэн хүн!" гэж хэлэхэд энэ нь үргэлж инээдтэй байдаг. Гэхдээ үүнээс өмнө би Apple-ийн лазер принтерүүддээ ашигладаг байсан PostScript хэл дээр ажиллаж байсан. Үүнээс өмнө би дөрөв дэх хэлний хэрэгжилтийг хийсэн. Миний хувьд нийтлэг сэдэв бол багаж хэрэгсэл хөгжүүлэх явдал юм. Би бүх амьдралынхаа туршид бусад хүмүүсийн гайхалтай хөтөлбөрөө бичих хэрэгслүүдийг хийсэн. Гэхдээ би үйлдлийн систем, драйвер, цөмийн түвшний дибаглагч, үйлдлийн систем хөгжүүлэх хэлийг боловсруулахад оролцож байсан бөгөөд энэ нь энгийн зүйлээс эхэлсэн боловч цаг хугацаа өнгөрөх тусам улам төвөгтэй болсон. Гэхдээ гол сэдэв нь багаж хэрэгслийг хөгжүүлэх явдал хэвээр байна. Миний амьдралын томоохон хэсэг Азул, Нар хоёрын хооронд өнгөрсөн бөгөөд энэ нь Жавагийн тухай байсан. Гэхдээ би Big Data болон Machine Learning-д орохдоо гоёмсог малгайгаа дахин өмсөж, "Өө, одоо бидэнд өчүүхэн биш асуудал тулгараад байна, маш олон сонирхолтой зүйл болж, хүмүүс юм хийж байна" гэж хэлсэн. Энэ бол хөгжлийн маш том зам юм.

Тийм ээ, би тархсан тооцоололд үнэхээр дуртай. Миний анхны ажил бол сурталчилгааны төсөл дээр С-д суралцаж байсан. Энэ нь бодит аналог анализаторын үйлдвэрлэсэн аналог OCR-ийн өгөгдлийг цуглуулдаг Zilog Z80 чип дээр тооцооллыг түгээсэн. Энэ бол гайхалтай, бүрэн галзуу сэдэв байсан. Гэхдээ асуудал гарсан, зарим хэсэг нь буруу танигдаагүй байсан тул та зургийг нь аваад нүдээрээ уншиж, юу гэж хэлснийг мэдээлэх чадвартай хүнд үзүүлэх шаардлагатай байсан, тиймээс өгөгдөлтэй ажил, эдгээр ажлууд байсан. өөрийн гэсэн хэлтэй байсан. Энэ бүхнийг боловсруулдаг арын хэсэг байсан - Z80-ууд vt100 терминалуудтай зэрэгцэн ажилладаг - нэг хүнд нэг, Z80 дээр зэрэгцээ програмчлалын загвар байсан. Оддын тохиргоон доторх бүх Z80-уудын хуваалцдаг зарим нийтлэг санах ойн хэсэг; Арын самбарыг мөн хуваалцсан бөгөөд RAM-ийн тал хувийг сүлжээнд хуваалцаж, нөгөө тал нь хувийн эсвэл өөр зүйл рүү явсан. Хуваалцсан ... хагас хуваалцсан санах ойтой утга учиртай цогц зэрэгцээ тархсан систем. Энэ хэзээ байсан бэ... 80-аад оны дундуур хаа нэгтээ би санахгүй байна. Нэлээд удаан хугацааны өмнө. 
Тийм ээ, 30 жил бол нэлээд урт хугацаа гэж бодъё.Тусгайлсан тооцоололтой холбоотой асуудлууд нэлээд удаан хугацаанд оршин тогтнож, хүмүүстэй удаан хугацаанд дайтсаар ирсэн. Beowulf- кластерууд. Ийм кластерууд нь ... Жишээ нь: Ethernet байгаа бөгөөд таны хурдан x86 энэ Ethernet-д холбогдсон, одоо та хуурамч хуваалцсан санах ой авахыг хүсч байна, учир нь тэр үед хэн ч тархсан тооцоолох кодчилол хийж чадахгүй байсан, энэ нь хэтэрхий хэцүү байсан тул тэнд байсан. Энэ нь x86 дээрх санах ойн хамгаалалтын хуудсуудтай хуурамч хуваалцсан санах ой байсан бөгөөд хэрэв та энэ хуудсанд бичсэн бол бид бусад процессоруудад ижил хуваалцсан санах ойд хандах юм бол танаас ачаалах хэрэгтэй гэж хэлсэн бөгөөд ингэснээр протоколыг дэмжих протокол шиг зүйл болно. кэшийн уялдаа холбоо, үүнд зориулсан програм хангамж гарч ирэв. Сонирхолтой ойлголт. Жинхэнэ асуудал нь мэдээж өөр зүйл байсан. Энэ бүхэн үр дүнд хүрсэн боловч гүйцэтгэлийн загваруудыг хэн ч хангалттай сайн түвшинд ойлгоогүй тул та хурдан гүйцэтгэлийн асуудалтай тулгарсан - санах ойд нэвтрэх ямар загварууд байдаг, зангилаанууд бие биенээ эцэс төгсгөлгүй ping хийхгүй байх гэх мэт.

H2O дээр миний олж мэдсэн зүйл бол параллелизм хаана нуугдаж, хаана нуугдаж байгааг тодорхойлох үүрэгтэй хүмүүс нь хөгжүүлэгчид өөрсдөө юм. Би өндөр гүйцэтгэлтэй код бичихэд хялбар бөгөөд хялбар болгосон кодчилолын загварыг гаргаж ирсэн. Гэхдээ удаан ажилладаг код бичих нь хэцүү, муухай харагдах болно. Та удаан код бичихийг нухацтай хичээх хэрэгтэй, та стандарт бус аргуудыг ашиглах хэрэгтэй болно. Тоормосны код нь анх харахад харагдана. Үүний үр дүнд та ихэвчлэн хурдан ажилладаг код бичдэг, гэхдээ хуваалцсан санах ойн хувьд юу хийхээ олж мэдэх хэрэгтэй. Энэ бүхэн нь том массивуудтай холбоотой бөгөөд тэдгээрийн үйл ажиллагаа нь зэрэгцээ Java дахь тогтворгүй том массивуудтай төстэй юм. Хоёр утас зэрэгцээ массив руу бичиж, тэдгээрийн нэг нь ялж, нөгөө нь ялагдаж, аль нь аль нь болохыг та мэдэхгүй байна гэж төсөөлөөд үз дээ. Хэрэв тэдгээр нь тогтворгүй бол захиалга нь таны хүссэн зүйл байж болно - энэ нь үнэхээр сайн ажилладаг. Хүмүүс үйл ажиллагааны дараалалд үнэхээр санаа тавьдаг, тогтворгүй зүйлсийг зөв газарт байрлуулж, санах ойтой холбоотой гүйцэтгэлийн асуудлуудыг зөв газарт нь хүлээж байдаг. Үгүй бол бүх нарийн төвөгтэй тохиолдлууд автоматаар параллель болно гэж найдаж, 1-ээс N хүртэлх гогцоо хэлбэрээр код бичнэ, энд N нь хэдэн их наяд байна. Гэхдээ H2O дээр энэ нь Java ч биш, Scala ч биш, хэрэв хүсвэл "Java хасах" гэж үзэж болно. Энэ нь маш ойлгомжтой програмчлалын загвар бөгөөд гогцоо, массив бүхий энгийн C эсвэл Java код бичихтэй төстэй юм. Гэхдээ үүний зэрэгцээ санах ойг терабайтаар боловсруулж болно. Би H2O ашигладаг хэвээр байна. Би үүнийг үе үе өөр өөр төслүүдэд ашигладаг бөгөөд энэ нь өрсөлдөгчдөөсөө хэдэн арван дахин хурдан, хамгийн хурдан зүйл хэвээр байна. Хэрэв та Big Data-г багана өгөгдлөөр хийж байгаа бол H2O-г ялах нь маш хэцүү байдаг.

Техникийн сорилтууд

Андрей: Таны карьер дахь хамгийн том сорилт юу байсан бэ?

Хадан цохио: Бид асуудлын техникийн болон техникийн бус хэсгийг хэлэлцэж байна уу? Хамгийн том бэрхшээл бол техникийн асуудал биш гэж би хэлмээр байна. 
Техникийн бэрхшээлүүдийн хувьд. Би тэднийг зүгээр л ялсан. Хамгийн том нь юу байдгийг ч мэдэхгүй ч сэтгэл санааны тэмцэл, цаг хугацаа шаардсан нэлээд сонирхолтой зүйлүүд байсан. Сүнд очиход хурдан эмхэтгэгч хийнэ гэдэгтээ итгэлтэй байсан бөгөөд хэдэн ахмадууд хариуд нь би хэзээ ч амжилтанд хүрэхгүй гэж хэлсэн. Гэхдээ би энэ замаар явж, регистрийн хуваарилагч руу хөрвүүлэгч бичсэн, энэ нь маш хурдан байсан. Энэ нь орчин үеийн C1 шиг хурдан байсан ч хуваарилагч нь тэр үед хамаагүй удаан байсан бөгөөд эргээд харахад энэ нь өгөгдлийн бүтцийн томоохон асуудал байсан юм. График регистрийн хуваарилагчийг бичихийн тулд энэ нь надад хэрэгтэй байсан бөгөөд тэр үед байсан бөгөөд маш чухал байсан кодын илэрхийлэл ба хурд хоёрын хоорондох маргааныг би ойлгосонгүй. Өгөгдлийн бүтэц нь тухайн үеийн x86-ийн кэшийн хэмжээнээс ихэвчлэн давсан байдаг тул хэрэв би анх регистрийн хуваарилагч нь нийт чичиргээний цагийн 5-10 хувийг ажиллана гэж таамаглаж байсан бол бодит байдал дээр энэ нь тийм болсон. 50 хувь.

Цаг хугацаа өнгөрөх тусам хөрвүүлэгч илүү цэвэрхэн, илүү үр дүнтэй болж, олон тохиолдолд аймшигтай код үүсгэхээ больж, гүйцэтгэл нь Си хөрвүүлэгчийн гаргадагтай төстэй болж эхэлсэн.Мэдээж хэрэг, чи C хүртэл хурдасгахгүй байх юм бол. . Хэрэв та C шиг код бичвэл илүү олон тохиолдолд C шиг гүйцэтгэлийг авах болно. Цаашлах тусам та С түвшинтэй асимптотоор давхцах кодтой болох тусам регистрийн хуваарилагч нь таны код хурдан эсвэл удаан ажиллаж байгаа эсэхээс үл хамааран бүрэн зүйл мэт харагдаж эхлэв. Би хуваарилагч дээр илүү сайн сонголт хийхийн тулд үргэлжлүүлэн ажилласан. Тэр удааширч, удааширч байсан ч өөр хэн ч даван туулж чадахгүй тохиолдолд илүү сайн, илүү сайн гүйцэтгэлийг үзүүлсэн. Би регистрийн хуваарилагч руу шумбаж, нэг сарын ажлыг тэнд булж, гэнэт бүх код 5% илүү хурдан ажиллаж эхлэх болно. Энэ нь үе үе тохиолдож, бүртгэл хуваарилагч нь урлагийн бүтээл болж хувирсан - хүн бүр үүнийг хайрладаг эсвэл үзэн яддаг байсан бөгөөд академийн хүмүүс "яагаад бүх зүйл ийм байдаг вэ" гэсэн сэдвээр асуулт асууж байсан. шугам скан хийх, мөн ялгаа нь юу вэ. Хариулт нь хэвээр байна: график зураг дээр суурилсан хуваарилагч, буфер кодтой маш болгоомжтой ажиллах нь ялалтын зэвсэгтэй тэнцүү бөгөөд хэн ч ялж чадахгүй хамгийн сайн хослол юм. Мөн энэ нь тодорхой бус зүйл юм. Эмхэтгэгчийн хийдэг бусад бүх зүйл нь нэлээд сайн судлагдсан, гэхдээ тэдгээрийг урлагийн түвшинд хүргэсэн байдаг. Би дандаа эмхэтгэгчийг урлагийн бүтээл болгох ёстой зүйлсийг хийдэг байсан. Гэхдээ бүртгэл хуваарилагчаас бусад нь ер бусын зүйл биш байв. Гол арга бол болгоомжтой байх явдал юм бууруулах ачаалалтай байх ба хэрэв ийм зүйл тохиолдвол (хэрэв сонирхож байгаа бол би илүү дэлгэрэнгүй тайлбарлаж болно) энэ нь гүйцэтгэлийн хуваарь дээр унах эрсдэлгүйгээр илүү түрэмгий байдлаар оруулах боломжтой гэсэн үг юм. Тэр үед олон тооны бүрэн хэмжээний эмхэтгэгчид, шүгэл зүүсэн, бүртгэл хуваарилагчтай байсан ч өөр хэн ч үүнийг хийж чадахгүй байв.

Асуудал нь хэрэв та доторлогооны талбайг нэмэгдүүлэх, нэмэгдүүлэх, доторлогоо хийх шаардлагатай аргуудыг нэмбэл ашигласан утгуудын багц нь регистрийн тооноос даруй давж гарах бөгөөд та тэдгээрийг хасах хэрэгтэй болно. Чухал түвшин нь ихэвчлэн хуваарилагч бууж өгөх үед ирдэг, болон асгарсан нь нэг сайн нэр дэвшигч өөр үнэ цэнэтэй юм, Та зарим нь ерөнхийдөө зэрлэг зүйлсийг зарах болно. Энд оруулахын утга нь та залгах, хадгалах зардал, нэмэлт зардлынхаа нэг хэсгийг алдаж, доторх утгыг харж, цаашид оновчтой болгох боломжтой болно. Дотор оруулах зардал нь олон тооны амьд утгууд үүсдэг бөгөөд хэрэв таны бүртгэлийн хуваарилагч шаардлагатай хэмжээнээс илүү шатаж байвал та тэр даруй алдах болно. Тиймээс ихэнх хуваарилагчдад асуудал тулгардаг: доторлогоо нь тодорхой шугамыг давах үед дэлхий дээрх бүх зүйл багасч, бүтээмжийг бие засах газар руу зайлуулж эхэлдэг. Хөрвүүлэгчийг хэрэгжүүлэгчид зарим эвристикийг нэмдэг: жишээлбэл, хангалттай том хэмжээнээс эхлэн доторлогоог зогсоох, учир нь хуваарилалт нь бүх зүйлийг сүйтгэх болно. Гүйцэтгэлийн графикийн гажуудал ийм байдлаар үүсдэг - та шугаман дээр, доторлогоотой, гүйцэтгэл аажмаар өсөж, дараа нь огцом өсдөг! – Хэтэрхий дотогшоо орсноос болж хурдан үүр шиг унана. Жава гарч ирэхээс өмнө бүх зүйл ингэж ажилладаг байсан. Java илүү их доторлогоо шаарддаг, тиймээс би хуваарилагчаа илүү түрэмгий болгох хэрэгтэй болсон бөгөөд ингэснээр гацахын оронд тэгшитгэх шаардлагатай болсон бөгөөд хэрвээ та хэт их оруулбал асгарч эхлэх боловч "дахиж асгарахгүй" мөч ирнэ. Энэ бол сонирхолтой ажиглалт бөгөөд энэ нь надад санамсаргүй тохиолдсон, тодорхой биш боловч сайн үр дүнд хүрсэн. Би түрэмгий доторлогоо хийж, энэ нь намайг Java болон C гүйцэтгэлийн зэрэгцэн ажилладаг газруудад хүргэсэн. Тэд үнэхээр ойрхон байна - би C код болон үүнтэй төстэй зүйлсээс хамаагүй хурдан Java код бичиж чадна, гэхдээ ерөнхий дүр зургийг нь авч үзвэл тэдгээрийг ойролцоогоор харьцуулж болно. Миний бодлоор энэ гавьяаны нэг хэсэг нь регистрийн хуваарилагч бөгөөд энэ нь намайг аль болох тэнэг оруулах боломжийг олгодог. Би зүгээр л харж байгаа бүхнээ оруулдаг. Энд асуулт бол хуваарилагч сайн ажиллаж байгаа эсэх, үр дүн нь ухаалаг кодтой ажиллаж байгаа эсэх юм. Энэ бүхнийг ойлгож, ажил хэрэг болгох гэдэг том сорилт байлаа.

Бүртгэлийн хуваарилалт, олон цөмийн талаар бага зэрэг

Владимир: Бүртгэлийн хуваарилалт гэх мэт асуудлууд нь мөнхийн, эцэс төгсгөлгүй сэдэв мэт санагддаг. Хэзээ нэгэн цагт ирээдүйтэй мэт санагдаж, дараа нь амьдрал дээр бүтэлгүйтсэн санаа байсан уу?

Хадан цохио: Мэдээж! Бүртгэлийн хуваарилалт нь NP-бүрэн асуудлыг шийдэхийн тулд зарим эвристикийг олохыг оролддог талбар юм. Та төгс шийдэлд хэзээ ч хүрч чадахгүй, тийм үү? Энэ бол ердөө л боломжгүй зүйл. Хараач, Урьдчилан эмхэтгэсэн - энэ нь бас муу ажилладаг. Энд байгаа яриа нь зарим дундаж тохиолдлын тухай юм. Ердийн гүйцэтгэлийн тухай, тиймээс та ердийн гүйцэтгэл сайн гэж бодож байгаа зүйлээ хэмжиж болно - эцэст нь та үүнийг сайжруулахаар ажиллаж байна! Бүртгэлийн хуваарилалт нь гүйцэтгэлтэй холбоотой сэдэв юм. Анхны прототиптэй болмогц энэ нь ажиллаж, шаардлагатай зүйлийг будаж, гүйцэтгэлийн ажил эхэлдэг. Та сайн хэмжиж сурах хэрэгтэй. Яагаад чухал вэ? Хэрэв танд тодорхой өгөгдөл байгаа бол та өөр өөр хэсгүүдийг харж болно: тийм ээ, энэ нь энд тусалсан, гэхдээ энд бүх зүйл эвдэрсэн! Зарим сайн санаанууд гарч ирэхэд та шинэ эвристикийг нэмээд гэнэт бүх зүйл дунджаар арай дээрдэж эхэлдэг. Эсвэл эхлэхгүй байна. Бидний хөгжлийг өмнөх хуваарилагчаас ялгаж чадсан таван хувийн гүйцэтгэлийн төлөө тэмцэж байсан олон тохиолдол надад тохиолдсон. Хаа нэгтээ хожиж, хаа нэгтээ хожигдох бүрт ингэж харагдана. Хэрэв танд гүйцэтгэлийн дүн шинжилгээ хийх сайн хэрэгсэл байгаа бол алдагдсан санаануудыг олж, яагаад бүтэлгүйтсэнийг ойлгох боломжтой. Магадгүй бүх зүйлийг байгаагаар нь үлдээх нь зүйтэй болов уу, эсвэл нарийн тааруулахын тулд илүү нухацтай хандах, эсвэл гадагш гарч өөр зүйл засах нь зүйтэй болов уу. Энэ бол бүхэл бүтэн зүйл юм! Би ийм гайхалтай хакердсан, гэхдээ надад энэ, энэ, энэ нь бас хэрэгтэй бөгөөд тэдгээрийн нийт хослол нь зарим сайжруулалтыг өгдөг. Мөн ганцаардмал хүмүүс бүтэлгүйтэж болно. Энэ бол NP-бүрэн асуудлуудын гүйцэтгэлийн ажлын мөн чанар юм.

Владимир: Хуваарилагч дээр будах гэх мэт зүйлс аль хэдийн шийдэгдсэн асуудал юм шиг санагддаг. За, таны хэлж байгаа зүйлээс харахад энэ нь таны хувьд шийдэгдсэн, тэгвэл энэ нь үнэ цэнэтэй юу ...

Хадан цохио: Ийм байдлаар шийдэгдээгүй байна. Та үүнийг "шийдвэрлэсэн" болгох ёстой. Хэцүү асуудлууд байгаа бөгөөд тэдгээрийг шийдвэрлэх шаардлагатай байна. Үүнийг хийчихвэл бүтээмжийн тал дээр ажиллах цаг болжээ. Та энэ ажилд зохих ёсоор хандах хэрэгтэй - жишиг үнэлгээ хийх, хэмжүүр цуглуулах, өмнөх хувилбар руу буцах үед таны хуучин хакердах ажиллагаа дахин ажиллаж эхлэх (эсвэл эсрэгээр зогссон) нөхцөл байдлыг тайлбарла. Мөн ямар нэгэн зүйлд хүрэх хүртлээ бүү бууж өг. Би аль хэдийн хэлсэнчлэн, хэрвээ үр дүнд хүрээгүй гайхалтай санаанууд байгаа бол санаануудын бүртгэлийг хуваарилах талбарт энэ нь бараг төгсгөлгүй юм. Жишээлбэл, та шинжлэх ухааны нийтлэлүүдийг уншиж болно. Хэдийгээр одоо энэ газар залуу наснаасаа хамаагүй удаан хөдөлж, илүү тодорхой болсон байна. Гэсэн хэдий ч, энэ салбарт ажиллаж буй тоо томшгүй олон хүмүүс байдаг бөгөөд тэдний бүх санааг туршиж үзэх нь зүйтэй бөгөөд тэд бүгд жигүүрт хүлээж байна. Мөн та тэдгээрийг туршиж үзэхгүй бол ямар сайн болохыг хэлж чадахгүй. Тэдгээр нь таны хуваарилагчийн бусад бүх зүйлтэй хэр сайн уялдаж байна вэ, учир нь хуваарилагч нь маш их зүйлийг хийдэг бөгөөд зарим санаанууд нь таны тусгай хуваарилагч дээр ажиллахгүй, харин өөр хуваарилагч дээр амархан ажиллах болно. Хуваарилагчийн хувьд ялах гол арга бол удаан зүйлийг үндсэн замаас гаргаж, удаан замуудын хилийн дагуу хуваахад хүргэдэг. Тиймээс хэрэв та GC ажиллуулахыг хүсвэл удаан замыг сонгон, оновчтой болгох, үл хамаарах зүйл хаях гэх мэт бүх зүйл бол эдгээр зүйл харьцангуй ховор гэдгийг та мэднэ. Тэд үнэхээр ховор, би шалгасан. Та нэмэлт ажил хийдэг бөгөөд энэ нь эдгээр удаан зам дээрх олон хязгаарлалтыг арилгадаг, гэхдээ тэдгээр нь удаан, ховор аялдаг тул энэ нь тийм ч чухал биш юм. Жишээлбэл, тэг заагч - энэ нь хэзээ ч тохиолддоггүй, тийм үү? Та өөр өөр зүйлд зориулсан хэд хэдэн замтай байх хэрэгтэй, гэхдээ тэдгээр нь гол зүйлд саад болохгүй. 

Владимир: Нэг дор олон мянган цөм байхад та олон цөмт системийн талаар ямар бодолтой байна вэ? Энэ ашигтай зүйл мөн үү?

Хадан цохио: GPU-ийн амжилт нь энэ нь маш ашигтай гэдгийг харуулж байна!

Владимир: Тэд нэлээд мэргэшсэн. Ерөнхий зориулалтын процессоруудын талаар юу хэлэх вэ?

Хадан цохио: За тэр Азулын бизнесийн загвар байсан. Хариулт нь хүмүүс урьдчилан таамаглах боломжтой гүйцэтгэлд үнэхээр дуртай байсан эрин үед буцаж ирэв. Тэр үед зэрэгцээ код бичихэд хэцүү байсан. H2O кодчилолын загвар нь маш өргөн цар хүрээтэй боловч ерөнхий зориулалтын загвар биш юм. Магадгүй GPU ашиглахаас арай илүү ерөнхий юм. Бид ийм зүйлийг хөгжүүлэх нарийн төвөгтэй байдлын талаар ярьж байна уу, эсвэл ашиглахад төвөгтэй байдаг уу? Жишээлбэл, Азул надад сонирхолтой хичээл заасан бөгөөд энэ нь тодорхой бус зүйл юм: жижиг кэш нь хэвийн зүйл. 

Амьдралын хамгийн том сорилт

Владимир: Техникийн бус бэрхшээлүүдийн талаар юу хэлэх вэ?

Хадан цохио: Хүмүүст эелдэг, эелдэг байх нь хамгийн том сорилт байсан. Үүний үр дүнд би байнга зөрчилдөөнтэй нөхцөл байдалд ордог. Бүх зүйл буруу болж байгааг мэдэж байсан ч эдгээр асуудлуудыг хэрхэн даван туулахаа мэдэхгүй, даван туулж чадахгүй байсан хүмүүс. Олон арван жил үргэлжилсэн урт хугацааны олон асуудал ийм байдлаар үүссэн. Java нь C1, C2 хөрвүүлэгчтэй байгаа нь үүний шууд үр дагавар юм. Жава хэл дээр арван жил дараалан олон түвшний эмхэтгэл байхгүй байсан нь бас шууд үр дагавар юм. Ийм тогтолцоо бидэнд хэрэгтэй байсан нь ойлгомжтой ч яагаад байгаагүй нь тодорхойгүй. Би нэг инженер ... эсвэл хэсэг инженертэй холбоотой асуудалтай тулгарсан. Нэгэн удаа би Sun-д ажиллаж байхдаа... За, зөвхөн тэр үед ч биш, би ерөнхийдөө бүх зүйлд өөрийн гэсэн бодолтой байдаг. Тэгээд чи өөрийнхөө энэ үнэнийг аваад шууд хэлчихнэ гэдэг үнэн гэж би бодсон. Ялангуяа би ихэнх тохиолдолд үнэхээр цочирддог байсан. Хэрэв та энэ хандлагад дургүй бол ... ялангуяа та буруу зүйл хийж, дэмий зүйл хийж байгаа бол ... Ерөнхийдөө цөөхөн хүн энэ харилцааны хэлбэрийг тэвчиж чадна. Хэдийгээр зарим нь над шиг чадна. Би бүх амьдралаа гавьяаны зарчмаар бүтээсэн. Хэрэв та надад буруу зүйл үзүүлбэл би тэр даруй эргэж хараад: чи дэмий зүйл хэлсэн. Үүний зэрэгцээ, мэдээжийн хэрэг, би уучлалт гуйж, энэ бүхний ач тусыг тэмдэглэж, бусад зөв арга хэмжээ авах болно. Нөгөөтэйгүүр, нийт цагийн жигшмээр их хувийг би цочирдуулмаар зөв хэлж байна. Мөн хүмүүстэй харилцах харилцаанд тийм ч сайн ажилладаггүй. Би аятайхан байх гэж хичээгээгүй ч шууд л асуулт асууж байна. "Энэ хэзээ ч ажиллахгүй, учир нь нэг, хоёр, гурав." Тэгээд тэд "Өө!" Бусад үр дагаврыг үл тоомсорлох нь дээр байж магадгүй юм: жишээлбэл, эхнэрээсээ салсан, түүнээс хойш арван жилийн сэтгэл гутралд хүргэсэн үр дагаварууд.

Бэрхшээл гэдэг бол юу хийж чадах, юу хийх боломжгүй, юу чухал, юу болохгүйг хүмүүстэй хийх тэмцэл юм. Кодлох хэв маягийн талаар олон бэрхшээл тулгарч байсан. Би маш их код бичдэг хэвээр байгаа бөгөөд тэр үед би нэг дээр анхаарлаа төвлөрүүлэхийн оронд хэт олон зэрэгцээ ажил хийж, муу хийж байсан тул удаашрах хүртэл байсан. Эргээд харахад би Java JIT командын кодыг хагасыг нь бичсэн C2 команд. Дараагийн хамгийн хурдан кодлогч тал нь удаан, дараагийнх нь удаан гэж бичсэн бөгөөд энэ нь экспоненциал бууралт байсан. Энэ эгнээний долоо дахь хүн маш удаан байсан - энэ нь үргэлж тохиолддог! Би маш олон кодыг хөндсөн. Би хэн юу бичсэнийг харлаа, би тэдний кодыг ширтэж, тус бүрийг нь хянаж, тэдний хэнээс ч илүү өөрөө бичсээр байв. Энэ арга нь хүмүүст тийм ч сайн тохирохгүй. Зарим хүмүүс үүнд дургүй байдаг. Тэгээд дийлэхгүй болохоор янз бүрийн гомдол эхэлдэг. Жишээ нь, нэг удаа би хэтэрхий их код бичээд багаа эрсдэлд оруулж байгаа учраас кодлохоо боль гэж хэлсэн бөгөөд энэ бүхэн надад хошигнол мэт санагдсан: найз минь, хэрэв багийн бусад гишүүд алга болж, би код бичсээр байвал чи Зөвхөн хагас багаа л хожигдох болно. Нөгөөтэйгүүр, хэрэв би код бичсээр байвал та багийн хагасыг алдвал энэ нь маш муу менежмент мэт санагдаж байна. Би энэ тухай хэзээ ч бодож байгаагүй, хэзээ ч ярьж байгаагүй, гэхдээ энэ нь миний толгойд хаа нэгтээ байсан. "Та нар бүгд надаар тоглоод байна уу?" гэсэн бодол толгойд минь эргэлдэж байв. Тэгэхээр хамгийн том асуудал бол надад болон хүмүүстэй харилцах харилцаа байсан. Одоо би өөрийгөө илүү сайн ойлгож байна, би удаан хугацааны турш програмистуудын багийн ахлагч байсан, одоо би хүмүүст шууд хэлдэг: би бол би хэн бэ, та нар надтай харьцах хэрэгтэй болно - би зогсож байвал зүгээр үү энд? Тэгээд тэд үүнийг шийдэж эхлэхэд бүх зүйл бүтсэн. Үнэндээ би муу ч биш, сайн ч биш, надад ямар ч муу санаа, хувиа хичээсэн хүсэл байхгүй, энэ бол зөвхөн миний мөн чанар, би үүнтэй ямар нэгэн байдлаар амьдрах хэрэгтэй.

Андрей: Саяхан хүн бүр интроверт хүмүүсийн өөрийгөө танин мэдэх, ерөнхийдөө зөөлөн ур чадварын тухай ярьж эхэлсэн. Энэ талаар та юу хэлж чадах вэ?

Хадан цохио: Тийм ээ, энэ бол эхнэрээсээ салснаасаа хойш авсан ухаарал, сургамж байлаа. Гэр бүл салалтаас олж мэдсэн зүйл бол өөрийгөө ойлгох явдал юм. Ингэж л би бусад хүмүүсийг ойлгож эхэлсэн. Энэ харилцан үйлчлэл хэрхэн явагддагийг ойлгоорой. Энэ нь ар араасаа нээлт хийхэд хүргэсэн. Би хэн бэ, юуг төлөөлж байна вэ гэсэн ойлголт байсан. Би юу хийж байна вэ: нэг бол би ажилдаа санаа зовсон, эсвэл зөрчилдөөнөөс зайлсхийж байна, эсвэл өөр зүйлээс зайлсхийж байна - өөрийгөө ухамсарлах энэ түвшин нь өөрийгөө хянахад үнэхээр тусалдаг. Үүний дараа бүх зүйл илүү хялбар болно. Би зөвхөн өөртөө төдийгүй бусад програмистуудад олж мэдсэн зүйл бол сэтгэл санааны дарамтанд орсон үедээ бодлоо үгээр илэрхийлэх чадваргүй байдал юм. Жишээлбэл, та тэнд кодлож, урсгалтай байдалд сууж байна, дараа нь тэд чам руу гүйж ирээд, ямар нэг зүйл эвдэрсэн, одоо таны эсрэг хатуу арга хэмжээ авах болно гэж хашгирч эхэлдэг. Мөн та сэтгэл санааны дарамтанд орсон тул нэг ч үг хэлж чадахгүй. Олж авсан мэдлэг нь танд энэ мөчид бэлдэж, түүнийг даван туулж, ухрах төлөвлөгөөнд шилжих боломжийг олгодог бөгөөд үүний дараа та ямар нэгэн зүйл хийх боломжтой болно. Тийм ээ, та энэ бүхэн хэрхэн ажилладагийг ойлгож эхлэх үед энэ нь амьдралыг өөрчлөх асар том үйл явдал юм. 
Би өөрөө зөв үг олж чадаагүй ч үйлдлийн дарааллыг санав. Хамгийн гол нь энэ хариу үйлдэл нь үг хэллэгтэй адил бие махбодийн шинж чанартай бөгөөд танд орон зай хэрэгтэй болно. Зэн утгаараа ийм орон зай. Энэ бол яг л тайлбарлах ёстой зүйл бөгөөд дараа нь тэр даруй хажуу тийшээ алхаарай - цэвэр бие махбодийн хувьд холдох хэрэгтэй. Би амаар чимээгүй байх үедээ нөхцөл байдлыг сэтгэл хөдлөлөөр боловсруулж чаддаг. Адреналин таны тархинд хүрч, таныг тулаан эсвэл нислэгийн горимд шилжүүлснээр та юу ч хэлж чадахгүй, үгүй ​​- одоо чи тэнэг, ташуурдах инженер, зохих хариу үйлдэл үзүүлэх, тэр ч байтугай дайралтыг зогсоох чадваргүй, халдагч чөлөөтэй байна. дахин дахин дайрах. Та эхлээд өөрийнхөөрөө болж, хяналтаа сэргээж, "тэмцэл эсвэл нисэх" горимоос гарах хэрэгтэй.

Үүний тулд бидэнд аман зай хэрэгтэй. Зүгээр л сул зай. Хэрэв та ямар нэгэн зүйл хэлэх юм бол яг ингэж хэлж болно, тэгээд явж, өөртөө "орон зай" олоорой: цэцэрлэгт хүрээлэнгээр зугаалж, шүршүүрт ороорой - энэ нь хамаагүй. Хамгийн гол нь тэр байдлаасаа түр салах хэрэгтэй. Та ядаж хэдэн секунд унтармагц удирдлага эргэж ирэхэд та ухаалаг бодож эхэлдэг. "За, би тэнэг хүн биш, би тэнэг зүйл хийдэггүй, би үнэхээр хэрэгтэй хүн." Та өөрийгөө итгүүлж чадсан бол дараагийн үе шат руу шилжих цаг болжээ: юу болсныг ойлгох. Чамайг дайрсан, дайралт таны төсөөлөөгүй газраас ирсэн, энэ бол шударга бус, бусармаг отолт байсан. Энэ муу байна. Дараагийн алхам бол халдагч яагаад ийм зүйл хэрэгтэйг ойлгох явдал юм. Үнэхээр яагаад? Магадгүй тэр өөрөө ууртай байгаа юм болов уу? Тэр яагаад галзуурсан юм бэ? Жишээлбэл, тэр өөрийгөө хуурч, хариуцлага хүлээхгүй байгаа юм уу? Энэ бол бүх нөхцөл байдлыг анхааралтай авч үзэх арга юм. Гэхдээ энэ нь маневр хийх зай, үгийн орон зайг шаарддаг. Хамгийн эхний алхам бол амаар харилцах харилцаагаа таслах явдал юм. Үгээр хэлэлцэхээс зайлсхий. Үүнийг цуцалж, аль болох хурдан яв. Хэрэв энэ нь утсаар ярих юм бол зүгээр л утсаа тасал - энэ бол миний хуучин эхнэртэй харилцахдаа сурсан чадвар юм. Ярилцлага тийм ч таатай биш байвал зүгээр л "баяртай" гэж хэлээд утсаа тасал. Утасны нөгөө талаас: "бла бла бла" гэж та: "тиймээ, баяртай!" тэгээд утсаа тасал. Та зүгээр л яриагаа дуусга. Таван минутын дараа ухаалаг сэтгэх чадвар танд эргэж ирэхэд та бага зэрэг даарч, бүх зүйлийг, юу болсон, дараа нь юу болох талаар бодох боломжтой болно. Зүгээр л сэтгэл хөдлөлөөс болж хариу үйлдэл үзүүлэхээс илүү бодолтой хариу үйлдэл хийж эхлээрэй. Миний хувьд өөрийгөө танин мэдэхэд гарсан ахиц дэвшил бол сэтгэлийн дарамттай үед би ярьж чадахгүй байсан явдал юм. Энэ байдлаас гарах, хэрхэн хариу арга хэмжээ авах, асуудлаа нөхөх талаар бодож, төлөвлөх нь ярих боломжгүй тохиолдолд зөв алхам юм. Хамгийн хялбар арга бол сэтгэл хөдлөлийн стресс илэрч буй нөхцөл байдлаас зугтаж, энэ стресст оролцохоо болих явдал юм. Үүний дараа хүн сэтгэдэг, сэтгэж чаддаг бол ярих чадвартай болдог гэх мэт.

Дашрамд хэлэхэд шүүх дээр эсрэг талын өмгөөлөгч танд үүнийг хийхийг оролдсон - одоо яагаад гэдэг нь тодорхой байна. Учир нь тэр таныг нэрээ ч дуудаж чадахгүй тийм байдалд хүргэх чадвартай. Бодит утгаараа чи ярих боломжгүй болно. Хэрэв танд ийм зүйл тохиолдвол, хэл амны хэрүүл маргаантай газар, шүүх гэх мэт газар өөрийгөө олох болно гэдгийг мэдэж байвал өмгөөлөгчтэйгээ ирж болно. Өмгөөлөгч таны талд зогсож, хэл амаар дайрахыг зогсоож, бүрэн хууль ёсны дагуу хийж, алдагдсан Зэн орон зай танд буцаж ирнэ. Жишээлбэл, би ар гэрийнхэн рүүгээ хэд хэдэн удаа залгах шаардлагатай болсон, шүүгч энэ талаар нэлээд найрсаг хандсан боловч эсрэг талын өмгөөлөгч над руу хашгирч, хашгирч, би нэг ч үг хэлж чадсангүй. Эдгээр тохиолдолд зуучлагчийг ашиглах нь надад хамгийн сайн нөлөө үзүүлдэг. Зуучлагч танд тасралтгүй урсаж буй энэ бүх дарамтыг зогсоож, та шаардлагатай Зэн орон зайг олж, түүнтэй хамт ярих чадвар нь эргэж ирдэг. Энэ бол бүхэл бүтэн мэдлэгийн талбар бөгөөд үүнд судлах зүйл, өөрийнхөө дотор нээх их зүйл байдаг бөгөөд энэ бүхэн өөр өөр хүмүүсийн хувьд өөр өөр өндөр түвшний стратегийн шийдвэрүүд болж хувирдаг. Зарим хүмүүст дээр дурьдсан асуудал байдаггүй, ихэвчлэн мэргэжлийн борлуулалт хийдэг хүмүүст байдаггүй. Алдарт дуучид, яруу найрагчид, шашны зүтгэлтнүүд, улстөрчид гэдэг үгээр амьдралаа залгуулдаг энэ бүх хүмүүст үргэлж хэлэх үг байдаг. Тэдэнд тийм асуудал байхгүй, харин надад байдаг.

Андрей: Энэ... гэнэтийн байсан. Гайхалтай, бид аль хэдийн маш их ярилцсан бөгөөд энэ ярилцлагаа дуусгах цаг болжээ. Чуулган дээр бид гарцаагүй уулзаж, энэ яриа хэлэлцээг үргэлжлүүлэх боломжтой. Hydra-д уулзацгаая!

Та 2019 оны 11-р сарын 12-2019-ны өдрүүдэд Санкт-Петербургт болох Hydra XNUMX бага хурлын үеэр Клиффтэй яриагаа үргэлжлүүлж болно. Тэр тайлантай ирнэ "Azul Hardware Transactional Memory туршлага". Тасалбар худалдаж авах боломжтой албан ёсны вэбсайт дээр.

Эх сурвалж: www.habr.com