Cliff ចុច - CTO នៃ Cratus (ឧបករណ៍ចាប់សញ្ញា IoT សម្រាប់ការកែលម្អដំណើរការ) ស្ថាបនិក និងជាសហស្ថាបនិកនៃការចាប់ផ្តើមអាជីវកម្មជាច្រើន (រួមទាំង Rocket Realtime School, Neurensic និង H2O.ai) ជាមួយនឹងច្រកចេញជោគជ័យជាច្រើន។ Cliff បានសរសេរអ្នកចងក្រងដំបូងរបស់គាត់នៅអាយុ 15 ឆ្នាំ (Pascal សម្រាប់ TRS Z-80)! គាត់ត្រូវបានគេស្គាល់ថាល្អបំផុតសម្រាប់ការងាររបស់គាត់នៅលើ C2 នៅ Java (សមុទ្រ Nodes IR) ។ កម្មវិធីចងក្រងនេះបានបង្ហាញពិភពលោកថា JIT អាចផលិតកូដដែលមានគុណភាពខ្ពស់ ដែលជាកត្តាមួយក្នុងការលេចឡើងនៃ Java ជាវេទិកាកម្មវិធីទំនើបដ៏សំខាន់មួយ។ បន្ទាប់មក Cliff បានជួយ Azul Systems បង្កើត mainframe 864-core ជាមួយនឹងកម្មវិធី Java សុទ្ធ ដែលគាំទ្រការផ្អាក GC នៅលើ 500-gigabyte heap ក្នុងរយៈពេល 10 មិល្លីវិនាទី។ ជាទូទៅ Cliff បានគ្រប់គ្រងដើម្បីធ្វើការលើគ្រប់ទិដ្ឋភាពនៃ JVM ។

 
habrapost នេះគឺជាការសម្ភាសន៍ដ៏អស្ចារ្យជាមួយ Cliff ។ យើងនឹងពិភាក្សាលើប្រធានបទខាងក្រោម៖

• ការផ្លាស់ប្តូរទៅការបង្កើនប្រសិទ្ធភាពកម្រិតទាប
• របៀបធ្វើ refactoring ដ៏ធំមួយ
• ម៉ូដែលថ្លៃដើម
• ការបណ្តុះបណ្តាលបង្កើនប្រសិទ្ធភាពកម្រិតទាប
• ឧទាហរណ៍ជាក់ស្តែងនៃការកែលម្អការអនុវត្ត
• ហេតុអ្វីបានជាបង្កើតភាសាសរសេរកម្មវិធីផ្ទាល់ខ្លួនរបស់អ្នក។
• អាជីពវិស្វករការសម្តែង
• បញ្ហាប្រឈមបច្ចេកទេស
• បន្តិចអំពីការចុះឈ្មោះការបែងចែក និងពហុស្នូល
• បញ្ហាប្រឈមដ៏ធំបំផុតក្នុងជីវិត

ការសម្ភាសន៍ធ្វើឡើងដោយ៖

• Andrey Satarin ពី Amazon Web Services ។ ក្នុងអាជីពរបស់គាត់ គាត់បានធ្វើការនៅក្នុងគម្រោងផ្សេងគ្នាទាំងស្រុង៖ គាត់បានសាកល្បងនូវមូលដ្ឋានទិន្នន័យចែកចាយ NewSQL នៅក្នុង Yandex ដែលជាប្រព័ន្ធស្វែងរកពពកនៅក្នុង Kaspersky Lab ដែលជាហ្គេមដែលមានអ្នកលេងច្រើននៅក្នុង Mail.ru និងសេវាកម្មសម្រាប់គណនាតម្លៃប្តូរប្រាក់បរទេសនៅក្នុងធនាគារ Deutsche Bank ។ ចាប់អារម្មណ៍ក្នុងការសាកល្បងប្រព័ន្ធ backend និងចែកចាយខ្នាតធំ។
• Vladimir Sitnikov ពី Netcracker ។ រយៈពេលដប់ឆ្នាំនៃការងារលើការអនុវត្ត និងការធ្វើមាត្រដ្ឋាននៃ NetCracker OS ដែលជាកម្មវិធីដែលប្រើដោយប្រតិបត្តិករទូរគមនាគមន៍ដើម្បីធ្វើស្វ័យប្រវត្តិកម្មបណ្តាញ និងដំណើរការគ្រប់គ្រងឧបករណ៍បណ្តាញ។ ចាប់អារម្មណ៍លើបញ្ហាប្រតិបត្តិការ Java និង Oracle Database ។ អ្នកនិពន្ធនៃការកែលម្អការអនុវត្តច្រើនជាងដប់នៅក្នុងកម្មវិធីបញ្ជា PostgreSQL JDBC ផ្លូវការ។

ការផ្លាស់ប្តូរទៅការបង្កើនប្រសិទ្ធភាពកម្រិតទាប

Andrei៖ អ្នកគឺជាឈ្មោះដ៏ធំមួយនៅក្នុងពិភពនៃការចងក្រង JIT, Java, និងការអនុវត្តការងារជាទូទៅមែនទេ? 

ច្រាំងថ្មចោទ៖ បែប​ហ្នឹង!

Andrei៖ ចូរចាប់ផ្តើមជាមួយនឹងសំណួរទូទៅមួយចំនួនអំពីការងារអនុវត្ត។ តើ​អ្នក​គិត​យ៉ាង​ណា​ចំពោះ​ជម្រើស​រវាង​ការ​បង្កើន​ប្រសិទ្ធភាព​កម្រិត​ខ្ពស់ និង​កម្រិត​ទាប ដូច​ជា​ការ​ធ្វើ​ការ​នៅ​កម្រិត CPU?

ច្រាំងថ្មចោទ៖ បាទ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញនៅទីនេះ។ លេខកូដដែលលឿនបំផុតគឺជាលេខកូដដែលមិនដែលដំណើរការ។ ដូច្នេះហើយ អ្នកតែងតែត្រូវចាប់ផ្តើមពីកម្រិតខ្ពស់ ធ្វើការលើក្បួនដោះស្រាយ។ សញ្ញាណ O ល្អជាងនឹងយកឈ្នះសញ្ញា O កាន់តែអាក្រក់ លុះត្រាតែមានអថេរមួយចំនួនធំគ្រប់គ្រាន់ធ្វើអន្តរាគមន៍។ អ្វី​ដែល​កម្រិត​ទាប​ទៅ​ជា​ចុងក្រោយ។ ជាធម្មតា ប្រសិនបើអ្នកបានបង្កើនប្រសិទ្ធភាពផ្នែកដែលនៅសល់របស់អ្នកឱ្យបានគ្រប់គ្រាន់ ហើយនៅតែមានវត្ថុគួរឱ្យចាប់អារម្មណ៍មួយចំនួនដែលនៅសល់ នោះជាកម្រិតទាប។ ប៉ុន្តែរបៀបចាប់ផ្តើមពីកម្រិតខ្ពស់? តើ​ធ្វើ​ដូចម្តេច​ទើប​ដឹង​ថា​ការងារ​កម្រិត​ខ្ពស់​គ្រប់គ្រាន់​ត្រូវ​បាន​ធ្វើ​ហើយ​? អញ្ចឹង... គ្មានផ្លូវទេ។ មិនមានរូបមន្តដែលត្រៀមរួចជាស្រេចទេ។ អ្នកត្រូវយល់ពីបញ្ហា សម្រេចចិត្តថាអ្នកនឹងធ្វើអ្វី (ដើម្បីកុំឱ្យចាត់វិធានការដែលមិនចាំបាច់នាពេលអនាគត) ហើយបន្ទាប់មកអ្នកអាចបើកបង្ហាញ profiler ដែលអាចនិយាយអ្វីដែលមានប្រយោជន៍។ នៅចំណុចខ្លះ អ្នកខ្លួនឯងដឹងថាអ្នកបានកម្ចាត់ចោលនូវអ្វីដែលមិនចាំបាច់ ហើយដល់ពេលដែលត្រូវធ្វើការកែតម្រូវកម្រិតទាបមួយចំនួន។ នេះ​គឺ​ជា​ប្រភេទ​សិល្បៈ​ដ៏​ពិសេស។ មាន​មនុស្ស​ជា​ច្រើន​ធ្វើ​អ្វី​ដែល​មិន​ចាំ​បាច់ ប៉ុន្តែ​ធ្វើ​ដំណើរ​លឿន​ពេក​រហូត​ដល់​គ្មាន​ពេល​បារម្ភ​អំពី​ផលិតភាព។ ប៉ុន្តែ​នេះ​គឺ​ទាល់​តែ​មាន​ចម្ងល់​កើតឡើង។ ជាធម្មតា 99% នៃពេលវេលាគ្មាននរណាម្នាក់ខ្វល់ពីអ្វីដែលខ្ញុំធ្វើនោះទេ រហូតដល់ពេលដែលរឿងសំខាន់មួយមកលើផ្លូវសំខាន់ដែលគ្មាននរណាម្នាក់ចាប់អារម្មណ៍។ ហើយនៅទីនេះ មនុស្សគ្រប់គ្នាចាប់ផ្តើមខឹងអ្នកអំពី "ហេតុអ្វីបានជាវាមិនដំណើរការល្អឥតខ្ចោះតាំងពីដំបូងមកម្ល៉េះ"។ ជាទូទៅ វាតែងតែមានអ្វីដែលត្រូវកែលម្អក្នុងការអនុវត្ត។ ប៉ុន្តែ 99% នៃពេលវេលាដែលអ្នកមិនមាននាំមុខ! អ្នកគ្រាន់តែព្យាយាមធ្វើឱ្យអ្វីមួយដំណើរការ ហើយនៅក្នុងដំណើរការនោះ អ្នកស្វែងយល់ពីអ្វីដែលសំខាន់។ អ្នក​មិន​អាច​ដឹង​ជាមុន​ថា​បំណែក​នេះ​ត្រូវ​ការ​ល្អ​ឥត​ខ្ចោះ ដូច្នេះ​តាម​ពិត អ្នក​ត្រូវ​តែ​ល្អ​ឥត​ខ្ចោះ​ក្នុង​គ្រប់​យ៉ាង។ ប៉ុន្តែនេះមិនអាចទៅរួចទេ ហើយអ្នកមិនធ្វើវាទេ។ វាតែងតែមានរឿងជាច្រើនដែលត្រូវជួសជុល - ហើយវាជារឿងធម្មតាទាំងស្រុង។

របៀបធ្វើ refactoring ដ៏ធំមួយ

Andrei៖ តើអ្នកធ្វើការលើការសម្តែងដោយរបៀបណា? នេះ​ជា​បញ្ហា​ឆ្លង​កាត់។ ជាឧទាហរណ៍ តើអ្នកធ្លាប់ធ្វើការលើបញ្ហាដែលកើតចេញពីចំនុចប្រសព្វនៃមុខងារដែលមានស្រាប់ច្រើនដែរឬទេ?

ច្រាំងថ្មចោទ៖ ខ្ញុំព្យាយាមជៀសវាងវា។ ប្រសិនបើខ្ញុំដឹងថាការអនុវត្តនឹងមានបញ្ហា ខ្ញុំគិតអំពីវាមុនពេលខ្ញុំចាប់ផ្តើមសរសេរកូដ ជាពិសេសជាមួយនឹងរចនាសម្ព័ន្ធទិន្នន័យ។ ប៉ុន្តែជាញឹកញាប់អ្នករកឃើញទាំងអស់នេះនៅពេលក្រោយ។ ហើយបន្ទាប់មកអ្នកត្រូវទៅរកវិធានការខ្លាំង ៗ ហើយធ្វើអ្វីដែលខ្ញុំហៅថា "សរសេរឡើងវិញនិងយកឈ្នះ"៖ អ្នកត្រូវចាប់យកដុំធំល្មម។ កូដមួយចំនួននឹងនៅតែត្រូវសរសេរឡើងវិញ ដោយសារបញ្ហាដំណើរការ ឬអ្វីផ្សេងទៀត។ មិនថាហេតុផលសម្រាប់ការសរសេរកូដឡើងវិញក៏ដោយ វាតែងតែប្រសើរជាងក្នុងការសរសេរឡើងវិញនូវដុំធំជាងដុំតូចជាង។ នៅ​ពេល​នេះ គ្រប់​គ្នា​ចាប់​ផ្ដើម​ញ័រ​ដោយ​ការ​ភ័យ​ខ្លាច៖ «ឱ​ព្រះ​អើយ អ្នក​មិន​អាច​ប៉ះ​លេខ​កូដ​ច្រើន​ទេ!»។ ប៉ុន្តែតាមពិត វិធីសាស្រ្តនេះស្ទើរតែតែងតែដំណើរការបានប្រសើរជាងមុន។ អ្នកត្រូវដោះស្រាយបញ្ហាធំភ្លាមៗ គូសរង្វង់ធំជុំវិញវា ហើយនិយាយថា៖ ខ្ញុំនឹងសរសេរឡើងវិញនូវអ្វីគ្រប់យ៉ាងនៅក្នុងរង្វង់។ ស៊ុមមានទំហំតូចជាងមាតិកានៅខាងក្នុងវាដែលត្រូវការជំនួស។ ហើយប្រសិនបើការកំណត់ព្រំដែនបែបនេះអនុញ្ញាតឱ្យអ្នកធ្វើការងារខាងក្នុងយ៉ាងល្អឥតខ្ចោះ ដៃរបស់អ្នកមានសេរីភាព ធ្វើអ្វីដែលអ្នកចង់បាន។ នៅពេលដែលអ្នកយល់ពីបញ្ហា ដំណើរការសរសេរឡើងវិញគឺកាន់តែងាយស្រួល ដូច្នេះសូមចំណាយពេលបន្តិច!
ក្នុងពេលជាមួយគ្នានេះ នៅពេលដែលអ្នកសរសេរសារឡើងវិញដ៏ធំ ហើយដឹងថាការអនុវត្តនឹងមានបញ្ហា អ្នកអាចចាប់ផ្តើមព្រួយបារម្ភភ្លាមៗអំពីវា។ ជាធម្មតា វាប្រែទៅជារឿងសាមញ្ញដូចជា "កុំចម្លងទិន្នន័យ គ្រប់គ្រងទិន្នន័យឱ្យសាមញ្ញតាមដែលអាចធ្វើទៅបាន ធ្វើឱ្យវាតូច។" នៅក្នុងការសរសេរឡើងវិញដ៏ធំ មានវិធីស្តង់ដារដើម្បីកែលម្អការអនុវត្ត។ ហើយពួកគេស្ទើរតែតែងតែវិលជុំវិញទិន្នន័យ។

ម៉ូដែលថ្លៃដើម

Andrei៖ នៅក្នុងផតខាសមួយដែលអ្នកបាននិយាយអំពីគំរូតម្លៃក្នុងបរិបទនៃផលិតភាព។ តើ​អ្នក​អាច​ពន្យល់​ពី​អ្វី​ដែល​អ្នក​ចង់​បាន​ដោយ​ការ​នេះ?

ច្រាំងថ្មចោទ៖ ប្រាកដណាស់ ខ្ញុំកើតនៅក្នុងយុគសម័យដែលដំណើរការរបស់ខួរក្បាលមានសារៈសំខាន់ខ្លាំងណាស់។ ហើយសម័យនេះត្រលប់មកវិញម្តងទៀត - ជោគវាសនាមិនមែនដោយគ្មានការហួសចិត្តទេ។ ខ្ញុំចាប់ផ្តើមរស់នៅក្នុងថ្ងៃនៃម៉ាស៊ីនប្រាំបីប៊ីត កុំព្យូទ័រដំបូងរបស់ខ្ញុំដំណើរការជាមួយ 256 បៃ។ ពិតប្រាកដបៃ។ អ្វីគ្រប់យ៉ាងគឺតូចណាស់។ ការណែនាំត្រូវតែត្រូវបានរាប់ ហើយនៅពេលដែលយើងចាប់ផ្តើមផ្លាស់ប្តូរបណ្តុំភាសាសរសេរកម្មវិធី នោះភាសាបានចាប់ផ្ដើមកាន់តែច្រើនឡើង។ មាន Assembler បន្ទាប់មក Basic បន្ទាប់មក C និង C បានយកចិត្តទុកដាក់លើព័ត៌មានលម្អិតជាច្រើន ដូចជាការចុះឈ្មោះការបែងចែក និងការជ្រើសរើសការណែនាំ។ ប៉ុន្តែអ្វីគ្រប់យ៉ាងគឺច្បាស់ណាស់នៅទីនោះ ហើយប្រសិនបើខ្ញុំធ្វើចង្អុលទៅឧទាហរណ៍នៃអថេរ នោះខ្ញុំនឹងទទួលបានបន្ទុក ហើយតម្លៃនៃការណែនាំនេះត្រូវបានគេដឹង។ ផ្នែករឹងបង្កើតចំនួនជាក់លាក់នៃវដ្តម៉ាស៊ីន ដូច្នេះល្បឿនប្រតិបត្តិនៃវត្ថុផ្សេងៗគ្នាអាចត្រូវបានគណនាដោយគ្រាន់តែបន្ថែមការណែនាំទាំងអស់ដែលអ្នកនឹងដំណើរការ។ រាល់ការប្រៀបធៀប/សាកល្បង/សាខា/ហៅ/ផ្ទុក/ហាង អាចត្រូវបានបន្ថែម ហើយនិយាយថា: នោះជាពេលវេលាប្រតិបត្តិសម្រាប់អ្នក។ នៅពេលធ្វើការលើការធ្វើឱ្យប្រសើរឡើងនូវការអនុវត្ត អ្នកពិតជានឹងយកចិត្តទុកដាក់ចំពោះអ្វីដែលលេខដែលត្រូវគ្នានឹងវដ្តក្តៅតូចៗ។ 
ប៉ុន្តែនៅពេលដែលអ្នកប្តូរទៅ Java, Python និងរបស់ស្រដៀងគ្នានេះ អ្នកផ្លាស់ទីយ៉ាងលឿនចេញពីផ្នែករឹងកម្រិតទាប។ តើការហៅទូរស័ព្ទទៅអ្នកទទួលនៅចាវ៉ាមានតម្លៃប៉ុន្មាន? ប្រសិនបើ JIT នៅក្នុង HotSpot គឺត្រឹមត្រូវ។ ជួរវានឹងផ្ទុក ប៉ុន្តែប្រសិនបើវាមិនបានធ្វើវាទេ វានឹងក្លាយជាការហៅមុខងារ។ ដោយសារ​ការហៅទូរសព្ទ​គឺ​នៅលើ​រង្វិលជុំ​ក្តៅ វានឹង​បដិសេធ​ការធ្វើឱ្យ​ប្រសើរ​ផ្សេងទៀត​ទាំងអស់​នៅក្នុង​រង្វិលជុំនោះ។ ដូច្នេះការចំណាយពិតប្រាកដនឹងខ្ពស់ជាងច្រើន។ ហើយភ្លាមៗនោះអ្នកបាត់បង់សមត្ថភាពក្នុងការមើលបំណែកនៃកូដ ហើយយល់ថាយើងគួរតែប្រតិបត្តិវាទាក់ទងនឹងល្បឿននាឡិកាខួរក្បាល អង្គចងចាំ និងឃ្លាំងសម្ងាត់ដែលបានប្រើ។ ទាំងអស់នេះក្លាយជាគួរឱ្យចាប់អារម្មណ៍លុះត្រាតែអ្នកពិតជាចូលទៅក្នុងការសម្តែង។
ឥឡូវនេះយើងឃើញខ្លួនយើងនៅក្នុងស្ថានភាពមួយដែលល្បឿនដំណើរការស្ទើរតែមិនបានកើនឡើងអស់រយៈពេលមួយទសវត្សរ៍។ អតីតកាលបានត្រលប់មកវិញហើយ! អ្នក​មិន​អាច​ពឹង​ផ្អែក​លើ​ការ​ដំណើរការ​ខ្សែ​តែមួយ​ដែល​ល្អ​បាន​ទៀត​ទេ។ ប៉ុន្តែ​ប្រសិន​បើ​អ្នក​ចូល​ទៅ​ក្នុង​ការ​គណនា​ស្រប​គ្នា​នោះ វា​ជា​ការ​លំបាក​មិន​គួរ​ឱ្យ​ជឿ អ្នក​រាល់​គ្នា​មើល​មក​អ្នក​ដូច James Bond។ ការបង្កើនល្បឿនដប់ដងនៅទីនេះជាធម្មតាកើតឡើងនៅកន្លែងដែលនរណាម្នាក់បានរញ៉េរញ៉ៃអ្វីមួយ។ ភាពឆបគ្នាទាមទារការងារច្រើន។ ដើម្បីទទួលបានការបង្កើនល្បឿន XNUMX ដងនោះ អ្នកត្រូវយល់ពីគំរូតម្លៃ។ តើវាមានតម្លៃប៉ុន្មាន? ហើយដើម្បីធ្វើដូច្នេះ អ្នកត្រូវយល់ពីរបៀបដែលអណ្តាតសមនឹងផ្នែករឹងខាងក្រោម។
Martin Thompson បានជ្រើសរើសពាក្យដ៏អស្ចារ្យសម្រាប់ប្លក់របស់គាត់។ ការអាណិតអាសូរមេកានិច! អ្នកត្រូវយល់ពីអ្វីដែលផ្នែករឹងនឹងធ្វើ របៀបដែលវានឹងធ្វើវាពិតប្រាកដ និងហេតុអ្វីបានជាវាធ្វើអ្វីដែលវាធ្វើដំបូង។ ដោយប្រើវា វាងាយស្រួលណាស់ក្នុងការចាប់ផ្តើមរាប់ការណែនាំ និងស្វែងរកកន្លែងដែលពេលវេលាប្រតិបត្តិនឹងទៅ។ ប្រសិនបើអ្នកមិនមានការបណ្តុះបណ្តាលសមស្របទេ អ្នកគ្រាន់តែស្វែងរកឆ្មាខ្មៅនៅក្នុងបន្ទប់ងងឹត។ ខ្ញុំឃើញមនុស្សបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការគ្រប់ពេលវេលា ដែលមិនដឹងថាពួកគេកំពុងធ្វើអ្វីនោះទេ។ ពួក​គេ​រង​ទុក្ខ​ច្រើន ហើយ​មិន​មាន​ការ​រីក​ចម្រើន​ច្រើន​ទេ។ ហើយនៅពេលដែលខ្ញុំយកលេខកូដដូចគ្នា រអិលពីរបីដង ហើយទទួលបានល្បឿនប្រាំ ឬដប់ដង ពួកគេដូចជា៖ អញ្ចឹង វាមិនយុត្តិធម៌ទេ យើងដឹងថាអ្នកប្រសើរជាងហើយ។ អស្ចារ្យ។ តើខ្ញុំកំពុងនិយាយអំពីអ្វី... គំរូតម្លៃគឺអំពីប្រភេទកូដដែលអ្នកសរសេរ និងល្បឿនដែលវាដំណើរការជាមធ្យមក្នុងរូបភាពធំ។

Andrei៖ ហើយ​តើ​អ្នក​អាច​រក្សា​បរិមាណ​បែប​នេះ​នៅ​ក្នុង​ក្បាល​របស់​អ្នក​ដោយ​របៀប​ណា? តើ​នេះ​សម្រេច​បាន​ដោយ​មាន​បទពិសោធន៍​បន្ថែម​ឬ? តើបទពិសោធន៍បែបនេះមកពីណា?

ច្រាំងថ្មចោទ៖ ខ្ញុំ​មិន​បាន​ទទួល​បទ​ពិសោធ​របស់​ខ្ញុំ​តាម​វិធី​ងាយ​បំផុត​ទេ។ ខ្ញុំ​បាន​រៀបចំ​កម្មវិធី​ក្នុង​សភា​ក្នុង​ថ្ងៃ​ដែល​អ្នក​អាច​យល់​រាល់​ការ​ណែនាំ​នីមួយៗ។ វាស្តាប់ទៅដូចជាឆោតល្ងង់ ប៉ុន្តែចាប់តាំងពីពេលនោះមក សំណុំការណែនាំ Z80 តែងតែស្ថិតនៅក្នុងក្បាលរបស់ខ្ញុំ ក្នុងការចងចាំរបស់ខ្ញុំ។ ខ្ញុំ​មិន​ចាំ​ឈ្មោះ​មនុស្ស​ក្នុង​ពេល​និយាយ​មួយ​នាទី​ទេ ប៉ុន្តែ​ខ្ញុំ​ចាំ​កូដ​ដែល​សរសេរ​កាល​ពី​៤០​ឆ្នាំ​មុន។ វាគួរឱ្យអស់សំណើចណាស់ វាមើលទៅដូចជារោគសញ្ញា"អ្នកវិទ្យាសាស្ត្រឆ្កួត"។

ការបណ្តុះបណ្តាលបង្កើនប្រសិទ្ធភាពកម្រិតទាប

Andrei៖ តើ​មាន​មធ្យោបាយ​ងាយស្រួល​ចូល​ទេ?

ច្រាំងថ្មចោទ៖ បាទ​ហើយ​ទេ។ Hardware ដែល​យើង​ប្រើ​ទាំង​អស់​គ្នា​មិន​បាន​ផ្លាស់​ប្តូរ​ច្រើន​នោះ​ទេ​តាម​រយៈ​ពេល​វេលា។ មនុស្សគ្រប់គ្នាប្រើ x86 លើកលែងតែស្មាតហ្វូន Arm ។ ប្រសិនបើអ្នកមិនធ្វើប្រភេទនៃការបង្កប់ hardcore ទេ អ្នកកំពុងធ្វើដូចគ្នា។ យល់ព្រម បន្ទាប់។ ការណែនាំក៏មិនបានផ្លាស់ប្តូរជាច្រើនសតវត្សមកហើយដែរ។ អ្នកត្រូវទៅសរសេរអ្វីមួយនៅក្នុងសភា។ មិនច្រើនទេ ប៉ុន្តែគ្រប់គ្រាន់ដើម្បីចាប់ផ្តើមយល់។ អ្នកកំពុងញញឹម ប៉ុន្តែខ្ញុំកំពុងនិយាយទាំងស្រុង។ អ្នកត្រូវយល់ពីការឆ្លើយឆ្លងរវាងភាសា និងផ្នែករឹង។ បន្ទាប់ពីនោះអ្នកត្រូវទៅសរសេរបន្តិច ហើយបង្កើតឧបករណ៍ចងក្រងក្មេងលេងតូចមួយសម្រាប់ភាសាក្មេងលេងតិចតួច។ ប្រដាប់ប្រដាក្មេងលេងមានន័យថាវាត្រូវធ្វើក្នុងបរិមាណសមហេតុផល។ វាអាចសាមញ្ញបំផុត ប៉ុន្តែវាត្រូវតែបង្កើតការណែនាំ។ ទង្វើនៃការបង្កើតការណែនាំនឹងជួយអ្នកឱ្យយល់អំពីគំរូតម្លៃសម្រាប់ស្ពានរវាងកូដកម្រិតខ្ពស់ដែលមនុស្សគ្រប់គ្នាសរសេរ និងកូដម៉ាស៊ីនដែលដំណើរការលើផ្នែករឹង។ ការឆ្លើយឆ្លងនេះនឹងត្រូវបានដុតចូលទៅក្នុងខួរក្បាលនៅពេលដែលអ្នកចងក្រងត្រូវបានសរសេរ។ សូម្បីតែអ្នកចងក្រងសាមញ្ញបំផុត។ បន្ទាប់ពីនោះ អ្នកអាចចាប់ផ្តើមមើល Java និងការពិតដែលថា chasm semantic របស់វាកាន់តែជ្រៅ ហើយវាកាន់តែលំបាកក្នុងការសាងសង់ស្ពាននៅលើវា។ នៅជ្វា វាកាន់តែពិបាកយល់ថាតើស្ពានរបស់យើងប្រែជាល្អ ឬអាក្រក់ អ្វីនឹងធ្វើឱ្យវាដួលរលំ និងអ្វីដែលនឹងមិន។ ប៉ុន្តែ​អ្នក​ត្រូវ​ការ​ចំណុច​ចាប់​ផ្ដើម​មួយ​ចំនួន​ដែល​អ្នក​មើល​កូដ​ហើយ​យល់៖ "បាទ អ្នក​ទទួល​នេះ​គួរ​ដាក់​បញ្ចូល​រាល់​ពេល"។ ហើយបន្ទាប់មកវាប្រែថាពេលខ្លះវាកើតឡើង លើកលែងតែស្ថានភាពនៅពេលដែលវិធីសាស្ត្រធំពេក ហើយ JIT ចាប់ផ្តើមបញ្ចូលអ្វីគ្រប់យ៉ាង។ ការអនុវត្តនៃកន្លែងបែបនេះអាចត្រូវបានព្យាករណ៍ភ្លាមៗ។ ជាធម្មតាអ្នកទទួលដំណើរការបានល្អ ប៉ុន្តែបន្ទាប់មកអ្នកមើលរង្វិលជុំក្តៅធំៗ ហើយដឹងថាមានការហៅមុខងារមួយចំនួនអណ្តែតនៅជុំវិញទីនោះ ដែលមិនដឹងថាពួកគេកំពុងធ្វើអ្វីនោះទេ។ នេះគឺជាបញ្ហាជាមួយនឹងការប្រើប្រាស់យ៉ាងទូលំទូលាយនៃ getters ហេតុផលដែលពួកគេមិនត្រូវបានបញ្ចូលគឺថាវាមិនច្បាស់ថាតើពួកគេជាអ្នកទទួល។ ប្រសិនបើអ្នកមានមូលដ្ឋានកូដតូចធំ អ្នកអាចចងចាំវាដោយសាមញ្ញ រួចនិយាយថា៖ នេះគឺជាអ្នកទទួល ហើយនេះគឺជាឧបករណ៍កំណត់។ នៅក្នុងមូលដ្ឋានកូដដ៏ធំមួយ មុខងារនីមួយៗមានប្រវត្តិផ្ទាល់ខ្លួនរបស់វា ដែលជាទូទៅគេមិនស្គាល់នរណាម្នាក់ឡើយ។ profiler និយាយថាយើងបានបាត់បង់ 24% នៃពេលវេលានៅលើរង្វិលជុំមួយចំនួន ហើយដើម្បីយល់ពីអ្វីដែលរង្វិលជុំនេះកំពុងធ្វើ យើងត្រូវមើលមុខងារនីមួយៗនៅខាងក្នុង។ វាមិនអាចទៅរួចទេក្នុងការយល់ពីរឿងនេះដោយមិនសិក្សាមុខងារហើយនេះធ្វើឱ្យដំណើរការនៃការយល់ដឹងថយចុះយ៉ាងធ្ងន់ធ្ងរ។ នោះហើយជាមូលហេតុដែលខ្ញុំមិនប្រើ getters និង setters ខ្ញុំបានឈានដល់កម្រិតថ្មីមួយ!
កន្លែងដែលត្រូវយកគំរូថ្លៃ? ជាការប្រសើរណាស់ អ្នកអាចអានអ្វីមួយបាន ជាការពិត... ប៉ុន្តែខ្ញុំគិតថា វិធីល្អបំផុតគឺត្រូវធ្វើសកម្មភាព។ ការបង្កើតកម្មវិធីចងក្រងតូចមួយនឹងជាវិធីល្អបំផុតដើម្បីយល់ពីគំរូតម្លៃ ហើយសមនឹងវាទៅក្នុងក្បាលរបស់អ្នក។ កម្មវិធីចងក្រងតូចមួយដែលនឹងសាកសមសម្រាប់ការសរសេរកម្មវិធីមីក្រូវ៉េវ គឺជាកិច្ចការសម្រាប់អ្នកចាប់ផ្តើមដំបូង។ អញ្ចឹងខ្ញុំចង់និយាយថា ប្រសិនបើអ្នកមានជំនាញសរសេរកម្មវិធីរួចហើយ នោះគួរតែគ្រប់គ្រាន់ហើយ។ រឿងទាំងអស់នេះដូចជាការញែកខ្សែអក្សរដែលអ្នកមានជាប្រភេទនៃកន្សោមពិជគណិតមួយចំនួន ទាញយកសេចក្តីណែនាំសម្រាប់ប្រតិបត្តិការគណិតវិទ្យាពីទីនោះតាមលំដាប់លំដោយត្រឹមត្រូវ យកតម្លៃត្រឹមត្រូវពីការចុះឈ្មោះ - ទាំងអស់នេះត្រូវបានធ្វើនៅពេលតែមួយ។ ហើយខណៈពេលដែលអ្នកធ្វើវា វានឹងជាប់ក្នុងខួរក្បាលរបស់អ្នក។ ខ្ញុំគិតថាគ្រប់គ្នាដឹងពីអ្វីដែលអ្នកចងក្រងធ្វើ។ ហើយនេះនឹងផ្តល់នូវការយល់ដឹងអំពីគំរូតម្លៃ។

ឧទាហរណ៍ជាក់ស្តែងនៃការកែលម្អការអនុវត្ត

Andrei៖ តើ​អ្នក​គួរ​យក​ចិត្ត​ទុក​ដាក់​អ្វី​ទៀត​ពេល​ធ្វើ​ការ​លើ​ផលិតភាព?

ច្រាំងថ្មចោទ៖ រចនាសម្ព័ន្ធទិន្នន័យ។ និយាយអីញ្ចឹង ខ្ញុំមិនបានបង្រៀនថ្នាក់ទាំងនេះយូរហើយ... សាលារ៉ុក្កែត. វា​សប្បាយ​ណាស់ ប៉ុន្តែ​វា​ទាមទារ​ការ​ប្រឹងប្រែង​ច្រើន ហើយ​ខ្ញុំ​ក៏​មាន​ជីវិត​ដែរ! យល់ព្រម។ ដូច្នេះនៅក្នុងថ្នាក់ធំ និងគួរឱ្យចាប់អារម្មណ៍មួយ “តើការសម្តែងរបស់អ្នកទៅណា” ខ្ញុំបានផ្តល់ឧទាហរណ៍ដល់សិស្ស៖ ទិន្នន័យ fintech ពីរនិងកន្លះជីហ្គាបៃត្រូវបានអានពីឯកសារ CSV ហើយបន្ទាប់មកពួកគេត្រូវគណនាចំនួនផលិតផលដែលបានលក់។ . ទិន្នន័យទីផ្សារធីកធម្មតា។ កញ្ចប់ UDP បានបំប្លែងទៅជាទម្រង់អត្ថបទតាំងពីទសវត្សរ៍ទី 70 ។ Chicago Mercantile Exchange - របស់គ្រប់ប្រភេទដូចជា ប៊ឺ ពោត សណ្តែកសៀងជាដើម។ វាចាំបាច់ក្នុងការរាប់ផលិតផលទាំងនេះ ចំនួនប្រតិបត្តិការ បរិមាណមធ្យមនៃចលនានៃមូលនិធិ និងទំនិញ។ល។ វាជាគណិតវិទ្យានៃការជួញដូរសាមញ្ញណាស់៖ ស្វែងរកលេខកូដផលិតផល (នោះគឺ 1-2 តួអក្សរក្នុងតារាងសញ្ញា) ទទួលបានចំនួនទឹកប្រាក់ បន្ថែមវាទៅក្នុងសំណុំពាណិជ្ជកម្មមួយ បន្ថែមបរិមាណ បន្ថែមតម្លៃ និងរបស់មួយចំនួនទៀត។ គណិតវិទ្យាសាមញ្ញណាស់។ ការអនុវត្តរបស់ក្មេងលេងគឺសាមញ្ញណាស់៖ អ្វីគ្រប់យ៉ាងគឺនៅក្នុងឯកសារមួយ ខ្ញុំបានអានឯកសារ ហើយឆ្លងកាត់វា ដោយបែងចែកកំណត់ត្រានីមួយៗទៅជាខ្សែ Java រកមើលអ្វីដែលចាំបាច់នៅក្នុងពួកវា ហើយបន្ថែមវាទៅតាមគណិតវិទ្យាដែលបានពិពណ៌នាខាងលើ។ ហើយវាដំណើរការក្នុងល្បឿនទាប។

ជាមួយនឹងវិធីសាស្រ្តនេះ វាច្បាស់ណាស់ថាមានអ្វីកើតឡើង ហើយការគណនាប៉ារ៉ាឡែលនឹងមិនអាចជួយបានទេមែនទេ? វាប្រែថាការកើនឡើងចំនួនប្រាំដងក្នុងការអនុវត្តអាចសម្រេចបានដោយគ្រាន់តែជ្រើសរើសរចនាសម្ព័ន្ធទិន្នន័យត្រឹមត្រូវ។ ហើយការភ្ញាក់ផ្អើលនេះសូម្បីតែអ្នកសរសេរកម្មវិធីដែលមានបទពិសោធន៍! ក្នុងករណីពិសេសរបស់ខ្ញុំ ល្បិចគឺថាអ្នកមិនគួរធ្វើការបែងចែកអង្គចងចាំក្នុងរង្វង់ក្តៅនោះទេ។ ជាការប្រសើរណាស់, នេះមិនមែនជាការពិតទាំងស្រុងនោះទេប៉ុន្តែជាទូទៅ - អ្នកមិនគួរបន្លិច "ម្តងក្នុង X" នៅពេលដែល X មានទំហំធំគ្រប់គ្រាន់។ នៅពេលដែល X មានពីរជីហ្គាបៃកន្លះ អ្នកមិនគួរបែងចែកអ្វីទាំងអស់ "ម្តងក្នុងមួយលិខិត" ឬ "ម្តងក្នុងមួយជួរ" ឬ "ម្តងក្នុងមួយវាល" អ្វីទាំងអស់ដូចនោះ។ នេះគឺជាកន្លែងដែលពេលវេលាត្រូវបានចំណាយ។ តើវាដំណើរការយ៉ាងដូចម្តេច? ស្រមៃថាខ្ញុំកំពុងហៅទូរស័ព្ទ String.split() ឬ BufferedReader.readLine(). Readline បង្កើតខ្សែអក្សរពីសំណុំនៃបៃដែលបានមកលើបណ្តាញ ម្តងសម្រាប់បន្ទាត់នីមួយៗ សម្រាប់បន្ទាត់នីមួយៗនៃរាប់រយលាន។ ខ្ញុំ​យក​បន្ទាត់​នេះ​ញែក​វា​ហើយ​បោះ​វា​ចោល។ ហេតុអ្វី​បាន​ជា​ខ្ញុំ​បោះ​វា​ចោល - បាទ ខ្ញុំ​បាន​ដំណើរ​ការ​វា​រួច​ហើយ នោះ​ជា​ទាំង​អស់។ ដូច្នេះ សម្រាប់បៃនីមួយៗដែលបានអានពី 2.7G នេះ តួអក្សរពីរនឹងត្រូវបានសរសេរក្នុងបន្ទាត់ នោះគឺ 5.4G រួចហើយ ហើយខ្ញុំមិនត្រូវការវាសម្រាប់អ្វីទៀតទេ ដូច្នេះពួកគេត្រូវបានបោះចោល។ ប្រសិនបើអ្នកក្រឡេកមើលកម្រិតបញ្ជូននៃអង្គចងចាំ យើងផ្ទុក 2.7G ដែលឆ្លងកាត់ memory និង memory bus នៅក្នុង processor ហើយបន្ទាប់មកពីរដងត្រូវបានផ្ញើទៅកាន់បន្ទាត់ដែលស្ថិតនៅក្នុង memory ហើយអ្វីៗទាំងអស់នេះត្រូវបាន frayed នៅពេលដែលបន្ទាត់ថ្មីនីមួយៗត្រូវបានបង្កើត។ ប៉ុន្តែ​ខ្ញុំ​ត្រូវ​តែ​អាន​វា ហាដវែរ​អាន​វា ទោះបី​អ្វីៗ​ត្រូវ​បាន​បំភាន់​ពេល​ក្រោយ​ក៏ដោយ។ ហើយ​ខ្ញុំ​ត្រូវ​សរសេរ​វា​ចុះ ព្រោះ​ខ្ញុំ​បាន​បង្កើត​បន្ទាត់ ហើយ​ឃ្លាំង​សម្ងាត់​ពេញ ឃ្លាំង​សម្ងាត់​មិន​អាច​ផ្ទុក 2.7G បានទេ។ ដូច្នេះសម្រាប់រាល់បៃដែលខ្ញុំអាន ខ្ញុំបានអានពីរបៃទៀត ហើយសរសេរពីរបៃទៀត ហើយនៅទីបញ្ចប់ពួកគេមានសមាមាត្រ 4:1 - ក្នុងសមាមាត្រនេះយើងកំពុងខ្ជះខ្ជាយល្បឿននៃការចងចាំ។ ហើយបន្ទាប់មកវាប្រែថាប្រសិនបើខ្ញុំធ្វើ String.split() - នេះមិនមែនជាលើកចុងក្រោយដែលខ្ញុំធ្វើបែបនេះទេ ប្រហែលជាមានវាល 6-7 ផ្សេងទៀតនៅខាងក្នុង។ ដូច្នេះ កូដបុរាណនៃការអាន CSV ហើយបន្ទាប់មកការញែកខ្សែនេះនាំឱ្យបាត់បង់កម្រិតបញ្ជូនអង្គចងចាំប្រហែល 14: 1 ទាក់ទងទៅនឹងអ្វីដែលអ្នកពិតជាចង់មាន។ ប្រសិនបើអ្នកបោះចោលជម្រើសទាំងនេះ អ្នកអាចទទួលបានល្បឿនប្រាំដង។

ហើយវាមិនពិបាកនោះទេ។ ប្រសិនបើអ្នកក្រឡេកមើលកូដពីមុំខាងស្តាំ វានឹងក្លាយទៅជារឿងសាមញ្ញ នៅពេលដែលអ្នកដឹងពីបញ្ហា។ អ្នកមិនគួរបញ្ឈប់ការបែងចែកអង្គចងចាំទាំងស្រុងនោះទេ៖ បញ្ហាតែមួយគត់គឺអ្នកបែងចែកអ្វីមួយ ហើយវាស្លាប់ភ្លាមៗ ហើយនៅតាមផ្លូវដែលវាដុតបំផ្លាញធនធានដ៏សំខាន់ ដែលក្នុងករណីនេះគឺកម្រិតបញ្ជូននៃអង្គចងចាំ។ ហើយទាំងអស់នេះនាំឱ្យថយចុះផលិតភាព។ នៅលើ x86 ជាធម្មតាអ្នកត្រូវដុតវដ្តដំណើរការយ៉ាងសកម្ម ប៉ុន្តែនៅទីនេះអ្នកបានដុតអង្គចងចាំទាំងអស់មុនច្រើន។ ដំណោះស្រាយគឺកាត់បន្ថយបរិមាណទឹករំអិល។ 
ផ្នែកផ្សេងទៀតនៃបញ្ហានោះគឺថា ប្រសិនបើអ្នកដំណើរការ profiler នៅពេលដែលបន្ទះ memory អស់ ភ្លាមៗនៅពេលដែលវាកើតឡើង ជាធម្មតាអ្នកកំពុងរង់ចាំ cache ត្រឡប់មកវិញ ព្រោះវាពោរពេញដោយសំរាមដែលអ្នកទើបតែផលិត គ្រប់បន្ទាត់ទាំងនោះ។ ដូច្នេះរាល់ការផ្ទុក ឬប្រតិបត្តិការរបស់ហាងកាន់តែយឺត ព្រោះវានាំឱ្យបាត់ឃ្លាំងសម្ងាត់ - ឃ្លាំងសម្ងាត់ទាំងមូលបានប្រែជាយឺត រង់ចាំសំរាមទុកចោល។ ដូច្នេះ ប្រូហ្វាលនឹងគ្រាន់តែបង្ហាញសំលេងរំខានក្តៅៗដែលលាបពេញរង្វង់ទាំងមូល វានឹងមិនមានការណែនាំ ឬកន្លែងក្តៅដាច់ដោយឡែកនៅក្នុងកូដនោះទេ។ សំលេងរំខានតែប៉ុណ្ណោះ។ ហើយប្រសិនបើអ្នកក្រឡេកមើលវដ្ត GC ពួកគេទាំងអស់សុទ្ធតែជា Young Generation ហើយមានល្បឿនលឿនបំផុត - microseconds ឬ milliseconds អតិបរមា។ យ៉ាងណាមិញ ការចងចាំទាំងអស់នេះនឹងស្លាប់ភ្លាមៗ។ អ្នកបែងចែករាប់ពាន់លានជីហ្គាបៃ ហើយគាត់កាត់វា ហើយកាត់វា ហើយកាត់វាម្តងទៀត។ ទាំងអស់នេះកើតឡើងយ៉ាងលឿន។ វាប្រែថាមានវដ្ត GC ថោក សំលេងរំខានក្តៅៗតាមវដ្តទាំងមូល ប៉ុន្តែយើងចង់ទទួលបានល្បឿន 5x។ នៅពេលនេះ អ្វីមួយគួរតែបិទនៅក្នុងក្បាលរបស់អ្នក ហើយបន្លឺឡើងថា "ហេតុអ្វីបានជានេះ?!" ការហៀរនៃបន្ទះអង្គចងចាំមិនត្រូវបានបង្ហាញនៅក្នុងកម្មវិធីបំបាត់កំហុសបុរាណទេ អ្នកត្រូវដំណើរការកម្មវិធីប្រឆាំងការបំបាត់កំហុសផ្នែករឹង ហើយមើលវាដោយខ្លួនឯង និងដោយផ្ទាល់។ ប៉ុន្តែនេះមិនអាចត្រូវបានគេសង្ស័យដោយផ្ទាល់ពីរោគសញ្ញាទាំងបីនេះទេ។ រោគសញ្ញាទីបីគឺនៅពេលអ្នកមើលអ្វីដែលអ្នកគូសបញ្ជាក់ សួរអ្នកបង្កើតទម្រង់ ហើយគាត់ឆ្លើយថា "អ្នកបានបង្កើតជួរមួយពាន់លាន ប៉ុន្តែ GC ដំណើរការដោយមិនគិតថ្លៃ"។ នៅពេលវាកើតឡើង អ្នកដឹងថាអ្នកបានបង្កើតវត្ថុច្រើនពេក ហើយបានដុតផ្លូវចងចាំទាំងមូល។ មានវិធីដើម្បីដោះស្រាយរឿងនេះ ប៉ុន្តែវាមិនច្បាស់ទេ។ 

បញ្ហាគឺនៅក្នុងរចនាសម្ព័ន្ធទិន្នន័យ៖ រចនាសម្ព័ន្ធទទេដែលស្ថិតនៅក្រោមអ្វីគ្រប់យ៉ាងដែលកើតឡើង វាធំពេក វាមាន 2.7G នៅលើថាស ដូច្នេះការធ្វើច្បាប់ចម្លងនៃរឿងនេះគឺមិនគួរឱ្យចង់បានខ្លាំងណាស់ - អ្នកចង់ផ្ទុកវាពីបណ្តុំបណ្តាញប៊ីតភ្លាមៗ។ ចូលទៅក្នុងការចុះឈ្មោះ ដើម្បីកុំឱ្យអាន-សរសេរទៅបន្ទាត់ត្រឡប់មកវិញ ប្រាំដង។ ជាអកុសល Java មិនផ្តល់ឱ្យអ្នកនូវបណ្ណាល័យបែបនេះជាផ្នែកនៃ JDK តាមលំនាំដើមទេ។ ប៉ុន្តែនេះជារឿងតូចតាចមែនទេ? សំខាន់ ទាំងនេះគឺជា 5-10 ជួរនៃកូដដែលនឹងត្រូវបានប្រើដើម្បីអនុវត្តកម្មវិធីផ្ទុកខ្សែអក្សរ buffered ផ្ទាល់ខ្លួនរបស់អ្នក ដែលធ្វើឡើងវិញនូវឥរិយាបទនៃថ្នាក់ខ្សែអក្សរ ខណៈដែលកំពុងរុំជុំវិញសតិបណ្ដោះអាសន្ន byte មូលដ្ឋាន។ ជាលទ្ធផល វាបង្ហាញថាអ្នកកំពុងធ្វើការស្ទើរតែដូចជាខ្សែអក្សរ ប៉ុន្តែតាមពិត ចង្អុលទៅសតិបណ្ដោះអាសន្នកំពុងផ្លាស់ទីទៅទីនោះ ហើយបៃឆៅមិនត្រូវបានចម្លងពីកន្លែងណាទេ ដូច្នេះហើយ សតិបណ្ដោះអាសន្នដូចគ្នាត្រូវប្រើម្តងហើយម្តងទៀត ហើយ ប្រព័ន្ធប្រតិបត្តិការរីករាយនឹងទទួលយកដោយខ្លួនឯងនូវអ្វីៗដែលវាត្រូវបានរចនាឡើងសម្រាប់ ដូចជាការលាក់បាំងសតិបណ្ដោះអាសន្នពីរដងនៃប៊ីត សតិបណ្ដោះអាសន្ន ហើយអ្នកលែងដំណើរការទិន្នន័យដែលមិនចាំបាច់គ្មានទីបញ្ចប់ទៀតហើយ។ និយាយអីញ្ចឹងតើអ្នកយល់ទេថានៅពេលធ្វើការជាមួយ GC វាត្រូវបានធានាថាការបែងចែកអង្គចងចាំនីមួយៗនឹងមិនអាចមើលឃើញដោយខួរក្បាលបន្ទាប់ពីវដ្ត GC ចុងក្រោយ? ដូច្នេះ អ្វីៗទាំងអស់នេះមិនអាចស្ថិតនៅក្នុងឃ្លាំងសម្ងាត់បានទេ ហើយបន្ទាប់មកការខកខានដែលបានធានា 100% កើតឡើង។ នៅពេលធ្វើការជាមួយទ្រនិចនៅលើ x86 ការដកការចុះឈ្មោះចេញពីអង្គចងចាំត្រូវចំណាយពេល 1-2 វដ្ត ហើយភ្លាមៗនៅពេលដែលវាកើតឡើង អ្នកបង់ បង់ បង់ ពីព្រោះអង្គចងចាំត្រូវបានបើក។ ប្រាំបួនឃ្លាំងសម្ងាត់ - ហើយនេះគឺជាតម្លៃនៃការបែងចែកការចងចាំ។ តម្លៃពិត។

ម្យ៉ាងវិញទៀត រចនាសម្ព័ន្ធទិន្នន័យគឺជារឿងពិបាកបំផុតក្នុងការផ្លាស់ប្តូរ។ ហើយនៅពេលដែលអ្នកដឹងថាអ្នកបានជ្រើសរើសរចនាសម្ព័ន្ធទិន្នន័យខុសដែលនឹងសម្លាប់ដំណើរការនៅពេលក្រោយ ជាធម្មតាមានការងារជាច្រើនដែលត្រូវធ្វើ ប៉ុន្តែប្រសិនបើអ្នកមិនធ្វើទេ អ្វីៗនឹងកាន់តែអាក្រក់ទៅៗ។ ដំបូងអ្នកត្រូវគិតអំពីរចនាសម្ព័ន្ធទិន្នន័យ នេះមានសារៈសំខាន់ណាស់។ ការចំណាយចម្បងនៅទីនេះគឺអាស្រ័យលើរចនាសម្ព័ន្ធទិន្នន័យខ្លាញ់ ដែលចាប់ផ្តើមប្រើក្នុងរចនាប័ទ្ម "ខ្ញុំបានចម្លងរចនាសម្ព័ន្ធទិន្នន័យ X ទៅក្នុងរចនាសម្ព័ន្ធទិន្នន័យ Y ពីព្រោះខ្ញុំចូលចិត្តរូបរាង Y ប្រសើរជាង" ។ ប៉ុន្តែប្រតិបត្តិការចម្លង (ដែលហាក់បីដូចជាថោក) ពិតជាខ្ជះខ្ជាយល្បឿននៃអង្គចងចាំ ហើយនោះជាកន្លែងដែលការខ្ជះខ្ជាយពេលវេលាប្រតិបត្តិទាំងអស់ត្រូវបានកប់។ ប្រសិនបើខ្ញុំមានខ្សែអក្សរ JSON ដ៏ធំ ហើយខ្ញុំចង់ប្រែក្លាយវាទៅជាមែកធាង DOM ដែលមានរចនាសម្ព័ន្ធនៃ POJOs ឬអ្វីមួយនោះ ប្រតិបត្តិការញែកខ្សែអក្សរនោះ និងបង្កើត POJO ហើយបន្ទាប់មកចូលប្រើ POJO ម្តងទៀតនៅពេលក្រោយ នឹងបណ្តាលឱ្យមានការចំណាយមិនចាំបាច់ - វាជា មិនថោកទេ។ លើកលែងតែអ្នករត់ជុំវិញ POJOs ញឹកញាប់ជាងអ្នករត់ជុំវិញខ្សែអក្សរ។ Offhand អ្នកអាចព្យាយាមឌិគ្រីបខ្សែអក្សរ ហើយទាញយកតែអ្វីដែលអ្នកត្រូវការពីទីនោះ ដោយមិនបង្វែរវាទៅជា POJO ណាមួយឡើយ។ ប្រសិនបើអ្វីៗទាំងអស់នេះកើតឡើងនៅលើផ្លូវដែលតម្រូវឱ្យមានការអនុវត្តអតិបរមា នោះគ្មាន POJO សម្រាប់អ្នកទេ អ្នកត្រូវជីកចូលទៅក្នុងបន្ទាត់ដោយផ្ទាល់។

ហេតុអ្វីបានជាបង្កើតភាសាសរសេរកម្មវិធីផ្ទាល់ខ្លួនរបស់អ្នក។

Andrei៖ អ្នក​បាន​និយាយ​ថា ដើម្បី​យល់​ពី​គំរូ​តម្លៃ អ្នក​ត្រូវ​សរសេរ​ភាសា​តូច​ៗ​របស់​អ្នក...

ច្រាំងថ្មចោទ៖ មិនមែនជាភាសាទេ ប៉ុន្តែជាអ្នកចងក្រង។ ភាសាមួយ និងកម្មវិធីចងក្រង គឺជារឿងពីរផ្សេងគ្នា។ ភាពខុសគ្នាដ៏សំខាន់បំផុតគឺនៅក្នុងក្បាលរបស់អ្នក។ 

Andrei៖ តាម​ដែល​ខ្ញុំ​ដឹង អ្នក​កំពុង​សាកល្បង​បង្កើត​ភាសា​របស់​អ្នក​ផ្ទាល់។ ដើម្បីអ្វី?

ច្រាំងថ្មចោទ៖ ព្រោះខ្ញុំអាច! ខ្ញុំចូលនិវត្តន៍ពាក់កណ្តាល ដូច្នេះនេះជាចំណង់ចំណូលចិត្តរបស់ខ្ញុំ។ ខ្ញុំ​បាន​អនុវត្ត​ភាសា​អ្នក​ដទៃ​ពេញ​មួយ​ជីវិត។ ខ្ញុំក៏បានធ្វើការច្រើនលើរចនាប័ទ្មសរសេរកូដរបស់ខ្ញុំផងដែរ។ ហើយ​ក៏​ព្រោះ​ខ្ញុំ​ឃើញ​បញ្ហា​ជា​ភាសា​ផ្សេង។ ខ្ញុំ​ឃើញ​ថា​មាន​វិធី​ល្អ​ជាង​ដើម្បី​ធ្វើ​រឿង​ដែល​ធ្លាប់​ស្គាល់។ ហើយខ្ញុំនឹងប្រើពួកគេ។ ខ្ញុំគ្រាន់តែធុញទ្រាន់នឹងការមើលឃើញបញ្ហានៅក្នុងខ្លួនខ្ញុំ នៅក្នុង Java, នៅក្នុង Python, ជាភាសាផ្សេងទៀត។ ឥឡូវនេះខ្ញុំសរសេរនៅក្នុង React Native, JavaScript និង Elm ជាចំណង់ចំណូលចិត្តដែលមិនមែនអំពីការចូលនិវត្តន៍ទេ ប៉ុន្តែអំពីការងារសកម្ម។ ខ្ញុំក៏សរសេរនៅក្នុង Python ហើយទំនងជានឹងបន្តធ្វើការលើ machine learning សម្រាប់ Java backends។ មានភាសាពេញនិយមជាច្រើន ហើយពួកគេទាំងអស់មានលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍។ មនុស្សគ្រប់គ្នាសុទ្ធតែល្អតាមរបៀបរបស់ពួកគេ ហើយអ្នកអាចព្យាយាមនាំយកលក្ខណៈពិសេសទាំងអស់នេះមកជាមួយគ្នា។ ដូច្នេះ ខ្ញុំកំពុងសិក្សាអ្វីដែលខ្ញុំចាប់អារម្មណ៍ អាកប្បកិរិយានៃភាសា ព្យាយាមបង្កើតអត្ថន័យសមហេតុផល។ ហើយមកដល់ពេលនេះខ្ញុំជោគជ័យហើយ! នៅពេលនេះខ្ញុំកំពុងជួបបញ្ហាជាមួយ memory semantics ពីព្រោះខ្ញុំចង់មានវាដូចនៅក្នុង C និង Java ហើយទទួលបានគំរូ memory និង memory semantics ខ្លាំងសម្រាប់ការផ្ទុក និង store ។ ក្នុងពេលជាមួយគ្នានេះ មានការសន្និដ្ឋានប្រភេទដោយស្វ័យប្រវត្តិដូចជានៅក្នុង Haskell ។ នៅទីនេះខ្ញុំកំពុងព្យាយាមលាយការសន្និដ្ឋានប្រភេទ Haskell ជាមួយនឹងការធ្វើការអង្គចងចាំទាំងនៅក្នុង C និង Java ។ នេះជាអ្វីដែលខ្ញុំបានធ្វើសម្រាប់ 2-3 ខែចុងក្រោយនេះឧទាហរណ៍។

Andrei៖ ប្រសិនបើអ្នកបង្កើតភាសាដែលយកទិដ្ឋភាពល្អជាងពីភាសាផ្សេងទៀត តើអ្នកគិតថានរណាម្នាក់នឹងធ្វើផ្ទុយពីនេះ៖ យកគំនិតរបស់អ្នក ហើយប្រើវា?

ច្រាំងថ្មចោទ៖ នេះជារបៀបដែលភាសាថ្មីលេចឡើង! ហេតុអ្វីបានជា Java ស្រដៀងនឹង C? ដោយសារតែ C មានវាក្យសម្ព័ន្ធដ៏ល្អដែលមនុស្សគ្រប់គ្នាយល់ ហើយ Java ត្រូវបានបំផុសគំនិតដោយវាក្យសម្ព័ន្ធនេះ ដោយបន្ថែមសុវត្ថិភាពប្រភេទ ការត្រួតពិនិត្យព្រំដែនអារេ GC ហើយពួកគេក៏បានកែលម្អអ្វីៗមួយចំនួនពី C. ពួកគេបានបន្ថែមរបស់ពួកគេ។ ប៉ុន្តែពួកគេត្រូវបានបំផុសគំនិតយ៉ាងខ្លាំងមែនទេ? មនុស្សគ្រប់គ្នាឈរនៅលើស្មារបស់យក្សដែលបានមកមុនអ្នក - នោះហើយជារបៀបដែលការរីកចម្រើនត្រូវបានបង្កើតឡើង។

Andrei៖ ដូចដែលខ្ញុំយល់ហើយ ភាសារបស់អ្នកនឹងមានសុវត្ថិភាពក្នុងការចងចាំ។ តើ​អ្នក​បាន​គិត​អំពី​ការ​អនុវត្ត​អ្វី​មួយ​ដូច​ជា​កម្មវិធី​ខ្ចី​ប្រាក់​ពី Rust ដែរ​ឬ​ទេ? តើអ្នកបានមើលគាត់ហើយ តើអ្នកគិតយ៉ាងណាចំពោះគាត់?

ច្រាំងថ្មចោទ៖ ជាការប្រសើរណាស់, ខ្ញុំបានសរសេរ C អស់ជាច្រើនឆ្នាំ ជាមួយនឹង malloc ទាំងអស់នេះ និងឥតគិតថ្លៃ និងគ្រប់គ្រងដោយដៃពេញមួយជីវិត។ អ្នកដឹងទេ 90-95% នៃពេលវេលាគ្រប់គ្រងដោយដៃមានរចនាសម្ព័ន្ធដូចគ្នា។ ហើយវាពិតជាឈឺចាប់ខ្លាំងណាស់ក្នុងការធ្វើវាដោយដៃ។ ខ្ញុំចង់ឱ្យអ្នកចងក្រងប្រាប់អ្នកពីអ្វីដែលកំពុងកើតឡើងនៅទីនោះ និងអ្វីដែលអ្នកសម្រេចបានជាមួយនឹងសកម្មភាពរបស់អ្នក។ សម្រាប់​រឿង​មួយ​ចំនួន អ្នក​ខ្ចី​ធីក​ធ្វើ​វា​ក្រៅ​ប្រអប់។ ហើយវាគួរតែបង្ហាញព័ត៌មានដោយស្វ័យប្រវត្តិ យល់គ្រប់យ៉ាង ហើយមិនដាក់បន្ទុកខ្ញុំក្នុងការបង្ហាញការយល់ដឹងនេះទេ។ វាត្រូវតែធ្វើការវិភាគរត់គេចខ្លួនយ៉ាងហោចណាស់ក្នុងមូលដ្ឋាន ហើយលុះត្រាតែវាបរាជ័យ នោះវាចាំបាច់ត្រូវបន្ថែមចំណារពន្យល់ប្រភេទដែលនឹងពណ៌នាអំពីអាយុកាល - ហើយគ្រោងការណ៍បែបនេះគឺស្មុគស្មាញជាងឧបករណ៍ពិនិត្យខ្ចី ឬពិតជាឧបករណ៍ពិនិត្យអង្គចងចាំដែលមានស្រាប់។ ជម្រើសរវាង "អ្វីគ្រប់យ៉ាងគឺល្អ" និង "ខ្ញុំមិនយល់អ្វីទាំងអស់" - ទេត្រូវតែមានអ្វីដែលប្រសើរជាងនេះ។ 
ដូច្នេះក្នុងនាមជាអ្នកដែលបានសរសេរកូដជាច្រើននៅក្នុង C ខ្ញុំគិតថាការមានការគាំទ្រសម្រាប់ការគ្រប់គ្រងពេញមួយជីវិតដោយស្វ័យប្រវត្តិគឺជារឿងសំខាន់បំផុត។ ខ្ញុំក៏ធុញទ្រាន់នឹងចំនួនដែល Java ប្រើអង្គចងចាំ ហើយពាក្យបណ្តឹងសំខាន់គឺ GC ។ នៅពេលអ្នកបែងចែកអង្គចងចាំក្នុង Java អ្នកនឹងមិនអាចទទួលបានអង្គចងចាំដែលមានមូលដ្ឋាននៅវដ្ត GC ចុងក្រោយនោះទេ។ នេះមិនមែនជាករណីនៅក្នុងភាសាដែលមានការគ្រប់គ្រងអង្គចងចាំច្បាស់លាស់ជាងនេះទេ។ ប្រសិនបើអ្នកទូរស័ព្ទទៅ malloc អ្នកនឹងទទួលបានអង្គចងចាំភ្លាមៗ ដែលជាធម្មតាទើបតែបានប្រើ។ ជាធម្មតា អ្នកធ្វើរឿងបណ្ដោះអាសន្នមួយចំនួនដោយការចងចាំ ហើយត្រលប់មកវិញភ្លាមៗ។ ហើយភ្លាមៗនោះវាត្រលប់ទៅអាងផ្សារម៉ាឡូក ហើយវដ្តម៉ាឡូកបន្ទាប់ទាញវាចេញម្តងទៀត។ ដូច្នេះការប្រើប្រាស់អង្គចងចាំពិតប្រាកដត្រូវបានកាត់បន្ថយទៅសំណុំនៃវត្ថុមានជីវិតនៅពេលជាក់លាក់មួយ បូកនឹងការលេចធ្លាយ។ ហើយប្រសិនបើអ្វីៗទាំងអស់មិនលេចធ្លាយក្នុងវិធីមិនសមរម្យទាំងស្រុងទេ អង្គចងចាំភាគច្រើនបញ្ចប់ដោយឃ្លាំងសម្ងាត់ និងខួរក្បាល ហើយវាដំណើរការបានយ៉ាងឆាប់រហ័ស។ ប៉ុន្តែតម្រូវឱ្យមានការគ្រប់គ្រងអង្គចងចាំដោយដៃច្រើនជាមួយ malloc និងការហៅដោយឥតគិតថ្លៃតាមលំដាប់ត្រឹមត្រូវ នៅកន្លែងត្រឹមត្រូវ។ ច្រែះអាចដោះស្រាយវាបានយ៉ាងត្រឹមត្រូវដោយខ្លួនឯង ហើយក្នុងករណីជាច្រើនផ្តល់នូវដំណើរការកាន់តែប្រសើរជាងមុន ចាប់តាំងពីការប្រើប្រាស់អង្គចងចាំត្រូវបានរួមតូចទៅត្រឹមតែការគណនាបច្ចុប្បន្នប៉ុណ្ណោះ - ផ្ទុយពីការរង់ចាំវដ្ត GC បន្ទាប់ដើម្បីរំដោះអង្គចងចាំ។ ជាលទ្ធផល យើងទទួលបានវិធីដ៏គួរឱ្យចាប់អារម្មណ៍មួយដើម្បីកែលម្អការអនុវត្ត។ ហើយមានថាមពលខ្លាំង - ខ្ញុំមានន័យថា ខ្ញុំបានធ្វើរឿងបែបនេះនៅពេលដំណើរការទិន្នន័យសម្រាប់ fintech ហើយនេះអនុញ្ញាតឱ្យខ្ញុំបង្កើនល្បឿនប្រហែល XNUMX ដង។ នោះគឺជាការជំរុញដ៏ធំមួយ ជាពិសេសនៅក្នុងពិភពលោកដែលប្រព័ន្ធដំណើរការមិនដំណើរការលឿនជាងមុន ហើយយើងនៅតែរង់ចាំការកែលម្អ។

អាជីពវិស្វករការសម្តែង

Andrei៖ ខ្ញុំក៏ចង់សួរជុំវិញអាជីពជាទូទៅដែរ។ អ្នកកាន់តែមានភាពល្បីល្បាញជាមួយនឹងការងារ JIT របស់អ្នកនៅ HotSpot ហើយបន្ទាប់មកបានផ្លាស់ទៅ Azul ដែលជាក្រុមហ៊ុន JVM ផងដែរ។ ប៉ុន្តែ​យើង​បាន​ធ្វើ​ការ​ច្រើន​ជាង​ផ្នែក​រឹង​ជាង​កម្មវិធី​រួច​ទៅ​ហើយ។ ហើយភ្លាមៗនោះពួកគេបានប្តូរទៅ Big Data និង Machine Learning ហើយបន្ទាប់មកទៅរកការរកឃើញការក្លែងបន្លំ។ តើរឿងនេះកើតឡើងដោយរបៀបណា? ទាំងនេះគឺជាវិស័យអភិវឌ្ឍន៍ខុសគ្នាខ្លាំង។

ច្រាំងថ្មចោទ៖ ខ្ញុំ​បាន​សរសេរ​កម្មវិធី​អស់​រយៈពេល​ជា​យូរ​មក​ហើយ ហើយ​បាន​គ្រប់គ្រង​ថ្នាក់​ផ្សេង​ៗ​ជា​ច្រើន។ ហើយនៅពេលដែលមនុស្សនិយាយថា "អូ អ្នកគឺជាអ្នកដែលបានធ្វើ JIT សម្រាប់ Java!" វាតែងតែកំប្លែង។ ប៉ុន្តែមុននោះ ខ្ញុំបានធ្វើការលើក្លូននៃ PostScript ដែលជាភាសាដែល Apple ធ្លាប់ប្រើសម្រាប់ម៉ាស៊ីនបោះពុម្ពឡាស៊ែររបស់ខ្លួន។ ហើយមុននោះ ខ្ញុំបានអនុវត្តភាសាហ្វត។ ខ្ញុំគិតថាប្រធានបទទូទៅសម្រាប់ខ្ញុំគឺការអភិវឌ្ឍន៍ឧបករណ៍។ ពេញមួយជីវិតរបស់ខ្ញុំ ខ្ញុំបានបង្កើតឧបករណ៍ដែលមនុស្សផ្សេងទៀតសរសេរកម្មវិធីល្អៗរបស់ពួកគេ។ ប៉ុន្តែខ្ញុំក៏បានចូលរួមផងដែរក្នុងការអភិវឌ្ឍន៍ប្រព័ន្ធប្រតិបត្តិការ កម្មវិធីបញ្ជា កម្មវិធីបំបាត់កំហុសកម្រិតខឺណែល ភាសាសម្រាប់ការអភិវឌ្ឍន៍ប្រព័ន្ធប្រតិបត្តិការ ដែលបានចាប់ផ្តើមមិនច្បាស់លាស់ ប៉ុន្តែយូរៗទៅកាន់តែស្មុគស្មាញ។ ប៉ុន្តែប្រធានបទសំខាន់នៅតែជាការអភិវឌ្ឍន៍ឧបករណ៍។ ផ្នែកដ៏ធំមួយនៃជីវិតរបស់ខ្ញុំបានឆ្លងកាត់រវាង Azul និង Sun ហើយវានិយាយអំពីកោះជ្វា។ ប៉ុន្តែនៅពេលដែលខ្ញុំចូលទៅក្នុង Big Data និង Machine Learning ខ្ញុំបានដាក់មួកពុម្ពអក្សរក្បូរក្បាច់របស់ខ្ញុំឡើងវិញ ហើយនិយាយថា "អូ ឥឡូវនេះយើងមានបញ្ហាមិនសំខាន់ ហើយមានរឿងគួរឱ្យចាប់អារម្មណ៍ជាច្រើនកំពុងកើតឡើង ហើយមនុស្សកំពុងធ្វើអ្វីៗ" ។ នេះ​ជា​ផ្លូវ​អភិវឌ្ឍន៍​ដ៏​អស្ចារ្យ​មួយ​ដែល​ត្រូវ​យក។

បាទ ខ្ញុំពិតជាចូលចិត្តការចែកចាយកុំព្យូទ័រ។ ការងារដំបូងរបស់ខ្ញុំគឺជានិស្សិតនៅ C លើគម្រោងផ្សាយពាណិជ្ជកម្ម។ នេះត្រូវបានចែកចាយដោយការគណនានៅលើបន្ទះឈីប Zilog Z80 ដែលប្រមូលទិន្នន័យសម្រាប់អាណាឡូក OCR ដែលផលិតដោយអ្នកវិភាគអាណាឡូកពិតប្រាកដ។ វាជាប្រធានបទដ៏ត្រជាក់ និងឆ្កួតទាំងស្រុង។ ប៉ុន្តែមានបញ្ហា ផ្នែកខ្លះមិនត្រូវបានគេទទួលស្គាល់ត្រឹមត្រូវ ដូច្នេះអ្នកត្រូវយករូបភាពមួយចេញ ហើយបង្ហាញវាដល់អ្នកដែលអាចអានដោយភ្នែករបស់ពួកគេរួចហើយ ហើយរាយការណ៍ពីអ្វីដែលវានិយាយ ដូច្នេះហើយមានការងារជាមួយទិន្នន័យ ហើយការងារទាំងនេះ មានភាសាផ្ទាល់ខ្លួន។ មានផ្នែកខាងក្រោយដែលដំណើរការទាំងអស់នេះ - Z80s ដំណើរការស្របជាមួយស្ថានីយ vt100 ដែលកំពុងដំណើរការ - មួយក្នុងមនុស្សម្នាក់ ហើយមានគំរូកម្មវិធីស្របគ្នានៅលើ Z80 ។ បំណែកនៃអង្គចងចាំទូទៅមួយចំនួនដែលត្រូវបានចែករំលែកដោយ Z80s ទាំងអស់នៅក្នុងការកំណត់រចនាសម្ព័ន្ធផ្កាយ។ យន្តហោះខាងក្រោយក៏ត្រូវបានចែករំលែកផងដែរ ហើយពាក់កណ្តាលនៃ RAM ត្រូវបានចែករំលែកនៅក្នុងបណ្តាញ ហើយពាក់កណ្តាលផ្សេងទៀតគឺឯកជន ឬទៅកាន់អ្វីផ្សេងទៀត។ ប្រព័ន្ធចែកចាយប៉ារ៉ាឡែលស្មុគ្រស្មាញប្រកបដោយអត្ថន័យជាមួយការចែករំលែក... សតិពាក់កណ្តាលចែករំលែក។ តើ​នេះ​នៅ​ពេល​ណា... ខ្ញុំ​មិន​អាច​ចាំ​បាន​ទេ កន្លែង​ណា​មួយ​នៅ​ពាក់​កណ្តាល​ទសវត្សរ៍​ទី ៨០។ យូរណាស់មកហើយ។ 
បាទ សូម​សន្មត​ថា 30 ឆ្នាំ​គឺ​ជា​យូរ​មក​ហើយ។ បញ្ហា​ទាក់ទង​នឹង​ការ​ចែក​ចាយ​កុំព្យូទ័រ​មាន​ជា​យូរ​មក​ហើយ មនុស្ស​បាន​ធ្វើ​សង្រ្គាម​ជា​យូរ​មក​ហើយ។ Beowulf-ចង្កោម។ ចង្កោមបែបនេះមើលទៅដូចជា... ឧទាហរណ៍៖ មានអ៊ីសឺរណិត ហើយ x86 លឿនរបស់អ្នកត្រូវបានភ្ជាប់ទៅអ៊ីសឺរណិតនេះ ហើយឥឡូវនេះអ្នកចង់ទទួលបានអង្គចងចាំដែលបានចែករំលែកក្លែងក្លាយ ពីព្រោះគ្មាននរណាម្នាក់អាចធ្វើការសរសេរកូដកុំព្យូទ័រដែលបានចែកចាយនៅពេលនោះ វាពិបាកពេក ដូច្នេះហើយនៅទីនោះ គឺជាអង្គចងចាំដែលបានចែករំលែកក្លែងក្លាយជាមួយនឹងទំព័រអង្គចងចាំការពារនៅលើ x86 ហើយប្រសិនបើអ្នកសរសេរទៅទំព័រនេះ នោះយើងបានប្រាប់អ្នកដំណើរការផ្សេងទៀតថា ប្រសិនបើពួកគេចូលប្រើអង្គចងចាំដែលបានចែករំលែកដូចគ្នានោះ វានឹងត្រូវផ្ទុកពីអ្នក ហើយដូច្នេះអ្វីមួយដូចជាពិធីការសម្រាប់ការគាំទ្រ។ cache coherence បានបង្ហាញខ្លួន ហើយកម្មវិធីសម្រាប់រឿងនេះ។ គំនិតគួរឱ្យចាប់អារម្មណ៍។ ជា​ការ​ពិត​ណាស់ បញ្ហា​ពិត​គឺ​ជា​អ្វី​ផ្សេង​ទៀត។ អ្វីៗទាំងអស់នេះដំណើរការ ប៉ុន្តែអ្នកមានបញ្ហាក្នុងការអនុវត្តភ្លាមៗ ពីព្រោះគ្មាននរណាម្នាក់យល់អំពីគំរូនៃការអនុវត្តក្នុងកម្រិតល្អគ្រប់គ្រាន់នោះទេ - តើទម្រង់នៃការចូលប្រើអង្គចងចាំអ្វីខ្លះនៅទីនោះ របៀបធ្វើឱ្យប្រាកដថាថ្នាំងមិនវាយគ្នាឥតឈប់ឈរ ហើយដូច្នេះនៅលើ។

អ្វីដែលខ្ញុំបានបង្កើតឡើងនៅក្នុង H2O គឺថាវាគឺជាអ្នកអភិវឌ្ឍន៍ខ្លួនឯងដែលទទួលខុសត្រូវក្នុងការកំណត់កន្លែងដែលភាពស្របគ្នាត្រូវបានលាក់ និងកន្លែងដែលវាមិនមែន។ ខ្ញុំបានបង្កើតគំរូសរសេរកូដដែលធ្វើឱ្យការសរសេរកូដដែលមានប្រសិទ្ធភាពខ្ពស់មានភាពងាយស្រួល និងសាមញ្ញ។ ប៉ុន្តែការសរសេរកូដដែលដំណើរការយឺតគឺពិបាក វានឹងមើលទៅអាក្រក់។ អ្នកត្រូវព្យាយាមយ៉ាងមុតមាំក្នុងការសរសេរកូដយឺត អ្នកនឹងត្រូវប្រើវិធីសាស្ត្រមិនស្តង់ដារ។ លេខកូដហ្វ្រាំងអាចមើលឃើញនៅ glance ដំបូង។ ជាលទ្ធផល ជាធម្មតាអ្នកសរសេរកូដដែលដំណើរការលឿន ប៉ុន្តែអ្នកត្រូវស្វែងយល់ពីអ្វីដែលត្រូវធ្វើក្នុងករណីមានអង្គចងចាំរួម។ ទាំងអស់នេះត្រូវបានចងភ្ជាប់ទៅនឹងអារេធំ ហើយឥរិយាបទនៅទីនោះគឺស្រដៀងទៅនឹងអារេធំដែលមិនងាយនឹងបង្កជាហេតុនៅក្នុង Java ប៉ារ៉ាឡែល។ ខ្ញុំមានន័យថា ស្រមៃថា ខ្សែអក្សរពីរសរសេរទៅអារេប៉ារ៉ាឡែល មួយក្នុងចំនោមពួកគេឈ្នះ ហើយមួយទៀតចាញ់តាមនោះ ហើយអ្នកមិនដឹងថាមួយណាជាមួយណាទេ។ ប្រសិនបើពួកគេមិនមានភាពប្រែប្រួលទេនោះការបញ្ជាទិញអាចជាអ្វីដែលអ្នកចង់បាន - ហើយនេះពិតជាដំណើរការល្អ។ មនុស្សពិតជាយកចិត្តទុកដាក់ចំពោះលំដាប់នៃប្រតិបត្តិការ ពួកគេដាក់ភាពប្រែប្រួលនៅកន្លែងដែលត្រឹមត្រូវ ហើយពួកគេរំពឹងថាមានបញ្ហាដំណើរការទាក់ទងនឹងការចងចាំនៅកន្លែងត្រឹមត្រូវ។ បើមិនដូច្នេះទេ ពួកគេនឹងសរសេរកូដជាទម្រង់រង្វិលជុំពី 1 ដល់ N ដែល N ជាចំនួនពាន់ពាន់លាន ដោយសង្ឃឹមថាករណីស្មុគស្មាញទាំងអស់នឹងមានភាពស្របគ្នាដោយស្វ័យប្រវត្តិ ហើយវាមិនដំណើរការនៅទីនោះទេ។ ប៉ុន្តែនៅក្នុង H2O នេះមិនមែនជា Java ឬ Scala ទេ អ្នកអាចពិចារណាវាថា "Java ដកដក" ប្រសិនបើអ្នកចង់បាន។ នេះគឺជារចនាប័ទ្មកម្មវិធីច្បាស់លាស់ ហើយស្រដៀងនឹងការសរសេរកូដ C ឬ Java សាមញ្ញជាមួយនឹងរង្វិលជុំ និងអារេ។ ប៉ុន្តែនៅពេលជាមួយគ្នានោះអង្គចងចាំអាចត្រូវបានដំណើរការជា terabytes ។ ខ្ញុំនៅតែប្រើ H2O ។ ខ្ញុំប្រើវាម្តងម្កាលនៅក្នុងគម្រោងផ្សេងៗគ្នា - ហើយវានៅតែជារឿងលឿនបំផុត លឿនជាងគូប្រជែងរាប់សិបដង។ ប្រសិនបើអ្នកកំពុងធ្វើ Big Data ជាមួយនឹងទិន្នន័យ columnar វាពិបាកណាស់ក្នុងការយកឈ្នះ H2O។

បញ្ហាប្រឈមបច្ចេកទេស

Andrei៖ តើអ្វីជាបញ្ហាប្រឈមធំបំផុតរបស់អ្នកក្នុងអាជីពទាំងមូលរបស់អ្នក?

ច្រាំងថ្មចោទ៖ តើ​យើង​កំពុង​ពិភាក្សា​ផ្នែក​បច្ចេកទេស ឬ​មិន​បច្ចេកទេស​នៃ​បញ្ហា​នេះ​ទេ? ខ្ញុំ​អាច​និយាយ​ថា បញ្ហា​ប្រឈម​ធំ​បំផុត​មិន​មែន​ជា​បញ្ហា​បច្ចេកទេស​ទេ។ 
ចំពោះបញ្ហាប្រឈមបច្ចេកទេស។ ខ្ញុំគ្រាន់តែយកឈ្នះពួកគេ។ ខ្ញុំមិនដឹងថាអ្វីធំជាងគេនោះទេ ប៉ុន្តែមានរឿងគួរឱ្យចាប់អារម្មណ៍មួយចំនួនដែលចំណាយពេលបន្តិច តស៊ូផ្លូវចិត្ត។ នៅពេលដែលខ្ញុំទៅ Sun ខ្ញុំប្រាកដថាខ្ញុំនឹងបង្កើតអ្នកចងក្រងលឿន ហើយមនុស្សចាស់មួយក្រុមបាននិយាយជាការឆ្លើយតបថាខ្ញុំនឹងមិនជោគជ័យទេ។ ប៉ុន្តែខ្ញុំបានដើរតាមគន្លងនេះ សរសេរកម្មវិធីចងក្រងទៅអ្នកបែងចែកចុះឈ្មោះ ហើយវាលឿនណាស់។ វាលឿនដូច C1 ទំនើបដែរ ប៉ុន្តែអ្នកបែងចែកមានភាពយឺតយ៉ាវជាងនៅពេលនោះ ហើយតាមក្រោយ វាគឺជាបញ្ហារចនាសម្ព័ន្ធទិន្នន័យដ៏ធំមួយ។ ខ្ញុំត្រូវការវាដើម្បីសរសេរ graphical register allocator ហើយខ្ញុំមិនយល់ពីភាពលំបាករវាងការបង្ហាញពីកូដ និងល្បឿនដែលមាននៅក្នុងសម័យនោះ ហើយមានសារៈសំខាន់ខ្លាំងណាស់។ វាប្រែថារចនាសម្ព័ន្ធទិន្នន័យជាធម្មតាលើសពីទំហំឃ្លាំងសម្ងាត់នៅលើ x86s នៃពេលនោះហើយដូច្នេះប្រសិនបើដំបូងខ្ញុំសន្មត់ថាអ្នកបែងចែកការចុះឈ្មោះនឹងដំណើរការ 5-10 ភាគរយនៃពេលវេលារំខានសរុបនោះតាមពិតវាប្រែទៅជា ៥០ ភាគរយ។

យូរៗទៅ កម្មវិធីចងក្រងកាន់តែស្អាត និងមានប្រសិទ្ធភាពជាងមុន ឈប់បង្កើតកូដដ៏គួរឱ្យភ័យខ្លាចក្នុងករណីជាច្រើនទៀត ហើយដំណើរការចាប់ផ្តើមកាន់តែខ្លាំងឡើងស្រដៀងទៅនឹងអ្វីដែលកម្មវិធីចងក្រង C ផលិត។ លុះត្រាតែអ្នកសរសេររឿងមួយចំនួនដែលសូម្បីតែ C ក៏មិនបង្កើនល្បឿនដែរ។ . ប្រសិនបើអ្នកសរសេរកូដដូចជា C អ្នកនឹងទទួលបានប្រសិទ្ធភាពដូច C ក្នុងករណីជាច្រើនទៀត។ ហើយកាន់តែអ្នកទៅទៀត កាន់តែញឹកញាប់អ្នកទទួលបានលេខកូដដែលស្របគ្នានឹងកម្រិត C នោះ អ្នកបែងចែកការចុះឈ្មោះចាប់ផ្តើមមើលទៅដូចជាអ្វីដែលពេញលេញ... មិនថាលេខកូដរបស់អ្នកដំណើរការលឿន ឬយឺតនោះទេ។ ខ្ញុំបានបន្តធ្វើការលើអ្នកបែងចែកដើម្បីធ្វើឱ្យវាធ្វើការជ្រើសរើសកាន់តែប្រសើរ។ គាត់កាន់តែមានភាពយឺតយ៉ាវ និងយឺតជាងមុន ប៉ុន្តែគាត់បានផ្តល់នូវការអនុវត្តកាន់តែប្រសើរ និងប្រសើរជាងក្នុងករណីដែលគ្មាននរណាម្នាក់អាចដោះស្រាយបាន។ ខ្ញុំអាចចូលទៅក្នុងអ្នកបែងចែកការចុះឈ្មោះ កប់ការងារមួយខែនៅទីនោះ ហើយភ្លាមៗនោះលេខកូដទាំងមូលនឹងចាប់ផ្តើមដំណើរការលឿនជាងមុន 5% ។ រឿងនេះបានកើតឡើងម្តងម្កាល ហើយអ្នកបែងចែកការចុះឈ្មោះបានក្លាយជាស្នាដៃសិល្បៈ - មនុស្សគ្រប់គ្នាចូលចិត្តវា ឬស្អប់វា ហើយមនុស្សមកពីសាលាបានសួរសំណួរលើប្រធានបទ "ហេតុអ្វីបានជាអ្វីៗគ្រប់យ៉ាងធ្វើដូចនេះ" ហេតុអ្វីមិន ស្កេនបន្ទាត់ហើយអ្វីដែលជាភាពខុសគ្នា។ ចំលើយគឺនៅតែដដែល៖ អ្នកបែងចែកផ្អែកលើពណ៌ក្រាហ្វ បូកនឹងការងារដោយប្រុងប្រយ័ត្នជាមួយកូដសតិបណ្ដោះអាសន្នគឺស្មើនឹងអាវុធនៃជ័យជំនះ ដែលជាការរួមបញ្ចូលគ្នាដ៏ល្អបំផុតដែលគ្មាននរណាម្នាក់អាចកម្ចាត់បាន។ ហើយនេះគឺជារឿងមិនច្បាស់។ អ្វីផ្សេងទៀតដែលអ្នកចងក្រងធ្វើនៅទីនោះ គឺជារឿងដែលសិក្សាយ៉ាងល្អ បើទោះបីជាពួកគេត្រូវបាននាំយកទៅកម្រិតសិល្បៈក៏ដោយ។ ខ្ញុំតែងតែធ្វើអ្វីៗដែលសន្មត់ថាបង្វែរអ្នកចងក្រងទៅជាការងារសិល្បៈ។ ប៉ុន្តែគ្មានអ្វីអស្ចារ្យនោះទេ - លើកលែងតែអ្នកបែងចែកការចុះឈ្មោះ។ ល្បិចគឺត្រូវប្រយ័ត្ន កាត់​បន្ថយ នៅក្រោមការផ្ទុក ហើយប្រសិនបើវាកើតឡើង (ខ្ញុំអាចពន្យល់លម្អិតបន្ថែមទៀតប្រសិនបើចាប់អារម្មណ៍) នេះមានន័យថាអ្នកអាចដាក់ក្នុងជួរបានកាន់តែខ្លាំងក្លា ដោយគ្មានហានិភ័យនៃការធ្លាក់ចុះនៅក្នុងកាលវិភាគនៃការអនុវត្ត។ នៅសម័យនោះ មានអ្នកចងក្រងពេញមួយក្រុម ព្យួរជាមួយនឹងបាវ និងផ្លុំកញ្ចែ ដែលមានអ្នកបែងចែកបញ្ជី ប៉ុន្តែគ្មាននរណាម្នាក់អាចធ្វើវាបានទេ។

បញ្ហាគឺថាប្រសិនបើអ្នកបន្ថែមវិធីសាស្រ្តដែលជាប្រធានបទដើម្បី inlining បង្កើននិងបង្កើនតំបន់ inlining នោះសំណុំនៃតម្លៃដែលបានប្រើភ្លាមៗលើសពីចំនួននៃការចុះឈ្មោះហើយអ្នកត្រូវកាត់បន្ថយពួកគេ។ កម្រិតសំខាន់ជាធម្មតាកើតឡើងនៅពេលដែលអ្នកបែងចែកផ្តល់ឱ្យឡើង ហើយបេក្ខជនដ៏ល្អម្នាក់សម្រាប់ការធ្លាយប្រេងមានតម្លៃមួយទៀត អ្នកនឹងលក់របស់ដែលមានលក្ខណៈព្រៃផ្សៃ។ តម្លៃនៃការ inlining នៅទីនេះគឺថាអ្នកបាត់បង់ផ្នែកមួយនៃ overhead , overhead សម្រាប់ការហៅទូរស័ព្ទនិងរក្សាទុក, អ្នកអាចឃើញតម្លៃនៅខាងក្នុងនិងអាចបង្កើនប្រសិទ្ធិភាពបន្ថែមទៀតពួកគេ។ តម្លៃនៃការ inlining គឺថាចំនួនដ៏ច្រើននៃតម្លៃបន្តផ្ទាល់ត្រូវបានបង្កើតឡើងហើយប្រសិនបើអ្នកបែងចែកការចុះឈ្មោះរបស់អ្នកឆេះលើសពីការចាំបាច់នោះអ្នកនឹងបាត់បង់ភ្លាមៗ។ ហេតុដូច្នេះហើយ អ្នកបែងចែកភាគច្រើនមានបញ្ហា៖ នៅពេលដាក់ចូលកាត់ខ្សែបន្ទាត់ជាក់លាក់មួយ អ្វីៗទាំងអស់ក្នុងពិភពលោកចាប់ផ្តើមត្រូវបានកាត់បន្ថយ ហើយផលិតភាពអាចហូរចូលបង្គន់បាន។ អ្នកដែលអនុវត្តកម្មវិធីចងក្រងបន្ថែមការពន្យល់មួយចំនួន៖ ឧទាហរណ៍ ដើម្បីបញ្ឈប់ការបញ្ចូល ដោយចាប់ផ្តើមពីទំហំធំល្មមមួយចំនួន ព្រោះការបែងចែកនឹងបំផ្លាញអ្វីៗទាំងអស់។ នេះជារបៀបដែល kink នៅក្នុងក្រាហ្វការអនុវត្តត្រូវបានបង្កើតឡើង - អ្នកនៅក្នុងជួរ, នៅក្នុងបន្ទាត់, ការសម្តែងរីកចម្រើនយឺត - ហើយបន្ទាប់មករីកចំរើន! - វាធ្លាក់ចុះដូចជា jack រហ័ស ដោយសារតែអ្នកតម្រង់ជួរច្រើនពេក។ នេះជារបៀបដែលអ្វីៗដំណើរការមុនការមកដល់នៃកោះជ្វា។ Java ទាមទារ​ឱ្យ​មាន​ការ​ចូល​ច្រើន​ជាង ដូច្នេះ​ខ្ញុំ​ត្រូវ​តែ​ធ្វើ​ឱ្យ​អ្នក​បែង​ចែក​របស់​ខ្ញុំ​កាន់តែ​កាច​ខ្លាំង​ឡើង​ ដើម្បី​ឱ្យ​វា​ចេញ​ជា​ជាង​គាំង ហើយ​ប្រសិន​បើ​អ្នក​ចូល​ច្រើន​ពេក វា​នឹង​ចាប់​ផ្តើម​ធ្លាយ​ចេញ ប៉ុន្តែ​ពេល​នោះ "មិន​មាន​ការ​កំពប់​ទៀត" នៅ​តែ​មក​ដល់។ នេះជាការសង្កេតដ៏គួរឱ្យចាប់អារម្មណ៍មួយ ហើយវាទើបតែមករកខ្ញុំពីកន្លែងណា មិនមែនជាក់ស្តែងទេ ប៉ុន្តែវាបានចេញយ៉ាងល្អ។ ខ្ញុំបានយកផ្នែកខាងក្នុងដ៏ឈ្លានពាន ហើយវានាំខ្ញុំទៅកន្លែងដែលការអនុវត្ត Java និង C ដំណើរការដោយចំហៀង។ ពួកគេពិតជាស្និទ្ធស្នាលណាស់ - ខ្ញុំអាចសរសេរកូដ Java ដែលលឿនជាងកូដ C និងអ្វីៗដូចនោះ ប៉ុន្តែជាមធ្យមក្នុងរូបភាពធំនៃរឿង ពួកវាអាចប្រៀបធៀបបានប្រហែល។ ខ្ញុំ​គិត​ថា​ផ្នែក​មួយ​នៃ​គុណសម្បត្តិ​នេះ​គឺ​អ្នក​បែងចែក​ការ​ចុះ​ឈ្មោះ ដែល​អនុញ្ញាត​ឱ្យ​ខ្ញុំ​ចូល​ក្នុង​ជួរ​ដោយ​ឆោតល្ងង់​តាម​ដែល​អាច​ធ្វើ​ទៅ​បាន។ ខ្ញុំគ្រាន់តែដាក់បញ្ចូលអ្វីគ្រប់យ៉ាងដែលខ្ញុំឃើញ។ សំណួរនៅទីនេះគឺថាតើអ្នកបែងចែកដំណើរការល្អឬអត់ ថាតើលទ្ធផលគឺកូដដំណើរការដោយឆ្លាតវៃ។ នេះ​ជា​បញ្ហា​ប្រឈម​ដ៏​ធំ៖ ដើម្បី​យល់​ពី​អ្វីៗ​ទាំង​អស់​នេះ ហើយ​ធ្វើ​ឱ្យ​វា​ដំណើរការ។

បន្តិចអំពីការចុះឈ្មោះការបែងចែក និងពហុស្នូល

Владимир៖ បញ្ហាដូចជាការបែងចែកការចុះឈ្មោះហាក់ដូចជាប្រភេទនៃប្រធានបទដ៏អស់កល្ប និងមិនចេះចប់។ ខ្ញុំឆ្ងល់ថាតើធ្លាប់មានគំនិតមួយដែលហាក់ដូចជាសន្យាហើយបន្ទាប់មកបរាជ័យក្នុងការអនុវត្ត?

ច្រាំងថ្មចោទ៖ ប្រាកដណាស់! ការបែងចែកការចុះឈ្មោះគឺជាផ្នែកមួយដែលអ្នកព្យាយាមស្វែងរកធាតុមួយចំនួនដើម្បីដោះស្រាយបញ្ហា NP-complete ។ ហើយអ្នកមិនអាចសម្រេចបាននូវដំណោះស្រាយដ៏ល្អឥតខ្ចោះមួយមែនទេ? នេះគឺមិនអាចទៅរួចទេ។ មើល ការចងក្រងមុនម៉ោង - វាក៏ដំណើរការមិនល្អដែរ។ ការសន្ទនានៅទីនេះគឺអំពីករណីមធ្យមមួយចំនួន។ អំពីដំណើរការធម្មតា ដូច្នេះអ្នកអាចទៅវាស់វែងអ្វីដែលអ្នកគិតថាជាដំណើរការធម្មតាល្អ - បន្ទាប់ពីទាំងអស់ អ្នកកំពុងធ្វើការដើម្បីកែលម្អវា! ការបែងចែកការចុះឈ្មោះគឺជាប្រធានបទទាំងអស់អំពីការអនុវត្ត។ នៅពេលដែលអ្នកមានគំរូដំបូង វាដំណើរការ និងលាបអ្វីដែលត្រូវការ ការងារអនុវត្តនឹងចាប់ផ្តើម។ អ្នកត្រូវរៀនវាស់វែងឱ្យបានល្អ។ ហេតុអ្វីបានជាវាសំខាន់? ប្រសិនបើអ្នកមានទិន្នន័យច្បាស់លាស់ អ្នកអាចមើលតំបន់ផ្សេងៗ ហើយឃើញ៖ បាទ វាបានជួយនៅទីនេះ ប៉ុន្តែនោះហើយជាកន្លែងដែលអ្វីៗបានបែកបាក់! គំនិតល្អៗមួយចំនួនបានចេញមក អ្នកបានបន្ថែមការពន្យល់ថ្មី ហើយភ្លាមៗនោះអ្វីៗចាប់ផ្តើមដំណើរការល្អជាងជាមធ្យម។ ឬវាមិនចាប់ផ្តើមទេ។ ខ្ញុំមានករណីជាច្រើនដែលយើងកំពុងតស៊ូដើម្បីការអនុវត្ត XNUMX ភាគរយដែលធ្វើអោយការអភិវឌ្ឍន៍របស់យើងខុសពីអ្នកបែងចែកមុន។ ហើយរាល់ពេលដែលវាមើលទៅដូចនេះ៖ កន្លែងណាដែលអ្នកឈ្នះ កន្លែងណាមួយដែលអ្នកចាញ់។ ប្រសិនបើអ្នកមានឧបករណ៍វិភាគលទ្ធផលល្អ អ្នកអាចស្វែងរកគំនិតដែលបាត់បង់ ហើយយល់ពីមូលហេតុដែលពួកគេបរាជ័យ។ ប្រហែល​ជា​វា​មានតម្លៃ​ទុក​អ្វីៗ​គ្រប់យ៉ាង​តាម​ដែល​វា​ជា ឬ​ប្រហែល​ជា​ប្រើ​វិធីសាស្ត្រ​ដ៏​ធ្ងន់ធ្ងរ​ជាង​នេះ​ដើម្បី​ធ្វើការ​កែតម្រូវ ឬ​ចេញ​ទៅ​ជួសជុល​អ្វី​ផ្សេង។ វា​ជា​ក្រុម​នៃ​អ្វី​ទាំងអស់​! ខ្ញុំបានធ្វើការ hack ដ៏ត្រជាក់នេះ ប៉ុន្តែខ្ញុំក៏ត្រូវការមួយនេះ ហើយមួយនេះ និងមួយនេះ - និងការរួមផ្សំសរុបរបស់ពួកគេផ្តល់នូវការកែលម្អមួយចំនួន។ ហើយអ្នកឯកកោអាចបរាជ័យ។ នេះគឺជាលក្ខណៈនៃការអនុវត្តការងារលើបញ្ហា NP-ពេញលេញ។

Владимир៖ មនុស្សម្នាក់ទទួលបានអារម្មណ៍ថាអ្វីៗដូចជាការគូររូបនៅក្នុងការបែងចែកគឺជាបញ្ហាដែលត្រូវបានដោះស្រាយរួចហើយ។ ជាការប្រសើរណាស់, វាត្រូវបានសម្រេចចិត្តសម្រាប់អ្នក, វិនិច្ឆ័យដោយអ្វីដែលអ្នកកំពុងនិយាយ, ដូច្នេះវាសូម្បីតែមានតម្លៃវានៅពេលនោះ ...

ច្រាំងថ្មចោទ៖ វា​មិន​ត្រូវ​បាន​ដោះស្រាយ​បែប​នេះ​ទេ។ វាគឺជាអ្នកដែលត្រូវប្រែក្លាយវាទៅជា "ដោះស្រាយ" ។ មាន​បញ្ហា​លំបាក ហើយ​ពួកគេ​ត្រូវ​ដោះស្រាយ។ នៅពេលនេះត្រូវបានធ្វើរួច វាដល់ពេលដែលត្រូវធ្វើការលើផលិតភាព។ អ្នកត្រូវខិតទៅជិតការងារនេះតាមនោះ - ធ្វើតារាងពិន្ទុ ប្រមូលរង្វាស់ ពន្យល់ពីស្ថានភាពនៅពេលដែល នៅពេលអ្នកត្រលប់ទៅកំណែមុន ការ hack ចាស់របស់អ្នកចាប់ផ្តើមដំណើរការម្តងទៀត (ឬផ្ទុយមកវិញ ឈប់)។ ហើយកុំចុះចាញ់រហូតដល់អ្នកសម្រេចបានអ្វីមួយ។ ដូចដែលខ្ញុំបាននិយាយរួចមកហើយថាប្រសិនបើមានគំនិតល្អ ៗ ដែលមិនដំណើរការប៉ុន្តែនៅក្នុងផ្នែកនៃការបែងចែកការចុះឈ្មោះនៃគំនិតវាគឺប្រហែលគ្មានទីបញ្ចប់។ ជាឧទាហរណ៍ អ្នកអាចអានការបោះពុម្ពផ្សាយបែបវិទ្យាសាស្ត្រ។ ថ្វីត្បិតតែពេលនេះតំបន់នេះចាប់ផ្តើមផ្លាស់ទីកាន់តែយឺត និងកាន់តែច្បាស់ជាងនៅវ័យក្មេង។ ទោះយ៉ាងណាក៏ដោយ មានមនុស្សរាប់មិនអស់ដែលធ្វើការក្នុងវិស័យនេះ ហើយគំនិតទាំងអស់របស់ពួកគេគឺមានតម្លៃសាកល្បង ពួកគេទាំងអស់គ្នាកំពុងរង់ចាំនៅក្នុងស្លាប។ ហើយអ្នកមិនអាចប្រាប់ថាតើពួកគេល្អប៉ុណ្ណាទេ លុះត្រាតែអ្នកសាកល្បងវា។ តើពួកគេរួមបញ្ចូលជាមួយអ្វីផ្សេងទៀតនៅក្នុងអ្នកបែងចែករបស់អ្នកបានល្អប៉ុណ្ណា ពីព្រោះអ្នកបែងចែកធ្វើកិច្ចការជាច្រើន ហើយគំនិតមួយចំនួននឹងមិនដំណើរការនៅក្នុងអ្នកបែងចែកជាក់លាក់របស់អ្នកទេ ប៉ុន្តែនៅក្នុងអ្នកបែងចែកផ្សេងទៀតពួកគេនឹងងាយស្រួល។ មធ្យោបាយសំខាន់ដើម្បីឈ្នះសម្រាប់អ្នកបែងចែកគឺដើម្បីទាញវត្ថុយឺតនៅខាងក្រៅផ្លូវធំ ហើយបង្ខំវាឱ្យបំបែកតាមព្រំដែននៃផ្លូវយឺត។ ដូច្នេះប្រសិនបើអ្នកចង់ដំណើរការ GC ដើរលើផ្លូវយឺត ធ្វើឱ្យប្រសើរឡើងវិញ បោះករណីលើកលែងមួយ - អ្នកដឹងថារឿងទាំងនេះកម្រមានណាស់។ ហើយពួកគេពិតជាកម្រណាស់ ខ្ញុំបានពិនិត្យ។ អ្នកធ្វើកិច្ចការបន្ថែម ហើយវាដកការរឹតបន្តឹងជាច្រើនលើផ្លូវយឺតទាំងនេះ ប៉ុន្តែវាពិតជាមិនមានបញ្ហាអ្វីទេ ព្រោះពួកគេយឺត និងកម្រធ្វើដំណើរណាស់។ ឧទាហរណ៍ ទ្រនិចទទេ - វាមិនដែលកើតឡើងទេមែនទេ? អ្នកត្រូវមានផ្លូវជាច្រើនសម្រាប់រឿងផ្សេងៗគ្នា ប៉ុន្តែពួកគេមិនគួរជ្រៀតជ្រែកជាមួយផ្លូវសំខាន់នោះទេ។ 

Владимир៖ តើ​អ្នក​គិត​យ៉ាង​ណា​ចំពោះ Multi-cores នៅ​ពេល​ដែល​មាន Cores រាប់​ពាន់​ក្នុងពេលតែមួយ? តើនេះជារបស់មានប្រយោជន៍ទេ?

ច្រាំងថ្មចោទ៖ ជោគជ័យនៃ GPU បង្ហាញថាវាមានប្រយោជន៍ណាស់!

Владимир៖ ពួកគេពិតជាជំនាញណាស់។ ចុះ​ប្រព័ន្ធ​ដំណើរការ​គោលបំណង​ទូទៅ​វិញ?

ច្រាំងថ្មចោទ៖ មែនហើយ នោះគឺជាគំរូអាជីវកម្មរបស់ Azul ។ ចម្លើយ​បាន​ត្រឡប់​មក​វិញ​ក្នុង​សម័យ​កាល​ដែល​មនុស្ស​ពិត​ជា​ចូល​ចិត្ត​ការ​សម្ដែង​ដែល​អាច​ទស្សន៍ទាយ​បាន។ វាពិបាកក្នុងការសរសេរកូដប៉ារ៉ាឡែលនៅពេលនោះ។ គំរូសរសេរកូដ H2O គឺអាចធ្វើមាត្រដ្ឋានបានខ្ពស់ ប៉ុន្តែវាមិនមែនជាគំរូគោលបំណងទូទៅទេ។ ប្រហែលជាទូទៅជាងពេលប្រើ GPU បន្តិច។ តើ​យើង​កំពុង​និយាយ​អំពី​ភាព​ស្មុគស្មាញ​នៃ​ការ​អភិវឌ្ឍ​រឿង​បែប​នេះ ឬ​ភាព​ស្មុគស្មាញ​ក្នុង​ការ​ប្រើ​វា? ជាឧទាហរណ៍ Azul បានបង្រៀនខ្ញុំនូវមេរៀនដ៏គួរឱ្យចាប់អារម្មណ៍មួយ ដែលមិនច្បាស់៖ ឃ្លាំងសម្ងាត់តូចៗគឺជារឿងធម្មតា។ 

បញ្ហាប្រឈមដ៏ធំបំផុតក្នុងជីវិត

Владимир៖ ចុះយ៉ាងណាចំពោះបញ្ហាប្រឈមដែលមិនមែនជាបច្ចេកទេស?

ច្រាំងថ្មចោទ៖ បញ្ហា​ប្រឈម​ធំ​ជាង​គេ​គឺ​មិន​មែន​ជា... ចិត្តល្អ និង​ល្អ​ចំពោះ​មនុស្ស​ទេ។ ហើយជាលទ្ធផល ខ្ញុំបានរកឃើញខ្លួនឯងជានិច្ចនៅក្នុងស្ថានភាពជម្លោះយ៉ាងខ្លាំង។ អ្នកដែលខ្ញុំដឹងថាមានរឿងខុស ប៉ុន្តែមិនដឹងពីរបៀបដើម្បីឆ្ពោះទៅមុខជាមួយនឹងបញ្ហាទាំងនោះ ហើយមិនអាចដោះស្រាយវាបាន។ បញ្ហា​រយៈពេល​វែង​ជា​ច្រើន​ដែល​មាន​រយៈពេល​រាប់​ទសវត្សរ៍​បាន​កើត​ឡើង​តាម​វិធី​នេះ។ ការពិតដែលថា Java មានកម្មវិធីចងក្រង C1 និង C2 គឺជាផលវិបាកផ្ទាល់នៃរឿងនេះ។ ការពិតដែលថាមិនមានការចងក្រងពហុកម្រិតនៅក្នុង Java អស់រយៈពេល XNUMX ឆ្នាំជាប់ៗគ្នាក៏ជាលទ្ធផលផ្ទាល់ផងដែរ។ វាច្បាស់ណាស់ថាយើងត្រូវការប្រព័ន្ធបែបនេះ ប៉ុន្តែវាមិនច្បាស់ថាហេតុអ្វីបានជាវាមិនមាន។ ខ្ញុំមានបញ្ហាជាមួយវិស្វករម្នាក់... ឬក្រុមវិស្វករ។ មានពេលមួយ នៅពេលដែលខ្ញុំចាប់ផ្តើមធ្វើការនៅ Sun ខ្ញុំគឺ... មិនអីទេ មិនត្រឹមតែប៉ុណ្ណោះ ជាទូទៅខ្ញុំតែងតែមានគំនិតផ្ទាល់ខ្លួនរបស់ខ្ញុំចំពោះអ្វីៗទាំងអស់។ ហើយ​ខ្ញុំ​គិត​ថា​វា​ជា​ការ​ពិត​ដែល​អ្នក​គ្រាន់​តែ​អាច​យក​ការ​ពិត​នេះ​របស់​អ្នក​ហើយ​ប្រាប់​វា​នៅ​ខាង​មុខ​។ ជាពិសេសចាប់តាំងពីខ្ញុំភ្ញាក់ផ្អើលយ៉ាងខ្លាំង។ ហើយប្រសិនបើអ្នកមិនចូលចិត្តវិធីសាស្រ្តនេះ... ជាពិសេសប្រសិនបើអ្នកពិតជាខុស និងធ្វើរឿងមិនសមហេតុសមផល... ជាទូទៅ មានមនុស្សតិចណាស់ដែលអាចទ្រាំទ្រទម្រង់ទំនាក់ទំនងនេះ។ ទោះបីជាអ្នកខ្លះអាចដូចខ្ញុំ។ ខ្ញុំ​បាន​សាង​ពេញ​មួយ​ជីវិត​របស់​ខ្ញុំ​លើ​គោលការណ៍​គុណធម៌។ ប្រសិនបើអ្នកបង្ហាញអ្វីខុស ខ្ញុំនឹងបង្វែរភ្លាមៗ ហើយនិយាយថា៖ អ្នកនិយាយមិនសមហេតុសមផល។ ក្នុងពេលជាមួយគ្នានេះ ជាការពិត ខ្ញុំសូមអភ័យទោស និងអ្វីៗទាំងអស់នោះ ខ្ញុំនឹងកត់សម្គាល់ពីគុណប្រយោជន៍ ប្រសិនបើមាន និងចាត់វិធានការត្រឹមត្រូវផ្សេងទៀត។ ម្យ៉ាងវិញទៀត ខ្ញុំពិតជាភ្ញាក់ផ្អើលយ៉ាងខ្លាំងអំពីភាគរយដ៏គួរឱ្យភ្ញាក់ផ្អើលនៃពេលវេលាសរុប។ ហើយវាមិនដំណើរការល្អទេក្នុងទំនាក់ទំនងជាមួយមនុស្ស។ ខ្ញុំ​មិន​ព្យាយាម​ធ្វើ​ខ្លួន​ស្អាត​ទេ ប៉ុន្តែ​ខ្ញុំ​សួរ​សំណួរ​ដោយ​ត្រង់។ "នេះនឹងមិនដំណើរការទេពីព្រោះមួយ ពីរ និងបី" ហើយពួកគេដូចជា "អូ!" មាន​ផល​វិបាក​ផ្សេង​ទៀត​ដែល​ប្រហែល​ជា​ល្អ​ជាង​ក្នុង​ការ​មិន​អើពើ៖ ជា​ឧទាហរណ៍ ផល​វិបាក​ដែល​នាំ​ឲ្យ​មាន​ការ​លែងលះ​ពី​ប្រពន្ធ​ខ្ញុំ និង​ការ​ធ្លាក់​ទឹក​ចិត្ត​ដប់​ឆ្នាំ​បន្ទាប់​ពី​នោះ។

ការប្រកួតប្រជែងគឺជាការតស៊ូជាមួយមនុស្ស ដោយមានការយល់ឃើញរបស់ពួកគេអំពីអ្វីដែលអ្នកអាចធ្វើបាន ឬមិនអាចធ្វើបាន អ្វីដែលសំខាន់ និងអ្វីដែលមិនមែនជា។ មានឧបសគ្គជាច្រើនអំពីរចនាប័ទ្មសរសេរកូដ។ ខ្ញុំនៅតែសរសេរកូដច្រើន ហើយនៅសម័យនោះ ខ្ញុំថែមទាំងត្រូវបន្ថយល្បឿន ដោយសារខ្ញុំធ្វើកិច្ចការស្របគ្នាច្រើនពេក ហើយធ្វើមិនបានល្អ ជំនួសឲ្យការផ្តោតទៅលើអ្វីមួយ។ ក្រឡេកមើលទៅក្រោយខ្ញុំបានសរសេរកូដពាក់កណ្តាលសម្រាប់ពាក្យបញ្ជា Java JIT ដែលជាពាក្យបញ្ជា C2 ។ អ្នកសរសេរកូដលឿនបំផុតបន្ទាប់សរសេរពាក់កណ្តាលយឺត ពាក់កណ្តាលបន្ទាប់ទៀតយឺត ហើយវាជាការធ្លាក់ចុះនិទស្សន្ត។ មនុស្សទីប្រាំពីរនៅក្នុងជួរនេះគឺយឺតណាស់ - ដែលតែងតែកើតឡើង! ខ្ញុំបានប៉ះលេខកូដជាច្រើន។ ខ្ញុំបានក្រឡេកមើលទៅអ្នកណាសរសេរអ្វី ដោយគ្មានករណីលើកលែង ខ្ញុំបានសម្លឹងមើលកូដរបស់ពួកគេ ពិនិត្យមើលពួកគេម្នាក់ៗ ហើយនៅតែបន្តសរសេរខ្លួនឯងច្រើនជាងពួកគេទាំងអស់។ វិធីសាស្រ្តនេះមិនដំណើរការល្អជាមួយមនុស្សទេ។ មនុស្សមួយចំនួនមិនចូលចិត្តរឿងនេះទេ។ ហើយនៅពេលដែលពួកគេមិនអាចដោះស្រាយបាន ការត្អូញត្អែរគ្រប់ប្រភេទចាប់ផ្តើម។ ឧទាហរណ៍៖ ខ្ញុំធ្លាប់ត្រូវបានគេប្រាប់ឱ្យឈប់សរសេរកូដ ព្រោះខ្ញុំសរសេរកូដច្រើនពេក ហើយវាធ្វើឱ្យប៉ះពាល់ដល់ក្រុម ហើយស្តាប់ទៅដូចជាលេងសើចចំពោះខ្ញុំ៖ មិត្តអើយ ប្រសិនបើក្រុមដែលនៅសល់បាត់ ហើយខ្ញុំបន្តសរសេរកូដអ្នក នឹងចាញ់តែពាក់កណ្តាលក្រុមប៉ុណ្ណោះ។ ម្យ៉ាងវិញទៀត ប្រសិនបើខ្ញុំបន្តសរសេរកូដ ហើយអ្នកបាត់បង់ក្រុមពាក់កណ្តាល នោះស្តាប់ទៅដូចជាការគ្រប់គ្រងមិនល្អខ្លាំងណាស់។ ខ្ញុំ​មិន​ដែល​គិត​ពី​រឿង​នោះ​ទេ មិន​ដែល​និយាយ​ពី​វា​ទេ ប៉ុន្តែ​វា​នៅ​តែ​ស្ថិត​ក្នុង​ក្បាល​ខ្ញុំ។ គំនិតកំពុងវិលវល់ក្នុងចិត្តខ្ញុំ៖ "តើអ្នកទាំងអស់គ្នាលេងសើចទេ?" ដូច្នេះ បញ្ហាធំបំផុតគឺខ្ញុំ និងទំនាក់ទំនងរបស់ខ្ញុំជាមួយមនុស្ស។ ឥឡូវនេះខ្ញុំយល់ខ្លួនឯងកាន់តែច្បាស់ ខ្ញុំជាអ្នកដឹកនាំក្រុមសម្រាប់អ្នកសរសេរកម្មវិធីអស់រយៈពេលជាយូរ ហើយឥឡូវនេះខ្ញុំប្រាប់មនុស្សដោយផ្ទាល់ថា អ្នកដឹងទេ ខ្ញុំជានរណា ហើយអ្នកនឹងត្រូវដោះស្រាយជាមួយខ្ញុំ - តើវាមិនអីទេប្រសិនបើខ្ញុំឈរ នៅទីនេះ? ហើយនៅពេលដែលពួកគេចាប់ផ្តើមដោះស្រាយជាមួយវា អ្វីគ្រប់យ៉ាងបានដំណើរការ។ តាមពិតទៅ ខ្ញុំមិនមែនអាក្រក់ ឬល្អទេ ខ្ញុំមិនមានចេតនាអាក្រក់ ឬសេចក្តីប្រាថ្នាអាត្មានិយមទេ វាគ្រាន់តែជាខ្លឹមសាររបស់ខ្ញុំ ហើយខ្ញុំត្រូវតែរស់នៅជាមួយវាដោយរបៀបណា។

Andrei៖ ទើប​តែ​ថ្មីៗ​នេះ​អ្នក​រាល់​គ្នា​បាន​ចាប់​ផ្ដើម​និយាយ​អំពី​ការ​យល់​ដឹង​ខ្លួន​ឯង​សម្រាប់​អ្នក​ណែនាំ​ខ្លួន និង​ជំនាញ​ទន់​ជា​ទូទៅ។ តើអ្នកអាចនិយាយអ្វីខ្លះអំពីរឿងនេះ?

ច្រាំងថ្មចោទ៖ បាទ នោះគឺជាការយល់ដឹង និងមេរៀនដែលខ្ញុំបានរៀនពីការលែងលះរបស់ខ្ញុំពីប្រពន្ធរបស់ខ្ញុំ។ អ្វី​ដែល​ខ្ញុំ​រៀន​ពី​ការ​លែង​លះ​គឺ​ការ​យល់​ពី​ខ្លួន​ឯង។ នេះជារបៀបដែលខ្ញុំចាប់ផ្តើមយល់ពីអ្នកដទៃ។ ស្វែងយល់ពីរបៀបដែលអន្តរកម្មនេះដំណើរការ។ នេះនាំឱ្យមានការរកឃើញម្តងមួយៗ។ មានការយល់ដឹងថាខ្ញុំជានរណា និងអ្វីដែលខ្ញុំតំណាង។ តើខ្ញុំកំពុងធ្វើអ្វី៖ ទាំងខ្ញុំរវល់នឹងកិច្ចការ ឬខ្ញុំកំពុងគេចពីជម្លោះ ឬអ្វីផ្សេងទៀត - ហើយកម្រិតនៃការយល់ដឹងពីខ្លួនឯងនេះពិតជាជួយរក្សាខ្លួនខ្ញុំក្នុងការគ្រប់គ្រង។ បន្ទាប់ពីនេះអ្វីៗនឹងកាន់តែងាយស្រួល។ រឿងមួយដែលខ្ញុំបានរកឃើញមិនត្រឹមតែនៅក្នុងខ្លួនខ្ញុំប៉ុណ្ណោះទេ ប៉ុន្តែនៅក្នុងអ្នកសរសេរកម្មវិធីផ្សេងទៀតគឺអសមត្ថភាពក្នុងការនិយាយពាក្យសម្ដីនៅពេលអ្នកស្ថិតក្នុងស្ថានភាពនៃភាពតានតឹងផ្លូវចិត្ត។ ជាឧទាហរណ៍ អ្នកកំពុងអង្គុយសរសេរកូដនៅទីនោះ ស្ថិតក្នុងស្ថានភាពហូរហៀរ ហើយបន្ទាប់មកពួកគេរត់មករកអ្នក ហើយចាប់ផ្តើមស្រែកដោយកំហឹងថាមានអ្វីមួយខូច ហើយឥឡូវនេះវិធានការខ្លាំងនឹងត្រូវចាត់វិធានការប្រឆាំងនឹងអ្នក។ ហើយ​អ្នក​មិន​អាច​និយាយ​ពាក្យ​មួយ​ម៉ាត់​បាន​ទេ ព្រោះ​អ្នក​ស្ថិត​ក្នុង​ស្ថានភាព​តានតឹង​ផ្លូវ​ចិត្ត។ ចំណេះដឹងដែលទទួលបានអនុញ្ញាតឱ្យអ្នករៀបចំសម្រាប់ពេលនេះ រស់រានមានជីវិត ហើយបន្តទៅផែនការដកថយ បន្ទាប់ពីនោះអ្នកអាចធ្វើអ្វីមួយបាន។ ដូច្នេះហើយ នៅពេលដែលអ្នកចាប់ផ្តើមដឹងពីរបៀបដែលវាដំណើរការ វាគឺជាព្រឹត្តិការណ៍ផ្លាស់ប្តូរជីវិតដ៏ធំមួយ។ 
ខ្ញុំ​ខ្លួន​ឯង​មិន​អាច​រក​ឃើញ​ពាក្យ​ត្រឹម​ត្រូវ​ទេ ប៉ុន្តែ​ខ្ញុំ​នឹក​ឃើញ​លំដាប់​នៃ​សកម្មភាព។ ចំណុចនោះគឺថា ប្រតិកម្មនេះមានលក្ខណៈរាងកាយច្រើនដូចពាក្យសំដី ហើយអ្នកត្រូវការកន្លែងទំនេរ។ ចន្លោះបែបនេះនៅក្នុងន័យ Zen ។ នេះ​ជា​អ្វី​ដែល​ត្រូវ​ពន្យល់ ហើយ​បោះ​ជំហាន​ចេញ​ពី​ខាង​ក្រៅ​ភ្លាមៗ​ទៅ​ឆ្ងាយ​ពី​ផ្លូវ​កាយ​សុទ្ធសាធ។ នៅពេលដែលខ្ញុំនៅស្ងៀមដោយពាក្យសំដី ខ្ញុំអាចដំណើរការស្ថានភាពដោយអារម្មណ៍។ នៅពេលដែល adrenaline ចូលដល់ខួរក្បាលរបស់អ្នក ប្តូរអ្នកចូលទៅក្នុងរបៀបប្រយុទ្ធ ឬការហោះហើរ អ្នកមិនអាចនិយាយអ្វីបានទៀតទេ ទេ - ឥឡូវនេះអ្នកជាមនុស្សឆ្កួត ជាវិស្វករវាយតប់ គ្មានសមត្ថភាពឆ្លើយតបសមរម្យ ឬសូម្បីតែបញ្ឈប់ការវាយប្រហារ ហើយអ្នកវាយប្រហារគឺឥតគិតថ្លៃ។ វាយប្រហារម្តងហើយម្តងទៀត។ ដំបូងអ្នកត្រូវតែក្លាយជាខ្លួនអ្នកម្តងទៀត គ្រប់គ្រងឡើងវិញ ចេញពីរបៀប "ប្រយុទ្ធ ឬការហោះហើរ"។

ហើយសម្រាប់រឿងនេះ យើងត្រូវការកន្លែងនិយាយ។ គ្រាន់តែទំហំទំនេរ។ ប្រសិនបើអ្នកនិយាយអ្វីទាំងអស់ នោះអ្នកអាចនិយាយបានយ៉ាងពិតប្រាកដ ហើយបន្ទាប់មកស្វែងរក "កន្លែងទំនេរ" សម្រាប់ខ្លួនអ្នក៖ ទៅដើរលេងក្នុងឧទ្យាន ចាក់សោខ្លួនអ្នកនៅក្នុងផ្កាឈូក - វាមិនមានបញ្ហាអ្វីនោះទេ។ រឿងសំខាន់គឺត្រូវផ្តាច់ជាបណ្តោះអាសន្នពីស្ថានភាពនោះ។ ដរាបណាអ្នកបិទយ៉ាងហោចណាស់ពីរបីវិនាទី ការគ្រប់គ្រងត្រលប់មកវិញ អ្នកចាប់ផ្តើមគិតដោយសុភាព។ "មិនអីទេ ខ្ញុំមិនមែនជាមនុស្សល្ងង់ទេ ខ្ញុំមិនធ្វើរឿងឆោតល្ងង់ទេ ខ្ញុំជាមនុស្សមានប្រយោជន៍" នៅពេលដែលអ្នកអាចបញ្ចុះបញ្ចូលខ្លួនឯងបាន នោះដល់ពេលដែលត្រូវបន្តទៅដំណាក់កាលបន្ទាប់៖ ការយល់ដឹងអំពីអ្វីដែលបានកើតឡើង។ អ្នកត្រូវបានវាយប្រហារ ការវាយប្រហារមកពីកន្លែងដែលអ្នកមិននឹកស្មានដល់ វាគឺជាការវាយឆ្មក់ដ៏ទុច្ចរិត។ នេះ​ជា​រឿង​អាក្រក់។ ជំហានបន្ទាប់គឺត្រូវស្វែងយល់ថាហេតុអ្វីបានជាអ្នកវាយប្រហារត្រូវការរឿងនេះ។ ពិតជាហេតុអ្វី? ប្រហែលមកពីខ្លួនឯងខឹង? ហេតុអ្វីបានជាគាត់ខឹង? ឧទាហរណ៍ ដោយសារ​គាត់​ធ្វើ​ខ្លួន​ឯង​មិន​អាច​ទទួល​ខុស​ត្រូវ? នេះគឺជាវិធីដើម្បីដោះស្រាយដោយប្រុងប្រយ័ត្ននូវស្ថានភាពទាំងមូល។ ប៉ុន្តែ​នេះ​ទាមទារ​ឱ្យ​មាន​បន្ទប់​សម្រាប់​ការ​បង្ខិត​បង្ខំ និង​ចន្លោះ​ពាក្យសំដី។ ជំហានដំបូងគឺត្រូវផ្តាច់ទំនាក់ទំនងពាក្យសំដី។ ជៀសវាងការពិភាក្សាជាមួយពាក្យ។ បោះបង់វា ដើរចេញឱ្យលឿនតាមដែលអាចធ្វើទៅបាន។ ប្រសិនបើវាជាការសន្ទនាតាមទូរស័ព្ទគ្រាន់តែព្យួរ - នេះគឺជាជំនាញដែលខ្ញុំបានរៀនពីការទំនាក់ទំនងជាមួយអតីតប្រពន្ធរបស់ខ្ញុំ។ ប្រសិនបើការសន្ទនាមិនដំណើរការល្អទេ គ្រាន់តែនិយាយថា "លាហើយ" ហើយព្យួរ។ ពីផ្នែកម្ខាងទៀតនៃទូរស័ព្ទ៖ “ blah blah blah” អ្នកឆ្លើយថា “បាទ លាហើយ!” ហើយព្យួរ។ អ្នកគ្រាន់តែបញ្ចប់ការសន្ទនា។ ប្រាំនាទីក្រោយមក នៅពេលដែលសមត្ថភាពក្នុងការគិតប្រកបដោយសតិសម្បជញ្ញៈត្រលប់មករកអ្នកវិញ អ្នកបានត្រជាក់ចុះបន្តិច វាអាចគិតបានគ្រប់រឿង តើមានអ្វីកើតឡើង និងអ្វីដែលនឹងកើតឡើងបន្ទាប់ទៀត។ ហើយចាប់ផ្តើមបង្កើតការឆ្លើយតបប្រកបដោយការគិត ជាជាងគ្រាន់តែប្រតិកម្មចេញពីអារម្មណ៍។ សម្រាប់ខ្ញុំ របកគំហើញនៃការយល់ដឹងដោយខ្លួនឯង គឺជាការពិតដែលថាក្នុងករណីមានភាពតានតឹងផ្លូវចិត្ត ខ្ញុំមិនអាចនិយាយបាន។ ការចាកចេញពីរដ្ឋនេះ គិត និងរៀបចំផែនការរបៀបឆ្លើយតប និងទូទាត់សងសម្រាប់បញ្ហា - ទាំងនេះគឺជាជំហានដ៏ត្រឹមត្រូវក្នុងករណីដែលអ្នកមិនអាចនិយាយបាន។ មធ្យោបាយងាយស្រួលបំផុតគឺរត់ចេញពីស្ថានភាពដែលភាពតានតឹងផ្លូវចិត្តបង្ហាញខ្លួនឯង ហើយឈប់ចូលរួមក្នុងភាពតានតឹងនេះ។ បន្ទាប់​មក​អ្នក​ក្លាយ​ជា​អាច​គិត, ពេល​ដែល​អ្នក​អាច​គិត, អ្នក​ក្លាយ​​​ជា​អាច​និយាយ​បាន, ល​។

និយាយអញ្ចឹង នៅក្នុងតុលាការ មេធាវីប្រឆាំងព្យាយាមធ្វើបែបនេះចំពោះអ្នក ឥឡូវនេះវាច្បាស់ណាស់ថាហេតុអ្វី។ ដោយសារតែគាត់មានសមត្ថភាពបង្រ្កាបអ្នកឱ្យស្ថិតក្នុងស្ថានភាពបែបនេះ ដែលអ្នកមិនអាចសូម្បីតែបញ្ចេញឈ្មោះរបស់អ្នកជាឧទាហរណ៍។ ក្នុងន័យពិត អ្នកនឹងមិនអាចនិយាយបានទេ។ ប្រសិនបើរឿងនេះកើតឡើងចំពោះអ្នក ហើយប្រសិនបើអ្នកដឹងថាអ្នកនឹងឃើញខ្លួនឯងនៅក្នុងកន្លែងដែលការប្រយុទ្ធគ្នាដោយពាក្យសំដីកំពុងផ្ទុះឡើងនៅក្នុងកន្លែងដូចជាតុលាការនោះ អ្នកអាចមកជាមួយមេធាវីរបស់អ្នក។ មេធាវីនឹងក្រោកឈរឡើងសម្រាប់អ្នក ហើយបញ្ឈប់ការវាយប្រហារដោយពាក្យសំដី ហើយនឹងធ្វើវាតាមរបៀបស្របច្បាប់ទាំងស្រុង ហើយចន្លោះ Zen ដែលបាត់បង់នឹងត្រលប់មកអ្នកវិញ។ ជាឧទាហរណ៍ ខ្ញុំត្រូវទូរស័ព្ទទៅគ្រួសារខ្ញុំពីរបីដង ចៅក្រមមានភាពរួសរាយរាក់ទាក់ចំពោះរឿងនេះ ប៉ុន្តែមេធាវីប្រឆាំងបានស្រែក និងស្រែកដាក់ខ្ញុំ ខ្ញុំមិនអាចសូម្បីតែទទួលពាក្យមួយម៉ាត់។ នៅក្នុងករណីទាំងនេះ ការប្រើអ្នកសម្រុះសម្រួលមានប្រសិទ្ធភាពបំផុតសម្រាប់ខ្ញុំ។ អ្នកសម្រុះសម្រួលបញ្ឈប់សម្ពាធទាំងអស់ដែលកំពុងហូរមកលើអ្នកក្នុងចរន្តបន្តមួយ អ្នករកឃើញចន្លោះ Zen ចាំបាច់ ហើយជាមួយនឹងសមត្ថភាពក្នុងការនិយាយត្រឡប់មកវិញ។ នេះគឺជាវិស័យចំណេះដឹងទាំងមូលដែលមានច្រើនដែលត្រូវសិក្សា មានច្រើនដើម្បីស្វែងយល់ពីខ្លួនអ្នក ហើយទាំងអស់នេះប្រែទៅជាការសម្រេចចិត្តជាយុទ្ធសាស្ត្រកម្រិតខ្ពស់ដែលខុសពីមនុស្សផ្សេងគ្នា។ អ្នក​ខ្លះ​មិន​មាន​បញ្ហា​ដូច​បាន​រៀប​រាប់​ខាង​លើ​ទេ ធម្មតា​អ្នក​ដែល​ជា​អ្នក​លក់​អាជីព​មិន​មាន​ទេ។ មនុស្សទាំងអស់នេះដែលបង្កើតជីវិតដោយពាក្យសម្ដី - អ្នកចម្រៀងល្បី កវី អ្នកដឹកនាំសាសនា និងអ្នកនយោបាយ ពួកគេតែងតែមានអ្វីដែលត្រូវនិយាយ។ ពួកគេមិនមានបញ្ហាបែបនេះទេ ប៉ុន្តែខ្ញុំធ្វើ។

Andrei៖ វា​ជា​ការ​មិន​បាន​រំពឹង​ទុក​។ ល្អណាស់ ពួកយើងបាននិយាយគ្នាច្រើនហើយ ដល់ពេលបញ្ចប់ការសម្ភាសន៍នេះ។ យើងពិតជានឹងជួបគ្នានៅសន្និសីទ ហើយនឹងអាចបន្តការសន្ទនានេះ។ ជួបគ្នានៅ Hydra!

អ្នកអាចបន្តការសន្ទនារបស់អ្នកជាមួយ Cliff នៅសន្និសីទ Hydra 2019 ដែលនឹងធ្វើឡើងនៅថ្ងៃទី 11-12 ខែកក្កដា ឆ្នាំ 2019 នៅ St. Petersburg។ គាត់នឹងមកជាមួយរបាយការណ៍ "បទពិសោធន៍ប្រតិបត្តិការអង្គចងចាំផ្នែករឹង Azul". សំបុត្រអាចទិញបាន។ នៅលើគេហទំព័រផ្លូវការ.

ប្រភព: www.habr.com