Cliff Click — Cratus-ის CTO (IoT სენსორები პროცესის გაუმჯობესებისთვის), რამდენიმე სტარტაპის დამფუძნებელი და თანადამფუძნებელი (მათ შორის Rocket Realtime School, Neurensic და H2O.ai) რამდენიმე წარმატებული გასასვლელით. კლიფმა დაწერა თავისი პირველი შემდგენელი 15 წლის ასაკში (პასკალი TRS Z-80-ისთვის)! ის ყველაზე ცნობილია C2-ზე მუშაობით ჯავაში (The Sea of ​​Nodes IR). ამ შემდგენელმა აჩვენა მსოფლიოს, რომ JIT-ს შეეძლო მაღალი ხარისხის კოდის წარმოება, რაც ჯავის ერთ-ერთი მთავარი თანამედროვე პროგრამული პლატფორმის გაჩენის ერთ-ერთი ფაქტორი იყო. შემდეგ კლიფი დაეხმარა Azul Systems-ს შექმნას 864 ბირთვიანი მეინფრეიმი სუფთა Java პროგრამული უზრუნველყოფით, რომელიც მხარს უჭერდა GC პაუზებს 500 გიგაბაიტიან გროვაზე 10 მილიწამში. ზოგადად, კლიფმა მოახერხა JVM-ის ყველა ასპექტზე მუშაობა.

 
ეს ჰაბრაპოსტი შესანიშნავი ინტერვიუა კლიფთან. ჩვენ ვისაუბრებთ შემდეგ თემებზე:

• დაბალი დონის ოპტიმიზაციაზე გადასვლა
• როგორ გავაკეთოთ დიდი რეფაქტორირება
• ღირებულების მოდელი
• დაბალი დონის ოპტიმიზაციის ტრენინგი
• შესრულების გაუმჯობესების პრაქტიკული მაგალითები
• რატომ შექმნათ თქვენი საკუთარი პროგრამირების ენა
• შესრულების ინჟინრის კარიერა
• ტექნიკური გამოწვევები
• ცოტა რამ რეგისტრის განაწილებისა და მრავალ ბირთვების შესახებ
• ყველაზე დიდი გამოწვევა ცხოვრებაში

ინტერვიუს ატარებს:

• ანდრეი სატარინი ამაზონის ვებ სერვისებიდან. თავის კარიერაში მან მოახერხა მუშაობა სრულიად განსხვავებულ პროექტებში: მან შეამოწმა NewSQL განაწილებული მონაცემთა ბაზა Yandex-ში, ღრუბლოვანი გამოვლენის სისტემა Kaspersky Lab-ში, მრავალმოთამაშიანი თამაში Mail.ru-ზე და სერვისი Deutsche Bank-ში სავალუტო ფასების გამოთვლისთვის. დაინტერესებულია ფართომასშტაბიანი backend და განაწილებული სისტემების ტესტირებით.
• ვლადიმერ სიტნიკოვი ნეტკრეკერისგან. ათწლიანი მუშაობა NetCracker OS-ის შესრულებასა და მასშტაბურობაზე, პროგრამული უზრუნველყოფა, რომელსაც იყენებენ ტელეკომის ოპერატორები ქსელისა და ქსელური აღჭურვილობის მართვის პროცესების ავტომატიზაციისთვის. დაინტერესებულია Java და Oracle მონაცემთა ბაზის მუშაობის საკითხებით. ავტორია ათზე მეტი შესრულების გაუმჯობესების ოფიციალურ PostgreSQL JDBC დრაივერში.

დაბალი დონის ოპტიმიზაციაზე გადასვლა

Andrew: თქვენ დიდი სახელი ხართ JIT კომპილაციის, ჯავის და ზოგადად შესრულების სამუშაოების სამყაროში, არა? 

კლდე: ასეა!

Andrew: დავიწყოთ რამდენიმე ზოგადი კითხვებით შესრულების სამუშაოს შესახებ. რას ფიქრობთ არჩევანის შესახებ მაღალი დონის და დაბალი დონის ოპტიმიზაციებს შორის, როგორიცაა CPU დონეზე მუშაობა?

კლდე: დიახ, აქ ყველაფერი მარტივია. ყველაზე სწრაფი კოდი არის ის, რომელიც არასდროს მუშაობს. ამიტომ, თქვენ ყოველთვის უნდა დაიწყოთ მაღალი დონიდან, იმუშაოთ ალგორითმებზე. უკეთესი O აღნიშვნა დაამარცხებს უარეს O აღნიშვნას, თუ საკმარისად დიდი მუდმივები არ ერევა. დაბალი დონის საქმეები ბოლოა. როგორც წესი, თუ თქვენ საკმარისად კარგად ოპტიმიზირებული გაქვთ თქვენი დატის დანარჩენი ნაწილი და ჯერ კიდევ დარჩა რამდენიმე საინტერესო მასალა, ეს დაბალი დონეა. მაგრამ როგორ დავიწყოთ მაღალი დონიდან? საიდან იცით, რომ საკმარისი მაღალი დონის სამუშაო გაკეთდა? ისე... არანაირად. მზა რეცეპტები არ არსებობს. თქვენ უნდა გესმოდეთ პრობლემა, გადაწყვიტოთ რას აპირებთ (რათა მომავალში ზედმეტი ნაბიჯები არ გადადგათ) და შემდეგ შეგიძლიათ გახსნათ პროფილერი, რომელსაც შეუძლია რაიმე სასარგებლო თქვას. რაღაც მომენტში, თქვენ თვითონ ხვდებით, რომ თავი დააღწიეთ არასაჭირო ნივთებს და დროა გააკეთოთ დაბალი დონის დახვეწა. ეს, რა თქმა უნდა, ხელოვნების განსაკუთრებული სახეობაა. ბევრი ადამიანი აკეთებს არასაჭირო საქმეებს, მაგრამ ისე სწრაფად მოძრაობს, რომ პროდუქტიულობაზე ფიქრის დრო არ რჩება. მაგრამ ეს მანამ, სანამ კითხვა პირდაპირ არ წამოიჭრება. როგორც წესი, 99% არავის აინტერესებს, რას ვაკეთებ, სანამ იმ მომენტამდე, როდესაც მნიშვნელოვანი რამ ჩნდება კრიტიკულ გზაზე, რომელიც არავის აინტერესებს. და აქ ყველა იწყებს შენზე წუხილს იმის შესახებ, თუ "რატომ არ მუშაობდა თავიდანვე იდეალურად". ზოგადად, ყოველთვის არის რაღაც გასაუმჯობესებელი შესრულებაში. მაგრამ 99% შემთხვევაში თქვენ არ გაქვთ ლიდერები! თქვენ უბრალოდ ცდილობთ, რომ რაღაც იმუშაოთ და ამ პროცესში ხვდებით, რა არის მნიშვნელოვანი. წინასწარ ვერასოდეს გაიგებ, რომ ეს ნაჭერი უნდა იყოს სრულყოფილი, ასე რომ, ფაქტობრივად, ყველაფერში უნდა იყო სრულყოფილი. მაგრამ ეს შეუძლებელია და თქვენ ამას არ აკეთებთ. ყოველთვის ბევრი რამ არის გამოსასწორებელი - და ეს სრულიად ნორმალურია.

როგორ გავაკეთოთ დიდი რეფაქტორირება

Andrew: როგორ მუშაობ სპექტაკლზე? ეს ჯვარედინი პრობლემაა. მაგალითად, გქონიათ ოდესმე მუშაობა იმ პრობლემებზე, რომლებიც წარმოიქმნება მრავალი არსებული ფუნქციონალური კვეთის შედეგად?

კლდე: ვცდილობ თავიდან ავიცილო. თუ ვიცი, რომ შესრულება იქნება პრობლემა, ვფიქრობ ამაზე სანამ დავიწყებ კოდირებას, განსაკუთრებით მონაცემთა სტრუქტურებთან დაკავშირებით. მაგრამ ხშირად ამ ყველაფერს ძალიან გვიან აღმოაჩენთ. შემდეგ კი თქვენ უნდა გადახვიდეთ უკიდურეს ზომებზე და გააკეთოთ ის, რასაც მე ვუწოდებ "გადაწერა და დაიპყრო": თქვენ უნდა აიღოთ საკმარისად დიდი ნაწილი. ზოგიერთი კოდი კვლავ უნდა გადაიწეროს შესრულების პრობლემების ან სხვა რამის გამო. როგორიც არ უნდა იყოს კოდის გადაწერის მიზეზი, თითქმის ყოველთვის უკეთესია უფრო დიდი ნაწილის გადაწერა, ვიდრე პატარა ნაჭერი. ამ დროს ყველა იწყებს შიშის კანკალს: "ღმერთო ჩემო, ამდენ კოდს ვერ შეეხები!" მაგრამ სინამდვილეში, ეს მიდგომა თითქმის ყოველთვის ბევრად უკეთ მუშაობს. თქვენ დაუყოვნებლივ უნდა აიღოთ დიდი პრობლემა, დახაზოთ დიდი წრე მის გარშემო და თქვათ: მე გადავწერ ყველაფერს წრის შიგნით. საზღვარი გაცილებით მცირეა, ვიდრე მის შიგნით არსებული შინაარსი, რომელიც უნდა შეიცვალოს. და თუ საზღვრების ასეთი გამოკვეთა საშუალებას გაძლევთ სრულყოფილად შეასრულოთ სამუშაო შიგნით, ხელები თავისუფალი გაქვთ, გააკეთეთ ის, რაც გსურთ. როგორც კი გააცნობიერებთ პრობლემას, გადაწერის პროცესი ბევრად უფრო ადვილია, ასე რომ დიდი კბენა!
ამავდროულად, როდესაც თქვენ აკეთებთ დიდ გადაწერას და ხვდებით, რომ შესრულება იქნება პრობლემა, შეგიძლიათ დაუყოვნებლივ დაიწყოთ ამაზე ფიქრი. ეს ჩვეულებრივ იქცევა მარტივ რაღაცეებში, როგორიცაა: „არ დააკოპიროთ მონაცემები, მართეთ მონაცემები რაც შეიძლება მარტივად, გახადეთ ის პატარა“. დიდ გადაწერებში, არსებობს შესრულების გაუმჯობესების სტანდარტული გზები. და ისინი თითქმის ყოველთვის ტრიალებს მონაცემების გარშემო.

ღირებულების მოდელი

Andrew: ერთ-ერთ პოდკასტში თქვენ ისაუბრეთ ღირებულების მოდელებზე პროდუქტიულობის კონტექსტში. შეგიძლია ამიხსნა რას გულისხმობ ამაში?

კლდე: Რა თქმა უნდა. მე დავიბადე ეპოქაში, როდესაც პროცესორის შესრულება ძალიან მნიშვნელოვანი იყო. და ეს ეპოქა ისევ ბრუნდება - ბედი ირონიის გარეშე არ არის. დავიწყე ცხოვრება რვა ბიტიანი მანქანების დღეებში; ჩემი პირველი კომპიუტერი მუშაობდა 256 ბაიტით. ზუსტად ბაიტები. ყველაფერი ძალიან პატარა იყო. საჭირო იყო ინსტრუქციების დათვლა და რაც ჩვენ დავიწყეთ პროგრამირების ენების დასტაზე ასვლა, ენები უფრო და უფრო მეტს იღებდნენ. იყო Assembler, შემდეგ Basic, შემდეგ C და C ზრუნავდა ბევრ დეტალზე, როგორიცაა რეგისტრაციის განაწილება და ინსტრუქციის შერჩევა. მაგრამ იქ ყველაფერი სავსებით ნათელი იყო და თუ ცვლადის ინსტანციას მივანიშნებდი, მაშინ მივიღებდი დატვირთვას და ამ ინსტრუქციის ღირებულება ცნობილია. აპარატურა აწარმოებს მანქანების ციკლების გარკვეულ რაოდენობას, ასე რომ, სხვადასხვა ნივთების შესრულების სიჩქარე შეიძლება გამოითვალოს უბრალოდ ყველა ინსტრუქციის დამატებით, რომლის შესრულებასაც აპირებთ. თითოეული შედარება / ტესტი / ფილიალი / ზარი / ჩატვირთვა / მაღაზია შეიძლება დაემატოს და თქვა: ეს არის შესრულების დრო თქვენთვის. შესრულების გაუმჯობესებაზე მუშაობისას აუცილებლად მიაქცევთ ყურადღებას, თუ რა რიცხვები შეესაბამება მცირე ცხელ ციკლებს. 
მაგრამ როგორც კი გადახვალთ Java-ზე, Python-ზე და მსგავს რამეებზე, ძალიან სწრაფად შორდებით დაბალი დონის აპარატურას. რა ღირს ჯავაში მიმღების გამოძახება? თუ JIT HotSpot-ში სწორია ჩასმული, ჩაიტვირთება, მაგრამ თუ ეს არ გააკეთა, ეს იქნება ფუნქციის გამოძახება. ვინაიდან ზარი არის ცხელ ციკლზე, ის გადალახავს ყველა სხვა ოპტიმიზაციას ამ ციკლში. შესაბამისად, რეალური ღირებულება გაცილებით მაღალი იქნება. და თქვენ მაშინვე დაკარგავთ კოდის ნაწილის დათვალიერების უნარს და გესმით, რომ ჩვენ უნდა შევასრულოთ ის პროცესორის საათის სიჩქარის, მეხსიერების და გამოყენებული ქეშის მიხედვით. ეს ყველაფერი საინტერესო ხდება მხოლოდ იმ შემთხვევაში, თუ ნამდვილად შეხვალ სპექტაკლში.
ახლა ჩვენ აღმოვჩნდებით სიტუაციაში, როდესაც პროცესორის სიჩქარე თითქმის ათწლეულის განმავლობაში არ გაიზარდა. ძველი დრო დაბრუნდა! თქვენ აღარ შეგიძლიათ დაეყრდნოთ კარგ ერთძაფის შესრულებას. მაგრამ თუ მოულოდნელად შეხვალთ პარალელურ გამოთვლებში, ეს წარმოუდგენლად რთულია, ყველა გიყურებთ, როგორც ჯეიმს ბონდი. ათჯერადი აჩქარება აქ ჩვეულებრივ ხდება ისეთ ადგილებში, სადაც ვიღაცამ რაღაც გააფუჭა. კონკურენტულობა დიდ შრომას მოითხოვს. ამ XNUMXx სიჩქარის მისაღებად, თქვენ უნდა გესმოდეთ ღირებულების მოდელი. რა და რა ღირს? და ამისათვის თქვენ უნდა გესმოდეთ, თუ როგორ ჯდება ენა ძირეულ აპარატურაზე.
მარტინ ტომპსონმა თავისი ბლოგისთვის შესანიშნავი სიტყვა აირჩია მექანიკური სიმპათია! თქვენ უნდა გესმოდეთ, რას აპირებს აპარატურა, ზუსტად როგორ გააკეთებს ამას და რატომ აკეთებს იმას, რასაც აკეთებს პირველ რიგში. ამის გამოყენებით, საკმაოდ მარტივია ინსტრუქციების დათვლა და იმის გარკვევა, თუ სად მიდის შესრულების დრო. თუ არ გაქვთ შესაბამისი ვარჯიში, უბრალოდ ეძებთ შავ კატას ბნელ ოთახში. მე ვხედავ ადამიანებს, რომლებიც მუდმივად ახდენენ მუშაობის ოპტიმიზაციას, რომლებსაც წარმოდგენა არ აქვთ, რას აკეთებენ ისინი. ისინი ძალიან განიცდიან და დიდ პროგრესს არ აღწევენ. და როდესაც მე ვიღებ იგივე კოდის ნაწილს, ჩავრთავ რამდენიმე პატარა ხრიკს და ვიღებ ხუთ ან ათჯერ აჩქარებას, ისინი ასე გამოიყურება: კარგი, ეს არ არის სამართლიანი, ჩვენ უკვე ვიცოდით, რომ უკეთესი იყავი. საოცარი. რაზე ვლაპარაკობ... ღირებულების მოდელი იმაზეა, თუ რა კოდს წერ და რამდენად სწრაფად მუშაობს საშუალო სურათზე.

Andrew: და როგორ შეგიძლია თავში ასეთი მოცულობის შენარჩუნება? ეს მიიღწევა მეტი გამოცდილებით თუ? საიდან ასეთი გამოცდილება?

კლდე: კარგი, მე არ მიმიღია ჩემი გამოცდილება ყველაზე მარტივად. მე დავაპროგრამე ასამბლეაში იმ დღეებში, როდესაც თქვენ შეგეძლოთ თითოეული ინსტრუქციის გაგება. სულელურად ჟღერს, მაგრამ მას შემდეგ Z80 ინსტრუქციის ნაკრები ყოველთვის დარჩა ჩემს თავში, მეხსიერებაში. ხალხის სახელები არ მახსოვს საუბრიდან ერთ წუთში, მაგრამ მახსოვს 40 წლის წინ დაწერილი კოდი. სასაცილოა, სინდრომს ჰგავს"იდიოტი მეცნიერი".

დაბალი დონის ოპტიმიზაციის ტრენინგი

Andrew: არის თუ არა შესვლის უფრო ადვილი გზა?

კლდე: Კი და არა. აპარატურა, რომელსაც ჩვენ ყველა ვიყენებთ, დროთა განმავლობაში დიდად არ შეცვლილა. ყველა იყენებს x86-ს, გარდა Arm სმარტფონებისა. თუ თქვენ არ აკეთებთ რაიმე სახის ჰარდკორის ჩაშენებას, თქვენ აკეთებთ იგივეს. კარგი, შემდეგი. ინსტრუქციები ასევე არ შეცვლილა საუკუნეების განმავლობაში. უნდა წახვიდე და დაწერო რამე ასამბლეაში. არც ისე ბევრი, მაგრამ საკმარისია გაგების დასაწყებად. შენ იღიმი, მაგრამ მე სრულიად სერიოზულად ვლაპარაკობ. თქვენ უნდა გესმოდეთ შესაბამისობა ენასა და აპარატურას შორის. ამის შემდეგ თქვენ უნდა წახვიდეთ და დაწეროთ ცოტა და გააკეთოთ პატარა სათამაშო შემდგენელი პატარა სათამაშო ენისთვის. სათამაშოს მსგავსი ნიშნავს, რომ ის უნდა დამზადდეს გონივრულ დროში. ეს შეიძლება იყოს ძალიან მარტივი, მაგრამ მან უნდა შექმნას ინსტრუქციები. ინსტრუქციის გენერირების აქტი დაგეხმარებათ გაიგოთ ღირებულების მოდელი ხიდის მაღალი დონის კოდს შორის, რომელსაც ყველა წერს და აპარატის კოდს, რომელიც მუშაობს აპარატურაზე. ეს კორესპონდენცია დაიწვება ტვინში შემდგენელის დაწერის დროს. უმარტივესი შემდგენელიც კი. ამის შემდეგ შეგიძლიათ დაიწყოთ ჯავის ყურება და ის ფაქტი, რომ მისი სემანტიკური უფსკრული გაცილებით ღრმაა და მასზე ხიდების აგება გაცილებით რთულია. ჯავაში გაცილებით რთულია იმის გაგება, ჩვენი ხიდი კარგი აღმოჩნდა თუ ცუდი, რა გამოიწვევს მის დაშლას და რა არა. მაგრამ თქვენ გჭირდებათ რაიმე სახის საწყისი წერტილი, სადაც შეხედავთ კოდს და გესმით: „დიახ, ეს მიმღები უნდა იყოს ჩასმული ყოველ ჯერზე“. შემდეგ კი აღმოჩნდება, რომ ზოგჯერ ეს ხდება, გარდა იმ სიტუაციისა, როდესაც მეთოდი ძალიან დიდი ხდება და JIT იწყებს ყველაფრის შერწყმას. ასეთი ადგილების მუშაობის პროგნოზირება შესაძლებელია მყისიერად. როგორც წესი, გეტერები კარგად მუშაობს, მაგრამ შემდეგ თქვენ უყურებთ დიდ ცხელ მარყუჟებს და ხვდებით, რომ არსებობს რამდენიმე ფუნქციის გამოძახება, რომლებიც არ იციან რას აკეთებენ. ეს არის მიმღებების ფართოდ გამოყენების პრობლემა, მათი ჩასმული არ არის ის, რომ გაურკვეველია არის თუ არა ისინი მიმღები. თუ თქვენ გაქვთ სუპერ მცირე კოდის ბაზა, შეგიძლიათ უბრალოდ დაიმახსოვროთ და შემდეგ თქვათ: ეს არის მიმღები და ეს არის სეტერი. დიდი კოდის ბაზაში, თითოეული ფუნქცია ცხოვრობს თავისი ისტორია, რომელიც, ზოგადად, არავისთვის არის ცნობილი. პროფილერი ამბობს, რომ ჩვენ დავკარგეთ დროის 24% რაღაც მარყუჟზე და იმის გასაგებად, თუ რას აკეთებს ეს ციკლი, უნდა შევხედოთ თითოეულ ფუნქციას შიგნით. ამის გაგება ფუნქციის შესწავლის გარეშე შეუძლებელია და ეს სერიოზულად ანელებს გაგების პროცესს. ამიტომაც არ ვიყენებ გეტერებსა და სეტერებს, ახალ საფეხურს მივაღწიე!
სად მივიღოთ ფასიანი მოდელი? რა თქმა უნდა, რაღაცის წაკითხვა შეგიძლია... მაგრამ მე ვფიქრობ, რომ საუკეთესო გზაა მოქმედება. პატარა შემდგენელის დამზადება საუკეთესო გზა იქნება ღირებულების მოდელის გასაგებად და საკუთარ თავში მორგებისთვის. პატარა შემდგენელი, რომელიც შესაფერისი იქნება მიკროტალღური ღუმელის დასაპროგრამებლად, დამწყებთათვის ამოცანაა. კარგი, ვგულისხმობ, თუ უკვე გაქვთ პროგრამირების უნარები, მაშინ ეს საკმარისი უნდა იყოს. ეს ყველაფერი, როგორიცაა სტრიქონის გარჩევა, რომელიც თქვენ გაქვთ, როგორც ალგებრული გამოხატულება, მათემატიკური მოქმედებების ინსტრუქციების ამოღება იქიდან სწორი თანმიმდევრობით, სწორი მნიშვნელობების აღება რეგისტრებიდან - ეს ყველაფერი კეთდება ერთდროულად. და სანამ ამას აკეთებთ, ის თქვენს ტვინში ჩაიბეჭდება. ვფიქრობ, ყველამ იცის, რას აკეთებს შემდგენელი. და ეს საშუალებას მოგცემთ გაიგოთ ღირებულების მოდელი.

შესრულების გაუმჯობესების პრაქტიკული მაგალითები

Andrew: კიდევ რას უნდა მიაქციოთ ყურადღება პროდუქტიულობაზე მუშაობისას?

კლდე: მონაცემთა სტრუქტურები. სხვათა შორის, დიახ, დიდი ხანია არ მისწავლია ეს გაკვეთილები... სარაკეტო სკოლა. სახალისო იყო, მაგრამ დიდ ძალისხმევას მოითხოვდა და მეც მაქვს სიცოცხლე! ᲙᲐᲠᲒᲘ. ასე რომ, ერთ-ერთ დიდ და საინტერესო გაკვეთილზე, „სად მიდის თქვენი შესრულება“, მე მივეცი მაგალითი სტუდენტებს: CSV ფაილიდან წაიკითხეს ორნახევარი გიგაბაიტი fintech მონაცემები და შემდეგ მათ უნდა გამოეთვალათ გაყიდული პროდუქტების რაოდენობა. . რეგულარული ბაზრის მონაცემები. UDP პაკეტები გადაკეთდა ტექსტის ფორმატში 70-იანი წლებიდან. ჩიკაგოს სასაქონლო ბირჟა - ყველა სახის ნივთი, როგორიცაა კარაქი, სიმინდი, სოიო, მსგავსი რამ. საჭირო იყო ამ პროდუქტების დათვლა, ტრანზაქციების რაოდენობა, სახსრებისა და საქონლის გადაადგილების საშუალო მოცულობა და ა.შ. სავაჭრო მათემატიკა საკმაოდ მარტივია: იპოვნეთ პროდუქტის კოდი (ეს არის 1-2 სიმბოლო ჰეშის ცხრილში), მიიღეთ თანხა, დაამატეთ იგი ერთ-ერთ სავაჭრო კომპლექტში, დაამატეთ მოცულობა, დაამატეთ ღირებულება და კიდევ რამდენიმე რამ. ძალიან მარტივი მათემატიკა. სათამაშოების განხორციელება ძალიან მარტივი იყო: ყველაფერი ფაილშია, მე ვკითხულობ ფაილს და ვმოძრაობ მასში, ვყოფ ცალკეულ ჩანაწერებს Java სტრიქონებში, ვეძებ მათში საჭირო ნივთებს და ვამატებ მათ ზემოთ აღწერილი მათემატიკის მიხედვით. და ის მუშაობს დაბალ სიჩქარეზე.

ამ მიდგომით, აშკარაა, რა ხდება და პარალელური გამოთვლები არ დაგვეხმარება, არა? გამოდის, რომ შესრულების ხუთჯერ გაზრდის მიღწევა შესაძლებელია მხოლოდ მონაცემთა სწორი სტრუქტურების არჩევით. და ეს აოცებს გამოცდილ პროგრამისტებსაც კი! ჩემს კონკრეტულ შემთხვევაში, ხრიკი იყო ის, რომ თქვენ არ უნდა გააკეთოთ მეხსიერების განაწილება ცხელ ციკლში. კარგი, ეს არ არის მთელი სიმართლე, მაგრამ ზოგადად - არ უნდა მონიშნოთ "ერთხელ X-ში", როდესაც X საკმარისად დიდია. როდესაც X არის ორნახევარი გიგაბაიტი, თქვენ არ უნდა გამოყოთ არაფერი "ასოზე ერთხელ", ან "ერთ სტრიქონზე" ან "ერთ ველზე ერთხელ", მსგავსი არაფერი. სწორედ აქ იხარჯება დრო. როგორ მუშაობს ეს საერთოდ? წარმოიდგინე, რომ დამირეკავს String.split() ან BufferedReader.readLine(). Readline აკეთებს სტრიქონს ბაიტების ნაკრებიდან, რომლებიც მოვიდა ქსელში, ერთხელ ყოველი ხაზისთვის, ყოველი ასეული მილიონი ხაზისთვის. მე ვიღებ ამ ხაზს, ვაანალიზებ და ვაგდებ. რატომ ვყრი მას - კარგი, მე უკვე დავამუშავე, ეს ყველაფერია. ასე რომ, ამ 2.7G-დან წაკითხულ თითოეულ ბაიტზე ორი სიმბოლო ჩაიწერება ხაზში, ანუ უკვე 5.4G და მე აღარ მჭირდება ისინი არაფრისთვის, ამიტომ გადაყრიან. თუ გადავხედავთ მეხსიერების გამტარუნარიანობას, ჩვენ ვტვირთავთ 2.7 გ-ს, რომელიც გადის პროცესორში მეხსიერების და მეხსიერების ავტობუსში, შემდეგ კი ორჯერ მეტი იგზავნება მეხსიერებაში მდებარე ხაზში და ეს ყველაფერი ფუჭდება ყოველი ახალი ხაზის შექმნისას. მაგრამ მე უნდა წავიკითხო, აპარატურა კითხულობს, მაშინაც კი, თუ ყველაფერი მოგვიანებით გაფუჭდა. და უნდა დავწერო, რადგან ხაზი შევქმენი და ქეშები სავსეა - ქეში 2.7გ-ს ვერ იტევს. ასე რომ, ყოველ წაკითხულ ბაიტზე მე ვკითხულობ კიდევ ორ ბაიტს და ვწერ კიდევ ორ ბაიტს, და ბოლოს მათ აქვთ 4:1 თანაფარდობა - ამ თანაფარდობაში ჩვენ ვკარგავთ მეხსიერების სიჩქარეს. შემდეგ კი გამოდის, რომ თუ გავაკეთებ String.split() – ეს არ არის ბოლო შემთხვევა, როცა ამას ვაკეთებ, შეიძლება კიდევ 6-7 ველი იყოს შიგნით. ასე რომ, CSV-ს წაკითხვის კლასიკური კოდი და შემდეგ სტრიქონების გარჩევა იწვევს მეხსიერების გამტარუნარიანობის დაკარგვას დაახლოებით 14:1-თან შედარებით, რაც რეალურად გსურთ გქონდეთ. თუ გადაყრით ამ არჩევანს, შეგიძლიათ მიიღოთ ხუთჯერადი სიჩქარე.

და ეს არც ისე რთულია. თუ კოდს სწორი კუთხიდან შეხედავთ, ეს ყველაფერი საკმაოდ მარტივი ხდება, როგორც კი გააცნობიერებთ პრობლემას. საერთოდ არ უნდა შეწყვიტო მეხსიერების გამოყოფა: ერთადერთი პრობლემა ისაა, რომ რაღაცას ანაწილებ და ის მაშინვე კვდება და გზაში წვავს მნიშვნელოვან რესურსს, რაც ამ შემთხვევაში მეხსიერების გამტარუნარიანობაა. და ეს ყველაფერი იწვევს პროდუქტიულობის ვარდნას. x86-ზე, ჩვეულებრივ, საჭიროა პროცესორის ციკლების აქტიური დაწვა, მაგრამ აქ თქვენ დაწვათ მთელი მეხსიერება ბევრად ადრე. გამოსავალი არის გამონადენის რაოდენობის შემცირება. 
პრობლემის მეორე ნაწილი ის არის, რომ თუ პროფილს აწარმოებთ, როდესაც მეხსიერების ზოლი ამოიწურება, სწორედ მაშინ, როცა ეს მოხდება, თქვენ ჩვეულებრივ ელოდებით ქეშის დაბრუნებას, რადგან ის სავსეა ნაგვით, რომელიც თქვენ ახლახან შექმენით, ყველა ეს ხაზი. ამიტომ, ყოველი ჩატვირთვის ან შენახვის ოპერაცია ხდება ნელი, რადგან ისინი იწვევს ქეშის გაცდენას - მთელი ქეში ნელი გახდა და ელოდება ნაგვის დატოვებას. ამიტომ, პროფილერი უბრალოდ აჩვენებს თბილ შემთხვევით ხმაურს, რომელიც გაჟღენთილია მთელ მარყუჟში - არ იქნება ცალკე ცხელი ინსტრუქცია ან ადგილი კოდში. მხოლოდ ხმაური. და თუ გადავხედავთ GC ციკლებს, ისინი ყველა ახალგაზრდა თაობაა და სუპერ სწრაფი - მიკროწამები ან მილიწამები მაქსიმუმ. ყოველივე ამის შემდეგ, მთელი ეს მეხსიერება მყისიერად კვდება. თქვენ გამოყოფთ მილიარდობით გიგაბაიტს და ის ჭრის მათ, ჭრის და ისევ ჭრის. ეს ყველაფერი ძალიან სწრაფად ხდება. გამოდის, რომ არის იაფი GC ციკლები, თბილი ხმაური მთელი ციკლის განმავლობაში, მაგრამ ჩვენ გვინდა მივიღოთ 5x სიჩქარე. ამ მომენტში რაღაც უნდა დაიხუროს თავში და ჟღერდეს: "რატომ არის ეს?" მეხსიერების ზოლის გადინება არ არის ნაჩვენები კლასიკურ გამართვაში; თქვენ უნდა გაუშვათ ტექნიკის შესრულების მრიცხველის გამართვა და ნახოთ იგი თავად და პირდაპირ. მაგრამ ეს არ შეიძლება პირდაპირ ეჭვობდეს ამ სამი სიმპტომიდან. მესამე სიმპტომია, როდესაც უყურებთ რას ხაზს უსვამთ, ჰკითხეთ პროფილერს და ის პასუხობს: „თქვენ შექმენით მილიარდი სტრიქონი, მაგრამ GC მუშაობდა უფასოდ“. როგორც კი ეს მოხდება, თქვენ ხვდებით, რომ თქვენ შექმენით ძალიან ბევრი ობიექტი და დაწვეთ მთელი მეხსიერების ზოლი. ამის გარკვევის გზა არსებობს, მაგრამ ეს არ არის აშკარა. 

პრობლემა მონაცემთა სტრუქტურაშია: შიშველი სტრუქტურა, რომელიც საფუძვლად უდევს ყველაფერს, რაც ხდება, ის ძალიან დიდია, არის 2.7 გ დისკზე, ამიტომ ამ ნივთის ასლის გაკეთება ძალიან არასასურველია - თქვენ გსურთ დაუყოვნებლივ ჩატვირთოთ იგი ქსელის ბაიტის ბუფერიდან. რეესტრებში, რათა არ მოხდეს სტრიქონზე წაკითხვა-ჩაწერა ხუთჯერ წინ და უკან. სამწუხაროდ, ჯავა ნაგულისხმევად არ გაძლევთ ასეთ ბიბლიოთეკას, როგორც JDK-ის ნაწილს. მაგრამ ეს ტრივიალურია, არა? არსებითად, ეს არის კოდის 5-10 სტრიქონი, რომელიც გამოყენებული იქნება თქვენი ბუფერული სტრიქონების ჩამტვირთველის განსახორციელებლად, რომელიც იმეორებს სტრიქონების კლასის ქცევას, თანაც არის ბაიტის ბუფერის გარშემო. შედეგად, გამოდის, რომ თქვენ მუშაობთ თითქმის ისე, თითქოს სტრიქონებით, მაგრამ სინამდვილეში ბუფერის მაჩვენებლები მოძრაობენ იქ, და ნედლეული ბაიტები არსად არ კოპირდება და, შესაბამისად, იგივე ბუფერები ხელახლა გამოიყენება არაერთხელ, და ოპერაციული სისტემა სიამოვნებით აიღებს საკუთარ თავზე იმ ნივთებს, რისთვისაც ის არის შექმნილი, როგორიცაა ამ ბაიტის ბუფერების ფარული ორმაგი ბუფერირება, და თქვენ აღარ ამუშავებთ არასაჭირო მონაცემების გაუთავებელ ნაკადს. სხვათა შორის, გესმით, რომ GC-თან მუშაობისას გარანტირებულია, რომ მეხსიერების თითოეული განაწილება არ იქნება ხილული პროცესორისთვის ბოლო GC ციკლის შემდეგ? ამიტომ, ეს ყველაფერი არ შეიძლება იყოს ქეშში და შემდეგ ხდება 100% გარანტირებული გამოტოვება. მაჩვენებელთან მუშაობისას, x86-ზე, მეხსიერებიდან რეგისტრის გამოკლებას სჭირდება 1-2 საათის ციკლი და როგორც კი ეს მოხდება, თქვენ იხდით, იხდით, იხდით, რადგან მეხსიერება ჩართულია. ცხრა ქეში - და ეს არის მეხსიერების გამოყოფის ღირებულება. რეალური ღირებულება.

სხვა სიტყვებით რომ ვთქვათ, მონაცემთა სტრუქტურების შეცვლა ყველაზე რთულია. და როგორც კი გააცნობიერებთ, რომ თქვენ შეარჩიეთ არასწორი მონაცემთა სტრუქტურა, რომელიც შემდგომში კლავს შესრულებას, ჩვეულებრივ ბევრი სამუშაოა გასაკეთებელი, მაგრამ თუ არ გააკეთებთ, ყველაფერი გაუარესდება. უპირველეს ყოვლისა, თქვენ უნდა იფიქროთ მონაცემთა სტრუქტურებზე, ეს მნიშვნელოვანია. ძირითადი ღირებულება აქ მოდის მსუქან მონაცემთა სტრუქტურებზე, რომლებიც იწყებენ გამოყენებას სტილში: „მე დავაკოპირე მონაცემთა სტრუქტურა X მონაცემთა Y სტრუქტურაში, რადგან მე უფრო მომწონს Y-ის ფორმა“. მაგრამ კოპირების ოპერაცია (რომელიც იაფი ჩანს) რეალურად კარგავს მეხსიერების გამტარუნარიანობას და სწორედ აქ არის ჩაფლული მთელი ფუჭად შესრულების დრო. თუ მე მაქვს JSON-ის გიგანტური სტრიქონი და მსურს მისი გადაქცევა POJO-ების სტრუქტურირებულ DOM ხედ ან სხვაგვარად, ამ სტრიქონის გარჩევის და POJO-ს აგების ოპერაცია, შემდეგ კი POJO-ზე ხელახლა წვდომა გამოიწვევს არასაჭირო ხარჯებს - ეს არის არაა იაფი. გარდა იმ შემთხვევისა, თუ POJO-ს გარშემო უფრო ხშირად დარბიხართ, ვიდრე სტრიქონს. სხვათა შორის, შეგიძლიათ სცადოთ სტრიქონის გაშიფვრა და ამოიღოთ მხოლოდ ის, რაც გჭირდებათ იქიდან, POJO-ში გადაქცევის გარეშე. თუ ეს ყველაფერი ხდება გზაზე, საიდანაც მაქსიმალური შესრულებაა საჭირო, POJO-ები თქვენთვის არ არის, თქვენ უნდა როგორმე პირდაპირ ხაზის გათხრა.

რატომ შექმნათ თქვენი საკუთარი პროგრამირების ენა

Andrew: თქვენ თქვით, რომ ღირებულების მოდელის გასაგებად, თქვენ უნდა დაწეროთ საკუთარი პატარა ენა...

კლდე: არა ენა, არამედ შემდგენელი. ენა და შემდგენელი ორი განსხვავებული რამ არის. ყველაზე მნიშვნელოვანი განსხვავება თქვენს თავშია. 

Andrew: სხვათა შორის, როგორც ვიცი, თქვენ ცდილობთ საკუთარი ენების შექმნას. Რისთვის?

კლდე: Იმიტომ რომ შემიძლია! ნახევრად პენსიონერი ვარ, ამიტომ ეს ჩემი ჰობია. მთელი ცხოვრება სხვის ენებს ვახორციელებ. ასევე ბევრი ვიმუშავე ჩემს კოდირების სტილზე. და ასევე იმიტომ, რომ მე ვხედავ პრობლემებს სხვა ენებზე. მე ვხედავ, რომ ნაცნობი საქმეების გასაკეთებლად უკეთესი გზები არსებობს. და გამოვიყენებდი მათ. უბრალოდ დავიღალე საკუთარ თავში პრობლემების დანახვით, ჯავაში, პითონში, ნებისმიერ სხვა ენაზე. ახლა ვწერ React Native-ში, JavaScript-სა და Elm-ში, როგორც ჰობი, რომელიც ეხება არა პენსიაზე გასვლას, არამედ აქტიურ მუშაობას. მე ასევე ვწერ Python-ში და, დიდი ალბათობით, გავაგრძელებ მუშაობას მანქანურ სწავლებაზე Java backend-ებისთვის. ბევრი პოპულარული ენაა და ყველა მათგანს აქვს საინტერესო თვისებები. ყველა თავისებურად კარგია და შეგიძლიათ სცადოთ ყველა ამ თვისების ერთად გაერთიანება. ასე რომ, მე ვსწავლობ რაღაცებს, რაც მაინტერესებს, ენის ქცევას, ვცდილობ გონივრული სემანტიკა გამოვიკვლიო. და ჯერჯერობით წარმატებას ვაღწევ! ამ მომენტში მე ვიბრძვი მეხსიერების სემანტიკასთან, რადგან მინდა მქონდეს ის, როგორც C და Java-ში და მივიღო ძლიერი მეხსიერების მოდელი და მეხსიერების სემანტიკა დატვირთვისთვის და შესანახად. ამავდროულად, გქონდეთ ავტომატური ტიპის დასკვნა, როგორც ჰასკელში. აქ, მე ვცდილობ შევურიო ჰასკელის მსგავსი ტიპის დასკვნა მეხსიერების მუშაობას როგორც C, ასევე Java-ში. ასე ვაკეთებ, მაგალითად, ბოლო 2-3 თვე.

Andrew: თუ თქვენ ააგებთ ენას, რომელიც სხვა ენებისგან უკეთეს ასპექტებს მიიღებს, ფიქრობთ, რომ ვინმე პირიქით მოიქცევა: აიღებს თქვენს იდეებს და გამოიყენებს მათ?

კლდე: ზუსტად ასე ჩნდება ახალი ენები! რატომ არის Java მსგავსი C-ს? იმის გამო, რომ C-ს ჰქონდა კარგი სინტაქსი, რომელიც ყველას ესმოდა და ჯავა იყო შთაგონებული ამ სინტაქსით, დაამატა ტიპის უსაფრთხოება, მასივის საზღვრების შემოწმება, GC და მათ ასევე გააუმჯობესეს ზოგიერთი რამ C-დან. მათ დაამატეს საკუთარი. მაგრამ ისინი საკმაოდ ბევრი შთაგონებული იყვნენ, არა? ყველა გიგანტების მხრებზე დგას, რომლებიც შენამდე მოვიდნენ – ასე მიიღწევა პროგრესი.

Andrew: როგორც მე მესმის, თქვენი ენა მეხსიერების უსაფრთხო იქნება. გიფიქრიათ Rust-ისგან სესხის შემოწმების მსგავსი რამის განხორციელებაზე? შეხედე მას, რას ფიქრობ მასზე?

კლდე: კარგი, მე ვწერ C-ს წლების განმავლობაში, ამ ყველაფერთან ერთად და უფასოდ, და ხელით ვმართავ სიცოცხლეს. მოგეხსენებათ, ხელით კონტროლირებადი სიცოცხლის ხანგრძლივობის 90-95%-ს იგივე სტრუქტურა აქვს. და ძალიან, ძალიან მტკივნეულია ამის ხელით გაკეთება. მე მინდა, რომ შემდგენელმა უბრალოდ გითხრათ, რა ხდება იქ და რას მიაღწიეთ თქვენი ქმედებებით. ზოგიერთი რამ, სესხის გამშვები აკეთებს ამას გარეთ ყუთში. და მან ავტომატურად უნდა აჩვენოს ინფორმაცია, გაიგოს ყველაფერი და არც კი დამიმძიმოს ამ გაგების წარმოდგენა. მან უნდა გააკეთოს მინიმუმ ადგილობრივი გაქცევის ანალიზი და მხოლოდ იმ შემთხვევაში, თუ ის ვერ მოხერხდება, მაშინ მას სჭირდება ტიპის ანოტაციების დამატება, რომლებიც აღწერს სიცოცხლის ხანგრძლივობას - და ასეთი სქემა ბევრად უფრო რთულია, ვიდრე სესხის გამშვები, ან მართლაც ნებისმიერი არსებული მეხსიერების შემოწმება. არჩევანი "ყველაფერი კარგადაა" და "მე არაფერი მესმის" შორის - არა, რაღაც უკეთესი უნდა იყოს. 
ასე რომ, როგორც ადამიანი, ვინც დაწერა ბევრი კოდი C-ში, მე ვფიქრობ, რომ მხარდაჭერის ქონა სიცოცხლის ხანგრძლივობის ავტომატური კონტროლისთვის არის ყველაზე მნიშვნელოვანი. მეც დავიღალე იმით, თუ რამდენად იყენებს Java მეხსიერებას და მთავარი საჩივარი არის GC. როდესაც თქვენ გამოყოფთ მეხსიერებას Java-ში, თქვენ არ დაიბრუნებთ მეხსიერებას, რომელიც ლოკალური იყო ბოლო GC ციკლში. ეს ასე არ არის მეხსიერების უფრო ზუსტი მართვის ენებში. თუ თქვენ დარეკავთ malloc-ს, მაშინვე მიიღებთ მეხსიერებას, რომელიც ჩვეულებრივ ახლახან გამოიყენებოდა. ჩვეულებრივ, მეხსიერებით აკეთებთ დროებით რაღაცეებს ​​და დაუყოვნებლივ აბრუნებთ მას. და ის მაშინვე უბრუნდება მალოკის აუზს და შემდეგი მალოკის ციკლი ისევ ამოიღებს მას. ამიტომ, მეხსიერების ფაქტობრივი გამოყენება მცირდება მოცემულ დროს ცოცხალი ობიექტების კომპლექტამდე, პლუს გაჟონვა. და თუ ყველაფერი არ გაჟონავს სრულიად უხამსად, მეხსიერების უმეტესი ნაწილი მთავრდება ქეშებში და პროცესორში და ის სწრაფად მუშაობს. მაგრამ მოითხოვს ბევრი ხელით მეხსიერების მართვას malloc-ით და უფასო გამოძახებით სწორი თანმიმდევრობით, სწორ ადგილას. Rust-ს შეუძლია დამოუკიდებლად გაუმკლავდეს ამას და ხშირ შემთხვევაში იძლევა კიდევ უფრო უკეთეს შესრულებას, რადგან მეხსიერების მოხმარება შემცირებულია მხოლოდ მიმდინარე გამოთვლებამდე - განსხვავებით მეხსიერების გასათავისუფლებლად შემდეგი GC ციკლის მოლოდინისა. შედეგად, ჩვენ მივიღეთ ძალიან საინტერესო გზა შესრულების გასაუმჯობესებლად. და საკმაოდ მძლავრი - ვგულისხმობ, მე ვაკეთებდი ასეთ რაღაცებს ფინტექს მონაცემების დამუშავებისას და ამან მომცა საშუალება მიმეღო სიჩქარე დაახლოებით ხუთჯერ. ეს საკმაოდ დიდი სტიმულია, განსაკუთრებით იმ სამყაროში, სადაც პროცესორები არ ჩქარობენ და ჩვენ კვლავ ველოდებით გაუმჯობესებას.

შესრულების ინჟინრის კარიერა

Andrew: ასევე მინდა ვიკითხო ზოგადად კარიერაზე. თქვენ გახდით ცნობილი თქვენი JIT მუშაობით HotSpot-ში და შემდეგ გადახვედით Azul-ში, რომელიც ასევე არის JVM კომპანია. მაგრამ ჩვენ უკვე უფრო მეტად ვმუშაობდით აპარატურაზე, ვიდრე პროგრამულ უზრუნველყოფაზე. შემდეგ ისინი მოულოდნელად გადავიდნენ დიდ მონაცემთა და მანქანურ სწავლებაზე, შემდეგ კი თაღლითობის გამოვლენაზე. Როგორ მოხდა ეს? ეს არის ძალიან განსხვავებული განვითარების სფეროები.

კლდე: საკმაოდ დიდი ხანია პროგრამირებას ვაკეთებ და ბევრი სხვადასხვა გაკვეთილის გავლა მოვახერხე. და როდესაც ხალხი ამბობს: „ოჰ, შენ ხარ ის ვინც JIT გააკეთე ჯავისთვის!“, ეს ყოველთვის სასაცილოა. მაგრამ მანამდე მე ვმუშაობდი PostScript-ის კლონზე - ენაზე, რომელსაც Apple ოდესღაც იყენებდა თავისი ლაზერული პრინტერებისთვის. მანამდე კი მეოთხე ენის იმპლემენტაცია გავაკეთე. ვფიქრობ, ჩემთვის საერთო თემაა ხელსაწყოების შემუშავება. მთელი ცხოვრება ვაკეთებ ინსტრუმენტებს, რომლებითაც სხვა ადამიანები წერენ თავიანთ მაგარ პროგრამებს. მაგრამ მე ასევე ვიყავი ჩართული ოპერაციული სისტემების, დრაივერების, ბირთვის დონის გამართვის, OS-ის განვითარების ენების შემუშავებაში, რომელიც ტრივიალურად დაიწყო, მაგრამ დროთა განმავლობაში უფრო და უფრო რთული გახდა. მაგრამ მთავარი თემა მაინც ინსტრუმენტების განვითარებაა. ჩემი ცხოვრების დიდი ნაწილი აზულსა და სუნს შორის გავიდა და ეს ეხებოდა ჯავას. მაგრამ როდესაც შევედი Big Data-სა და Machine Learning-ში, დავიხურე ჩემი ლამაზი ქუდი და ვუთხარი: „ოჰ, ახლა ჩვენ გვაქვს არა ტრივიალური პრობლემა და ბევრი საინტერესო რამ ხდება და ადამიანები აკეთებენ რაღაცებს“. ეს არის განვითარების შესანიშნავი გზა.

დიახ, მე ნამდვილად მიყვარს განაწილებული გამოთვლები. ჩემი პირველი სამუშაო იყო სტუდენტი C-ში, სარეკლამო პროექტზე. ეს განაწილდა გამოთვლებით Zilog Z80 ჩიპებზე, რომლებიც აგროვებდნენ მონაცემებს ანალოგური OCR-სთვის, რომელიც წარმოებულია რეალური ანალოგური ანალიზატორის მიერ. მაგარი და სრულიად გიჟური თემა იყო. მაგრამ იყო პრობლემები, რაღაც ნაწილი სწორად არ იყო ამოცნობილი, ამიტომ უნდა ამოეღო სურათი და ეჩვენებინა ადამიანი, რომელსაც უკვე შეეძლო თვალით წაკითხვა და მოხსენება, რაც ეწერა, და ამიტომ იყო სამუშაოები მონაცემებით და ეს სამუშაოები. ჰქონდათ საკუთარი ენა. იყო ბექენდი, რომელიც ამუშავებდა ამ ყველაფერს - Z80-ები მუშაობდნენ vt100 ტერმინალების პარალელურად გაშვებული - თითო ადამიანზე და იყო პარალელური პროგრამირების მოდელი Z80-ზე. მეხსიერების ზოგიერთი საერთო ნაწილი, რომელიც იზიარებს ყველა Z80-ს ვარსკვლავის კონფიგურაციაში; უკანა პლანი ასევე გაზიარებული იყო და RAM-ის ნახევარი გაზიარებული იყო ქსელში, ხოლო მეორე ნახევარი იყო პირადი ან გადავიდა სხვა რამეზე. მნიშვნელოვანი კომპლექსური პარალელური განაწილებული სისტემა საერთო... ნახევრად გაზიარებული მეხსიერებით. როდის იყო ეს... არც კი მახსოვს, სადღაც 80-იანი წლების შუა ხანებში. საკმაოდ დიდი ხნის წინ. 
დიახ, დავუშვათ, რომ 30 წელი საკმაოდ დიდი დროა, განაწილებულ გამოთვლებთან დაკავშირებული პრობლემები საკმაოდ დიდი ხანია არსებობს, ხალხი დიდი ხანია ომშია. Beowulf- მტევანი. ასეთი კლასტერები ასე გამოიყურება... მაგალითად: არის Ethernet და თქვენი სწრაფი x86 დაკავშირებულია ამ Ethernet-თან და ახლა გსურთ მიიღოთ ყალბი საერთო მეხსიერება, რადგან მაშინ ვერავინ ახერხებდა განაწილებული გამოთვლითი კოდირების გაკეთებას, ძალიან რთული იყო და ამიტომ იქ იყო ყალბი გაზიარებული მეხსიერება დამცავი მეხსიერების გვერდებით x86-ზე, და თუ თქვენ დაწერეთ ამ გვერდზე, მაშინ ჩვენ ვუთხარით სხვა პროცესორებს, რომ თუ ისინი შედიოდნენ იმავე საზიარო მეხსიერებაზე, ის უნდა ჩაიტვირთოს თქვენგან და, შესაბამისად, რაღაც პროტოკოლის მსგავსი მხარდაჭერისთვის. გამოჩნდა ქეში თანმიმდევრულობა და ამისათვის პროგრამული უზრუნველყოფა. საინტერესო კონცეფცია. რეალური პრობლემა, რა თქმა უნდა, სხვა რაღაცაში იყო. ამ ყველაფერმა იმუშავა, მაგრამ თქვენ სწრაფად შეგექმნათ შესრულების პრობლემები, რადგან არავის ესმოდა შესრულების მოდელები საკმარისად კარგ დონეზე - მეხსიერების წვდომის რა შაბლონები იყო, როგორ დავრწმუნდეთ, რომ კვანძები უსასრულოდ არ იწერდნენ ერთმანეთს და ა.შ.

რაც მე მივიღე H2O-ში არის ის, რომ თავად დეველოპერები არიან პასუხისმგებელი იმის დადგენაზე, სად იმალება პარალელიზმი და სად არა. მე გამოვნახე კოდირების მოდელი, რომელმაც მაღალი ხარისხის კოდის დაწერა მარტივი და მარტივი გახადა. მაგრამ ნელი კოდის დაწერა რთულია, ცუდად გამოიყურება. თქვენ სერიოზულად უნდა სცადოთ ნელი კოდის დაწერა, მოგიწევთ არასტანდარტული მეთოდების გამოყენება. სამუხრუჭე კოდი ჩანს ერთი შეხედვით. შედეგად, თქვენ ჩვეულებრივ წერთ კოდს, რომელიც სწრაფად მუშაობს, მაგრამ თქვენ უნდა გაარკვიოთ რა უნდა გააკეთოთ საზიარო მეხსიერების შემთხვევაში. ეს ყველაფერი დაკავშირებულია დიდ მასივებთან და იქ ქცევა მსგავსია არასტაბილური დიდი მასივების პარალელურ ჯავაში. ვგულისხმობ, წარმოიდგინე, რომ ორი ძაფი იწერება პარალელურ მასივზე, ერთი იგებს, მეორე კი, შესაბამისად, კარგავს და თქვენ არ იცით რომელი რომელია. თუ ისინი არ არიან არასტაბილური, მაშინ შეკვეთა შეიძლება იყოს ის, რაც გსურთ - და ეს ძალიან კარგად მუშაობს. ადამიანებს ნამდვილად აინტერესებთ ოპერაციების თანმიმდევრობა, ისინი ათავსებენ არასტაბილურ სწორ ადგილებში და ელოდებათ მეხსიერებასთან დაკავშირებული მუშაობის პრობლემებს სწორ ადგილებში. წინააღმდეგ შემთხვევაში, ისინი უბრალოდ დაწერდნენ კოდს მარყუჟების სახით 1-დან N-მდე, სადაც N არის რამდენიმე ტრილიონი, იმ იმედით, რომ ყველა რთული შემთხვევა ავტომატურად გახდება პარალელური - და ის იქ არ მუშაობს. მაგრამ H2O-ში ეს არც ჯავაა და არც სკალა; თუ გინდათ, შეგიძლიათ ჩათვალოთ "ჯავა მინუს მინუს". ეს არის ძალიან მკაფიო პროგრამირების სტილი და მსგავსია მარტივი C ან Java კოდის დაწერას მარყუჟებითა და მასივებით. მაგრამ ამავე დროს, მეხსიერების დამუშავება შესაძლებელია ტერაბაიტებში. მე მაინც ვიყენებ H2O-ს. მე მას დროდადრო ვიყენებ სხვადასხვა პროექტებში - და ის მაინც ყველაზე სწრაფია, ათეულჯერ უფრო სწრაფი ვიდრე მისი კონკურენტები. თუ თქვენ აკეთებთ Big Data-ს სვეტური მონაცემებით, ძალიან რთულია H2O-ის დამარცხება.

ტექნიკური გამოწვევები

Andrew: რა იყო თქვენი ყველაზე დიდი გამოწვევა მთელ კარიერაში?

კლდე: განვიხილავთ საკითხის ტექნიკურ თუ არატექნიკურ ნაწილს? მე ვიტყოდი, რომ ყველაზე დიდი გამოწვევები ტექნიკური არ არის. 
რაც შეეხება ტექნიკურ გამოწვევებს. მე უბრალოდ დავამარცხე ისინი. არც კი ვიცი, რა იყო ყველაზე დიდი, მაგრამ იყო რამდენიმე საკმაოდ საინტერესო, რომელსაც საკმაოდ დიდი დრო დასჭირდა, გონებრივი ბრძოლა. Sun-ში რომ მივედი, დარწმუნებული ვიყავი, რომ სწრაფ შემდგენელს გავაკეთებდი და უამრავმა უფროსმა საპასუხოდ თქვა, რომ ვერასოდეს მივაღწევდი. მაგრამ მე მივყევი ამ გზას, დავწერე კომპილერი რეგისტრის ალოკატორში და ეს საკმაოდ სწრაფი იყო. ის ისეთივე სწრაფი იყო, როგორც თანამედროვე C1, მაგრამ გამანაწილებელი მაშინ გაცილებით ნელი იყო და, როგორც ჩანს, მონაცემთა სტრუქტურის დიდი პრობლემა იყო. ეს მჭირდებოდა გრაფიკული რეგისტრის ალოკატორის დასაწერად და ვერ გავიგე დილემა კოდის ექსპრესიულობასა და სიჩქარეს შორის, რომელიც იმ ეპოქაში არსებობდა და ძალიან მნიშვნელოვანი იყო. აღმოჩნდა, რომ მონაცემთა სტრუქტურა ჩვეულებრივ აღემატება ქეშის ზომას იმდროინდელ x86s-ზე და ამიტომ, თუ თავდაპირველად ვივარაუდებდი, რომ რეგისტრის გამანაწილებელი გამოიმუშავებდა ჯამური დროის 5-10 პროცენტს, მაშინ სინამდვილეში ეს ასე იყო. 50 პროცენტი.

რაც დრო გადიოდა, შემდგენელი გახდა უფრო სუფთა და ეფექტური, შეწყვიტა საშინელი კოდის გენერირება უფრო მეტ შემთხვევაში და შესრულება სულ უფრო დაემსგავსა იმას, რასაც აწარმოებს C კომპილერი. . თუ დაწერთ კოდს, როგორიცაა C, უფრო მეტ შემთხვევაში მიიღებთ შესრულებას, როგორიცაა C. და რაც უფრო შორს მიდიხართ, მით უფრო ხშირად იღებდით კოდს, რომელიც ასიმპტომურად ემთხვეოდა C დონეს, რეგისტრის გამანაწილებელი რაღაც სრულყოფილს დაემსგავსა... მიუხედავად იმისა, თქვენი კოდი სწრაფად მუშაობს თუ ნელა. გავაგრძელე ალოკატორზე მუშაობა, რათა უკეთესი არჩევანი გაეკეთებინა. ის უფრო და უფრო ნელა ხდებოდა, მაგრამ უკეთეს და უკეთეს შესრულებას აძლევდა ისეთ შემთხვევებში, როდესაც სხვა ვერავინ უმკლავდებოდა. შემეძლო ჩავძირულიყავი რეგისტრის ალოკატორში, დავმარხე იქ ერთი თვის სამუშაო და უცებ მთელი კოდი 5%-ით უფრო სწრაფად დაიწყებდა შესრულებას. ეს ხდებოდა დროდადრო და რეგისტრის გამანაწილებელი რაღაც ხელოვნების ნიმუშად იქცა - ყველას უყვარდა ან სძულდა და აკადემიის ხალხი სვამდა კითხვებს თემაზე "რატომ კეთდება ყველაფერი ასე", რატომაც არა. ხაზის სკანირებადა რა განსხვავებაა. პასუხი მაინც იგივეა: გრაფიკის შეღებვაზე დაფუძნებული ალოკატორი პლუს ბუფერულ კოდთან ძალიან ფრთხილად მუშაობა უდრის გამარჯვების იარაღს, საუკეთესო კომბინაციას, რომელსაც ვერავინ დაამარცხებს. და ეს საკმაოდ არააშკარა რამ არის. ყველაფერი, რასაც შემდგენელი იქ აკეთებს, საკმაოდ კარგად შესწავლილია, თუმცა ისინიც ხელოვნების დონემდეა მიყვანილი. მე ყოველთვის ვაკეთებდი რაღაცეებს, რაც უნდა გადაექცია შემდგენელი ხელოვნების ნიმუშად. მაგრამ არცერთი ეს არ იყო რაიმე განსაკუთრებული - გარდა რეესტრის განაწილებისა. ხრიკი არის სიფრთხილე შემცირება დატვირთვის ქვეშ და, თუ ეს მოხდება (დაწვრილებით შემიძლია აგიხსნათ დაინტერესების შემთხვევაში), ეს ნიშნავს, რომ თქვენ შეგიძლიათ უფრო აგრესიულად შეხვიდეთ, შესრულების განრიგში გადახრის რისკის გარეშე. იმ დღეებში არსებობდა სრულმასშტაბიანი შემდგენელების თაიგულები, ბაბლეტებითა და სასტვენებით ჩამოკიდებული, რომლებსაც ჰქონდათ რეგისტრის გამანაწილებლები, მაგრამ ამას სხვა ვერავინ შეძლებდა.

პრობლემა ის არის, რომ თუ თქვენ დაამატებთ მეთოდებს, რომლებიც ექვემდებარება ჩასმას, გაზრდის და გაზრდის არეს, გამოყენებული მნიშვნელობების ნაკრები მყისიერად აჭარბებს რეგისტრების რაოდენობას და თქვენ უნდა გაჭრათ ისინი. კრიტიკული დონე ჩვეულებრივ მოდის მაშინ, როდესაც ალოკატორი უარს ამბობს და დაღვრის ერთი კარგი კანდიდატი მეორეს ღირს, თქვენ გაყიდით ზოგიერთ ზოგადად ველურ ნივთს. აქ ჩართვის მნიშვნელობა არის ის, რომ კარგავთ ზედნადების ნაწილს, ზარის და დაზოგვის ნაწილს, შეგიძლიათ იხილოთ მნიშვნელობები შიგნით და შეგიძლიათ მათი შემდგომი ოპტიმიზაცია. შეყვანის ღირებულება არის ის, რომ იქმნება ცოცხალი მნიშვნელობების დიდი რაოდენობა და თუ თქვენი რეესტრის გამანაწილებელი საჭიროზე მეტს იწვის, მაშინვე დაკარგავთ. აქედან გამომდინარე, ალოკატორების უმეტესობას აქვს პრობლემა: როდესაც ინლაინინგი კვეთს გარკვეულ ხაზს, მსოფლიოში ყველაფრის შემცირება იწყება და პროდუქტიულობა შეიძლება დაიწიოს ტუალეტში. ისინი, ვინც ახორციელებენ კომპილატორს, ამატებენ რამდენიმე ევრისტიკას: მაგალითად, შეწყვიტოს ინლაინინგი, დაწყებული საკმარისად დიდი ზომით, რადგან გამოყოფა ყველაფერს გააფუჭებს. ასე წარმოიქმნება შერყევა შესრულების გრაფიკში - თქვენ ინლაინ, ინლაინ, შესრულება ნელ-ნელა იზრდება - და შემდეგ ბუმი! – სვიფტ ჯეკივით ცვივა, რადგან ზედმეტად აწიე. ასე მუშაობდა ყველაფერი ჯავის მოსვლამდე. ჯავას გაცილებით მეტი ინლაინინგი სჭირდება, ამიტომ მომიწია ჩემი გამანაწილებელი უფრო აგრესიული გავხადე, რათა ის დონემდე მიიყვანოს, ვიდრე ავარიულიყო, და თუ ზედმეტად ჩაწერთ, ის იწყებს დაღვრას, მაგრამ შემდეგ მაინც მოდის მომენტი "აღარ დაღვრას". ეს არის საინტერესო დაკვირვება და ის უბრალოდ მოვიდა ჩემთან, არა აშკარა, მაგრამ კარგად გამოვიდა. მე ავიღე აგრესიული ინლაინინგი და მიმიყვანა ისეთ ადგილებში, სადაც Java და C შესრულება ერთმანეთის გვერდიგვერდ მუშაობენ. ისინი ძალიან ახლოს არიან - შემიძლია დავწერო Java კოდი, რომელიც მნიშვნელოვნად უფრო სწრაფია, ვიდრე C კოდი და მსგავსი რამ, მაგრამ საშუალოდ, საგნების დიდ სურათში, ისინი დაახლოებით შედარებულია. ვფიქრობ, ამ დამსახურების ნაწილია რეგისტრის გამანაწილებელი, რომელიც მაძლევს საშუალებას, რაც შეიძლება სულელურად ჩავწერო. მე უბრალოდ ჩავწერ ყველაფერს, რასაც ვხედავ. აქ ისმის კითხვა, მუშაობს თუ არა გამანაწილებელი კარგად, არის თუ არა შედეგი ინტელექტუალურად მოქმედი კოდი. ეს იყო დიდი გამოწვევა: ამ ყველაფრის გაგება და ამოქმედება.

ცოტა რამ რეგისტრის განაწილებისა და მრავალ ბირთვების შესახებ

ვლადიმერ: პრობლემები, როგორიცაა რეგისტრების განაწილება, რაღაც მარადიულ, გაუთავებელ თემას ჰგავს. მაინტერესებს ოდესმე ყოფილა იდეა, რომელიც პერსპექტიული ჩანდა და შემდეგ პრაქტიკაში ჩავარდა?

კლდე: Რა თქმა უნდა! რეგისტრაციის განაწილება არის სფერო, რომელშიც თქვენ ცდილობთ იპოვოთ ევრისტიკა NP-სრული პრობლემის გადასაჭრელად. და ვერასოდეს მიაღწევ სრულყოფილ გადაწყვეტას, არა? ეს უბრალოდ შეუძლებელია. შეხედეთ, Ahead of Time კომპილაცია - ის ასევე ცუდად მუშაობს. აქ საუბარი რამდენიმე საშუალო შემთხვევაზეა. ტიპიური შესრულების შესახებ, ასე რომ თქვენ შეგიძლიათ წახვიდეთ და გაზომოთ ის, რაც თქვენი აზრით კარგი ტიპიური შესრულებაა - ბოლოს და ბოლოს, თქვენ მუშაობთ მის გასაუმჯობესებლად! რეგისტრაციის განაწილება არის თემა, რომელიც ეხება შესრულებას. როგორც კი გექნებათ პირველი პროტოტიპი, ის მუშაობს და ხატავს იმას, რაც საჭიროა, იწყება შესრულების სამუშაოები. თქვენ უნდა ისწავლოთ კარგად გაზომვა. Რატომ არის ეს მნიშვნელოვანი? თუ თქვენ გაქვთ მკაფიო მონაცემები, შეგიძლიათ გადახედოთ სხვადასხვა სფეროს და ნახოთ: დიახ, აქ დაგვეხმარა, მაგრამ აქ ყველაფერი დაირღვა! რამდენიმე კარგი იდეა ჩნდება, თქვენ ამატებთ ახალ ევრისტიკას და უცებ ყველაფერი საშუალოდ ცოტა უკეთესად მუშაობს. ან არ იწყება. მე მქონდა უამრავი შემთხვევა, როდესაც ჩვენ ვიბრძოდით ხუთპროცენტიანი შესრულებისთვის, რომელიც განასხვავებდა ჩვენს განვითარებას წინა ალოკატორისგან. და ყოველ ჯერზე ასე გამოიყურება: სადღაც იმარჯვებ, სადღაც კარგავ. თუ თქვენ გაქვთ შესრულების ანალიზის კარგი ხელსაწყოები, შეგიძლიათ იპოვოთ წაგებული იდეები და გაიგოთ, რატომ ვერ ხერხდება ისინი. შესაძლოა, ღირდეს ყველაფრის ისე დატოვება, როგორც არის, ან შესაძლოა უფრო სერიოზული მიდგომა დალაგებაზე, ან გასვლა და სხვა რამის გამოსწორება. ეს არის მთელი თაიგული! მე გავაკეთე ეს მაგარი ჰაკი, მაგრამ ასევე მჭირდება ეს, და ეს და ეს - და მათი საერთო კომბინაცია გარკვეულ გაუმჯობესებას იძლევა. და მარტოხელა შეიძლება მარცხი. ეს არის NP-სრული პრობლემების შესრულების მუშაობის ბუნება.

ვლადიმერ: იქმნება განცდა, რომ ისეთი რაღაცეები, როგორიცაა ალოკატორებში შეღებვა, უკვე მოგვარებული პრობლემაა. ისე, შენთვის გადაწყვეტილია, თუ ვიმსჯელებთ შენს ნათქვამზე, ღირს კი მაშინ...

კლდე: ასე არ წყდება. ეს თქვენ უნდა გადააქციოთ "გადაწყვეტილებად". არის რთული პრობლემები და მათი მოგვარებაა საჭირო. როგორც კი ეს გაკეთდება, დროა იმუშაოთ პროდუქტიულობაზე. თქვენ უნდა მიუდგეთ ამ სამუშაოს შესაბამისად - გააკეთეთ ეტალონები, შეაგროვეთ მეტრიკა, ახსენით სიტუაციები, როდესაც წინა ვერსიაზე გადაბრუნებისას თქვენმა ძველმა ჰაკმა კვლავ დაიწყო მუშაობა (ან პირიქით, შეჩერდა). და არ დანებდე, სანამ რამეს არ მიაღწევ. როგორც უკვე ვთქვი, თუ არის მაგარი იდეები, რომლებმაც არ იმუშავეს, მაგრამ იდეების რეგისტრების განაწილების სფეროში ეს დაახლოებით უსასრულოა. შეგიძლიათ, მაგალითად, წაიკითხოთ სამეცნიერო პუბლიკაციები. მიუხედავად იმისა, რომ ახლა ამ სფერომ გაცილებით ნელა დაიწყო მოძრაობა და უფრო ნათელი გახდა, ვიდრე ახალგაზრდობაში. თუმცა, ამ სფეროში უთვალავი ადამიანი მუშაობს და მათი ყველა იდეა ცდად ღირს, ყველა ფრთებში ელოდება. და ვერ გეტყვით, რამდენად კარგები არიან ისინი, თუ არ გამოსცადეთ. რამდენად კარგად ერწყმის ისინი ყველაფერ დანარჩენს თქვენს ალოკატორში, რადგან ალოკატორი ბევრ რამეს აკეთებს და ზოგიერთი იდეა არ იმუშავებს თქვენს კონკრეტულ ალოკატორში, მაგრამ სხვა ალოკატორში ისინი ადვილად იმუშავებენ. გამანაწილებლის გამარჯვების მთავარი გზა არის ნელი ნივთების გაყვანა ძირითადი ბილიკის გარეთ და აიძულეთ იგი გაიყოს ნელი ბილიკების საზღვრებზე. ასე რომ, თუ გსურთ GC-ის გაშვება, აიღეთ ნელი გზა, დეოპტიმიზაცია, გამონაკლისების დაყენება, ეს ყველაფერი - თქვენ იცით, რომ ეს ყველაფერი შედარებით იშვიათია. და ისინი მართლაც იშვიათია, შევამოწმე. თქვენ აკეთებთ დამატებით სამუშაოს და ეს ხსნის ბევრ შეზღუდვას ამ ნელი ბილიკებისთვის, მაგრამ ამას ნამდვილად არ აქვს მნიშვნელობა, რადგან ისინი ნელია და იშვიათად იმოგზაურებთ. მაგალითად, ნულოვანი მაჩვენებელი - ეს არასდროს ხდება, არა? თქვენ უნდა გქონდეთ რამდენიმე გზა სხვადასხვა რამისთვის, მაგრამ მათ არ უნდა შეუშალონ ხელი მთავარს. 

ვლადიმერ: რას ფიქრობთ მრავალ ბირთვზე, როდესაც ერთდროულად ათასობით ბირთვია? ეს სასარგებლო რამეა?

კლდე: GPU-ს წარმატება აჩვენებს, რომ ის საკმაოდ სასარგებლოა!

ვლადიმერ: საკმაოდ სპეციალიზებულები არიან. რაც შეეხება ზოგადი დანიშნულების პროცესორებს?

კლდე: კარგი, ეს იყო აზულის ბიზნეს მოდელი. პასუხი დაბრუნდა იმ ეპოქაში, როდესაც ხალხს ნამდვილად უყვარდა პროგნოზირებადი შესრულება. მაშინ რთული იყო პარალელური კოდის დაწერა. H2O კოდირების მოდელი ძალიან მასშტაბირებადია, მაგრამ ეს არ არის ზოგადი დანიშნულების მოდელი. შესაძლოა ცოტა უფრო ზოგადი ვიდრე GPU-ს გამოყენებისას. ასეთი რამის შემუშავების სირთულეზეა საუბარი თუ გამოყენების სირთულეზე? მაგალითად, აზულმა მასწავლა საინტერესო გაკვეთილი, საკმაოდ არააშკარა: პატარა ქეშები ნორმალურია. 

ყველაზე დიდი გამოწვევა ცხოვრებაში

ვლადიმერ: რაც შეეხება არატექნიკურ გამოწვევებს?

კლდე: ყველაზე დიდი გამოწვევა იყო არ იყო... კეთილი და კეთილი ადამიანების მიმართ. და შედეგად, მუდმივად აღმოვჩნდი უკიდურესად კონფლიქტურ სიტუაციებში. ისინი, სადაც ვიცოდი, რომ ყველაფერი არასწორად მიდიოდა, მაგრამ არ იცოდნენ, როგორ წასულიყვნენ წინ ამ პრობლემების მოგვარებაში და ვერ გაუმკლავდნენ მათ. ამ გზით წარმოიშვა მრავალი გრძელვადიანი პრობლემა, რომელიც ათწლეულების განმავლობაში გაგრძელდა. ის ფაქტი, რომ ჯავას აქვს C1 და C2 შემდგენელები, ამის პირდაპირი შედეგია. ის ფაქტი, რომ ჯავაში ზედიზედ ათი წლის განმავლობაში არ იყო მრავალდონიანი კომპილაცია, ასევე პირდაპირი შედეგია. აშკარაა, რომ ასეთი სისტემა გვჭირდებოდა, მაგრამ რატომ არ არსებობდა, არ არის გასაგები. პრობლემა მქონდა ერთ ინჟინერთან... ან ინჟინრების ჯგუფთან. ოდესღაც, როცა „სანში“ დავიწყე მუშაობა, ვიყავი... კარგი, არა მარტო მაშინ, ზოგადად ყოველთვის ყველაფერზე საკუთარი აზრი მაქვს. და მე მეგონა, რომ მართალი იყო, რომ შენ შეგეძლო უბრალოდ აეღო ეს შენი სიმართლე და პირდაპირ ეთქვა. მით უმეტეს, რომ უმეტესად შოკისმომგვრელი მართალი ვიყავი. და თუ არ მოგწონთ ეს მიდგომა... მით უმეტეს, თუ აშკარად ცდებით და სისულელეს აკეთებთ... ზოგადად, კომუნიკაციის ამ ფორმას ცოტა ადამიანი მოითმენს. მიუხედავად იმისა, რომ ზოგიერთს შეეძლო, როგორც მე. მთელი ჩემი ცხოვრება მერიტოკრატიულ პრინციპებზე ავაშენე. თუ რამეს მაჩვენებ, მაშინვე შემოვბრუნდები და ვიტყვი: სისულელე თქვი. ამავდროულად, რა თქმა უნდა, ბოდიშს ვიხდი და ყოველივე ამას, არსებითად, თუ ასეთი იქნება, ავღნიშნავ და მივმართავ სხვა სწორ ქმედებებს. მეორეს მხრივ, შოკისმომგვრელი მართალი ვარ მთლიანი დროის შოკისმომგვრელ დიდ პროცენტზე. და ეს არც ისე კარგად მუშაობს ადამიანებთან ურთიერთობაში. არ ვცდილობ ვიყო კარგი, მაგრამ კითხვას უხეშად ვსვამ. ”ეს არასოდეს იმუშავებს, რადგან ერთი, ორი და სამი.” და ისინი ასე იყვნენ: "ოჰ!" იყო სხვა შედეგებიც, რომელთა უგულებელყოფა ალბათ უკეთესი იყო: მაგალითად, ის, რამაც გამოიწვია ჩემი ცოლის განქორწინება და ამის შემდეგ ათი წლის დეპრესია.

გამოწვევა არის ბრძოლა ადამიანებთან, მათი აღქმით, თუ რისი გაკეთება შეგიძლია ან არ შეიძლება, რა არის მნიშვნელოვანი და რა არა. ბევრი გამოწვევა იყო კოდირების სტილთან დაკავშირებით. მე ჯერ კიდევ ბევრ კოდს ვწერ და იმ დღეებში სიჩქარის შენელებაც კი მომიწია, რადგან ძალიან ბევრ პარალელურ დავალებას ვასრულებდი და ცუდად ვასრულებდი, ნაცვლად იმისა, რომ ერთზე ფოკუსირება მომეხდინა. უკან რომ ვიხედები, დავწერე ნახევარი კოდი Java JIT ბრძანებისთვის, C2 ბრძანება. შემდეგი უსწრაფესი კოდირმა დაწერა ნახევრად ნელი, შემდეგი ნახევარი ნელი და ეს იყო ექსპონენციალური კლება. ამ რიგში მეშვიდე ადამიანი ძალიან, ძალიან ნელი იყო - ეს ყოველთვის ხდება! ბევრ კოდს შევეხე. შევხედე, ვინ რა დაწერა, გამონაკლისის გარეშე, მათ კოდს მივაშტერდი, თითოეულ მათგანს გადავხედე და მაინც გავაგრძელე უფრო მეტის წერა, ვიდრე რომელიმე მათგანი. ეს მიდგომა არც თუ ისე კარგად მუშაობს ხალხთან. ზოგს ეს არ მოსწონს. და როცა ვერ უმკლავდებიან, ყველანაირი ჩივილი იწყება. მაგალითად, ერთხელ მითხრეს, შეწყვიტე კოდირება, რადგან ძალიან ბევრ კოდს ვწერდი და ეს საფრთხეს უქმნიდა გუნდს და ეს ყველაფერი ხუმრობად მომეჩვენა: ძმაო, თუ გუნდის დანარჩენი ნაწილი გაქრება და მე გავაგრძელებ კოდის წერას, შენ დავკარგავთ მხოლოდ ნახევარ გუნდებს. მეორე მხრივ, თუ გავაგრძელებ კოდის წერას და გუნდის ნახევარს დაკარგავთ, ეს ძალიან ცუდი მენეჯმენტად ჟღერს. არასდროს მიფიქრია ამაზე, არასდროს მილაპარაკია, მაგრამ მაინც სადღაც ჩემს თავში იყო. ფიქრი მიტრიალებდა თავში: "ყველა მეხუმრებით?" ასე რომ, ყველაზე დიდი პრობლემა მე და ადამიანებთან ჩემი ურთიერთობა იყო. ახლა ბევრად უკეთ მესმის ჩემი თავი, დიდი ხნის განმავლობაში ვიყავი პროგრამისტების გუნდის ლიდერი და ახლა პირდაპირ ვეუბნები ხალხს: იცით, მე ვარ ის, ვინც ვარ და მოგიწევთ ჩემთან ურთიერთობა - კარგია თუ დავდგები აქ? და როდესაც მათ დაიწყეს მასთან გამკლავება, ყველაფერი მუშაობდა. ფაქტობრივად, არც ცუდი ვარ და არც კარგი, არც ცუდი ზრახვები და არც ეგოისტური მისწრაფებები არ მაქვს, ეს მხოლოდ ჩემი არსია და როგორმე უნდა ვიცხოვრო მასთან.

Andrew: სულ ახლახან ყველამ დაიწყო ლაპარაკი ინტროვერტებისთვის თვითშემეცნებაზე და ზოგადად რბილ უნარებზე. რას იტყვით ამაზე?

კლდე: დიახ, ეს იყო გამჭრიახობა და გაკვეთილი, რაც მე ვისწავლე ჩემი ცოლისგან განქორწინებიდან. რაც გავიგე განქორწინებიდან იყო საკუთარი თავის გაგება. ასე დავიწყე სხვა ადამიანების გაგება. გაიგეთ როგორ მუშაობს ეს ურთიერთქმედება. ამან გამოიწვია აღმოჩენები ერთმანეთის მიყოლებით. იყო იმის გაცნობიერება, თუ ვინ ვარ და რას წარმოვადგენ. რას ვაკეთებ: ან დავალებით ვარ დაკავებული, ან კონფლიქტს ვერიდები, ან სხვა რამეს - და თვითშემეცნების ეს დონე ნამდვილად მეხმარება საკუთარი თავის კონტროლის შენარჩუნებაში. ამის შემდეგ ყველაფერი ბევრად უფრო ადვილი ხდება. ერთი რამ, რაც აღმოვაჩინე არა მხოლოდ საკუთარ თავში, არამედ სხვა პროგრამისტებშიც, არის აზრების ვერბალიზაციის შეუძლებლობა, როცა ემოციურ სტრესში ხარ. მაგალითად, თქვენ ზიხართ იქ და კოდირებით, ნაკადის მდგომარეობაში, შემდეგ ისინი მოდიან თქვენთან და ისტერიკაში იწყებენ ყვირილს, რომ რაღაც დაირღვა და ახლა თქვენ წინააღმდეგ უკიდურესი ზომები იქნება მიღებული. და თქვენ ვერ იტყვით სიტყვას, რადგან ემოციური სტრესის მდგომარეობაში ხართ. მიღებული ცოდნა საშუალებას გაძლევთ მოემზადოთ ამ მომენტისთვის, გადარჩეთ მას და გადახვიდეთ უკან დახევის გეგმაზე, რის შემდეგაც შეგიძლიათ რაღაცის გაკეთება. ასე რომ, დიახ, როდესაც დაიწყებთ იმის გაცნობიერებას, თუ როგორ მუშაობს ეს ყველაფერი, ეს არის უზარმაზარი მოვლენა, რომელიც ცვლის თქვენს ცხოვრებას. 
მე თვითონ ვერ ვიპოვე სწორი სიტყვები, მაგრამ მახსოვდა მოქმედებების თანმიმდევრობა. საქმე იმაშია, რომ ეს რეაქცია ისეთივე ფიზიკურია, რამდენადაც სიტყვიერი და სივრცე გჭირდება. ასეთი სივრცე, ზენის გაგებით. ეს არის ზუსტად ის, რისი ახსნაა საჭირო და მაშინვე განზე გადგომა - წმინდა ფიზიკურად დაშორება. როცა სიტყვიერად ვჩუმდები, შემიძლია სიტუაციის ემოციურად დამუშავება. ადრენალინი ტვინში აღწევს, გადაგყავს ბრძოლის ან ფრენის რეჟიმში, ვეღარაფერს იტყვი, არა - ახლა შენ ხარ იდიოტი, შოლტის ინჟინერი, არ შეუძლია ღირსეული პასუხის გაცემა ან თუნდაც შეტევის შეჩერება და თავდამსხმელი თავისუფალია. თავდასხმა ისევ და ისევ. ჯერ ისევ უნდა გახდე საკუთარი თავი, დაიბრუნო კონტროლი, გამოხვიდე „ბრძოლა ან გაფრენის“ რეჟიმიდან.

და ამისთვის გვჭირდება ვერბალური სივრცე. უბრალოდ თავისუფალი ადგილი. თუ რამეს ამბობთ, შეგიძლიათ ზუსტად თქვათ ეს, შემდეგ კი წადით და ნამდვილად იპოვნეთ თქვენთვის "სივრცე": გაისეირნეთ პარკში, ჩაკეტეთ შხაპში - არ აქვს მნიშვნელობა. მთავარია ამ სიტუაციიდან დროებით გათიშვა. როგორც კი გამორთავთ სულ მცირე რამდენიმე წამით, კონტროლი ბრუნდება, იწყებთ ფხიზელ ფიქრს. ”კარგი, მე არ ვარ რაღაც იდიოტი, მე არ ვაკეთებ სისულელეს, მე საკმაოდ სასარგებლო ადამიანი ვარ.” მას შემდეგ რაც შეძლებთ საკუთარი თავის დარწმუნებას, დროა გადავიდეთ შემდეგ ეტაპზე: იმის გაგება, რაც მოხდა. თქვენ თავს დაესხნენ, თავდასხმა იქიდან მოვიდა, სადაც ამას არ ელოდით, ეს იყო არაკეთილსინდისიერი, საზიზღარი ჩასაფრება. Ეს არის ცუდი. შემდეგი ნაბიჯი არის იმის გაგება, თუ რატომ სჭირდებოდა ეს თავდამსხმელს. Მართლაც, რატომ? იქნებ იმიტომ, რომ თვითონ არის გაბრაზებული? რატომ გიჟდება? მაგალითად, იმიტომ, რომ მან თავი მოიკლა და პასუხისმგებლობას ვერ იღებს? ეს არის მთელი სიტუაციის ფრთხილად გატარების გზა. მაგრამ ეს მოითხოვს მანევრირების ადგილს, ვერბალურ სივრცეს. პირველი ნაბიჯი არის სიტყვიერი კონტაქტის შეწყვეტა. მოერიდეთ სიტყვებით დისკუსიას. გააუქმეთ, რაც შეიძლება სწრაფად წადით. თუ ეს სატელეფონო საუბარია, უბრალოდ გათიშე - ეს არის უნარი, რომელიც ვისწავლე ყოფილ მეუღლესთან ურთიერთობისას. თუ საუბარი არსად კარგად არ მიდის, უბრალოდ თქვით "მშვიდობით" და გათიშე. ტელეფონის მეორე მხრიდან: "ბლა ბლა ბლა", თქვენ პასუხობთ: "კი, ნახვამდის!" და გათიშა. თქვენ უბრალოდ დაასრულეთ საუბარი. ხუთი წუთის შემდეგ, როცა გონივრულად აზროვნების უნარი დაგიბრუნდებათ, ცოტა გაცივდით, შესაძლებელი ხდება იფიქროთ ყველაფერზე, რა მოხდა და რა იქნება შემდეგ. და დაიწყეთ გააზრებული პასუხის ფორმულირება, ვიდრე უბრალოდ რეაგირება ემოციებისგან. ჩემთვის თვითშემეცნებაში გარღვევა სწორედ ის იყო, რომ ემოციური სტრესის შემთხვევაში ლაპარაკი არ შემიძლია. ამ მდგომარეობიდან გამოსვლა, ფიქრი და დაგეგმვა, როგორ უპასუხო და აანაზღაურო პრობლემებზე - ეს სწორი ნაბიჯებია იმ შემთხვევაში, როცა ლაპარაკი არ შეგიძლია. უმარტივესი გზაა გაექცეთ იმ სიტუაციას, რომელშიც ემოციური სტრესი იჩენს თავს და უბრალოდ შეწყვიტეთ ამ სტრესში მონაწილეობა. ამის შემდეგ ხდები აზროვნების უნარი, როცა შეგიძლია აზროვნება, ხდები ლაპარაკის უნარი და ა.შ.

სხვათა შორის, სასამართლოში, მოწინააღმდეგე ადვოკატი ცდილობს ამის გაკეთებას თქვენთან - ახლა გასაგებია, რატომ. იმიტომ, რომ მას აქვს უნარი დათრგუნოს ისეთ მდგომარეობამდე, რომ შენს სახელსაც კი ვერ წარმოთქვამ, მაგალითად. ძალიან რეალური გაგებით, თქვენ ვერ შეძლებთ ლაპარაკს. თუ ეს დაგემართათ და თუ იცით, რომ აღმოჩნდებით ისეთ ადგილას, სადაც სიტყვიერი ბრძოლები მძვინვარებს, ისეთ ადგილას, როგორიც სასამართლოა, მაშინ შეგიძლიათ თქვენს ადვოკატთან ერთად მოხვიდეთ. ადვოკატი დაგიდგება წინ და შეაჩერებს სიტყვიერ შეტევას და ამას სრულიად ლეგალური გზით გააკეთებს და დაკარგული ზენის სივრცე დაგიბრუნდებათ. მაგალითად, რამდენჯერმე მომიწია ოჯახთან დარეკვა, მოსამართლე საკმაოდ მეგობრულად იყო განწყობილი ამ საკითხთან დაკავშირებით, მაგრამ მოწინააღმდეგე ადვოკატი ყვიროდა და მიყვიროდა, სიტყვასაც ვერ ვიღებდი. ამ შემთხვევაში, მედიატორის გამოყენება ყველაზე კარგად გამომდის. შუამავალი აჩერებს მთელ ამ ზეწოლას, რომელიც გიჟდებათ უწყვეტ ნაკადში, თქვენ იპოვით აუცილებელ ზენის სივრცეს და მასთან ერთად უბრუნდება საუბრის უნარი. ეს არის ცოდნის მთელი სფერო, რომელშიც ბევრი რამ არის შესასწავლი, ბევრი რამის აღმოჩენა საკუთარ თავში და ეს ყველაფერი იქცევა მაღალი დონის სტრატეგიულ გადაწყვეტილებებად, რომლებიც განსხვავებულია სხვადასხვა ადამიანებისთვის. ზოგიერთ ადამიანს არ აქვს ზემოთ აღწერილი პრობლემები; ჩვეულებრივ, ადამიანებს, რომლებიც არიან პროფესიონალი გაყიდვების წარმომადგენლები, არ აქვთ ისინი. ყველა ეს ადამიანი, ვინც თავის ცხოვრებას სიტყვებით აკეთებს - ცნობილი მომღერლები, პოეტები, რელიგიური ლიდერები და პოლიტიკოსები, მათ ყოველთვის აქვთ სათქმელი. მათ არ აქვთ ასეთი პრობლემები, მაგრამ მე მაქვს.

Andrew: ეს იყო... მოულოდნელი. ძალიან კარგი, ჩვენ უკვე ბევრი ვისაუბრეთ და დროა დავასრულოთ ეს ინტერვიუ. ჩვენ აუცილებლად შევხვდებით კონფერენციაზე და შევძლებთ ამ დიალოგის გაგრძელებას. შევხვდებით ჰიდრაში!

კლიფთან საუბრის გაგრძელება შეგიძლიათ Hydra 2019-ის კონფერენციაზე, რომელიც 11 წლის 12-2019 ივლისს სანქტ-პეტერბურგში გაიმართება. მოხსენებით მოვა "Azul Hardware Transactional Memory გამოცდილება". ბილეთების შეძენა შესაძლებელია ოფიციალურ ვებგვერდზე.

წყარო: www.habr.com