Cliff Click — CTO ຂອງ Crtus (ເຊັນເຊີ IoT ສໍາລັບການປັບປຸງຂະບວນການ), ຜູ້ກໍ່ຕັ້ງແລະຜູ້ຮ່ວມກໍ່ຕັ້ງຂອງ startups ຫຼາຍຄັ້ງ (ລວມທັງໂຮງຮຽນ Rocket Realtime, Neurensic ແລະ H2O.ai) ດ້ວຍການອອກສົບຜົນສໍາເລັດຈໍານວນຫນຶ່ງ. Cliff ຂຽນ compiler ທໍາອິດຂອງລາວໃນອາຍຸ 15 ປີ (Pascal ສໍາລັບ TRS Z-80)! ລາວເປັນທີ່ຮູ້ຈັກດີທີ່ສຸດສໍາລັບການເຮັດວຽກຂອງລາວໃນ C2 ໃນ Java (ທະເລຂອງ Nodes IR). compiler ນີ້ໄດ້ສະແດງໃຫ້ໂລກຮູ້ວ່າ JIT ສາມາດຜະລິດລະຫັດທີ່ມີຄຸນນະພາບສູງ, ເຊິ່ງເປັນຫນຶ່ງໃນປັດໃຈທີ່ເກີດຂື້ນຂອງ Java ເປັນຫນຶ່ງໃນເວທີຊອບແວທີ່ທັນສະໄຫມຕົ້ນຕໍ. ຫຼັງຈາກນັ້ນ, Cliff ໄດ້ຊ່ວຍ Azul Systems ສ້າງ mainframe 864-core ດ້ວຍຊອບແວ Java ບໍລິສຸດທີ່ສະຫນັບສະຫນູນການຢຸດ GC ໃນ heap 500-gigabyte ພາຍໃນ 10 milliseconds. ໂດຍທົ່ວໄປ, 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 ທີ່ຮ້າຍແຮງກວ່າເກົ່າ, ເວັ້ນເສຍແຕ່ວ່າຈໍານວນຄົງທີ່ຂະຫນາດໃຫຍ່ພຽງພໍແຊກແຊງ. ສິ່ງ​ທີ່​ມີ​ລະ​ດັບ​ຕ​່​ໍ​າ​ເປັນ​ໄປ​ໄດ້​. ໂດຍປົກກະຕິ, ຖ້າທ່ານໄດ້ເພີ່ມປະສິດທິພາບສ່ວນທີ່ເຫຼືອຂອງ stack ຂອງທ່ານດີພຽງພໍແລະຍັງມີສິ່ງທີ່ຫນ້າສົນໃຈທີ່ເຫລືອຢູ່, ນັ້ນແມ່ນລະດັບຕໍ່າ. ແຕ່ວິທີການເລີ່ມຕົ້ນຈາກລະດັບສູງ? ເຈົ້າຮູ້ໄດ້ແນວໃດວ່າວຽກລະດັບສູງພຽງພໍແລ້ວ? ດີ ... ບໍ່ມີທາງ. ບໍ່ມີສູດທີ່ກຽມພ້ອມ. ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈບັນຫາ, ຕັດສິນໃຈວ່າເຈົ້າຈະເຮັດຫຍັງ (ເພື່ອບໍ່ເອົາຂັ້ນຕອນທີ່ບໍ່ຈໍາເປັນໃນອະນາຄົດ) ແລະຫຼັງຈາກນັ້ນທ່ານສາມາດເປີດເຜີຍ profiler, ເຊິ່ງສາມາດເວົ້າບາງສິ່ງບາງຢ່າງທີ່ເປັນປະໂຫຍດ. ໃນບາງຈຸດ, ຕົວທ່ານເອງຮູ້ວ່າທ່ານໄດ້ກໍາຈັດສິ່ງທີ່ບໍ່ຈໍາເປັນແລະມັນເຖິງເວລາທີ່ຈະເຮັດການປັບລະດັບຕ່ໍາ. ແນ່ນອນ, ນີ້ແມ່ນປະເພດສິລະປະພິເສດ. ມີຫຼາຍຄົນທີ່ເຮັດສິ່ງທີ່ບໍ່ຈໍາເປັນ, ແຕ່ການເຄື່ອນຍ້າຍໄວຫຼາຍທີ່ພວກເຂົາບໍ່ມີເວລາທີ່ຈະກັງວົນກ່ຽວກັບຜົນຜະລິດ. ແຕ່ນີ້ແມ່ນຈົນກ່ວາຄໍາຖາມທີ່ເກີດຂຶ້ນ bluntly. ປົກກະຕິແລ້ວ 99% ຂອງເວລາທີ່ບໍ່ມີໃຜສົນໃຈສິ່ງທີ່ຂ້ອຍເຮັດ, ຈົນກ່ວາເວລາທີ່ສິ່ງທີ່ສໍາຄັນເຂົ້າມາໃນເສັ້ນທາງທີ່ສໍາຄັນທີ່ບໍ່ມີໃຜສົນໃຈ. ແລະຢູ່ທີ່ນີ້, ທຸກຄົນເລີ່ມຂີ້ຕົວະເຈົ້າກ່ຽວກັບ "ເປັນຫຍັງມັນບໍ່ເຮັດວຽກຢ່າງສົມບູນຕັ້ງແຕ່ເລີ່ມຕົ້ນ." ໂດຍທົ່ວໄປ, ມີສະເຫມີບາງສິ່ງບາງຢ່າງທີ່ຈະປັບປຸງໃນການປະຕິບັດ. ແຕ່ 99% ຂອງເວລາທີ່ທ່ານບໍ່ມີຜູ້ນໍາ! ທ່ານພຽງແຕ່ພະຍາຍາມເຮັດໃຫ້ບາງສິ່ງບາງຢ່າງເຮັດວຽກແລະໃນຂະບວນການທີ່ທ່ານຄິດອອກສິ່ງທີ່ສໍາຄັນ. ເຈົ້າບໍ່ສາມາດຮູ້ລ່ວງໜ້າໄດ້ວ່າສິ້ນນີ້ຕ້ອງສົມບູນແບບ, ສະນັ້ນ, ໃນຄວາມເປັນຈິງ, ເຈົ້າຕ້ອງສົມບູນແບບໃນທຸກຢ່າງ. ແຕ່ນີ້ເປັນໄປບໍ່ໄດ້ ແລະເຈົ້າບໍ່ເຮັດມັນ. ມີຫຼາຍສິ່ງທີ່ຕ້ອງແກ້ໄຂສະເໝີ - ແລະນັ້ນເປັນເລື່ອງປົກກະຕິໝົດ.

ວິທີການເຮັດ refactoring ໃຫຍ່

Andrei: ເຈົ້າເຮັດວຽກກ່ຽວກັບການປະຕິບັດແນວໃດ? ນີ້​ແມ່ນ​ບັນ​ຫາ​ການ​ຕັດ​ຕໍ່​. ຕົວຢ່າງ, ເຈົ້າເຄີຍເຮັດວຽກກ່ຽວກັບບັນຫາທີ່ເກີດຂື້ນຈາກຈຸດຕັດກັນຂອງຫຼາຍຫນ້າທີ່ເຮັດວຽກທີ່ມີຢູ່ບໍ?

ຜາ: ຂ້ອຍພະຍາຍາມຫຼີກເວັ້ນມັນ. ຖ້າຂ້ອຍຮູ້ວ່າການປະຕິບັດຈະເປັນບັນຫາ, ຂ້ອຍຄິດກ່ຽວກັບມັນກ່ອນທີ່ຂ້ອຍຈະເລີ່ມຕົ້ນການຂຽນລະຫັດ, ໂດຍສະເພາະກັບໂຄງສ້າງຂໍ້ມູນ. ແຕ່ເລື້ອຍໆເຈົ້າຄົ້ນພົບສິ່ງທັງໝົດນີ້ໃນພາຍຫຼັງ. ແລະຫຼັງຈາກນັ້ນທ່ານຕ້ອງໄປຫາມາດຕະການທີ່ຮ້າຍກາດແລະເຮັດໃນສິ່ງທີ່ຂ້ອຍເອີ້ນວ່າ "ຂຽນຄືນໃຫມ່ແລະເອົາຊະນະ": ທ່ານຈໍາເປັນຕ້ອງຄວ້າເອົາຊິ້ນສ່ວນຂະຫນາດໃຫຍ່ພຽງພໍ. ບາງລະຫັດຍັງຈະຕ້ອງຖືກຂຽນຄືນໃຫມ່ເນື່ອງຈາກບັນຫາການປະຕິບັດຫຼືບາງສິ່ງບາງຢ່າງອື່ນ. ບໍ່ວ່າເຫດຜົນສໍາລັບການຂຽນລະຫັດຄືນໃຫມ່, ມັນເກືອບສະເຫມີດີກວ່າທີ່ຈະຂຽນຄືນສິ້ນຂະຫນາດໃຫຍ່ກວ່າຊິ້ນສ່ວນຂະຫນາດນ້ອຍກວ່າ. ໃນເວລານີ້, ທຸກຄົນເລີ່ມສັ່ນສະເທືອນດ້ວຍຄວາມຢ້ານກົວ: "ໂອ້ພະເຈົ້າ, ເຈົ້າບໍ່ສາມາດແຕະຕ້ອງລະຫັດຫຼາຍ!" ແຕ່​ໃນ​ຄວາມ​ເປັນ​ຈິງ, ວິ​ທີ​ການ​ນີ້​ເກືອບ​ສະ​ເຫມີ​ໄປ​ເຮັດ​ວຽກ​ດີກ​ວ່າ​ຫຼາຍ. ທ່ານຈໍາເປັນຕ້ອງໄດ້ແກ້ໄຂບັນຫາໃຫຍ່ທັນທີ, ແຕ້ມຮູບວົງມົນໃຫຍ່ປະມານມັນແລະເວົ້າວ່າ: ຂ້ອຍຈະຂຽນຄືນໃຫມ່ທຸກຢ່າງພາຍໃນວົງມົນ. ຊາຍແດນແມ່ນນ້ອຍກວ່າເນື້ອໃນພາຍໃນມັນທີ່ຕ້ອງການປ່ຽນແທນ. ແລະຖ້າຫາກວ່າການກໍານົດຂອບເຂດຊາຍແດນດັ່ງກ່າວອະນຸຍາດໃຫ້ທ່ານເຮັດວຽກພາຍໃນຢ່າງສົມບູນ, ມືຂອງທ່ານມີອິດສະຫຼະ, ເຮັດສິ່ງທີ່ທ່ານຕ້ອງການ. ເມື່ອທ່ານເຂົ້າໃຈບັນຫາ, ຂະບວນການຂຽນຄືນໃຫມ່ແມ່ນງ່າຍຂຶ້ນຫຼາຍ, ສະນັ້ນໃຊ້ເວລາຫຼາຍ!
ໃນເວລາດຽວກັນ, ເມື່ອທ່ານຂຽນຄືນໃຫມ່ຂະຫນາດໃຫຍ່ແລະຮູ້ວ່າການປະຕິບັດຈະມີບັນຫາ, ທ່ານສາມາດເລີ່ມຕົ້ນກັງວົນກ່ຽວກັບມັນທັນທີ. ນີ້ມັກຈະກາຍເປັນສິ່ງທີ່ງ່າຍດາຍເຊັ່ນ "ຢ່າຄັດລອກຂໍ້ມູນ, ຈັດການຂໍ້ມູນງ່າຍໆເທົ່າທີ່ເປັນໄປໄດ້, ເຮັດໃຫ້ມັນນ້ອຍ." ໃນການຂຽນຄືນໃຫມ່ຂະຫນາດໃຫຍ່, ມີວິທີການມາດຕະຖານເພື່ອປັບປຸງການປະຕິບັດ. ແລະພວກເຂົາເຈົ້າເກືອບສະເຫມີ revolve ກ່ຽວກັບຂໍ້ມູນ.

ຮູບແບບຄ່າໃຊ້ຈ່າຍ

Andrei: ໃນຫນຶ່ງຂອງ podcasts ທ່ານໄດ້ເວົ້າກ່ຽວກັບແບບຈໍາລອງຄ່າໃຊ້ຈ່າຍໃນສະພາບການຂອງຜົນຜະລິດ. ເຈົ້າສາມາດອະທິບາຍສິ່ງທີ່ເຈົ້າຫມາຍເຖິງນີ້ບໍ?

ຜາ: ແນ່ນອນ. ຂ້ອຍເກີດມາໃນຍຸກທີ່ປະສິດທິພາບຂອງໂປເຊດເຊີມີຄວາມສໍາຄັນທີ່ສຸດ. ແລະຍຸກນີ້ກັບຄືນມາອີກເທື່ອຫນຶ່ງ - ຊະຕາກໍາບໍ່ແມ່ນໂດຍບໍ່ມີການ irony. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ດໍາ​ລົງ​ຊີ​ວິດ​ໃນ​ສະ​ໄຫມ​ຂອງ​ເຄື່ອງ​ແປດ​ບິດ​, ຄອມ​ພິວ​ເຕີ​ທໍາ​ອິດ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ເຮັດ​ວຽກ​ກັບ 256 bytes​. ແທ້ bytes. ທຸກສິ່ງທຸກຢ່າງແມ່ນນ້ອຍຫຼາຍ. ຄໍາ​ແນະ​ນໍາ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ນັບ​, ແລະ​ດັ່ງ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ການ​ເຄື່ອນ​ຍ້າຍ​ເຖິງ stack ພາ​ສາ​ໂຄງ​ການ​, ພາ​ສາ​ໄດ້​ມີ​ຫຼາຍ​ຂຶ້ນ​. ມີ Assembler, ຫຼັງຈາກນັ້ນພື້ນຖານ, ຫຼັງຈາກນັ້ນ C, ແລະ C ໄດ້ດູແລລາຍລະອຽດຫຼາຍຢ່າງເຊັ່ນ: ການຈັດສັນການລົງທະບຽນແລະການເລືອກຄໍາແນະນໍາ. ແຕ່ທຸກສິ່ງທຸກຢ່າງແມ່ນຂ້ອນຂ້າງຊັດເຈນຢູ່ທີ່ນັ້ນ, ແລະຖ້າຂ້ອຍເຮັດຕົວຊີ້ໄປຫາຕົວຢ່າງຂອງຕົວແປ, ຂ້ອຍຈະໄດ້ຮັບການໂຫຼດ, ແລະຄ່າໃຊ້ຈ່າຍຂອງຄໍາແນະນໍານີ້ແມ່ນເປັນທີ່ຮູ້ຈັກ. ຮາດແວຜະລິດຈໍານວນທີ່ແນ່ນອນຂອງຮອບວຽນເຄື່ອງຈັກ, ດັ່ງນັ້ນຄວາມໄວການປະຕິບັດຂອງສິ່ງທີ່ແຕກຕ່າງກັນສາມາດຖືກຄິດໄລ່ງ່າຍໆໂດຍການເພີ່ມຄໍາແນະນໍາທັງຫມົດທີ່ທ່ານຈະດໍາເນີນການ. ແຕ່ລະປຽບທຽບ / ທົດສອບ / ສາຂາ / ໂທ / ໂຫຼດ / ຮ້ານສາມາດຖືກເພີ່ມແລະເວົ້າວ່າ: ນັ້ນແມ່ນເວລາປະຕິບັດສໍາລັບທ່ານ. ໃນເວລາທີ່ເຮັດວຽກກ່ຽວກັບການປັບປຸງການປະຕິບັດ, ທ່ານແນ່ນອນຈະເອົາໃຈໃສ່ກັບຕົວເລກທີ່ກົງກັບວົງຈອນຮ້ອນຂະຫນາດນ້ອຍ. 
ແຕ່ທັນທີທີ່ທ່ານປ່ຽນໄປໃຊ້ Java, Python ແລະສິ່ງທີ່ຄ້າຍຄືກັນ, ທ່ານຈະຍ້າຍອອກໄປຈາກຮາດແວລະດັບຕ່ໍາຢ່າງໄວວາ. ຄ່າໃຊ້ຈ່າຍໃນການໂທຫາ getter ໃນ Java ແມ່ນຫຍັງ? ຖ້າ JIT ໃນ HotSpot ແມ່ນຖືກຕ້ອງ ໃນແຖວ, ມັນຈະໂຫລດ, ແຕ່ຖ້າມັນບໍ່ໄດ້ເຮັດ, ມັນຈະເປັນການໂທຟັງຊັນ. ເນື່ອງຈາກການໂທຢູ່ໃນວົງຈອນຮ້ອນ, ມັນຈະ override ການເພີ່ມປະສິດທິພາບອື່ນໆທັງຫມົດໃນ loop ນັ້ນ. ດັ່ງນັ້ນ, ຄ່າໃຊ້ຈ່າຍທີ່ແທ້ຈິງຈະສູງຂຶ້ນຫຼາຍ. ແລະທ່ານທັນທີສູນເສຍຄວາມສາມາດໃນການເບິ່ງຊິ້ນສ່ວນຂອງລະຫັດແລະເຂົ້າໃຈວ່າພວກເຮົາຄວນປະຕິບັດມັນໃນແງ່ຂອງຄວາມໄວໂມງຂອງໂປເຊດເຊີ, ຫນ່ວຍຄວາມຈໍາແລະແຄດທີ່ໃຊ້. ທັງຫມົດນີ້ຈະກາຍເປັນທີ່ຫນ້າສົນໃຈພຽງແຕ່ຖ້າຫາກວ່າທ່ານກໍ່ເຂົ້າໄປໃນການປະຕິບັດ.
ໃນປັດຈຸບັນພວກເຮົາພົບເຫັນຕົວເຮົາເອງຢູ່ໃນສະຖານະການທີ່ຄວາມໄວຂອງໂປເຊດເຊີໄດ້ເພີ່ມຂຶ້ນເກືອບເປັນທົດສະວັດ. ວັນເກົ່າກັບມາ! ທ່ານບໍ່ສາມາດນັບໄດ້ກັບການປະຕິບັດກະທູ້ດຽວທີ່ດີໄດ້ອີກຕໍ່ໄປ. ແຕ່ຖ້າທ່ານເຂົ້າໄປໃນຄອມພິວເຕີ້ຂະຫນານຢ່າງກະທັນຫັນ, ມັນຍາກຢ່າງບໍ່ຫນ້າເຊື່ອ, ທຸກຄົນເບິ່ງເຈົ້າຄືກັບ James Bond. ການເລັ່ງສິບເທົ່າຢູ່ທີ່ນີ້ມັກຈະເກີດຂຶ້ນໃນສະຖານທີ່ທີ່ໃຜຜູ້ຫນຶ່ງໄດ້ messed ຂຶ້ນ. Concurrency ຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກຫຼາຍ. ເພື່ອໃຫ້ໄດ້ຄວາມໄວ XNUMX ເທົ່າ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈຮູບແບບຄ່າໃຊ້ຈ່າຍ. ແມ່ນຫຍັງ ແລະລາຄາເທົ່າໃດ? ແລະເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າລີ້ນເຫມາະກັບຮາດແວພື້ນຖານແນວໃດ.
Martin Thompson ເລືອກຄໍາທີ່ດີສໍາລັບ blog ລາວ ຄວາມເຫັນອົກເຫັນໃຈກົນຈັກ! ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈສິ່ງທີ່ຮາດແວຈະເຮັດ, ມັນຈະເຮັດແນວໃດແທ້, ແລະເປັນຫຍັງມັນເຮັດສິ່ງທີ່ມັນເຮັດໃນຕອນທໍາອິດ. ການ​ນໍາ​ໃຊ້​ນີ້​, ມັນ​ເປັນ​ທໍາ​ງ່າຍ​ດາຍ​ທີ່​ຈະ​ເລີ່ມ​ຕົ້ນ​ການ​ນັບ​ຄໍາ​ແນະ​ນໍາ​ແລະ​ການ​ຄິດ​ໄລ່​ອອກ​ທີ່​ເວ​ລາ​ປະ​ຕິ​ບັດ​ແມ່ນ​ໄປ​. ຖ້າທ່ານບໍ່ມີການຝຶກອົບຮົມທີ່ເຫມາະສົມ, ທ່ານພຽງແຕ່ຊອກຫາແມວສີດໍາຢູ່ໃນຫ້ອງຊ້ໍາ. ຂ້າ​ພະ​ເຈົ້າ​ເຫັນ​ປະ​ຊາ​ຊົນ optimizing ການ​ປະ​ຕິ​ບັດ​ຕະ​ຫຼອດ​ເວ​ລາ​ທີ່​ບໍ່​ມີ​ຄວາມ​ຄິດ​ວ່າ​ສິ່ງ​ທີ່​ເຂົາ​ເຈົ້າ​ກໍາ​ລັງ​ເຮັດ​ແນວ​ໃດ. ເຂົາເຈົ້າທົນທຸກທໍລະມານຫຼາຍ ແລະບໍ່ມີຄວາມຄືບໜ້າຫຼາຍ. ແລະໃນເວລາທີ່ຂ້າພະເຈົ້າເອົາລະຫັດດຽວກັນ, ເລື່ອນເຂົ້າໄປໃນສອງສາມ hacks ຂະຫນາດນ້ອຍແລະໄດ້ຮັບການເລັ່ງຫ້າຫຼືສິບເທົ່າ, ພວກເຂົາຄື: ດີ, ມັນບໍ່ຍຸດຕິທໍາ, ພວກເຮົາຮູ້ວ່າເຈົ້າດີກວ່າ. ອັດສະຈັນ. ຂ້ອຍເວົ້າກ່ຽວກັບຫຍັງ ... ຮູບແບບຄ່າໃຊ້ຈ່າຍແມ່ນກ່ຽວກັບປະເພດຂອງລະຫັດທີ່ທ່ານຂຽນແລະຄວາມໄວທີ່ມັນແລ່ນໂດຍສະເລ່ຍໃນຮູບໃຫຍ່.

Andrei: ແລະເຈົ້າຈະຮັກສາປະລິມານດັ່ງກ່າວໄວ້ໃນຫົວຂອງເຈົ້າໄດ້ແນວໃດ? ນີ້ແມ່ນບັນລຸໄດ້ໂດຍປະສົບການເພີ່ມເຕີມ, ຫຼື? ປະສົບການດັ່ງກ່າວມາຈາກໃສ?

ຜາ: ດີ, ຂ້ອຍບໍ່ໄດ້ຮັບປະສົບການຂອງຂ້ອຍໃນວິທີທີ່ງ່າຍທີ່ສຸດ. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ຕັ້ງ​ໂຄງ​ການ​ຢູ່​ໃນ​ສະ​ພາ​ແຫ່ງ​ຊາດ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ທີ່​ທ່ານ​ສາ​ມາດ​ເຂົ້າ​ໃຈ​ທຸກ​ຄໍາ​ແນະ​ນໍາ. ມັນຟັງຄືໂງ່, ແຕ່ຕັ້ງແຕ່ນັ້ນມາຊຸດຄໍາແນະນໍາ Z80 ຍັງຄົງຢູ່ໃນຫົວຂອງຂ້ອຍ, ໃນຄວາມຊົງຈໍາຂອງຂ້ອຍ. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ຈື່​ຊື່​ຂອງ​ຜູ້​ຄົນ​ພາຍ​ໃນ​ນາ​ທີ​ຂອງ​ການ​ເວົ້າ​, ແຕ່​ຂ້າ​ພະ​ເຈົ້າ​ຈື່​ລະ​ຫັດ​ທີ່​ຂຽນ​ເມື່ອ 40 ປີ​ກ່ອນ​. ມັນຕະຫລົກ, ມັນເບິ່ງຄືວ່າເປັນໂຣກ "ນັກວິທະຍາສາດ idiot".

ການຝຶກອົບຮົມການເພີ່ມປະສິດທິພາບລະດັບຕ່ໍາ

Andrei: ມີວິທີທີ່ງ່າຍກວ່າທີ່ຈະເຂົ້າໄປໃນບໍ?

ຜາ: ແມ່ນ​ແລະ​ບໍ່​ແມ່ນ. ຮາດແວທີ່ພວກເຮົາທຸກຄົນໃຊ້ບໍ່ໄດ້ມີການປ່ຽນແປງທັງຫມົດໃນໄລຍະເວລາ. ທຸກຄົນໃຊ້ x86, ຍົກເວັ້ນໂທລະສັບສະຫຼາດ Arm. ຖ້າທ່ານບໍ່ໄດ້ເຮັດບາງປະເພດຂອງການຝັງ hardcore, ທ່ານກໍາລັງເຮັດສິ່ງດຽວກັນ. ຕົກລົງ, ຕໍ່ໄປ. ຄໍາ​ແນະ​ນໍາ​ຍັງ​ບໍ່​ໄດ້​ມີ​ການ​ປ່ຽນ​ແປງ​ສໍາ​ລັບ​ສັດ​ຕະ​ວັດ​ແລ້ວ​. ທ່ານຈໍາເປັນຕ້ອງໄປຂຽນບາງສິ່ງບາງຢ່າງໃນສະພາ. ບໍ່ຫຼາຍປານໃດ, ແຕ່ພຽງພໍທີ່ຈະເລີ່ມຕົ້ນທີ່ຈະເຂົ້າໃຈ. ເຈົ້າຍິ້ມ, ແຕ່ຂ້ອຍເວົ້າຢ່າງຈິງຈັງ. ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈການຕິດຕໍ່ລະຫວ່າງພາສາແລະຮາດແວ. ຫຼັງ​ຈາກ​ນັ້ນ​ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄປ​ແລະ​ຂຽນ​ເລັກ​ນ້ອຍ​ແລະ​ເຮັດ​ໃຫ້​ເປັນ​ການ​ສັງ​ລວມ​ຂອງ​ຫຼິ້ນ​ເລັກ​ນ້ອຍ​ສໍາ​ລັບ​ພາ​ສາ toy ພຽງ​ເລັກ​ນ້ອຍ​. ຄ້າຍຄືຂອງຫຼິ້ນຫມາຍຄວາມວ່າມັນຈໍາເປັນຕ້ອງໄດ້ເຮັດໃນຈໍານວນທີ່ເຫມາະສົມຂອງເວລາ. ມັນ​ສາ​ມາດ​ແມ່ນ​ງ່າຍ​ດາຍ super​, ແຕ່​ວ່າ​ມັນ​ຈະ​ຕ້ອງ​ສ້າງ​ຄໍາ​ແນະ​ນໍາ​. ການກະທໍາຂອງການສ້າງຄໍາແນະນໍາຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈຮູບແບບຄ່າໃຊ້ຈ່າຍສໍາລັບຂົວລະຫວ່າງລະຫັດລະດັບສູງທີ່ທຸກຄົນຂຽນແລະລະຫັດເຄື່ອງຈັກທີ່ເຮັດວຽກຢູ່ໃນຮາດແວ. ຈົດໝາຍນີ້ຈະຖືກເຜົາໄໝ້ໃນສະໝອງໃນເວລາທີ່ຜູ້ສັງລວມຂຽນ. ເຖິງແມ່ນວ່າ compiler ງ່າຍດາຍທີ່ສຸດ. ຫຼັງຈາກນັ້ນ, ທ່ານສາມາດເລີ່ມຕົ້ນເບິ່ງ Java ແລະຄວາມຈິງທີ່ວ່າ chasm semantic ຂອງມັນເລິກຫຼາຍ, ແລະມັນກໍ່ມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະສ້າງຂົວຂ້າມມັນ. ໃນ Java, ມັນເປັນການຍາກຫຼາຍທີ່ຈະເຂົ້າໃຈວ່າຂົວຂອງພວກເຮົາຫັນອອກດີຫຼືບໍ່ດີ, ສິ່ງທີ່ເຮັດໃຫ້ມັນແຕກຫັກແລະສິ່ງທີ່ຈະບໍ່. ແຕ່ທ່ານຕ້ອງການຈຸດເລີ່ມຕົ້ນບາງຢ່າງທີ່ທ່ານເບິ່ງລະຫັດແລະເຂົ້າໃຈ: "ແມ່ນແລ້ວ, ຜູ້ຮັບນີ້ຄວນຈະຖືກໃສ່ໃນທຸກໆຄັ້ງ." ແລະຫຼັງຈາກນັ້ນມັນປະກົດວ່າບາງຄັ້ງນີ້ເກີດຂຶ້ນ, ຍົກເວັ້ນສະຖານະການໃນເວລາທີ່ວິທີການກາຍເປັນຂະຫນາດໃຫຍ່ເກີນໄປ, ແລະ JIT ເລີ່ມຕົ້ນ inlining ທຸກສິ່ງທຸກຢ່າງ. ການປະຕິບັດຂອງສະຖານທີ່ດັ່ງກ່າວສາມາດຄາດຄະເນໄດ້ທັນທີ. ປົກກະຕິແລ້ວ getters ເຮັດວຽກໄດ້ດີ, ແຕ່ຫຼັງຈາກນັ້ນທ່ານເບິ່ງຢູ່ໃນ loops ຮ້ອນຂະຫນາດໃຫຍ່ແລະຮັບຮູ້ວ່າມີບາງ function calls ລອຍຢູ່ອ້ອມຂ້າງນັ້ນບໍ່ຮູ້ວ່າສິ່ງທີ່ເຂົາເຈົ້າກໍາລັງເຮັດ. ນີ້ແມ່ນບັນຫາທີ່ມີການນໍາໃຊ້ຢ່າງແຜ່ຫຼາຍຂອງ getters, ເຫດຜົນວ່າເປັນຫຍັງພວກມັນບໍ່ຢູ່ໃນເສັ້ນແມ່ນວ່າມັນບໍ່ຊັດເຈນວ່າພວກເຂົາເປັນ getter. ຖ້າທ່ານມີພື້ນຖານລະຫັດຂະຫນາດນ້ອຍທີ່ສຸດ, ທ່ານພຽງແຕ່ສາມາດຈື່ມັນແລະຫຼັງຈາກນັ້ນເວົ້າວ່າ: ນີ້ແມ່ນ getter, ແລະນີ້ແມ່ນຕົວກໍານົດ. ໃນພື້ນຖານລະຫັດຂະຫນາດໃຫຍ່, ແຕ່ລະຫນ້າທີ່ມີຊີວິດຢູ່ໃນປະຫວັດສາດຂອງຕົນເອງ, ເຊິ່ງໂດຍທົ່ວໄປແລ້ວ, ບໍ່ມີໃຜຮູ້ຈັກ. profiler ເວົ້າວ່າພວກເຮົາສູນເສຍ 24% ຂອງເວລາໃນບາງ loop ແລະເພື່ອເຂົ້າໃຈວ່າ loop ນີ້ເຮັດຫຍັງ, ພວກເຮົາຈໍາເປັນຕ້ອງເບິ່ງແຕ່ລະຫນ້າທີ່ພາຍໃນ. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຂົ້າໃຈນີ້ໂດຍບໍ່ມີການສຶກສາຫນ້າທີ່, ແລະນີ້ຢ່າງຈິງຈັງຊ້າລົງຂະບວນການຄວາມເຂົ້າໃຈ. ນັ້ນແມ່ນເຫດຜົນທີ່ຂ້ອຍບໍ່ໃຊ້ getters ແລະ setters, ຂ້ອຍໄດ້ບັນລຸລະດັບໃຫມ່!
ບ່ອນໃດທີ່ຈະໄດ້ຮັບຮູບແບບຄ່າໃຊ້ຈ່າຍ? ດີ, ທ່ານສາມາດອ່ານບາງສິ່ງບາງຢ່າງ, ແນ່ນອນ ... ແຕ່ຂ້ອຍຄິດວ່າວິທີທີ່ດີທີ່ສຸດແມ່ນການປະຕິບັດ. ການສ້າງ compiler ຂະຫນາດນ້ອຍຈະເປັນວິທີທີ່ດີທີ່ສຸດທີ່ຈະເຂົ້າໃຈຮູບແບບຄ່າໃຊ້ຈ່າຍແລະເຫມາະກັບຫົວຂອງທ່ານເອງ. ເຄື່ອງລວບລວມຂໍ້ມູນຂະຫນາດນ້ອຍທີ່ເຫມາະສົມສໍາລັບການຂຽນໂປລແກລມ microwave ເປັນວຽກສໍາລັບຜູ້ເລີ່ມຕົ້ນ. ດີ, ຂ້ອຍຫມາຍຄວາມວ່າ, ຖ້າທ່ານມີທັກສະການຂຽນໂປຼແກຼມແລ້ວ, ມັນຄວນຈະພຽງພໍ. ສິ່ງທັງຫມົດເຫຼົ່ານີ້ເຊັ່ນ: ການແຍກສະຕຣິງທີ່ທ່ານມີເປັນບາງປະເພດຂອງການສະແດງອອກກ່ຽວກັບພຶດຊະຄະນິດ, ສະກັດຄໍາແນະນໍາສໍາລັບການປະຕິບັດງານທາງຄະນິດສາດຈາກບ່ອນນັ້ນຕາມລໍາດັບທີ່ຖືກຕ້ອງ, ເອົາຄ່າທີ່ຖືກຕ້ອງຈາກການລົງທະບຽນ - ທັງຫມົດນີ້ແມ່ນເຮັດໃນເວລາດຽວກັນ. ແລະໃນຂະນະທີ່ທ່ານເຮັດມັນ, ມັນຈະຖືກພິມຢູ່ໃນສະຫມອງຂອງທ່ານ. ຂ້າພະເຈົ້າຄິດວ່າທຸກຄົນຮູ້ວ່າ compiler ເຮັດຫຍັງ. ແລະນີ້ຈະໃຫ້ຄວາມເຂົ້າໃຈກ່ຽວກັບຮູບແບບຄ່າໃຊ້ຈ່າຍ.

ຕົວຢ່າງການປະຕິບັດຂອງການປັບປຸງການປະຕິບັດ

Andrei: ມີຫຍັງອີກແດ່ທີ່ທ່ານຄວນເອົາໃຈໃສ່ໃນເວລາທີ່ເຮັດວຽກກ່ຽວກັບຜົນຜະລິດ?

ຜາ: ໂຄງສ້າງຂໍ້ມູນ. ໂດຍວິທີທາງການ, ແມ່ນແລ້ວ, ຂ້ອຍບໍ່ໄດ້ສອນຫ້ອງຮຽນເຫຼົ່ານີ້ເປັນເວລາດົນນານ ... ໂຮງຮຽນບັ້ງໄຟ. ມັນ​ເປັນ​ການ​ມ່ວນ​ຊື່ນ​, ແຕ່​ມັນ​ຕ້ອງ​ການ​ຫຼາຍ​ຂອງ​ຄວາມ​ພະ​ຍາ​ຍາມ​, ແລະ​ຂ້າ​ພະ​ເຈົ້າ​ມີ​ຊີ​ວິດ​! ຕົກ​ລົງ. ດັ່ງນັ້ນ, ໃນຫ້ອງຮຽນໃຫຍ່ແລະຫນ້າສົນໃຈຫນຶ່ງ, "ການປະຕິບັດຂອງເຈົ້າໄປໃສ," ຂ້າພະເຈົ້າໄດ້ຍົກຕົວຢ່າງໃຫ້ນັກຮຽນ: ສອງແລະເຄິ່ງຫນຶ່ງ gigabytes ຂອງຂໍ້ມູນ fintech ຖືກອ່ານຈາກໄຟລ໌ CSV ແລະຫຼັງຈາກນັ້ນພວກເຂົາຕ້ອງຄິດໄລ່ຈໍານວນຜະລິດຕະພັນທີ່ຂາຍ. . ຂໍ້ມູນຕະຫຼາດຫມາຍຕິກປົກກະຕິ. ແພັກເກັດ UDP ຖືກປ່ຽນເປັນຮູບແບບຂໍ້ຄວາມຕັ້ງແຕ່ປີ 70s. Chicago Mercantile Exchange - ທຸກປະເພດຂອງສິ່ງຕ່າງໆເຊັ່ນມັນເບີ, ສາລີ, ຖົ່ວເຫຼືອງ, ສິ່ງຕ່າງໆເຊັ່ນນັ້ນ. ມັນຈໍາເປັນຕ້ອງນັບຜະລິດຕະພັນເຫຼົ່ານີ້, ຈໍານວນການເຮັດທຸລະກໍາ, ປະລິມານສະເລ່ຍຂອງການເຄື່ອນໄຫວຂອງກອງທຶນແລະສິນຄ້າ, ແລະອື່ນໆ. ມັນ​ເປັນ​ທາງ​ເລກ​ຄະ​ນິດ​ສາດ​ການ​ຄ້າ​ທີ່​ງ່າຍ​ດາຍ​: ຊອກ​ຫາ​ລະ​ຫັດ​ຜະ​ລິດ​ຕະ​ພັນ (ນັ້ນ​ແມ່ນ 1-2 ຕົວ​ອັກ​ສອນ​ໃນ​ຕາ​ຕະ​ລາງ hash​)​, ໄດ້​ຮັບ​ຈໍາ​ນວນ​ເງິນ​, ເພີ່ມ​ມັນ​ກັບ​ຫນຶ່ງ​ໃນ​ຊຸດ​ການ​ຄ້າ​, ເພີ່ມ​ປະ​ລິ​ມານ​, ເພີ່ມ​ມູນ​ຄ່າ​, ແລະ​ສອງ​ສິ່ງ​ອື່ນໆ​. ຄະນິດສາດງ່າຍດາຍຫຼາຍ. ການປະຕິບັດຂອງຫຼິ້ນແມ່ນກົງໄປກົງມາຫຼາຍ: ທຸກສິ່ງທຸກຢ່າງແມ່ນຢູ່ໃນໄຟລ໌, ຂ້ອຍອ່ານໄຟລ໌ແລະຍ້າຍຜ່ານມັນ, ແບ່ງບັນທຶກສ່ວນບຸກຄົນເຂົ້າໄປໃນສາຍ Java, ຊອກຫາສິ່ງທີ່ຈໍາເປັນໃນພວກມັນແລະເພີ່ມມັນຕາມຄະນິດສາດທີ່ອະທິບາຍຂ້າງເທິງ. ແລະມັນເຮັດວຽກຢູ່ໃນຄວາມໄວຕ່ໍາບາງ.

ດ້ວຍວິທີການນີ້, ມັນຈະແຈ້ງວ່າມີຫຍັງເກີດຂຶ້ນ, ແລະຄອມພິວເຕີ້ຂະຫນານຈະບໍ່ຊ່ວຍໄດ້, ແມ່ນບໍ? ມັນ turns ໃຫ້ ເຫັນ ວ່າ ການ ເພີ່ມ ຂຶ້ນ ຫ້າ ໃນ ການ ປະ ຕິ ບັດ ສາ ມາດ ບັນ ລຸ ໄດ້ ພຽງ ແຕ່ ໂດຍ ການ ເລືອກ ໂຄງ ສ້າງ ຂໍ້ ມູນ ທີ່ ຖືກ ຕ້ອງ. ແລະຄວາມແປກໃຈນີ້ເຖິງແມ່ນນັກຂຽນໂປລແກລມທີ່ມີປະສົບການ! ໃນກໍລະນີພິເສດຂອງຂ້ອຍ, ເຄັດລັບແມ່ນວ່າເຈົ້າບໍ່ຄວນເຮັດໃຫ້ການຈັດສັນຄວາມຊົງຈໍາໃນວົງຮ້ອນ. ດີ, ນີ້ບໍ່ແມ່ນຄວາມຈິງທັງຫມົດ, ແຕ່ໂດຍທົ່ວໄປ - ທ່ານບໍ່ຄວນເນັ້ນໃສ່ "ຫນຶ່ງຄັ້ງໃນ X" ເມື່ອ X ມີຂະຫນາດໃຫຍ່ພຽງພໍ. ເມື່ອ X ແມ່ນສອງແລະເຄິ່ງຫນຶ່ງ gigabytes, ທ່ານບໍ່ຄວນຈັດສັນສິ່ງໃດ "ຫນຶ່ງຄັ້ງຕໍ່ຈົດຫມາຍ", ຫຼື "ຫນຶ່ງຄັ້ງຕໍ່ແຖວ", ຫຼື "ຫນຶ່ງຄັ້ງຕໍ່ພາກສະຫນາມ", ຫຍັງເຊັ່ນນັ້ນ. ນີ້ແມ່ນບ່ອນທີ່ໃຊ້ເວລາ. ມັນເຮັດວຽກແນວໃດ? ຈິນຕະນາການຂ້ອຍໂທຫາ String.split() ຫຼື BufferedReader.readLine(). Readline ເຮັດໃຫ້ສະຕຣິງຈາກຊຸດຂອງ bytes ທີ່ເຂົ້າມາໃນເຄືອຂ່າຍ, ຫນຶ່ງຄັ້ງສໍາລັບແຕ່ລະເສັ້ນ, ສໍາລັບແຕ່ລະຮ້ອຍລ້ານສາຍ. ຂ້ອຍເອົາເສັ້ນນີ້, ແຍກມັນແລະຖິ້ມມັນໄປ. ເປັນຫຍັງຂ້ອຍຖິ້ມມັນໄປ - ດີ, ຂ້ອຍໄດ້ປຸງແຕ່ງມັນແລ້ວ, ນັ້ນແມ່ນທັງຫມົດ. ດັ່ງນັ້ນ, ສໍາລັບແຕ່ລະ byte ອ່ານຈາກ 2.7G ເຫຼົ່ານີ້, ສອງຕົວອັກສອນຈະຖືກຂຽນຢູ່ໃນເສັ້ນ, ນັ້ນແມ່ນ, ແລ້ວ 5.4G, ແລະຂ້ອຍບໍ່ຕ້ອງການພວກມັນສໍາລັບສິ່ງໃດກໍ່ຕາມ, ດັ່ງນັ້ນພວກມັນຖືກຖິ້ມອອກໄປ. ຖ້າທ່ານເບິ່ງແບນວິດຂອງຫນ່ວຍຄວາມຈໍາ, ພວກເຮົາໂຫລດ 2.7G ທີ່ຜ່ານຫນ່ວຍຄວາມຈໍາແລະລົດເມຫນ່ວຍຄວາມຈໍາໃນໂປເຊດເຊີ, ແລະຫຼັງຈາກນັ້ນສອງເທົ່າຖືກສົ່ງໄປຫາສາຍທີ່ນອນຢູ່ໃນຫນ່ວຍຄວາມຈໍາ, ແລະທັງຫມົດນີ້ແມ່ນ frayed ເມື່ອແຕ່ລະສາຍໃຫມ່ຖືກສ້າງຂຶ້ນ. ແຕ່ຂ້ອຍຈໍາເປັນຕ້ອງໄດ້ອ່ານມັນ, ຮາດແວຈະອ່ານມັນ, ເຖິງແມ່ນວ່າທຸກສິ່ງທຸກຢ່າງຈະ frayed ຕໍ່ມາ. ແລະຂ້ອຍຕ້ອງຂຽນມັນລົງເພາະວ່າຂ້ອຍສ້າງເສັ້ນແລະ cache ເຕັມ - cache ບໍ່ສາມາດຮອງຮັບ 2.7G. ດັ່ງນັ້ນ, ສໍາລັບທຸກໆ byte ທີ່ຂ້ອຍອ່ານ, ຂ້ອຍອ່ານສອງ bytes ແລະຂຽນອີກສອງ bytes, ແລະໃນທີ່ສຸດພວກເຂົາມີອັດຕາສ່ວນ 4: 1 - ໃນອັດຕາສ່ວນນີ້ພວກເຮົາກໍາລັງສູນເສຍແບນວິດຂອງຫນ່ວຍຄວາມຈໍາ. ແລະຫຼັງຈາກນັ້ນມັນ turns ໃຫ້ເຫັນວ່າຖ້າຂ້ອຍເຮັດ String.split() – ນີ້​ບໍ່​ແມ່ນ​ຄັ້ງ​ສຸດ​ທ້າຍ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ເຮັດ​ແນວ​ນີ້, ອາດ​ຈະ​ມີ​ອີກ 6-7 ທົ່ງ​ນາ​ພາຍ​ໃນ. ດັ່ງນັ້ນລະຫັດຄລາສສິກຂອງການອ່ານ CSV ແລະຫຼັງຈາກນັ້ນ parsing ສະຕິງເສຍປະມານ 14: 1 ຂອງແບນວິດຫນ່ວຍຄວາມຈໍາທີ່ເຈົ້າຕ້ອງການ. ຖ້າທ່ານຖິ້ມການເລືອກເຫຼົ່ານີ້, ທ່ານສາມາດໄດ້ຮັບຄວາມໄວຫ້າເທົ່າ.

ແລະມັນບໍ່ຍາກປານໃດ. ຖ້າທ່ານເບິ່ງລະຫັດຈາກມຸມຂວາ, ມັນທັງຫມົດຈະກາຍເປັນງ່າຍດາຍເມື່ອທ່ານຮັບຮູ້ບັນຫາ. ທ່ານບໍ່ຄວນຢຸດການຈັດສັນຄວາມຊົງຈໍາທັງຫມົດ: ບັນຫາດຽວແມ່ນວ່າທ່ານຈັດສັນບາງສິ່ງບາງຢ່າງແລະມັນຕາຍທັນທີ, ແລະຕາມວິທີທີ່ມັນເຜົາໄຫມ້ຊັບພະຍາກອນທີ່ສໍາຄັນ, ເຊິ່ງໃນກໍລະນີນີ້ແມ່ນແບນວິດຫນ່ວຍຄວາມຈໍາ. ແລະທັງຫມົດນີ້ເຮັດໃຫ້ຜົນຜະລິດຫຼຸດລົງ. ໃນ x86 ປົກກະຕິແລ້ວທ່ານຕ້ອງການເຜົາໄຫມ້ວົງຈອນຂອງໂປເຊດເຊີຢ່າງຫ້າວຫັນ, ແຕ່ໃນທີ່ນີ້ທ່ານໄດ້ເຜົາໄຫມ້ຫນ່ວຍຄວາມຈໍາທັງຫມົດກ່ອນຫນ້ານີ້. ການແກ້ໄຂແມ່ນເພື່ອຫຼຸດຜ່ອນປະລິມານການໄຫຼອອກ. 
ອີກບັນຫາຫນຶ່ງຂອງບັນຫາແມ່ນວ່າຖ້າທ່ານແລ່ນ profiler ເມື່ອແຖບຫນ່ວຍຄວາມຈໍາຫມົດ, ເມື່ອມັນເກີດຂຶ້ນ, ປົກກະຕິແລ້ວທ່ານລໍຖ້າ cache ກັບຄືນມາເພາະວ່າມັນເຕັມໄປດ້ວຍຂີ້ເຫຍື້ອທີ່ເຈົ້າຫາກໍ່ຜະລິດ, ເສັ້ນເຫຼົ່ານັ້ນທັງຫມົດ. ດັ່ງນັ້ນ, ທຸກໆການໂຫຼດຫຼືການດໍາເນີນງານຂອງຮ້ານຈະກາຍເປັນຊ້າ, ເພາະວ່າພວກມັນນໍາໄປສູ່ການສູນຫາຍໄປຂອງ cache - cache ທັງຫມົດໄດ້ກາຍເປັນຊ້າ, ລໍຖ້າຂີ້ເຫຍື້ອອອກຈາກມັນ. ດັ່ງນັ້ນ, profiler ພຽງແຕ່ຈະສະແດງໃຫ້ເຫັນສຽງສຸ່ມທີ່ອົບອຸ່ນ smeared ໃນທົ່ວ loop ທັງຫມົດ - ຈະບໍ່ມີຄໍາແນະນໍາຮ້ອນແຍກຕ່າງຫາກຫຼືສະຖານທີ່ໃນລະຫັດ. ພຽງແຕ່ສິ່ງລົບກວນ. ແລະຖ້າທ່ານເບິ່ງຮອບວຽນ GC, ພວກເຂົາທັງຫມົດແມ່ນ Young Generation ແລະໄວທີ່ສຸດ - microseconds ຫຼື milliseconds ສູງສຸດ. ຫຼັງຈາກທີ່ທັງຫມົດ, ຄວາມຊົງຈໍາທັງຫມົດນີ້ຕາຍທັນທີ. ເຈົ້າຈັດສັນຫຼາຍຕື້ກິກາໄບ, ແລະລາວຕັດມັນ, ແລະຕັດມັນ, ແລະຕັດມັນອີກເທື່ອຫນຶ່ງ. ທັງຫມົດນີ້ເກີດຂຶ້ນຢ່າງໄວວາ. ມັນ turns ໃຫ້ເຫັນວ່າມີວົງຈອນ GC ລາຄາຖືກ, ສິ່ງລົບກວນອົບອຸ່ນຕາມວົງຈອນທັງຫມົດ, ແຕ່ພວກເຮົາຕ້ອງການທີ່ຈະໄດ້ຮັບການ 5x speedup. ໃນເວລານີ້, ບາງສິ່ງບາງຢ່າງຄວນປິດຢູ່ໃນຫົວຂອງເຈົ້າແລະສຽງ: "ເປັນຫຍັງນີ້?!" ການລົ້ນແຖບຄວາມຈໍາບໍ່ສະແດງຢູ່ໃນເຄື່ອງດີບັກຄລາດສິກ, ທ່ານຈໍາເປັນຕ້ອງແລ່ນຕົວຕ້ານການດີບັກປະສິດທິພາບຂອງຮາດແວແລະເບິ່ງມັນດ້ວຍຕົວທ່ານເອງແລະໂດຍກົງ. ແຕ່ນີ້ບໍ່ສາມາດຖືກສົງໃສໂດຍກົງຈາກສາມອາການເຫຼົ່ານີ້. ອາການທີ່ສາມແມ່ນເມື່ອທ່ານເບິ່ງສິ່ງທີ່ທ່ານເນັ້ນໃສ່, ຖາມຜູ້ສ້າງໂປຣໄຟລ໌, ແລະລາວຕອບວ່າ: "ເຈົ້າສ້າງແຖວເປັນຕື້, ແຕ່ GC ເຮັດວຽກໄດ້ຟຣີ." ທັນທີທີ່ເຫດການນີ້ເກີດຂຶ້ນ, ທ່ານຮັບຮູ້ວ່າທ່ານໄດ້ສ້າງວັດຖຸຫຼາຍເກີນໄປແລະໄຟໄຫມ້ເສັ້ນຄວາມຊົງຈໍາທັງຫມົດ. ມີວິທີທີ່ຈະຄິດແນວນີ້, ແຕ່ມັນບໍ່ຊັດເຈນ. 

ບັນຫາແມ່ນຢູ່ໃນໂຄງສ້າງຂໍ້ມູນ: ໂຄງສ້າງເປົ່າທີ່ຕິດພັນກັບທຸກສິ່ງທຸກຢ່າງທີ່ເກີດຂື້ນ, ມັນມີຂະຫນາດໃຫຍ່ເກີນໄປ, ມັນແມ່ນ 2.7G ໃນແຜ່ນ, ດັ່ງນັ້ນການເຮັດສໍາເນົາຂອງສິ່ງນີ້ແມ່ນບໍ່ຕ້ອງການຫຼາຍ - ທ່ານຕ້ອງການໂຫລດມັນຈາກເຄືອຂ່າຍ byte buffer. ທັນ​ທີ​ເຂົ້າ​ໄປ​ໃນ​ການ​ຈົດ​ທະ​ບຽນ​, ດັ່ງ​ນັ້ນ​ເປັນ​ທີ່​ຈະ​ບໍ່​ໄດ້​ອ່ານ​ຂຽນ​ກັບ​ເສັ້ນ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ຫ້າ​ຄັ້ງ​. ແຕ່ຫນ້າເສຍດາຍ, Java ບໍ່ໄດ້ໃຫ້ທ່ານຫ້ອງສະຫມຸດດັ່ງກ່າວເປັນສ່ວນຫນຶ່ງຂອງ JDK ໂດຍຄ່າເລີ່ມຕົ້ນ. ແຕ່ນີ້ແມ່ນເລື່ອງເລັກໆນ້ອຍໆ, ແມ່ນບໍ? ໂດຍພື້ນຖານແລ້ວ, ເຫຼົ່ານີ້ແມ່ນ 5-10 ເສັ້ນຂອງລະຫັດທີ່ຈະໃຊ້ເພື່ອປະຕິບັດຕົວໂຫລດ string buffered ຂອງທ່ານເອງ, ເຊິ່ງເຮັດຊ້ໍາພຶດຕິກໍາຂອງຊັ້ນ string, ໃນຂະນະທີ່ເປັນ wrapper ປະມານ byte buffer ພື້ນຖານ. ດັ່ງນັ້ນ, ມັນປາກົດວ່າທ່ານກໍາລັງເຮັດວຽກເກືອບຄືກັບສາຍ, ແຕ່ໃນຄວາມເປັນຈິງ pointers ກັບ buffer ກໍາລັງເຄື່ອນຍ້າຍໄປທີ່ນັ້ນ, ແລະ bytes ດິບບໍ່ໄດ້ຖືກຄັດລອກຢູ່ບ່ອນໃດກໍ່ຕາມ, ແລະດັ່ງນັ້ນ buffers ດຽວກັນຖືກນໍາມາໃຊ້ຄືນໃຫມ່ເລື້ອຍໆ, ແລະ. ລະບົບປະຕິບັດການມີຄວາມຍິນດີທີ່ຈະຮັບເອົາສິ່ງທີ່ມັນຖືກອອກແບບມາສໍາລັບຕົວທ່ານເອງ, ເຊັ່ນ: buffering double-buffering ຂອງ byte buffers ເຫຼົ່ານີ້, ແລະທ່ານບໍ່ໄດ້ grinding ຜ່ານນ້ໍາທີ່ບໍ່ມີທີ່ສິ້ນສຸດຂອງຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນ. ໂດຍວິທີທາງການ, ທ່ານເຂົ້າໃຈບໍວ່າເມື່ອເຮັດວຽກກັບ GC, ມັນຮັບປະກັນວ່າການຈັດສັນຫນ່ວຍຄວາມຈໍາແຕ່ລະຄົນຈະບໍ່ເຫັນໄດ້ໂດຍໂປເຊດເຊີຫຼັງຈາກຮອບວຽນ GC ສຸດທ້າຍ? ດັ່ງນັ້ນ, ທັງຫມົດນີ້ອາດຈະບໍ່ຢູ່ໃນ cache, ແລະຫຼັງຈາກນັ້ນການຮັບປະກັນ 100% ພາດເກີດຂຶ້ນ. ເມື່ອເຮັດວຽກກັບຕົວຊີ້, ໃນ x86, ການລົບການລົງທະບຽນຈາກຫນ່ວຍຄວາມຈໍາໃຊ້ເວລາ 1-2 ຮອບວຽນໂມງ, ແລະທັນທີທີ່ເຫດການນີ້ເກີດຂຶ້ນ, ທ່ານຈ່າຍ, ຈ່າຍ, ຈ່າຍ, ເພາະວ່າຫນ່ວຍຄວາມຈໍາແມ່ນທັງຫມົດ. ເກົ້າແຄສ - ແລະນີ້ແມ່ນຄ່າໃຊ້ຈ່າຍຂອງການຈັດສັນຄວາມຊົງຈໍາ. ມູນຄ່າທີ່ແທ້ຈິງ.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ໂຄງສ້າງຂໍ້ມູນແມ່ນສິ່ງທີ່ຍາກທີ່ສຸດໃນການປ່ຽນແປງ. ແລະເມື່ອທ່ານຮູ້ວ່າທ່ານໄດ້ເລືອກໂຄງສ້າງຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງທີ່ຈະຂ້າປະສິດທິພາບໃນພາຍຫລັງ, ປົກກະຕິແລ້ວມີວຽກຫຼາຍຢ່າງທີ່ຕ້ອງເຮັດ, ແຕ່ຖ້າທ່ານບໍ່ເຮັດ, ສິ່ງຕ່າງໆກໍ່ຈະຮ້າຍແຮງຂຶ້ນ. ກ່ອນອື່ນ ໝົດ, ທ່ານ ຈຳ ເປັນຕ້ອງຄິດກ່ຽວກັບໂຄງສ້າງຂໍ້ມູນ, ນີ້ແມ່ນສິ່ງ ສຳ ຄັນ. ຄ່າໃຊ້ຈ່າຍຕົ້ນຕໍຢູ່ທີ່ນີ້ແມ່ນຕົກຢູ່ໃນໂຄງສ້າງຂໍ້ມູນໄຂມັນ, ເຊິ່ງເລີ່ມຖືກນໍາໃຊ້ໃນແບບຂອງ "ຂ້ອຍໄດ້ຄັດລອກໂຄງສ້າງຂໍ້ມູນ X ເຂົ້າໄປໃນໂຄງສ້າງຂໍ້ມູນ Y ເພາະວ່າຂ້ອຍມັກຮູບຮ່າງຂອງ Y ດີກວ່າ." ແຕ່ການປະຕິບັດການຄັດລອກ (ທີ່ເບິ່ງຄືວ່າລາຄາຖືກ) ຕົວຈິງແລ້ວເສຍແບນວິດຫນ່ວຍຄວາມຈໍາແລະນັ້ນແມ່ນບ່ອນທີ່ເວລາປະຕິບັດການເສຍເງິນທັງຫມົດຖືກຝັງໄວ້. ຖ້າຂ້ອຍມີສາຍ JSON ຍັກໃຫຍ່ແລະຂ້ອຍຕ້ອງການປ່ຽນມັນໃຫ້ເປັນ DOM ໂຄງສ້າງຂອງ POJOs ຫຼືບາງສິ່ງບາງຢ່າງ, ການປະຕິບັດການແຍກສາຍນັ້ນແລະສ້າງ POJO, ແລະຫຼັງຈາກນັ້ນເຂົ້າເຖິງ POJO ອີກເທື່ອຫນຶ່ງຕໍ່ມາ, ຈະເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍທີ່ບໍ່ຈໍາເປັນ - ມັນເປັນ. ບໍ່ຖືກ. ຍົກເວັ້ນຖ້າທ່ານແລ່ນອ້ອມ POJOs ເລື້ອຍໆຫຼາຍກ່ວາທ່ານແລ່ນຮອບສາຍ. Offhand, ແທນທີ່ຈະພະຍາຍາມຖອດລະຫັດສະຕຣິງແລະສະກັດເອົາແຕ່ສິ່ງທີ່ທ່ານຕ້ອງການຈາກບ່ອນນັ້ນ, ໂດຍບໍ່ມີການປ່ຽນເປັນ POJO ໃດໆ. ຖ້າສິ່ງທັງຫມົດນີ້ເກີດຂື້ນໃນເສັ້ນທາງທີ່ການປະຕິບັດສູງສຸດແມ່ນຕ້ອງການ, ບໍ່ມີ POJOs ສໍາລັບທ່ານ, ທ່ານຈໍາເປັນຕ້ອງຂຸດເຂົ້າໄປໃນເສັ້ນໂດຍກົງ.

ເປັນຫຍັງຈຶ່ງສ້າງພາສາການຂຽນໂປຼແກຼມຂອງທ່ານເອງ

Andrei: ເຈົ້າບອກວ່າເພື່ອເຂົ້າໃຈຮູບແບບຄ່າໃຊ້ຈ່າຍ, ເຈົ້າຕ້ອງຂຽນພາສານ້ອຍໆຂອງເຈົ້າເອງ...

ຜາ: ບໍ່ແມ່ນພາສາ, ແຕ່ເປັນ compiler. ພາສາແລະ compiler ເປັນສອງສິ່ງທີ່ແຕກຕ່າງກັນ. ຄວາມແຕກຕ່າງທີ່ສໍາຄັນທີ່ສຸດແມ່ນຢູ່ໃນຫົວຂອງທ່ານ. 

Andrei: ໂດຍວິທີທາງການ, ເທົ່າທີ່ຂ້າພະເຈົ້າຮູ້, ທ່ານກໍາລັງທົດລອງສ້າງພາສາຂອງຕົນເອງ. ເພື່ອ​ຫຍັງ?

ຜາ: ເພາະ​ວ່າ​ຂ້ອຍ​ສາ​ມາດ! ຂ້າ​ພະ​ເຈົ້າ​ແມ່ນ​ເຄິ່ງ​ກິນ​ບໍາ​ນານ​, ສະ​ນັ້ນ​ນີ້​ແມ່ນ hobby ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​. ຂ້ອຍໄດ້ປະຕິບັດພາສາຂອງຄົນອື່ນຕະຫຼອດຊີວິດຂອງຂ້ອຍ. ຂ້ອຍຍັງໄດ້ເຮັດວຽກຫຼາຍກ່ຽວກັບຮູບແບບການເຂົ້າລະຫັດຂອງຂ້ອຍ. ແລະຍ້ອນວ່າຂ້ອຍເຫັນບັນຫາໃນພາສາອື່ນ. ຂ້ອຍເຫັນວ່າມີວິທີທີ່ດີກວ່າທີ່ຈະເຮັດສິ່ງທີ່ຄຸ້ນເຄີຍ. ແລະຂ້ອຍຈະໃຊ້ພວກມັນ. ຂ້ອຍພຽງແຕ່ເບື່ອທີ່ຈະເຫັນບັນຫາໃນຕົວຂ້ອຍເອງ, ໃນ Java, ໃນ Python, ໃນພາສາອື່ນ. ຕອນນີ້ຂ້ອຍຂຽນໃນ React Native, JavaScript ແລະ Elm ເປັນວຽກອະດິເລກທີ່ບໍ່ກ່ຽວກັບການບໍານານ, ແຕ່ກ່ຽວກັບການເຮັດວຽກທີ່ມີການເຄື່ອນໄຫວ. ຂ້ອຍຍັງຂຽນໃນ Python ແລະ, ສ່ວນຫຼາຍອາດຈະ, ຈະສືບຕໍ່ເຮັດວຽກກ່ຽວກັບການຮຽນຮູ້ເຄື່ອງຈັກສໍາລັບ Java backends. ມີຫຼາຍພາສາທີ່ນິຍົມແລະພວກເຂົາທັງຫມົດມີລັກສະນະທີ່ຫນ້າສົນໃຈ. ບຸກຄົນທຸກຄົນແມ່ນດີໃນວິທີການຂອງຕົນເອງແລະທ່ານສາມາດພະຍາຍາມນໍາເອົາລັກສະນະເຫຼົ່ານີ້ທັງຫມົດຮ່ວມກັນ. ດັ່ງນັ້ນ, ຂ້ອຍກໍາລັງສຶກສາສິ່ງທີ່ຂ້ອຍສົນໃຈ, ພຶດຕິກໍາຂອງພາສາ, ພະຍາຍາມຫາຄວາມຫມາຍທີ່ສົມເຫດສົມຜົນ. ແລະມາເຖິງຕອນນັ້ນຂ້ອຍປະສົບຜົນສໍາເລັດ! ໃນເວລານີ້ຂ້ອຍກໍາລັງຕໍ່ສູ້ກັບຄວາມຊົງຈໍາ, ເພາະວ່າຂ້ອຍຕ້ອງການໃຫ້ມັນຄືກັບ C ແລະ Java, ແລະໄດ້ຮັບຮູບແບບຄວາມຊົງຈໍາທີ່ເຂັ້ມແຂງແລະ semantics ຫນ່ວຍຄວາມຈໍາສໍາລັບການໂຫຼດແລະຮ້ານຄ້າ. ໃນເວລາດຽວກັນ, ມີ inference ປະເພດອັດຕະໂນມັດເຊັ່ນໃນ Haskell. ນີ້, ຂ້ອຍພະຍາຍາມປະສົມການ inference ປະເພດ Haskell ກັບການເຮັດວຽກຂອງຫນ່ວຍຄວາມຈໍາໃນທັງ C ແລະ Java. ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍໄດ້ເຮັດສໍາລັບ 2-3 ເດືອນທີ່ຜ່ານມາ, ຕົວຢ່າງ.

Andrei: ຖ້າທ່ານສ້າງພາສາທີ່ເອົາລັກສະນະທີ່ດີກວ່າຈາກພາສາອື່ນ, ທ່ານຄິດວ່າຜູ້ໃດຜູ້ຫນຶ່ງຈະເຮັດກົງກັນຂ້າມ: ເອົາຄວາມຄິດຂອງເຈົ້າແລະນໍາໃຊ້ມັນບໍ?

ຜາ: ອັນນີ້ຄືພາສາໃໝ່ປະກົດຂຶ້ນ! ເປັນຫຍັງ Java ຈຶ່ງຄ້າຍຄືກັນກັບ C? ເນື່ອງຈາກວ່າ C ມີ syntax ທີ່ດີທີ່ທຸກຄົນເຂົ້າໃຈແລະ Java ໄດ້ຮັບການດົນໃຈຈາກ syntax ນີ້, ເພີ່ມຄວາມປອດໄພຂອງປະເພດ, ການກວດສອບຂອບເຂດຂອງ array, GC, ແລະພວກເຂົາຍັງປັບປຸງບາງຢ່າງຈາກ C. ພວກເຂົາເພີ່ມຂອງຕົນເອງ. ແຕ່ພວກເຂົາໄດ້ຮັບການດົນໃຈຫຼາຍ, ແມ່ນບໍ? ທຸກໆຄົນຢືນຢູ່ເທິງບ່າຂອງຍັກໃຫຍ່ທີ່ເຂົ້າມາກ່ອນທ່ານ - ນັ້ນແມ່ນຄວາມກ້າວຫນ້າ.

Andrei: ດັ່ງທີ່ຂ້ອຍເຂົ້າໃຈມັນ, ພາສາຂອງເຈົ້າຈະປອດໄພ. ທ່ານໄດ້ຄິດກ່ຽວກັບການປະຕິບັດບາງສິ່ງບາງຢ່າງເຊັ່ນ: ການກູ້ຢືມເງິນ checker ຈາກ Rust? ເຈົ້າເບິ່ງລາວແລ້ວ ເຈົ້າຄິດແນວໃດກັບລາວ?

ຜາ: ດີ, ຂ້າພະເຈົ້າໄດ້ຂຽນ C ສໍາລັບອາຍຸ, ມີ malloc ທັງຫມົດນີ້ແລະບໍ່ເສຍຄ່າ, ແລະຄູ່ມືການຄຸ້ມຄອງຕະຫຼອດຊີວິດ. ເຈົ້າຮູ້, 90-95% ຂອງເວລາຊີວິດທີ່ຄວບຄຸມດ້ວຍຕົນເອງມີໂຄງສ້າງດຽວກັນ. ແລະມັນເຈັບປວດຫຼາຍທີ່ຈະເຮັດມັນດ້ວຍຕົນເອງ. ຂ້າພະເຈົ້າຢາກໃຫ້ຜູ້ລວບລວມຂໍ້ມູນພຽງແຕ່ບອກເຈົ້າວ່າມີຫຍັງເກີດຂຶ້ນຢູ່ທີ່ນັ້ນແລະສິ່ງທີ່ທ່ານບັນລຸໄດ້ດ້ວຍການກະທໍາຂອງເຈົ້າ. ສໍາລັບບາງສິ່ງທີ່, ຢືມ checker ເຮັດນີ້ອອກຈາກປ່ອງ. ແລະມັນຄວນຈະສະແດງຂໍ້ມູນອັດຕະໂນມັດ, ເຂົ້າໃຈທຸກຢ່າງ, ແລະບໍ່ແມ່ນແຕ່ພາລະຂ້ອຍໃນການນໍາສະເຫນີຄວາມເຂົ້າໃຈນີ້. ມັນຕ້ອງເຮັດຢ່າງຫນ້ອຍການວິເຄາະການຫລົບຫນີໃນທ້ອງຖິ່ນ, ແລະພຽງແຕ່ຖ້າມັນລົ້ມເຫລວ, ຫຼັງຈາກນັ້ນ, ມັນຈໍາເປັນຕ້ອງເພີ່ມຄໍາບັນຍາຍປະເພດທີ່ຈະອະທິບາຍຕະຫຼອດຊີວິດ - ແລະໂຄງການດັ່ງກ່າວແມ່ນມີຄວາມຊັບຊ້ອນຫຼາຍກ່ວາ checker ກູ້ຢືມ, ຫຼືແທ້ຈິງແລ້ວເຄື່ອງກວດຄວາມຈໍາທີ່ມີຢູ່. ທາງເລືອກລະຫວ່າງ "ທຸກສິ່ງທຸກຢ່າງແມ່ນດີ" ແລະ "ຂ້ອຍບໍ່ເຂົ້າໃຈຫຍັງ" - ບໍ່, ຕ້ອງມີບາງສິ່ງບາງຢ່າງທີ່ດີກວ່າ. 
ດັ່ງນັ້ນ, ໃນຖານະເປັນຜູ້ທີ່ຂຽນລະຫັດຫຼາຍໃນ C, ຂ້າພະເຈົ້າຄິດວ່າການມີການສະຫນັບສະຫນູນການຄວບຄຸມຕະຫຼອດຊີວິດແບບອັດຕະໂນມັດແມ່ນສິ່ງທີ່ສໍາຄັນທີ່ສຸດ. ຂ້ອຍຍັງເບື່ອກັບ Java ໃຊ້ຄວາມຊົງຈໍາຫຼາຍປານໃດແລະການຮ້ອງທຸກຕົ້ນຕໍແມ່ນ GC. ເມື່ອທ່ານຈັດສັນຫນ່ວຍຄວາມຈໍາໃນ Java, ທ່ານຈະບໍ່ໄດ້ຮັບຫນ່ວຍຄວາມຈໍາທີ່ຢູ່ໃນທ້ອງຖິ່ນໃນຮອບສຸດທ້າຍຂອງ GC. ນີ້ບໍ່ແມ່ນກໍລະນີໃນພາສາທີ່ມີການຈັດການຄວາມຊົງຈໍາທີ່ຊັດເຈນກວ່າ. ຖ້າທ່ານໂທຫາ malloc, ທ່ານຈະໄດ້ຮັບຄວາມຊົງຈໍາທີ່ປົກກະຕິແລ້ວພຽງແຕ່ໃຊ້. ປົກກະຕິແລ້ວທ່ານເຮັດບາງສິ່ງທີ່ຊົ່ວຄາວດ້ວຍຄວາມຊົງຈໍາແລະທັນທີທັນໃດກັບຄືນມັນ. ແລະທັນທີທັນໃດມັນກັບຄືນໄປສະນຸກເກີ malloc, ແລະວົງຈອນ malloc ຕໍ່ໄປດຶງມັນອອກອີກເທື່ອຫນຶ່ງ. ດັ່ງນັ້ນ, ການນໍາໃຊ້ຄວາມຊົງຈໍາຕົວຈິງແມ່ນຫຼຸດລົງເຖິງຊຸດຂອງສິ່ງມີຊີວິດໃນເວລາໃດຫນຶ່ງ, ບວກກັບການຮົ່ວໄຫລ. ແລະຖ້າທຸກສິ່ງທຸກຢ່າງບໍ່ຮົ່ວໄຫຼໃນທາງທີ່ບໍ່ເຫມາະສົມຢ່າງສົມບູນ, ຫນ່ວຍຄວາມຈໍາສ່ວນໃຫຍ່ຈະສິ້ນສຸດລົງໃນແຄດແລະໂປເຊດເຊີ, ແລະມັນເຮັດວຽກໄດ້ໄວ. ແຕ່ຮຽກຮ້ອງໃຫ້ມີການຈັດການຫນ່ວຍຄວາມຈໍາຄູ່ມືຫຼາຍກັບ malloc ແລະບໍ່ເສຍຄ່າທີ່ເອີ້ນວ່າໃນຄໍາສັ່ງທີ່ເຫມາະສົມ, ໃນສະຖານທີ່ທີ່ເຫມາະສົມ. Rust ສາມາດຈັດການໄດ້ຢ່າງຖືກຕ້ອງດ້ວຍຕົວມັນເອງ, ແລະໃນຫຼາຍໆກໍລະນີໃຫ້ການປະຕິບັດທີ່ດີຂຶ້ນ, ນັບຕັ້ງແຕ່ການບໍລິໂພກຫນ່ວຍຄວາມຈໍາຖືກແຄບລົງເປັນພຽງແຕ່ການຄິດໄລ່ໃນປະຈຸບັນ - ກົງກັນຂ້າມກັບການລໍຖ້າຮອບວຽນ GC ຕໍ່ໄປເພື່ອຂະຫຍາຍຫນ່ວຍຄວາມຈໍາ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບວິທີທີ່ຫນ້າສົນໃຈຫຼາຍເພື່ອປັບປຸງການປະຕິບັດ. ແລະຂ້ອນຂ້າງມີອໍານາດ - ຂ້າພະເຈົ້າຫມາຍຄວາມວ່າ, ຂ້າພະເຈົ້າໄດ້ເຮັດສິ່ງດັ່ງກ່າວໃນເວລາທີ່ການປຸງແຕ່ງຂໍ້ມູນສໍາລັບ fintech, ແລະນີ້ເຮັດໃຫ້ຂ້ອຍໄດ້ຮັບຄວາມໄວປະມານຫ້າເທື່ອ. ນັ້ນແມ່ນການຊຸກຍູ້ອັນໃຫຍ່ຫຼວງຫຼາຍ, ໂດຍສະເພາະໃນໂລກທີ່ໂປເຊດເຊີບໍ່ໄວຂຶ້ນແລະພວກເຮົາຍັງລໍຖ້າການປັບປຸງ.

ອາຊີບວິສະວະກອນປະສິດທິພາບ

Andrei: ຂ້າພະເຈົ້າຍັງຢາກຖາມກ່ຽວກັບອາຊີບໂດຍທົ່ວໄປ. ທ່ານໄດ້ກາຍເປັນຊື່ສຽງກັບການເຮັດວຽກ JIT ຂອງທ່ານຢູ່ HotSpot ແລະຫຼັງຈາກນັ້ນຍ້າຍໄປ Azul, ເຊິ່ງເປັນບໍລິສັດ JVM. ແຕ່ພວກເຮົາໄດ້ເຮັດວຽກຢູ່ໃນຮາດແວຫຼາຍກວ່າຊອບແວ. ແລະຫຼັງຈາກນັ້ນພວກເຂົາເຈົ້າທັນທີທັນໃດໄດ້ປ່ຽນໄປ Big Data ແລະ Machine Learning, ແລະຫຼັງຈາກນັ້ນເພື່ອກວດຫາການສໍ້ໂກງ. ນີ້ເກີດຂຶ້ນໄດ້ແນວໃດ? ເຫຼົ່ານີ້ແມ່ນຂົງເຂດທີ່ແຕກຕ່າງກັນຫຼາຍຂອງການພັດທະນາ.

ຜາ: ຂ້ອຍຂຽນໂປຣແກມມາດົນແລ້ວ ແລະສາມາດເຂົ້າຮຽນຫຼາຍໆຫ້ອງ. ແລະໃນເວລາທີ່ຄົນເວົ້າວ່າ: "ໂອ້, ເຈົ້າແມ່ນຜູ້ທີ່ເຮັດ JIT ສໍາລັບ Java!", ມັນເປັນເລື່ອງຕະຫລົກສະເຫມີ. ແຕ່ກ່ອນນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເຮັດວຽກກ່ຽວກັບການໂຄນຂອງ PostScript - ພາສາທີ່ Apple ເຄີຍໃຊ້ສໍາລັບເຄື່ອງພິມເລເຊີຂອງມັນ. ແລະກ່ອນນັ້ນຂ້ອຍໄດ້ປະຕິບັດພາສາ Forth. ຂ້າພະເຈົ້າຄິດວ່າຫົວຂໍ້ທົ່ວໄປສໍາລັບຂ້ອຍແມ່ນການພັດທະນາເຄື່ອງມື. ຕະຫຼອດຊີວິດຂອງຂ້ອຍຂ້ອຍໄດ້ເຮັດເຄື່ອງມືທີ່ຄົນອື່ນຂຽນໂປຼແກຼມເຢັນຂອງພວກເຂົາ. ແຕ່ຂ້ອຍຍັງໄດ້ມີສ່ວນຮ່ວມໃນການພັດທະນາລະບົບປະຕິບັດການ, ໄດເວີ, ແກ້ໄຂຈຸດບົກພ່ອງລະດັບ kernel, ພາສາສໍາລັບການພັດທະນາ OS, ເຊິ່ງເລີ່ມຕົ້ນຈາກເລື່ອງເລັກໆນ້ອຍໆ, ແຕ່ເມື່ອເວລາຜ່ານໄປໄດ້ກາຍເປັນຄວາມສັບສົນຫຼາຍ. ແຕ່ຫົວຂໍ້ຕົ້ນຕໍແມ່ນຍັງເປັນການພັດທະນາຂອງເຄື່ອງມື. ສ່ວນຫນຶ່ງຂອງຊີວິດຂອງຂ້ອຍໄດ້ຜ່ານລະຫວ່າງ Azul ແລະ Sun, ແລະມັນແມ່ນກ່ຽວກັບ Java. ແຕ່ເມື່ອຂ້ອຍເຂົ້າໄປໃນ Big Data ແລະ Machine Learning, ຂ້ອຍໄດ້ໃສ່ຫມວກແຟນຊີຂອງຂ້ອຍຄືນໃຫມ່ແລະເວົ້າວ່າ, "ໂອ້, ຕອນນີ້ພວກເຮົາມີບັນຫາທີ່ບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ, ແລະມີຫຼາຍສິ່ງທີ່ຫນ້າສົນໃຈທີ່ເກີດຂື້ນແລະຄົນເຮັດສິ່ງຕ່າງໆ." ນີ້​ແມ່ນ​ເສັ້ນ​ທາງ​ການ​ພັດ​ທະ​ນາ​ທີ່​ຍິ່ງ​ໃຫຍ່​ທີ່​ຈະ​ເອົາ​.

ແມ່ນແລ້ວ, ຂ້ອຍມັກຄອມພິວເຕີ້ແຈກຢາຍ. ວຽກທໍາອິດຂອງຂ້ອຍແມ່ນເປັນນັກຮຽນໃນ C, ໃນໂຄງການໂຄສະນາ. ນີ້ໄດ້ຖືກແຈກຢາຍຄອມພິວເຕີ້ຢູ່ໃນຊິບ Zilog Z80 ທີ່ເກັບກໍາຂໍ້ມູນສໍາລັບ OCR ອະນາລັອກ, ຜະລິດໂດຍການວິເຄາະອະນາລັອກທີ່ແທ້ຈິງ. ມັນເປັນຫົວຂໍ້ທີ່ເຢັນແລະບ້າຫມົດ. ແຕ່ມີບັນຫາ, ບາງສ່ວນຂອງການຮັບຮູ້ບໍ່ຖືກຕ້ອງ, ດັ່ງນັ້ນທ່ານຕ້ອງເອົາຮູບອອກແລະສະແດງໃຫ້ຜູ້ທີ່ສາມາດອ່ານດ້ວຍຕາຂອງເຂົາເຈົ້າແລະລາຍງານສິ່ງທີ່ມັນເວົ້າ, ແລະດັ່ງນັ້ນຈຶ່ງມີວຽກເຮັດງານທໍາທີ່ມີຂໍ້ມູນ, ແລະວຽກເຮັດງານທໍາເຫຼົ່ານີ້. ມີພາສາຂອງຕົນເອງ. ມີ backend ທີ່ດໍາເນີນການທັງຫມົດນີ້ - Z80s ແລ່ນຂະຫນານກັບ vt100 terminals ແລ່ນ - ຫນຶ່ງຕໍ່ຄົນ, ແລະມີຮູບແບບການຂຽນໂປລແກລມຂະຫນານໃນ Z80. ບາງສ່ວນຂອງຄວາມຊົງຈໍາທົ່ວໄປທີ່ແບ່ງປັນໂດຍ Z80s ທັງຫມົດພາຍໃນການຕັ້ງຄ່າດາວ; backplane ຍັງຖືກແບ່ງປັນ, ແລະເຄິ່ງຫນຶ່ງຂອງ RAM ໄດ້ຖືກແບ່ງປັນພາຍໃນເຄືອຂ່າຍ, ແລະອີກເຄິ່ງຫນຶ່ງເປັນສ່ວນຕົວຫຼືໄປຫາສິ່ງອື່ນ. ລະບົບກະຈາຍຂະໜານທີ່ສັບສົນທີ່ມີຄວາມໝາຍກັບການແບ່ງປັນ... ຄວາມຊົງຈຳເຄິ່ງແບ່ງປັນ. ນີ້ແມ່ນເວລາໃດ ... ຂ້ອຍຈື່ບໍ່ໄດ້, ບາງບ່ອນໃນກາງຊຸມປີ 80. ຂ້ອນຂ້າງຍາວກ່ອນຫນ້ານີ້. 
ແມ່ນແລ້ວ, ໃຫ້ສົມມຸດວ່າ 30 ປີແມ່ນຂ້ອນຂ້າງຍາວກ່ອນຫນ້ານີ້. ບັນຫາທີ່ກ່ຽວຂ້ອງກັບຄອມພິວເຕີ້ແຈກຢາຍແມ່ນມີມາດົນນານແລ້ວ; ຜູ້ຄົນໄດ້ເຮັດສົງຄາມກັບພວກເຂົາມາດົນນານແລ້ວ. Beowulf- ກຸ່ມ. ກຸ່ມດັ່ງກ່າວເບິ່ງຄືວ່າ ... ຕົວຢ່າງ: ມີ Ethernet ແລະ x86 ໄວຂອງເຈົ້າເຊື່ອມຕໍ່ກັບ Ethernet ນີ້, ແລະຕອນນີ້ເຈົ້າຕ້ອງການທີ່ຈະໄດ້ຮັບຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນປອມ, ເພາະວ່າບໍ່ມີໃຜສາມາດເຮັດລະຫັດຄອມພິວເຕີ້ແຈກຢາຍໃນເວລານັ້ນ, ມັນຍາກເກີນໄປແລະດັ່ງນັ້ນ. ເປັນຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນປອມກັບຫນ້າຫນ່ວຍຄວາມຈໍາປ້ອງກັນໃນ x86, ແລະຖ້າທ່ານຂຽນໄປຫາຫນ້ານີ້, ພວກເຮົາບອກໂປເຊດເຊີອື່ນໆວ່າຖ້າພວກເຂົາເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນ, ມັນຈໍາເປັນຕ້ອງຖືກໂຫລດຈາກເຈົ້າ, ແລະດັ່ງນັ້ນບາງສິ່ງບາງຢ່າງເຊັ່ນ: ໂປໂຕຄອນສໍາລັບການສະຫນັບສະຫນູນ. cache coherence ປາກົດແລະຊອບແວສໍາລັບການນີ້. ແນວຄວາມຄິດທີ່ຫນ້າສົນໃຈ. ບັນຫາທີ່ແທ້ຈິງ, ແນ່ນອນ, ແມ່ນສິ່ງອື່ນ. ທັງຫມົດນີ້ເຮັດວຽກ, ແຕ່ວ່າທ່ານມີບັນຫາການປະຕິບັດຢ່າງໄວວາ, ເພາະວ່າບໍ່ມີໃຜເຂົ້າໃຈແບບຈໍາລອງການປະຕິບັດໃນລະດັບທີ່ດີ - ຮູບແບບການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາແມ່ນຫຍັງ, ວິທີການໃຫ້ແນ່ໃຈວ່າ nodes ບໍ່ໄດ້ ping ກັນແລະກັນ, ແລະອື່ນໆ.

ສິ່ງທີ່ຂ້ອຍເກີດຂື້ນໃນ H2O ແມ່ນວ່າມັນແມ່ນນັກພັດທະນາຕົວເອງທີ່ຮັບຜິດຊອບໃນການກໍານົດບ່ອນທີ່ຄວາມຂະຫນານຖືກເຊື່ອງໄວ້ແລະບ່ອນທີ່ມັນບໍ່ແມ່ນ. ຂ້ອຍມາກັບຮູບແບບການຂຽນລະຫັດທີ່ເຮັດໃຫ້ການຂຽນລະຫັດທີ່ມີປະສິດທິພາບສູງແລະງ່າຍດາຍ. ແຕ່ການຂຽນລະຫັດແລ່ນຊ້າແມ່ນຍາກ, ມັນຈະເບິ່ງບໍ່ດີ. ທ່ານຈໍາເປັນຕ້ອງພະຍາຍາມຢ່າງຈິງຈັງເພື່ອຂຽນລະຫັດຊ້າ, ທ່ານຈະຕ້ອງໃຊ້ວິທີການທີ່ບໍ່ແມ່ນມາດຕະຖານ. ລະຫັດເບກແມ່ນເຫັນໄດ້ໃນ glance ທໍາອິດ. ດັ່ງນັ້ນ, ປົກກະຕິແລ້ວທ່ານຂຽນລະຫັດທີ່ແລ່ນໄວ, ແຕ່ທ່ານຕ້ອງຄິດອອກວ່າຈະເຮັດແນວໃດໃນກໍລະນີຂອງຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ຮ່ວມກັນ. ທັງຫມົດນີ້ແມ່ນຕິດກັບ array ຂະຫນາດໃຫຍ່ແລະພຶດຕິກໍາທີ່ມີລັກສະນະຄ້າຍຄືກັນກັບ array ຂະຫນາດໃຫຍ່ທີ່ບໍ່ປ່ຽນແປງໃນຂະຫນານ Java. ຂ້ອຍຫມາຍຄວາມວ່າ, ຈິນຕະນາການວ່າສອງກະທູ້ຂຽນໃສ່ແຖວຂະຫນານ, ຫນຶ່ງໃນນັ້ນຊະນະ, ແລະອີກອັນຫນຶ່ງ, ຕາມນັ້ນ, ສູນເສຍ, ແລະເຈົ້າບໍ່ຮູ້ວ່າອັນໃດເປັນອັນໃດ. ຖ້າພວກເຂົາບໍ່ປ່ຽນແປງ, ຫຼັງຈາກນັ້ນຄໍາສັ່ງສາມາດເປັນສິ່ງທີ່ທ່ານຕ້ອງການ - ແລະນີ້ກໍ່ເຮັດວຽກໄດ້ດີ. ປະຊາຊົນກໍ່ສົນໃຈກັບຄໍາສັ່ງຂອງການດໍາເນີນງານ, ພວກເຂົາວາງຕົວປ່ຽນແປງໃນສະຖານທີ່ທີ່ເຫມາະສົມ, ແລະພວກເຂົາຄາດຫວັງວ່າບັນຫາການປະຕິບັດທີ່ກ່ຽວຂ້ອງກັບຄວາມຊົງຈໍາໃນສະຖານທີ່ທີ່ເຫມາະສົມ. ຖ້າບໍ່ດັ່ງນັ້ນ, ພວກເຂົາພຽງແຕ່ຂຽນລະຫັດໃນຮູບແບບຂອງ loops ຈາກ 1 ຫາ N, ບ່ອນທີ່ N ແມ່ນບາງພັນຕື້, ໂດຍຫວັງວ່າກໍລະນີທີ່ສັບສົນທັງຫມົດຈະກາຍເປັນຂະຫນານໂດຍອັດຕະໂນມັດ - ແລະມັນບໍ່ເຮັດວຽກຢູ່ທີ່ນັ້ນ. ແຕ່ໃນ H2O ນີ້ບໍ່ແມ່ນ Java ຫຼື Scala; ທ່ານສາມາດພິຈາລະນາມັນ "Java ລົບລົບ" ຖ້າທ່ານຕ້ອງການ. ນີ້ແມ່ນຮູບແບບການຂຽນໂປລແກລມທີ່ຊັດເຈນຫຼາຍແລະຄ້າຍຄືກັບການຂຽນລະຫັດ C ຫຼື Java ງ່າຍໆດ້ວຍ loops ແລະ arrays. ແຕ່ໃນເວລາດຽວກັນ, ຫນ່ວຍຄວາມຈໍາສາມາດຖືກປຸງແຕ່ງໃນ terabytes. ຂ້ອຍຍັງໃຊ້ H2O. ຂ້ອຍໃຊ້ມັນບາງຄັ້ງໃນໂຄງການທີ່ແຕກຕ່າງກັນ - ແລະມັນຍັງຄົງເປັນສິ່ງທີ່ໄວທີ່ສຸດ, ຫຼາຍສິບເທື່ອໄວກວ່າຄູ່ແຂ່ງຂອງມັນ. ຖ້າທ່ານກໍາລັງເຮັດ Big Data ກັບຂໍ້ມູນຖັນ, ມັນຍາກຫຼາຍທີ່ຈະຕີ H2O.

ສິ່ງທ້າທາຍດ້ານວິຊາການ

Andrei: ແມ່ນຫຍັງຄືສິ່ງທ້າທາຍທີ່ໃຫຍ່ທີ່ສຸດຂອງເຈົ້າໃນອາຊີບທັງໝົດຂອງເຈົ້າ?

ຜາ: ພວກເຮົາສົນທະນາກ່ຽວກັບບັນຫາດ້ານວິຊາການຫຼືບໍ່ແມ່ນດ້ານວິຊາການ? ຂ້າພະເຈົ້າຈະເວົ້າວ່າສິ່ງທ້າທາຍທີ່ໃຫຍ່ທີ່ສຸດບໍ່ແມ່ນດ້ານວິຊາການ. 
ສໍາລັບສິ່ງທ້າທາຍດ້ານວິຊາການ. ຂ້າພະເຈົ້າພຽງແຕ່ defeated ເຂົາເຈົ້າ. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ຮູ້​ວ່າ​ສິ່ງ​ທີ່​ໃຫຍ່​ທີ່​ສຸດ​ແມ່ນ​, ແຕ່​ວ່າ​ມີ​ບາງ​ອັນ​ທີ່​ຫນ້າ​ສົນ​ໃຈ​ທີ່​ໃຊ້​ເວ​ລາ​ຂ້ອນ​ຂ້າງ​ນ້ອຍ​ຂອງ​ການ​ຕໍ່​ສູ້​ທາງ​ຈິດ​ໃຈ​. ເມື່ອຂ້ອຍໄປ Sun, ຂ້ອຍແນ່ໃຈວ່າຂ້ອຍຈະເຮັດການລວບລວມໄວ, ແລະຜູ້ອາວຸໂສຫຼາຍໆຄົນໄດ້ຕອບວ່າຂ້ອຍຈະບໍ່ມີວັນປະສົບຜົນສໍາເລັດ. ແຕ່ຂ້ອຍປະຕິບັດຕາມເສັ້ນທາງນີ້, ຂຽນ compiler ລົງໄປຫາຜູ້ຈັດສັນທະບຽນ, ແລະມັນຂ້ອນຂ້າງໄວ. ມັນໄວເທົ່າກັບ C1 ທີ່ທັນສະໄຫມ, ແຕ່ຜູ້ຈັດສັນແມ່ນຊ້າກວ່າໃນເວລານັ້ນ, ແລະໃນທາງຫລັງແມ່ນບັນຫາໂຄງສ້າງຂໍ້ມູນຂະຫນາດໃຫຍ່. ຂ້າພະເຈົ້າຕ້ອງການມັນເພື່ອຂຽນຜູ້ຈັດສັນການລົງທະບຽນກາຟິກແລະຂ້ອຍບໍ່ເຂົ້າໃຈຄວາມຫຍຸ້ງຍາກລະຫວ່າງການສະແດງອອກຂອງລະຫັດແລະຄວາມໄວ, ທີ່ມີຢູ່ໃນຍຸກນັ້ນແລະມີຄວາມສໍາຄັນຫຼາຍ. ມັນໄດ້ຫັນອອກວ່າໂຄງສ້າງຂໍ້ມູນປົກກະຕິແລ້ວເກີນຂະຫນາດ cache ໃນ x86s ໃນເວລານັ້ນ, ແລະດັ່ງນັ້ນ, ຖ້າຂ້ອຍສົມມຸດໃນເບື້ອງຕົ້ນວ່າຜູ້ຈັດສັນການລົງທະບຽນຈະເຮັດວຽກອອກ 5-10 ເປີເຊັນຂອງເວລາສັ່ນສະເທືອນທັງຫມົດ, ຫຼັງຈາກນັ້ນໃນຄວາມເປັນຈິງແລ້ວມັນກໍ່ກາຍເປັນ. 50 ເປີເຊັນ.

ເມື່ອເວລາຜ່ານໄປ, compiler ໄດ້ກາຍເປັນທີ່ສະອາດແລະມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ຢຸດເຊົາການສ້າງລະຫັດທີ່ຂີ້ຮ້າຍໃນກໍລະນີຫຼາຍ, ແລະການປະຕິບັດກໍ່ເລີ່ມຄ້າຍຄືກັບສິ່ງທີ່ C compiler ຜະລິດ. . ຖ້າທ່ານຂຽນລະຫັດເຊັ່ນ C, ທ່ານຈະໄດ້ຮັບການປະຕິບັດເຊັ່ນ C ໃນກໍລະນີຫຼາຍ. ແລະຍິ່ງໄປກວ່ານັ້ນ, ເຈົ້າໄດ້ຮັບລະຫັດທີ່ກົງກັນກັບລະດັບ C, ເລື້ອຍໆ, ຜູ້ຈັດສັນການລົງທະບຽນເລີ່ມເບິ່ງຄືວ່າມີບາງສິ່ງບາງຢ່າງທີ່ສົມບູນ ... ໂດຍບໍ່ຄໍານຶງເຖິງວ່າລະຫັດຂອງທ່ານຈະແລ່ນໄວຫຼືຊ້າ. ຂ້າພະເຈົ້າໄດ້ສືບຕໍ່ເຮັດວຽກກ່ຽວກັບຜູ້ຈັດສັນເພື່ອເຮັດໃຫ້ມັນເລືອກທີ່ດີກວ່າ. ລາວໄດ້ກາຍເປັນຊ້າລົງແລະຊ້າລົງ, ແຕ່ລາວໄດ້ໃຫ້ການປະຕິບັດທີ່ດີກວ່າແລະດີກວ່າໃນກໍລະນີທີ່ບໍ່ມີໃຜສາມາດຮັບມືກັບໄດ້. ຂ້ອຍສາມາດເຂົ້າໄປໃນຜູ້ຈັດສັນການລົງທະບຽນ, ຝັງຫນຶ່ງເດືອນຂອງການເຮັດວຽກຢູ່ທີ່ນັ້ນ, ແລະທັນທີທັນໃດລະຫັດທັງຫມົດຈະເລີ່ມປະຕິບັດໄດ້ໄວຂຶ້ນ 5%. ເຫດການນີ້ເກີດຂຶ້ນເລື້ອຍໆແລະຜູ້ຈັດສັນການລົງທະບຽນໄດ້ກາຍເປັນວຽກງານສິລະປະ - ທຸກຄົນຮັກມັນຫຼືກຽດຊັງມັນ, ແລະປະຊາຊົນຈາກໂຮງຮຽນໄດ້ຖາມຄໍາຖາມກ່ຽວກັບຫົວຂໍ້ "ເປັນຫຍັງທຸກຢ່າງຈຶ່ງເຮັດແບບນີ້", ເປັນຫຍັງບໍ່? ສະແກນເສັ້ນ, ແລະສິ່ງທີ່ແຕກຕ່າງກັນ. ຄໍາຕອບແມ່ນຍັງຄືກັນ: ຜູ້ຈັດສັນໂດຍອີງໃສ່ຮູບແຕ້ມຮູບບວກກັບການເຮັດວຽກທີ່ລະມັດລະວັງຫຼາຍກັບລະຫັດ buffer ແມ່ນເທົ່າກັບອາວຸດແຫ່ງໄຊຊະນະ, ການປະສົມປະສານທີ່ດີທີ່ສຸດທີ່ບໍ່ມີໃຜສາມາດເອົາຊະນະໄດ້. ແລະນີ້ແມ່ນສິ່ງທີ່ບໍ່ຊັດເຈນ. ທຸກສິ່ງທຸກຢ່າງອື່ນທີ່ compiler ເຮັດມີການສຶກສາຂ້ອນຂ້າງດີ, ເຖິງແມ່ນວ່າພວກເຂົາເຈົ້າໄດ້ຖືກນໍາມາໃນລະດັບຂອງສິນລະປະ. ຂ້າພະເຈົ້າສະເຫມີເຮັດສິ່ງທີ່ຄວນຈະເຮັດໃຫ້ compiler ກາຍເປັນວຽກງານສິລະປະ. ແຕ່ອັນໃດອັນໜຶ່ງອັນນີ້ບໍ່ມີຫຍັງພິເສດ - ຍົກເວັ້ນຜູ້ຈັດສັນທະບຽນ. trick ແມ່ນເພື່ອລະມັດລະວັງ ຕັດລົງ ພາຍໃຕ້ການໂຫຼດແລະ, ຖ້າຫາກວ່ານີ້ເກີດຂຶ້ນ (ຂ້າພະເຈົ້າສາມາດອະທິບາຍລາຍລະອຽດເພີ່ມເຕີມຖ້າຫາກວ່າມີຄວາມສົນໃຈ), ນີ້ຫມາຍຄວາມວ່າທ່ານສາມາດ inline ຮຸກຮານຫຼາຍ, ໂດຍບໍ່ມີການຄວາມສ່ຽງຂອງການຫຼຸດລົງໃນໄລຍະ kink ໃນຕາຕະລາງການປະຕິບັດ. ໃນສະໄໝນັ້ນ, ມີເຄື່ອງລວບລວມຂໍ້ມູນເຕັມຮູບແບບ, ແຂວນໃສ່ກັບ baubles ແລະ whistles, ທີ່ມີຜູ້ຈັດສັນທະບຽນ, ແຕ່ບໍ່ມີໃຜສາມາດເຮັດໄດ້.

ບັນຫາແມ່ນວ່າຖ້າທ່ານເພີ່ມວິທີການທີ່ຂຶ້ນກັບ inlining, ເພີ່ມຂຶ້ນແລະເພີ່ມພື້ນທີ່ inlining, ຊຸດຂອງມູນຄ່າທີ່ນໍາໃຊ້ທັນທີ outstrips ຈໍານວນຂອງການລົງທະບຽນ, ແລະທ່ານຕ້ອງຕັດໃຫ້ເຂົາເຈົ້າ. ລະດັບທີ່ສໍາຄັນມັກຈະມາໃນເວລາທີ່ຜູ້ຈັດສັນໃຫ້ເຖິງ, ແລະຜູ້ສະຫມັກທີ່ດີສໍາລັບການຮົ່ວໄຫຼແມ່ນມີມູນຄ່າອີກ, ທ່ານຈະຂາຍບາງສິ່ງທີ່ທໍາມະຊາດໂດຍທົ່ວໄປ. ມູນຄ່າຂອງ inlining ນີ້ແມ່ນວ່າທ່ານສູນເສຍສ່ວນຫນຶ່ງຂອງ overhead, overhead ສໍາລັບການໂທຫາແລະປະຫຍັດ, ທ່ານສາມາດເບິ່ງຄຸນຄ່າພາຍໃນແລະສາມາດເພີ່ມປະສິດທິພາບໃຫ້ເຂົາເຈົ້າຕື່ມອີກ. ຄ່າໃຊ້ຈ່າຍຂອງ inlining ແມ່ນວ່າຈໍານວນຂະຫນາດໃຫຍ່ຂອງມູນຄ່າທີ່ມີຊີວິດໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ, ແລະຖ້າຜູ້ຈັດສັນການລົງທະບຽນຂອງທ່ານເຜົາໄຫມ້ຫຼາຍກ່ວາຄວາມຈໍາເປັນ, ທ່ານຈະສູນເສຍທັນທີ. ດັ່ງນັ້ນ, ຜູ້ຈັດສັນສ່ວນໃຫຍ່ມີບັນຫາ: ເມື່ອ inlining ຂ້າມເສັ້ນທີ່ແນ່ນອນ, ທຸກສິ່ງທຸກຢ່າງໃນໂລກເລີ່ມຖືກຕັດລົງແລະຜົນຜະລິດສາມາດຖືກລ້າງລົງໃນຫ້ອງນ້ໍາ. ຜູ້ທີ່ປະຕິບັດ compiler ເພີ່ມ heuristics ບາງຢ່າງ: ສໍາລັບການຍົກຕົວຢ່າງ, ຢຸດເຊົາການ inlining, ເລີ່ມຕົ້ນດ້ວຍບາງຂະຫນາດໃຫຍ່ພຽງພໍ, ເນື່ອງຈາກວ່າການຈັດສັນຈະທໍາລາຍທຸກສິ່ງທຸກຢ່າງ. ນີ້ແມ່ນວິທີການ kink ໃນກາຟການປະຕິບັດໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ - ທ່ານ inline, inline, ການປະຕິບັດການຂະຫຍາຍຕົວຊ້າໆ - ແລະຫຼັງຈາກນັ້ນຂະຫຍາຍຕົວຢ່າງ! – ມັນລົ້ມລົງຄືກັບ jack swift ເພາະວ່າເຈົ້າວາງສາຍຫຼາຍເກີນໄປ. ນີ້ແມ່ນວິທີທີ່ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກກ່ອນທີ່ຈະມາຮອດຂອງ Java. Java ຕ້ອງການ inlining ຫຼາຍ, ສະນັ້ນຂ້ອຍຕ້ອງເຮັດໃຫ້ຜູ້ຈັດສັນຂອງຂ້ອຍມີຄວາມຮຸກຮານຫຼາຍເພື່ອໃຫ້ມັນຢູ່ໃນລະດັບຫຼາຍກວ່າການຂັດຂ້ອງ, ແລະຖ້າທ່ານ inline ຫຼາຍເກີນໄປ, ມັນຈະເລີ່ມຮົ່ວ, ແຕ່ຫຼັງຈາກນັ້ນ "ບໍ່ມີການຮົ່ວໄຫຼ" ມາຮອດປັດຈຸບັນ. ນີ້ແມ່ນການສັງເກດການທີ່ຫນ້າສົນໃຈແລະມັນພຽງແຕ່ມາຫາຂ້ອຍຈາກບ່ອນໃດກໍ່ຕາມ, ບໍ່ຊັດເຈນ, ແຕ່ມັນກໍ່ໄດ້ຮັບຜົນດີ. ຂ້າພະເຈົ້າໄດ້ເອົາ inlining ຮຸກຮານແລະມັນໄດ້ນໍາຂ້າພະເຈົ້າໄປບ່ອນທີ່ການປະຕິບັດ Java ແລະ C ເຮັດວຽກຄຽງຄູ່ກັນ. ພວກເຂົາໃກ້ຊິດແທ້ໆ - ຂ້ອຍສາມາດຂຽນລະຫັດ Java ທີ່ໄວກວ່າລະຫັດ C ແລະສິ່ງຕ່າງໆເຊັ່ນນັ້ນ, ແຕ່ໂດຍສະເລ່ຍ, ໃນຮູບໃຫຍ່ຂອງສິ່ງຕ່າງໆ, ພວກມັນປຽບທຽບໄດ້ປະມານ. ຂ້າພະເຈົ້າຄິດວ່າສ່ວນຫນຶ່ງຂອງຄຸນງາມຄວາມດີນີ້ແມ່ນຜູ້ຈັດສັນການລົງທະບຽນ, ເຊິ່ງເຮັດໃຫ້ຂ້ອຍສາມາດ inline ເປັນ stupid ທີ່ເປັນໄປໄດ້. ຂ້າພະເຈົ້າພຽງແຕ່ inline ທຸກສິ່ງທຸກຢ່າງທີ່ຂ້າພະເຈົ້າເຫັນ. ຄໍາຖາມຢູ່ທີ່ນີ້ແມ່ນວ່າຜູ້ຈັດສັນເຮັດວຽກດີ, ບໍ່ວ່າຜົນໄດ້ຮັບແມ່ນລະຫັດເຮັດວຽກຢ່າງສະຫຼາດ. ນີ້ແມ່ນສິ່ງທ້າທາຍອັນໃຫຍ່ຫຼວງ: ເພື່ອເຂົ້າໃຈສິ່ງທັງຫມົດນີ້ແລະເຮັດໃຫ້ມັນເຮັດວຽກ.

ເລັກນ້ອຍກ່ຽວກັບການລົງທະບຽນການຈັດສັນແລະຫຼາຍແກນ

Владимир: ບັນຫາເຊັ່ນການຈັດສັນການລົງທະບຽນເບິ່ງຄືວ່າເປັນບາງປະເພດຂອງຫົວຂໍ້ນິລັນດອນ, ບໍ່ມີທີ່ສິ້ນສຸດ. ຂ້າ​ພະ​ເຈົ້າ​ສົງ​ໃສ​ວ່າ​ມີ​ເຄີຍ​ມີ​ຄວາມ​ຄິດ​ທີ່​ເບິ່ງ​ຄື​ວ່າ​ມີ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ຄວາມ​ລົ້ມ​ເຫຼວ​ໃນ​ການ​ປະ​ຕິ​ບັດ​?

ຜາ: ແນ່ນອນ! ການຈັດສັນການລົງທະບຽນແມ່ນພື້ນທີ່ທີ່ທ່ານພະຍາຍາມຊອກຫາ heuristics ບາງຢ່າງເພື່ອແກ້ໄຂບັນຫາ NP-complete. ແລະທ່ານບໍ່ເຄີຍສາມາດບັນລຸການແກ້ໄຂທີ່ສົມບູນແບບ, ແມ່ນບໍ? ນີ້ແມ່ນເປັນໄປບໍ່ໄດ້ພຽງແຕ່. ເບິ່ງ, ການລວບລວມລ່ວງຫນ້າຂອງເວລາ - ມັນຍັງເຮັດວຽກບໍ່ດີ. ການສົນທະນານີ້ແມ່ນກ່ຽວກັບບາງກໍລະນີໂດຍສະເລ່ຍ. ກ່ຽວກັບການປະຕິບັດປົກກະຕິ, ດັ່ງນັ້ນທ່ານສາມາດໄປແລະວັດແທກບາງສິ່ງບາງຢ່າງທີ່ທ່ານຄິດວ່າເປັນການປະຕິບັດປົກກະຕິທີ່ດີ - ຫຼັງຈາກທີ່ທັງຫມົດ, ທ່ານກໍາລັງເຮັດວຽກເພື່ອປັບປຸງມັນ! ການຈັດສັນການລົງທະບຽນແມ່ນຫົວຂໍ້ກ່ຽວກັບການປະຕິບັດ. ເມື່ອທ່ານມີຕົ້ນແບບທໍາອິດ, ມັນເຮັດວຽກແລະທາສີສິ່ງທີ່ຈໍາເປັນ, ວຽກງານການປະຕິບັດຈະເລີ່ມຕົ້ນ. ທ່ານຈໍາເປັນຕ້ອງຮຽນຮູ້ການວັດແທກທີ່ດີ. ເປັນຫຍັງມັນຈຶ່ງສໍາຄັນ? ຖ້າທ່ານມີຂໍ້ມູນທີ່ຊັດເຈນ, ທ່ານສາມາດເບິ່ງໃນພື້ນທີ່ຕ່າງໆແລະເບິ່ງ: ແມ່ນແລ້ວ, ມັນໄດ້ຊ່ວຍຢູ່ທີ່ນີ້, ແຕ່ນັ້ນແມ່ນບ່ອນທີ່ທຸກສິ່ງທຸກຢ່າງແຕກ! ບາງແນວຄວາມຄິດທີ່ດີມາ, ທ່ານເພີ່ມ heuristics ໃຫມ່ແລະທັນທີທັນໃດທຸກສິ່ງທຸກຢ່າງເລີ່ມຕົ້ນເຮັດວຽກດີຂຶ້ນເລັກນ້ອຍໂດຍສະເລ່ຍ. ຫຼືມັນບໍ່ເລີ່ມຕົ້ນ. ຂ້ອຍມີກໍລະນີທີ່ພວກເຮົາກໍາລັງສູ້ກັນສໍາລັບການປະຕິບັດຫ້າເປີເຊັນທີ່ແຕກຕ່າງຈາກການພັດທະນາຂອງພວກເຮົາຈາກຜູ້ຈັດສັນທີ່ຜ່ານມາ. ແລະທຸກໆຄັ້ງທີ່ມັນເບິ່ງຄືວ່າ: ບາງບ່ອນເຈົ້າຊະນະ, ບາງບ່ອນເຈົ້າສູນເສຍ. ຖ້າທ່ານມີເຄື່ອງມືການວິເຄາະປະສິດທິພາບທີ່ດີ, ທ່ານສາມາດຊອກຫາແນວຄວາມຄິດທີ່ສູນເສຍແລະເຂົ້າໃຈວ່າເປັນຫຍັງພວກມັນລົ້ມເຫລວ. ບາງທີມັນຄຸ້ມຄ່າທີ່ຈະປ່ອຍໃຫ້ທຸກຢ່າງເປັນໄປຕາມໆກັນ, ຫຼືອາດຈະໃຊ້ວິທີການທີ່ຈິງຈັງກວ່າໃນການປັບໄໝ, ຫຼືອອກໄປແກ້ໄຂອັນອື່ນ. ມັນ​ເປັນ​ຊໍ່​ທັງ​ຫມົດ​ຂອງ​ສິ່ງ​ທີ່​! ຂ້າພະເຈົ້າໄດ້ເຮັດການ hack ເຢັນນີ້, ແຕ່ຂ້າພະເຈົ້າຍັງຕ້ອງການອັນນີ້, ແລະອັນນີ້, ແລະອັນນີ້ - ແລະການປະສົມປະສານທັງຫມົດຂອງພວກເຂົາເຮັດໃຫ້ການປັບປຸງບາງຢ່າງ. ແລະຜູ້ໂດດດ່ຽວສາມາດລົ້ມເຫລວ. ນີ້ແມ່ນລັກສະນະຂອງການປະຕິບັດວຽກງານກ່ຽວກັບບັນຫາ NP-ສໍາເລັດ.

Владимир: ຄົນຫນຶ່ງໄດ້ຮັບຄວາມຮູ້ສຶກວ່າສິ່ງຕ່າງໆເຊັ່ນການແຕ້ມຮູບໃນຜູ້ຈັດສັນແມ່ນບັນຫາທີ່ໄດ້ຮັບການແກ້ໄຂແລ້ວ. ແລ້ວ, ມັນຕັດສິນໃຈສໍາລັບທ່ານ, ຕັດສິນໂດຍສິ່ງທີ່ເຈົ້າເວົ້າ, ດັ່ງນັ້ນມັນກໍ່ຄຸ້ມຄ່າມັນ ...

ຜາ: ມັນບໍ່ໄດ້ຖືກແກ້ໄຂເຊັ່ນນັ້ນ. ມັນແມ່ນທ່ານຜູ້ທີ່ຕ້ອງປ່ຽນມັນເຂົ້າໄປໃນ "ແກ້ໄຂ". ມີບັນຫາຫຍຸ້ງຍາກແລະພວກເຂົາຕ້ອງໄດ້ຮັບການແກ້ໄຂ. ເມື່ອນີ້ສໍາເລັດ, ມັນເປັນເວລາທີ່ຈະເຮັດວຽກກ່ຽວກັບຜົນຜະລິດ. ທ່ານຈໍາເປັນຕ້ອງເຂົ້າຫາວຽກງານນີ້ຕາມຄວາມເຫມາະສົມ - ເຮັດມາດຕະຖານ, ລວບລວມຕົວຊີ້ບອກ, ອະທິບາຍສະຖານະການ, ເມື່ອທ່ານກັບຄືນໄປຫາສະບັບກ່ອນ, ການ hack ເກົ່າຂອງທ່ານເລີ່ມເຮັດວຽກອີກເທື່ອຫນຶ່ງ (ຫຼືກົງກັນຂ້າມ, ຢຸດເຊົາ). ແລະຢ່າຍອມແພ້ຈົນກວ່າເຈົ້າຈະບັນລຸບາງສິ່ງບາງຢ່າງ. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວ, ຖ້າມີແນວຄວາມຄິດເຢັນໆທີ່ບໍ່ໄດ້ຜົນ, ແຕ່ໃນພາກສະຫນາມຂອງການຈັດສັນການລົງທະບຽນແນວຄວາມຄິດແມ່ນປະມານທີ່ບໍ່ມີທີ່ສິ້ນສຸດ. ຕົວຢ່າງ, ເຈົ້າສາມາດອ່ານສິ່ງພິມທາງວິທະຍາສາດໄດ້. ເຖິງ​ແມ່ນ​ວ່າ​ໃນ​ປັດ​ຈຸ​ບັນ​ເຂດ​ນີ້​ໄດ້​ເລີ່ມ​ຕົ້ນ​ເຄື່ອນ​ໄຫວ​ຊ້າ​ຫຼາຍ​ແລະ​ໄດ້​ກາຍ​ເປັນ​ທີ່​ຈະ​ແຈ້ງ​ຫຼາຍ​ກ​່​ວາ​ໃນ​ໄວ​ຫນຸ່ມ​ຂອງ​ຕົນ. ຢ່າງໃດກໍຕາມ, ມີຄົນນັບບໍ່ຖ້ວນທີ່ເຮັດວຽກຢູ່ໃນພາກສະຫນາມນີ້ແລະຄວາມຄິດຂອງພວກເຂົາທັງຫມົດແມ່ນມີມູນຄ່າພະຍາຍາມ, ພວກເຂົາທັງຫມົດລໍຖ້າຢູ່ໃນປີກ. ແລະເຈົ້າບໍ່ສາມາດບອກໄດ້ວ່າພວກມັນດີສໍ່າໃດ ເວັ້ນເສຍແຕ່ເຈົ້າຈະພະຍາຍາມມັນ. ພວກເຂົາເຈົ້າປະສົມປະສານກັບທຸກສິ່ງອື່ນໆໃນຜູ້ຈັດສັນຂອງເຈົ້າດີເທົ່າໃດ, ເພາະວ່າຜູ້ຈັດສັນເຮັດຫຼາຍສິ່ງຫຼາຍຢ່າງ, ແລະແນວຄວາມຄິດບາງຢ່າງຈະບໍ່ເຮັດວຽກຢູ່ໃນຜູ້ຈັດສັນສະເພາະຂອງເຈົ້າ, ແຕ່ໃນຜູ້ຈັດສັນອື່ນພວກເຂົາຈະເຮັດໄດ້ງ່າຍ. ວິທີການຕົ້ນຕໍທີ່ຈະຊະນະສໍາລັບຜູ້ຈັດສັນແມ່ນການດຶງສິ່ງທີ່ຊ້າໆຢູ່ນອກເສັ້ນທາງຕົ້ນຕໍແລະບັງຄັບໃຫ້ມັນແບ່ງອອກຕາມຂອບເຂດຂອງເສັ້ນທາງຊ້າ. ດັ່ງນັ້ນຖ້າຫາກວ່າທ່ານຕ້ອງການທີ່ຈະດໍາເນີນການ GC, ໄປຕາມເສັ້ນທາງຊ້າ, deoptimize, ຖິ້ມຂໍ້ຍົກເວັ້ນ, ສິ່ງທັງຫມົດ - ທ່ານຮູ້ວ່າສິ່ງເຫຼົ່ານີ້ແມ່ນຂ້ອນຂ້າງຫາຍາກ. ແລະພວກເຂົາແມ່ນຫາຍາກແທ້ໆ, ຂ້າພະເຈົ້າໄດ້ກວດເບິ່ງ. ທ່ານເຮັດວຽກພິເສດແລະມັນເອົາຂໍ້ຈໍາກັດຫຼາຍຢ່າງກ່ຽວກັບເສັ້ນທາງຊ້າເຫຼົ່ານີ້, ແຕ່ມັນບໍ່ສໍາຄັນເພາະວ່າພວກເຂົາຊ້າແລະບໍ່ຄ່ອຍໄດ້ເດີນທາງ. ຕົວຢ່າງ, ຕົວຊີ້ null - ມັນບໍ່ເຄີຍເກີດຂຶ້ນ, ແມ່ນບໍ? ທ່ານຈໍາເປັນຕ້ອງມີເສັ້ນທາງຫຼາຍສໍາລັບສິ່ງທີ່ແຕກຕ່າງກັນ, ແຕ່ພວກເຂົາບໍ່ຄວນແຊກແຊງກັບຕົ້ນຕໍ. 

Владимир: ທ່ານຄິດແນວໃດກ່ຽວກັບ multi-cores, ເມື່ອມີຫລາຍພັນ cores ໃນເວລາດຽວກັນ? ນີ້ແມ່ນສິ່ງທີ່ເປັນປະໂຫຍດບໍ?

ຜາ: ຄວາມສໍາເລັດຂອງ GPU ສະແດງໃຫ້ເຫັນວ່າມັນເປັນປະໂຫຍດຫຼາຍ!

Владимир: ພວກເຂົາເຈົ້າແມ່ນຂ້ອນຂ້າງຊ່ຽວຊານ. ແມ່ນຫຍັງກ່ຽວກັບໂປເຊດເຊີຈຸດປະສົງທົ່ວໄປ?

ຜາ: ດີ, ນັ້ນແມ່ນຮູບແບບທຸລະກິດຂອງ Azul. ຄໍາຕອບໄດ້ກັບຄືນມາໃນຍຸກທີ່ປະຊາຊົນມັກການປະຕິບັດການຄາດເດົາ. ມັນເປັນການຍາກທີ່ຈະຂຽນລະຫັດຂະຫນານກັບຄືນໄປບ່ອນນັ້ນ. ຮູບແບບການເຂົ້າລະຫັດ H2O ແມ່ນສາມາດຂະຫຍາຍໄດ້ສູງ, ແຕ່ມັນບໍ່ແມ່ນຮູບແບບທີ່ມີຈຸດປະສົງທົ່ວໄປ. ບາງທີໂດຍທົ່ວໄປເລັກນ້ອຍກວ່າເມື່ອໃຊ້ GPU. ພວກເຮົາເວົ້າກ່ຽວກັບຄວາມສັບສົນຂອງການພັດທະນາສິ່ງດັ່ງກ່າວຫຼືຄວາມສັບສົນຂອງການນໍາໃຊ້ມັນບໍ? ສໍາລັບຕົວຢ່າງ, Azul ໄດ້ສອນຂ້າພະເຈົ້າບົດຮຽນທີ່ຫນ້າສົນໃຈ, ແທນທີ່ຈະບໍ່ຈະແຈ້ງ: cache ຂະຫນາດນ້ອຍແມ່ນປົກກະຕິ. 

ສິ່ງທ້າທາຍທີ່ໃຫຍ່ທີ່ສຸດໃນຊີວິດ

Владимир: ຈະເປັນແນວໃດກ່ຽວກັບສິ່ງທ້າທາຍທີ່ບໍ່ແມ່ນດ້ານວິຊາການ?

ຜາ: ສິ່ງທ້າທາຍທີ່ໃຫຍ່ທີ່ສຸດບໍ່ແມ່ນການເປັນ ... ໃຈດີແລະງາມກັບຄົນ. ແລະດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ພົບເຫັນຕົວເອງຢ່າງຕໍ່ເນື່ອງໃນສະຖານະການຂັດແຍ້ງທີ່ສຸດ. ຄົນທີ່ຂ້ອຍຮູ້ວ່າສິ່ງທີ່ຜິດພາດ, ແຕ່ບໍ່ຮູ້ວິທີທີ່ຈະກ້າວໄປຂ້າງຫນ້າກັບບັນຫາເຫຼົ່ານັ້ນແລະບໍ່ສາມາດຈັດການກັບພວກມັນໄດ້. ບັນຫາໄລຍະຍາວຈໍານວນຫຼາຍ, ຊໍາເຮື້ອສໍາລັບການທົດສະວັດ, ເກີດຂຶ້ນໃນລັກສະນະນີ້. ຄວາມຈິງທີ່ວ່າ Java ມີ C1 ແລະ C2 compilers ແມ່ນຜົນສະທ້ອນໂດຍກົງຂອງເລື່ອງນີ້. ຄວາມຈິງທີ່ວ່າບໍ່ມີການລວບລວມຫຼາຍລະດັບໃນ Java ສໍາລັບສິບປີຕິດຕໍ່ກັນກໍ່ເປັນຜົນສະທ້ອນໂດຍກົງ. ມັນເຫັນໄດ້ຊັດເຈນວ່າພວກເຮົາຕ້ອງການລະບົບດັ່ງກ່າວ, ແຕ່ມັນບໍ່ຊັດເຈນວ່າເປັນຫຍັງມັນບໍ່ມີ. ຂ້ອຍມີບັນຫາກັບວິສະວະກອນຄົນໜຶ່ງ... ຫຼືກຸ່ມວິສະວະກອນ. ມີຄັ້ງຫນຶ່ງ, ເມື່ອຂ້ອຍເລີ່ມເຮັດວຽກຢູ່ Sun, ຂ້ອຍແມ່ນ ... Okay, ບໍ່ພຽງແຕ່ຫຼັງຈາກນັ້ນ, ໂດຍທົ່ວໄປແລ້ວຂ້ອຍມັກຈະມີຄວາມຄິດເຫັນຂອງຕົນເອງກ່ຽວກັບທຸກສິ່ງທຸກຢ່າງ. ແລະ​ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ມັນ​ເປັນ​ຄວາມ​ຈິງ​ທີ່​ທ່ານ​ພຽງ​ແຕ່​ສາ​ມາດ​ເອົາ​ຄວາມ​ຈິງ​ນີ້​ຂອງ​ທ່ານ​ແລະ​ບອກ​ມັນ​ໃນ​ຫົວ​ຫນ້າ. ໂດຍ​ສະ​ເພາະ​ແມ່ນ​ຍ້ອນ​ວ່າ​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້ shockingly ສິດ​ທີ່​ສຸດ​ຂອງ​ທີ່​ໃຊ້​ເວ​ລາ. ແລະຖ້າທ່ານບໍ່ມັກວິທີການນີ້ ... ໂດຍສະເພາະຖ້າທ່ານແນ່ນອນຜິດແລະເຮັດໄຮ້ສາລະ ... ໂດຍທົ່ວໄປ, ມີຄົນຈໍານວນຫນ້ອຍທີ່ສາມາດທົນທານຕໍ່ຮູບແບບການສື່ສານນີ້. ເຖິງແມ່ນວ່າບາງຄົນສາມາດ, ຄືກັບຂ້ອຍ. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ສ້າງ​ຊີ​ວິດ​ທັງ​ຫມົດ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ກ່ຽວ​ກັບ​ຫຼັກ​ການ​ຄຸນ​ນະ​ສົມ​ບັດ. ຖ້າເຈົ້າສະແດງໃຫ້ຂ້ອຍເຫັນສິ່ງທີ່ຜິດພາດ, ຂ້ອຍຈະຫັນໜ້າໄປທັນທີ ແລະເວົ້າວ່າ: ເຈົ້າເວົ້າເລື່ອງໄຮ້ສາລະ. ໃນເວລາດຽວກັນ, ແນ່ນອນ, ຂ້າພະເຈົ້າຂໍໂທດແລະທັງຫມົດນັ້ນ, ຂ້າພະເຈົ້າຈະສັງເກດຄຸນງາມຄວາມດີ, ຖ້າມີ, ແລະດໍາເນີນການທີ່ຖືກຕ້ອງອື່ນໆ. ໃນທາງກົງກັນຂ້າມ, ຂ້ອຍຮູ້ສຶກຕົກໃຈກ່ຽວກັບອັດຕາສ່ວນທີ່ໃຫຍ່ທີ່ ໜ້າ ຕົກໃຈຂອງເວລາທັງ ໝົດ. ແລະມັນບໍ່ໄດ້ຜົນດີຫຼາຍໃນການພົວພັນກັບຄົນ. ຂ້ອຍບໍ່ໄດ້ພະຍາຍາມເປັນຄົນດີ, ແຕ່ຂ້ອຍຖາມຄໍາຖາມແບບບໍ່ກົງໄປກົງມາ. "ນີ້ຈະບໍ່ເຮັດວຽກ, ເພາະວ່າຫນຶ່ງ, ສອງແລະສາມ." ແລະພວກເຂົາຄື, "ໂອ້!" ມີຜົນສະທ້ອນອື່ນໆທີ່ອາດຈະດີກວ່າທີ່ຈະບໍ່ສົນໃຈ: ຕົວຢ່າງເຊັ່ນ, ເຫດການທີ່ນໍາໄປສູ່ການຢ່າຮ້າງຈາກພັນລະຍາຂອງຂ້ອຍແລະສິບປີຂອງການຊຶມເສົ້າຫຼັງຈາກນັ້ນ.

ສິ່ງທ້າທາຍແມ່ນການຕໍ່ສູ້ຂອງປະຊາຊົນ, ດ້ວຍຄວາມຮັບຮູ້ຂອງເຂົາເຈົ້າກ່ຽວກັບສິ່ງທີ່ທ່ານສາມາດເຮັດໄດ້ຫຼືເຮັດບໍ່ໄດ້, ສິ່ງທີ່ສໍາຄັນແລະສິ່ງທີ່ບໍ່. ມີຄວາມທ້າທາຍຫຼາຍຢ່າງກ່ຽວກັບຮູບແບບການຂຽນລະຫັດ. ຂ້ອຍຍັງຂຽນລະຫັດຫຼາຍ, ແລະໃນສະໄຫມນັ້ນຂ້ອຍກໍ່ຕ້ອງຊ້າລົງເພາະວ່າຂ້ອຍເຮັດວຽກຂະຫນານຫຼາຍເກີນໄປແລະເຮັດມັນບໍ່ດີ, ແທນທີ່ຈະສຸມໃສ່ຫນຶ່ງ. ຊອກຫາກັບຄືນໄປບ່ອນ, ຂ້າພະເຈົ້າໄດ້ຂຽນລະຫັດເຄິ່ງຫນຶ່ງສໍາລັບຄໍາສັ່ງ Java JIT, ຄໍາສັ່ງ C2. ຕົວແປງລະຫັດທີ່ໄວທີ່ສຸດຕໍ່ໄປຂຽນເຄິ່ງຫນຶ່ງເປັນຊ້າ, ຕໍ່ໄປອີກເຄິ່ງຫນຶ່ງເປັນຊ້າ, ແລະມັນແມ່ນການຫຼຸດລົງຂອງຕົວເລກ. ຄົນທີ XNUMX ໃນແຖວນີ້ແມ່ນຊ້າຫຼາຍ - ມັນເກີດຂຶ້ນສະເໝີ! ຂ້ອຍແຕະລະຫັດຫຼາຍ. ຂ້າພະເຈົ້າໄດ້ເບິ່ງວ່າໃຜຂຽນສິ່ງທີ່, ໂດຍບໍ່ມີຂໍ້ຍົກເວັ້ນ, ຂ້າພະເຈົ້າໄດ້ເບິ່ງລະຫັດຂອງພວກເຂົາ, ທົບທວນຄືນພວກເຂົາແຕ່ລະຄົນ, ແລະຍັງຈະສືບຕໍ່ຂຽນຕົວເອງຫຼາຍກ່ວາພວກເຂົາ. ວິທີການນີ້ໃຊ້ບໍ່ໄດ້ດີຫຼາຍກັບຄົນ. ບາງຄົນບໍ່ມັກອັນນີ້. ແລະເມື່ອພວກເຂົາບໍ່ສາມາດຈັດການກັບມັນໄດ້, ການຮ້ອງທຸກທຸກປະເພດເລີ່ມຕົ້ນ. ຕົວຢ່າງ, ຂ້ອຍເຄີຍຖືກບອກໃຫ້ຢຸດການຂຽນລະຫັດເພາະວ່າຂ້ອຍຂຽນລະຫັດຫຼາຍເກີນໄປແລະມັນເປັນອັນຕະລາຍຕໍ່ທີມງານ, ແລະມັນເບິ່ງຄືວ່າເປັນເລື່ອງຕະຫລົກສໍາລັບຂ້ອຍ: dude, ຖ້າສ່ວນທີ່ເຫຼືອຂອງທີມງານຫາຍໄປແລະຂ້ອຍສືບຕໍ່ຂຽນລະຫັດ, ເຈົ້າ. ຈະສູນເສຍພຽງແຕ່ເຄິ່ງທີມ. ໃນທາງກົງກັນຂ້າມ, ຖ້າຂ້ອຍສືບຕໍ່ຂຽນລະຫັດແລະເຈົ້າສູນເສຍທີມງານເຄິ່ງຫນຶ່ງ, ມັນເບິ່ງຄືວ່າການຈັດການທີ່ບໍ່ດີຫຼາຍ. ຂ້ອຍບໍ່ເຄີຍຄິດກ່ຽວກັບມັນແທ້ໆ, ບໍ່ເຄີຍເວົ້າກ່ຽວກັບມັນ, ແຕ່ມັນຍັງຢູ່ໃນຫົວຂອງຂ້ອຍ. ຄວາມ​ຄິດ​ໄດ້​ຫວັ່ນ​ໄຫວ​ຢູ່​ໃນ​ໃຈ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ: “ທ່ານ​ທັງ​ຫມົດ​ແມ່ນ​ທ່ານ​ກໍາ​ລັງ​ຫຼິ້ນ​ໃຫ້​ຂ້າ​ພະ​ເຈົ້າ?” ດັ່ງນັ້ນ, ບັນຫາໃຫຍ່ທີ່ສຸດແມ່ນຂ້ອຍແລະຄວາມສໍາພັນຂອງຂ້ອຍກັບຄົນ. ຕອນນີ້ຂ້ອຍເຂົ້າໃຈຕົວເອງດີຂຶ້ນຫຼາຍ, ຂ້ອຍເປັນຫົວຫນ້າທີມສໍາລັບນັກຂຽນໂປລແກລມເປັນເວລາດົນນານ, ແລະຕອນນີ້ຂ້ອຍບອກຄົນໂດຍກົງວ່າ: ເຈົ້າຮູ້, ຂ້ອຍແມ່ນຂ້ອຍ, ແລະເຈົ້າຈະຕ້ອງຈັດການກັບຂ້ອຍ - ມັນບໍ່ເປັນຫຍັງຖ້າຂ້ອຍຢືນຢູ່. ທີ່ນີ້? ແລະເມື່ອພວກເຂົາເລີ່ມຈັດການກັບມັນ, ທຸກສິ່ງທຸກຢ່າງກໍ່ເຮັດວຽກ. ແທ້ຈິງແລ້ວ, ຂ້ອຍບໍ່ແມ່ນຄົນບໍ່ດີຫລືດີ, ຂ້ອຍບໍ່ມີເຈດຕະນາທີ່ບໍ່ດີຫຼືຄວາມປາຖະຫນາທີ່ເຫັນແກ່ຕົວ, ມັນເປັນພຽງແຕ່ຄວາມສໍາຄັນຂອງຂ້ອຍ, ແລະຂ້ອຍຈໍາເປັນຕ້ອງຢູ່ກັບມັນຢ່າງໃດກໍ່ຕາມ.

Andrei: ເມື່ອບໍ່ດົນມານີ້ ທຸກຄົນເລີ່ມເວົ້າກ່ຽວກັບການຮັບຮູ້ຕົນເອງສຳລັບຄົນ introverts, ແລະທັກສະອ່ອນໆໂດຍທົ່ວໄປ. ເຈົ້າສາມາດເວົ້າຫຍັງໄດ້ກ່ຽວກັບເລື່ອງນີ້?

ຜາ: ແມ່ນແລ້ວ, ນັ້ນແມ່ນຄວາມເຂົ້າໃຈ ແລະບົດຮຽນທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ຈາກການຢ່າຮ້າງຈາກເມຍຂອງຂ້ອຍ. ສິ່ງທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ຈາກການຢ່າຮ້າງແມ່ນການເຂົ້າໃຈຕົວເອງ. ນີ້ແມ່ນວິທີທີ່ຂ້ອຍເລີ່ມເຂົ້າໃຈຄົນອື່ນ. ເຂົ້າໃຈວ່າການໂຕ້ຕອບນີ້ເຮັດວຽກແນວໃດ. ນີ້ເຮັດໃຫ້ການຄົ້ນພົບຫນຶ່ງຫຼັງຈາກທີ່ອື່ນ. ມີການຮັບຮູ້ວ່າຂ້ອຍແມ່ນໃຜ ແລະສິ່ງທີ່ຂ້ອຍເປັນຕົວແທນ. ຂ້ອຍກໍາລັງເຮັດຫຍັງ: ບໍ່ວ່າຈະເປັນຂ້ອຍສົນໃຈກັບວຽກ, ຫຼືຂ້ອຍຫຼີກລ່ຽງການຂັດແຍ້ງ, ຫຼືສິ່ງອື່ນ - ແລະການຮັບຮູ້ຕົນເອງໃນລະດັບນີ້ກໍ່ຊ່ວຍຄວບຄຸມຕົວເອງ. ຫຼັງຈາກນີ້, ທຸກສິ່ງທຸກຢ່າງຈະງ່າຍຂຶ້ນຫຼາຍ. ສິ່ງຫນຶ່ງທີ່ຂ້ອຍຄົ້ນພົບບໍ່ພຽງແຕ່ຢູ່ໃນຕົວຂ້ອຍເອງ, ແຕ່ຍັງຢູ່ໃນນັກຂຽນໂປລແກລມອື່ນໆແມ່ນຄວາມບໍ່ສາມາດເວົ້າຄໍາເວົ້າໃນເວລາທີ່ທ່ານຢູ່ໃນສະພາບຂອງຄວາມກົດດັນທາງດ້ານຈິດໃຈ. ຕົວຢ່າງ, ທ່ານກໍາລັງນັ່ງຢູ່ບ່ອນນັ້ນ, ຢູ່ໃນສະຖານະການໄຫຼເຂົ້າ, ແລະຫຼັງຈາກນັ້ນພວກເຂົາມາແລ່ນໄປຫາທ່ານແລະເລີ່ມຮ້ອງອອກມາໃນຄວາມວຸ້ນວາຍວ່າມີບາງສິ່ງບາງຢ່າງແຕກຫັກແລະຕອນນີ້ມາດຕະການຮ້າຍແຮງຈະຖືກປະຕິບັດຕໍ່ທ່ານ. ແລະທ່ານບໍ່ສາມາດເວົ້າຄໍາເວົ້າໄດ້ເພາະວ່າທ່ານຢູ່ໃນສະພາບຂອງຄວາມກົດດັນທາງດ້ານຈິດໃຈ. ຄວາມ​ຮູ້​ທີ່​ໄດ້​ມາ​ເຮັດ​ໃຫ້​ທ່ານ​ກະ​ກຽມ​ສໍາ​ລັບ​ປັດ​ຈຸ​ບັນ​ນີ້​, ຄວາມ​ຢູ່​ລອດ​ແລະ​ກ້າວ​ໄປ​ສູ່​ການ​ແຜນ retreat​, ຫຼັງ​ຈາກ​ນັ້ນ​ທ່ານ​ສາ​ມາດ​ເຮັດ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​. ດັ່ງນັ້ນແມ່ນແລ້ວ, ເມື່ອທ່ານເລີ່ມຮັບຮູ້ວິທີການເຮັດວຽກທັງຫມົດ, ມັນເປັນເຫດການທີ່ປ່ຽນແປງຊີວິດອັນໃຫຍ່ຫຼວງ. 
ຂ້ອຍເອງບໍ່ສາມາດຊອກຫາຄໍາທີ່ຖືກຕ້ອງ, ແຕ່ຂ້ອຍຈື່ລໍາດັບຂອງການກະທໍາ. ຈຸດແມ່ນວ່າຕິກິຣິຍານີ້ແມ່ນຫຼາຍທາງດ້ານຮ່າງກາຍເປັນຄໍາເວົ້າ, ແລະທ່ານຕ້ອງການພື້ນທີ່. ຊ່ອງດັ່ງກ່າວ, ໃນຄວາມຮູ້ສຶກ Zen. ນີ້ແມ່ນສິ່ງທີ່ຕ້ອງໄດ້ຮັບການອະທິບາຍ, ແລະຫຼັງຈາກນັ້ນທັນທີທັນໃດກ້າວຫລີກໄປທາງຫນຶ່ງ - ອອກຈາກທາງຮ່າງກາຍຢ່າງດຽວ. ເມື່ອຂ້ອຍມິດງຽບດ້ວຍວາຈາ, ຂ້ອຍສາມາດປະມວນຜົນສະຖານະການໄດ້ດ້ວຍອາລົມ. ໃນຂະນະທີ່ adrenaline ມາຮອດສະຫມອງຂອງທ່ານ, ປ່ຽນທ່ານເຂົ້າໄປໃນຮູບແບບການຕໍ່ສູ້ຫຼືການບິນ, ທ່ານບໍ່ສາມາດເວົ້າຫຍັງໄດ້, ບໍ່ - ຕອນນີ້ເຈົ້າເປັນຄົນໂງ່, ເປັນວິສະວະກອນ whipping, ບໍ່ສາມາດຕອບສະຫນອງທີ່ເຫມາະສົມຫຼືແມ້ກະທັ້ງຢຸດການໂຈມຕີ, ແລະຜູ້ໂຈມຕີແມ່ນບໍ່ເສຍຄ່າ. ເພື່ອ​ໂຈມ​ຕີ​ອີກ​ເທື່ອ​ຫນຶ່ງ​. ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງກາຍເປັນຕົວທ່ານເອງ, ຄວບຄຸມຄືນ, ອອກຈາກໂຫມດ "ການຕໍ່ສູ້ຫຼືການບິນ".

ແລະສໍາລັບການນີ້ພວກເຮົາຕ້ອງການຊ່ອງປາກເວົ້າ. ພຽງແຕ່ພື້ນທີ່ຫວ່າງ. ຖ້າເຈົ້າເວົ້າຫຍັງໝົດ, ເຈົ້າສາມາດເວົ້າແບບນັ້ນໄດ້ຢ່າງແນ່ນອນ, ແລ້ວໄປຊອກຫາ “ພື້ນທີ່” ໃຫ້ຕົວເອງແທ້ໆ: ໄປຍ່າງຫຼິ້ນໃນສວນສາທາລະນະ, ລັອກຕົວເອງໃນອາບນໍ້າ - ມັນບໍ່ສໍາຄັນ. ສິ່ງທີ່ ສຳ ຄັນແມ່ນການຢຸດຊົ່ວຄາວຈາກສະຖານະການນັ້ນ. ທັນ​ທີ​ທີ່​ທ່ານ​ປິດ​ສໍາ​ລັບ​ຢ່າງ​ຫນ້ອຍ​ສອງ​ສາມ​ວິ​ນາ​ທີ​, ການ​ຄວບ​ຄຸມ​ຜົນ​ຕອບ​ແທນ​, ທ່ານ​ຈະ​ເລີ່ມ​ຕົ້ນ​ທີ່​ຈະ​ຄິດ soberly​. "ໂອ້, ຂ້ອຍບໍ່ແມ່ນຄົນໂງ່, ຂ້ອຍບໍ່ເຮັດສິ່ງທີ່ໂງ່, ຂ້ອຍເປັນຄົນທີ່ມີປະໂຫຍດຫຼາຍ." ເມື່ອເຈົ້າສາມາດໂນ້ມນ້າວຕົວເອງໄດ້, ມັນເຖິງເວລາແລ້ວທີ່ຈະກ້າວໄປສູ່ຂັ້ນຕອນຕໍ່ໄປ: ເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນ. ເຈົ້າຖືກໂຈມຕີ, ການໂຈມຕີມາຈາກບ່ອນທີ່ທ່ານບໍ່ຄາດຄິດ, ມັນເປັນການຖົກຖຽງທີ່ບໍ່ຊື່ສັດ, ໂຫດຮ້າຍ. ນີ້ແມ່ນບໍ່ດີ. ຂັ້ນຕອນຕໍ່ໄປແມ່ນເພື່ອເຂົ້າໃຈວ່າເປັນຫຍັງຜູ້ໂຈມຕີຕ້ອງການນີ້. ແທ້, ເປັນຫຍັງ? ອາດ​ເປັນ​ຍ້ອນ​ວ່າ​ຕົນ​ເອງ​ແມ່ນ furious? ເປັນຫຍັງລາວຈຶ່ງເປັນບ້າ? ຍົກ​ຕົວ​ຢ່າງ, ຍ້ອນ​ວ່າ​ລາວ​ໄດ້​ເຮັດ​ໃຫ້​ຕົນ​ເອງ​ບໍ່​ສາ​ມາດ​ຮັບ​ຜິດ​ຊອບ​? ນີ້ແມ່ນວິທີທີ່ຈະຈັດການສະຖານະການທັງຫມົດຢ່າງລະມັດລະວັງ. ແຕ່ນີ້ຮຽກຮ້ອງໃຫ້ມີຫ້ອງສໍາລັບການ maneuver, ຊ່ອງປາກເວົ້າ. ຂັ້ນຕອນທໍາອິດແມ່ນການທໍາລາຍການຕິດຕໍ່ທາງປາກ. ຫຼີກເວັ້ນການສົນທະນາກັບຄໍາສັບຕ່າງໆ. ຍົກເລີກມັນ, ຍ່າງຫນີໄວເທົ່າທີ່ຈະໄວໄດ້. ຖ້າມັນເປັນການສົນທະນາທາງໂທລະສັບ, ພຽງແຕ່ວາງສາຍ - ນີ້ແມ່ນທັກສະທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ຈາກການສື່ສານກັບອະດີດພັນລະຍາຂອງຂ້ອຍ. ຖ້າການສົນທະນາບໍ່ດີ, ພຽງແຕ່ເວົ້າວ່າ "ສະບາຍດີ" ແລະວາງສາຍ. ຈາກອີກດ້ານຫນຶ່ງຂອງໂທລະສັບ: "blah blah blah", ເຈົ້າຕອບວ່າ: "ແມ່ນແລ້ວ, ສະບາຍດີ!" ແລະວາງສາຍ. ທ່ານພຽງແຕ່ສິ້ນສຸດການສົນທະນາ. ຫ້ານາທີຕໍ່ມາ, ເມື່ອຄວາມສາມາດໃນການຄິດຢ່າງມີສະຕິກັບຄືນມາຫາເຈົ້າ, ເຈົ້າໄດ້ເຢັນລົງເລັກນ້ອຍ, ມັນເປັນໄປໄດ້ທີ່ຈະຄິດກ່ຽວກັບທຸກສິ່ງທຸກຢ່າງ, ສິ່ງທີ່ເກີດຂຶ້ນແລະສິ່ງທີ່ຈະເກີດຂຶ້ນຕໍ່ໄປ. ແລະເລີ່ມຕົ້ນສ້າງການຕອບໂຕ້ທີ່ຄິດ, ແທນທີ່ຈະພຽງແຕ່ຕອບສະຫນອງຄວາມຮູ້ສຶກ. ສຳ ລັບຂ້ອຍ, ຄວາມກ້າວ ໜ້າ ໃນການຮັບຮູ້ຕົນເອງແມ່ນຄວາມຈິງທີ່ວ່າໃນກໍລະນີຂອງຄວາມກົດດັນທາງອາລົມຂ້ອຍບໍ່ສາມາດເວົ້າໄດ້. ການອອກຈາກລັດນີ້, ຄິດແລະວາງແຜນວິທີການຕອບສະຫນອງແລະຊົດເຊີຍບັນຫາ - ເຫຼົ່ານີ້ແມ່ນຂັ້ນຕອນທີ່ຖືກຕ້ອງໃນກໍລະນີທີ່ທ່ານບໍ່ສາມາດເວົ້າໄດ້. ວິທີທີ່ງ່າຍທີ່ສຸດຄືການແລ່ນຫນີຈາກສະຖານະການທີ່ຄວາມກົດດັນທາງອາລົມ manifests ຕົວຂອງມັນເອງແລະພຽງແຕ່ຢຸດເຊົາການມີສ່ວນຮ່ວມໃນຄວາມກົດດັນນີ້. ຫຼັງຈາກນັ້ນ, ເຈົ້າສາມາດຄິດໄດ້, ເມື່ອເຈົ້າຄິດໄດ້, ເຈົ້າກາຍເປັນສາມາດເວົ້າ, ແລະອື່ນໆ.

ໂດຍວິທີທາງການ, ໃນສານ, ທະນາຍຄວາມຝ່າຍຄ້ານພະຍາຍາມເຮັດສິ່ງນີ້ກັບທ່ານ - ດຽວນີ້ມັນຈະແຈ້ງວ່າເປັນຫຍັງ. ຍ້ອນວ່າລາວມີຄວາມສາມາດທີ່ຈະສະກັດກັ້ນທ່ານໃນສະຖານະການດັ່ງກ່າວທີ່ທ່ານບໍ່ສາມາດອອກສຽງຊື່ຂອງເຈົ້າ, ຕົວຢ່າງ. ໃນຄວາມຫມາຍທີ່ແທ້ຈິງ, ເຈົ້າຈະບໍ່ສາມາດເວົ້າໄດ້. ຖ້າເຫດການນີ້ເກີດຂຶ້ນກັບເຈົ້າ, ແລະຖ້າທ່ານຮູ້ວ່າເຈົ້າຈະພົບເຫັນຕົວເອງໃນສະຖານທີ່ທີ່ມີການສູ້ຮົບທາງວາຈາ, ຢູ່ໃນສະຖານທີ່ຄ້າຍຄືສານ, ເຈົ້າສາມາດມາກັບທະນາຍຄວາມຂອງເຈົ້າ. ທະ​ນາຍ​ຄວາມ​ຈະ​ຢືນ​ຂຶ້ນ​ສໍາ​ລັບ​ທ່ານ​ແລະ​ຢຸດ​ເຊົາ​ການ​ໂຈມ​ຕີ​ທາງ​ປາກ​ເວົ້າ​, ແລະ​ຈະ​ເຮັດ​ມັນ​ໃນ​ທາງ​ດ້ານ​ກົດ​ຫມາຍ​ຢ່າງ​ສົມ​ບູນ​, ແລະ​ຊ່ອງ Zen ທີ່​ສູນ​ເສຍ​ໄປ​ຈະ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ທ່ານ​. ຕົວຢ່າງ, ຂ້ອຍຕ້ອງໂທຫາຄອບຄົວຂອງຂ້ອຍສອງສາມເທື່ອ, ຜູ້ພິພາກສາແມ່ນຂ້ອນຂ້າງເປັນມິດກັບເລື່ອງນີ້, ແຕ່ທະນາຍຄວາມຝ່າຍຄ້ານໄດ້ຮ້ອງແລະຮ້ອງໃສ່ຂ້ອຍ, ຂ້ອຍບໍ່ສາມາດເວົ້າໄດ້ໃນຂອບເຂດ. ໃນກໍລະນີເຫຼົ່ານີ້, ການນໍາໃຊ້ຜູ້ໄກ່ເກ່ຍເຮັດວຽກທີ່ດີທີ່ສຸດສໍາລັບຂ້ອຍ. ຜູ້ໄກ່ເກ່ຍຢຸດຄວາມກົດດັນທັງ ໝົດ ນີ້ທີ່ ກຳ ລັງຖອກໃສ່ເຈົ້າໃນກະແສຢ່າງຕໍ່ເນື່ອງ, ເຈົ້າຊອກຫາພື້ນທີ່ Zen ທີ່ ຈຳ ເປັນ, ແລະມີຄວາມສາມາດໃນການເວົ້າຄືນ. ນີ້ແມ່ນຂົງເຂດຄວາມຮູ້ທັງຫມົດທີ່ມີຫຼາຍທີ່ຈະສຶກສາ, ຫຼາຍທີ່ຈະຄົ້ນພົບພາຍໃນຕົວທ່ານເອງ, ແລະທັງຫມົດນີ້ກາຍເປັນການຕັດສິນໃຈຍຸດທະສາດລະດັບສູງທີ່ແຕກຕ່າງກັນສໍາລັບຄົນທີ່ແຕກຕ່າງກັນ. ບາງຄົນບໍ່ມີບັນຫາທີ່ອະທິບາຍຂ້າງເທິງ, ປົກກະຕິແລ້ວ, ຄົນທີ່ເປັນນັກຂາຍມືອາຊີບບໍ່ມີພວກມັນ. ຄົນເຫຼົ່ານີ້ທັງຫມົດທີ່ເຮັດຊີວິດຂອງເຂົາເຈົ້າດ້ວຍຄໍາເວົ້າ - ນັກຮ້ອງທີ່ມີຊື່ສຽງ, ນັກກະວີ, ຜູ້ນໍາທາງສາສະຫນາແລະນັກການເມືອງ, ພວກເຂົາສະເຫມີມີບາງສິ່ງບາງຢ່າງທີ່ຈະເວົ້າ. ພວກເຂົາບໍ່ມີບັນຫາດັ່ງກ່າວ, ແຕ່ຂ້ອຍເຮັດ.

Andrei: ມັນແມ່ນ ... ບໍ່ໄດ້ຄາດຫວັງ. ດີຫຼາຍ, ພວກເຮົາໄດ້ລົມກັນຫຼາຍແລ້ວ ແລະເຖິງເວລາແລ້ວທີ່ຈະສິ້ນສຸດການສໍາພາດນີ້. ພວກ​ເຮົາ​ຈະ​ໄດ້​ພົບ​ປະ​ກັນ​ຢູ່​ທີ່​ກອງ​ປະຊຸມ​ຢ່າງ​ແນ່ນອນ​ແລະ​ຈະ​ສາມາດ​ສືບ​ຕໍ່​ສົນທະນາ​ກັນ​ໄດ້. ແລ້ວພົບກັນທີ່ Hydra!

ທ່ານສາມາດສືບຕໍ່ການສົນທະນາຂອງທ່ານກັບ Cliff ໃນກອງປະຊຸມ Hydra 2019, ເຊິ່ງຈະຈັດຂຶ້ນໃນວັນທີ 11-12 ກໍລະກົດ 2019 ທີ່ເຊນປີເຕີສເບີກ. ລາວຈະມາພ້ອມກັບບົດລາຍງານ "ປະສົບການການເຮັດທຸລະກໍາຂອງຮາດແວ Azul". ປີ້ສາມາດຊື້ໄດ້ ຢູ່ໃນເວັບໄຊທ໌ທາງການ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com