क्लिफ क्लिक - क्रैटस के सीटीओ (प्रक्रिया में सुधार के लिए IoT सेंसर), कई सफल निकासों के साथ कई स्टार्टअप (रॉकेट रियलटाइम स्कूल, न्यूरेंसिक और H2O.ai सहित) के संस्थापक और सह-संस्थापक। क्लिफ़ ने अपना पहला कंपाइलर 15 साल की उम्र में लिखा था (टीआरएस ज़ेड-80 के लिए पास्कल)! उन्हें जावा (सी ऑफ नोड्स आईआर) में सी2 पर उनके काम के लिए जाना जाता है। इस कंपाइलर ने दुनिया को दिखाया कि JIT उच्च गुणवत्ता वाले कोड का उत्पादन कर सकता है, जो जावा के मुख्य आधुनिक सॉफ्टवेयर प्लेटफार्मों में से एक के रूप में उभरने के कारकों में से एक था। तब क्लिफ ने अज़ुल सिस्टम्स को शुद्ध जावा सॉफ्टवेयर के साथ 864-कोर मेनफ्रेम बनाने में मदद की, जो 500 मिलीसेकंड के भीतर 10-गीगाबाइट ढेर पर जीसी पॉज़ का समर्थन करता था। सामान्य तौर पर, क्लिफ जेवीएम के सभी पहलुओं पर काम करने में कामयाब रहा।

 
यह हैब्रापोस्ट क्लिफ के साथ एक बेहतरीन साक्षात्कार है। हम निम्नलिखित विषयों पर बात करेंगे:

• निम्न-स्तरीय अनुकूलन में संक्रमण
• बड़ी रिफैक्टरिंग कैसे करें
• लागत मॉडल
• निम्न-स्तरीय अनुकूलन प्रशिक्षण
• प्रदर्शन सुधार के व्यावहारिक उदाहरण
• अपनी खुद की प्रोग्रामिंग भाषा क्यों बनाएं?
• प्रदर्शन इंजीनियर कैरियर
• तकनीकी चुनौतियाँ
• रजिस्टर आवंटन और मल्टी-कोर के बारे में थोड़ा
• जीवन की सबसे बड़ी चुनौती

साक्षात्कार किसके द्वारा आयोजित किया जाता है:

• एंड्री सैटरिन अमेज़न वेब सर्विसेज से. अपने करियर में, वह पूरी तरह से अलग परियोजनाओं में काम करने में कामयाब रहे: उन्होंने यांडेक्स में न्यूएसक्यूएल वितरित डेटाबेस, कैस्परस्की लैब में क्लाउड डिटेक्शन सिस्टम, मेल.आरयू में एक मल्टीप्लेयर गेम और ड्यूश बैंक में विदेशी मुद्रा कीमतों की गणना के लिए एक सेवा का परीक्षण किया। बड़े पैमाने पर बैकएंड और वितरित सिस्टम के परीक्षण में रुचि।
• व्लादिमीर सीतनिकोव नेटक्रैकर से. नेटक्रैकर ओएस के प्रदर्शन और स्केलेबिलिटी पर दस साल का काम, नेटवर्क और नेटवर्क उपकरण प्रबंधन प्रक्रियाओं को स्वचालित करने के लिए दूरसंचार ऑपरेटरों द्वारा उपयोग किया जाने वाला सॉफ्टवेयर। जावा और ओरेकल डेटाबेस प्रदर्शन मुद्दों में रुचि। आधिकारिक PostgreSQL JDBC ड्राइवर में एक दर्जन से अधिक प्रदर्शन सुधारों के लेखक।

निम्न-स्तरीय अनुकूलन में संक्रमण

एंड्रयू: आप जेआईटी संकलन, जावा और सामान्य रूप से प्रदर्शन कार्य की दुनिया में एक बड़ा नाम हैं, है ना? 

क्लिफ: मै सोने के लिए जाना चाहता हूँ!

एंड्रयू: आइए प्रदर्शन कार्य के बारे में कुछ सामान्य प्रश्नों से शुरुआत करें। सीपीयू स्तर पर काम करने जैसे उच्च-स्तरीय और निम्न-स्तरीय अनुकूलन के बीच चयन के बारे में आप क्या सोचते हैं?

क्लिफ: हाँ, यहाँ सब कुछ सरल है। सबसे तेज़ कोड वह है जो कभी नहीं चलता। इसलिए, आपको हमेशा उच्च स्तर से शुरुआत करने, एल्गोरिदम पर काम करने की आवश्यकता है। एक बेहतर O अंकन बदतर O अंकन को हरा देगा, जब तक कि कुछ पर्याप्त बड़े स्थिरांक हस्तक्षेप न करें। निचले स्तर की बातें सबसे आखिर में चलती हैं. आमतौर पर, यदि आपने अपने शेष स्टैक को पर्याप्त रूप से अनुकूलित कर लिया है और अभी भी कुछ दिलचस्प चीजें बची हैं, तो यह निम्न स्तर है। लेकिन ऊंचे स्तर से शुरुआत कैसे करें? आप कैसे जानते हैं कि पर्याप्त उच्च-स्तरीय कार्य किया जा चुका है? खैर... बिलकुल नहीं. कोई तैयार व्यंजन नहीं हैं. आपको समस्या को समझने की जरूरत है, तय करें कि आप क्या करने जा रहे हैं (ताकि भविष्य में अनावश्यक कदम न उठाएं) और फिर आप प्रोफाइलर को उजागर कर सकते हैं, जो कुछ उपयोगी कह सकता है। कुछ बिंदु पर, आपको स्वयं एहसास होता है कि आपने अनावश्यक चीज़ों से छुटकारा पा लिया है और अब कुछ निम्न-स्तरीय फ़ाइन ट्यूनिंग करने का समय आ गया है। यह निश्चित ही एक विशेष प्रकार की कला है। ऐसे बहुत से लोग हैं जो अनावश्यक चीजें तो कर रहे हैं, लेकिन इतनी तेजी से आगे बढ़ रहे हैं कि उनके पास उत्पादकता के बारे में चिंता करने का समय ही नहीं है। लेकिन यह तब तक है जब तक सवाल दो टूक न उठे. आमतौर पर 99% समय किसी को इसकी परवाह नहीं होती कि मैं क्या करता हूँ, जब तक कि उस क्षण तक नहीं जब कोई महत्वपूर्ण चीज़ महत्वपूर्ण रास्ते पर आ जाती है जिसकी किसी को परवाह नहीं होती। और यहां हर कोई आपको इस बात पर परेशान करना शुरू कर देता है कि "यह शुरू से ही पूरी तरह से काम क्यों नहीं करता है।" सामान्य तौर पर, प्रदर्शन में सुधार करने के लिए हमेशा कुछ न कुछ होता है। लेकिन 99% मामलों में आपके पास कोई लीड नहीं होता! आप बस कुछ काम करने की कोशिश कर रहे हैं और इस प्रक्रिया में आपको पता चलता है कि क्या महत्वपूर्ण है। आप पहले से कभी नहीं जान सकते कि इस टुकड़े को परफेक्ट होने की जरूरत है, इसलिए, वास्तव में, आपको हर चीज में परफेक्ट होना होगा। लेकिन यह असंभव है और आप ऐसा नहीं करते. हमेशा बहुत सारी चीज़ें ठीक करनी होती हैं - और यह पूरी तरह से सामान्य है।

बड़ी रिफैक्टरिंग कैसे करें

एंड्रयू: आप किसी प्रदर्शन पर कैसे काम करते हैं? यह एक क्रॉस-कटिंग समस्या है. उदाहरण के लिए, क्या आपको कभी उन समस्याओं पर काम करना पड़ा है जो कई मौजूदा कार्यक्षमताओं के अंतर्विरोध से उत्पन्न होती हैं?

क्लिफ: मैं इससे बचने की कोशिश करता हूं. अगर मुझे पता है कि प्रदर्शन एक मुद्दा होगा, तो मैं कोडिंग शुरू करने से पहले इसके बारे में सोचता हूं, खासकर डेटा संरचनाओं के साथ। लेकिन अक्सर आपको यह सब बहुत बाद में पता चलता है। और फिर आपको चरम उपाय करने होंगे और वह करना होगा जिसे मैं "फिर से लिखना और जीतना" कहता हूं: आपको एक काफी बड़ा टुकड़ा लेने की जरूरत है। प्रदर्शन समस्याओं या किसी अन्य चीज़ के कारण कुछ कोड को अभी भी फिर से लिखना होगा। कोड को दोबारा लिखने का कारण जो भी हो, छोटे टुकड़े की तुलना में बड़े टुकड़े को दोबारा लिखना लगभग हमेशा बेहतर होता है। इस समय, हर कोई डर से कांपने लगता है: "हे भगवान, आप इतना कोड नहीं छू सकते!" लेकिन वास्तव में, यह दृष्टिकोण लगभग हमेशा बेहतर काम करता है। आपको तुरंत एक बड़ी समस्या लेने की ज़रूरत है, उसके चारों ओर एक बड़ा घेरा बनाएं और कहें: मैं घेरे के अंदर सब कुछ फिर से लिखूंगा। बॉर्डर इसके अंदर की सामग्री से बहुत छोटा है जिसे बदलने की आवश्यकता है। और अगर सीमाओं का ऐसा चित्रण आपको अंदर का काम पूरी तरह से करने की अनुमति देता है, तो आपके हाथ स्वतंत्र हैं, आप जो चाहते हैं वह करें। एक बार जब आप समस्या को समझ जाते हैं, तो पुनर्लेखन प्रक्रिया बहुत आसान हो जाती है, इसलिए एक बड़ा प्रयास करें!
उसी समय, जब आप एक बड़ा पुनर्लेखन करते हैं और महसूस करते हैं कि प्रदर्शन एक मुद्दा बनने वाला है, तो आप तुरंत इसके बारे में चिंता करना शुरू कर सकते हैं। यह आम तौर पर सरल चीजों में बदल जाता है जैसे "डेटा की प्रतिलिपि न बनाएं, डेटा को यथासंभव सरलता से प्रबंधित करें, इसे छोटा करें।" बड़े पुनर्लेखन में, प्रदर्शन को बेहतर बनाने के मानक तरीके होते हैं। और वे लगभग हमेशा डेटा के इर्द-गिर्द घूमते हैं।

लागत मॉडल

एंड्रयू: पॉडकास्ट में से एक में आपने उत्पादकता के संदर्भ में लागत मॉडल के बारे में बात की थी। क्या आप बता सकते हैं कि इससे आपका क्या मतलब है?

क्लिफ: निश्चित रूप से। मेरा जन्म ऐसे युग में हुआ था जब प्रोसेसर का प्रदर्शन बेहद महत्वपूर्ण था। और यह युग फिर से लौट आता है - भाग्य विडम्बना रहित नहीं है। मैंने आठ-बिट मशीनों के दिनों में रहना शुरू कर दिया; मेरा पहला कंप्यूटर 256 बाइट्स के साथ काम करता था। बिल्कुल बाइट्स. सब कुछ बहुत छोटा था. निर्देशों को गिनना पड़ा, और जैसे-जैसे हमने प्रोग्रामिंग भाषा स्टैक पर आगे बढ़ना शुरू किया, भाषाओं ने अधिक से अधिक काम करना शुरू कर दिया। असेंबलर था, फिर बेसिक, फिर सी, और सी ने रजिस्टर आवंटन और निर्देश चयन जैसे कई विवरणों का ध्यान रखा। लेकिन वहां सब कुछ बिल्कुल स्पष्ट था, और अगर मैंने एक चर के उदाहरण के लिए एक संकेतक बनाया, तो मुझे लोड मिलेगा, और इस निर्देश की लागत ज्ञात होगी। हार्डवेयर एक निश्चित संख्या में मशीन चक्रों का उत्पादन करता है, इसलिए विभिन्न चीजों की निष्पादन गति की गणना उन सभी निर्देशों को जोड़कर की जा सकती है जिन्हें आप चलाने जा रहे हैं। प्रत्येक तुलना/परीक्षण/शाखा/कॉल/लोड/स्टोर को जोड़ा जा सकता है और कहा जा सकता है: यह आपके लिए निष्पादन का समय है। प्रदर्शन में सुधार पर काम करते समय, आप निश्चित रूप से इस बात पर ध्यान देंगे कि कौन सी संख्याएँ छोटे गर्म चक्रों से मेल खाती हैं। 
लेकिन जैसे ही आप जावा, पायथन और इसी तरह की चीजों पर स्विच करते हैं, आप बहुत जल्दी निम्न-स्तरीय हार्डवेयर से दूर चले जाते हैं। जावा में गेटर को कॉल करने की लागत क्या है? यदि हॉटस्पॉट में JIT सही है रेखांकित, यह लोड होगा, लेकिन अगर उसने ऐसा नहीं किया, तो यह एक फ़ंक्शन कॉल होगा। चूंकि कॉल हॉट लूप पर है, यह उस लूप में अन्य सभी अनुकूलन को ओवरराइड कर देगा। इसलिए, वास्तविक लागत बहुत अधिक होगी. और आप तुरंत कोड के एक टुकड़े को देखने और यह समझने की क्षमता खो देते हैं कि हमें इसे प्रोसेसर घड़ी की गति, मेमोरी और उपयोग किए गए कैश के संदर्भ में निष्पादित करना चाहिए। यह सब तभी दिलचस्प हो जाता है जब आप वास्तव में प्रदर्शन में उतरते हैं।
अब हम खुद को ऐसी स्थिति में पाते हैं जहां पिछले एक दशक में प्रोसेसर की गति मुश्किल से बढ़ी है। पुराने दिन वापस आ गए! अब आप अच्छे सिंगल-थ्रेडेड प्रदर्शन पर भरोसा नहीं कर सकते। लेकिन अगर आप अचानक समानांतर कंप्यूटिंग में लग जाते हैं, तो यह अविश्वसनीय रूप से कठिन है, हर कोई आपको जेम्स बॉन्ड की तरह देखता है। यहां दस गुना तेजी आमतौर पर उन जगहों पर होती है जहां किसी ने कुछ गड़बड़ कर दी है। समवर्तीता के लिए बहुत अधिक कार्य की आवश्यकता होती है। उस XNUMXx स्पीडअप को प्राप्त करने के लिए, आपको लागत मॉडल को समझने की आवश्यकता है। इसकी लागत क्या और कितनी है? और ऐसा करने के लिए, आपको यह समझने की ज़रूरत है कि जीभ अंतर्निहित हार्डवेयर पर कैसे फिट बैठती है।
मार्टिन थॉम्पसन ने अपने ब्लॉग के लिए एक बेहतरीन शब्द चुना यांत्रिक सहानुभूति! आपको यह समझने की आवश्यकता है कि हार्डवेयर क्या करने जा रहा है, यह वास्तव में यह कैसे करेगा, और सबसे पहले यह जो करता है वह क्यों करता है। इसका उपयोग करके, निर्देशों की गिनती शुरू करना और यह पता लगाना काफी आसान है कि निष्पादन का समय कहां जा रहा है। यदि आपके पास उचित प्रशिक्षण नहीं है, तो आप बस एक अंधेरे कमरे में एक काली बिल्ली की तलाश कर रहे हैं। मैं ऐसे लोगों को हर समय प्रदर्शन को अनुकूलित करते हुए देखता हूं जिन्हें पता ही नहीं होता कि वे क्या कर रहे हैं। वे बहुत कष्ट सहते हैं और अधिक प्रगति नहीं कर पाते हैं। और जब मैं कोड का एक ही टुकड़ा लेता हूं, कुछ छोटे हैक करता हूं और पांच या दस गुना स्पीडअप प्राप्त करता हूं, तो वे इस प्रकार हैं: ठीक है, यह उचित नहीं है, हम पहले से ही जानते थे कि आप बेहतर थे। अद्भुत। मैं किस बारे में बात कर रहा हूं... लागत मॉडल इस बारे में है कि आप किस प्रकार का कोड लिखते हैं और बड़ी तस्वीर में यह औसतन कितनी तेजी से चलता है।

एंड्रयू: और आप इतनी मात्रा अपने दिमाग में कैसे रख सकते हैं? क्या यह अधिक अनुभव के साथ हासिल किया गया है, या? ऐसा अनुभव कहां से आता है?

क्लिफ: खैर, मुझे अपना अनुभव सबसे आसान तरीके से नहीं मिला। मैंने उन दिनों असेंबली में प्रोग्राम किया था जब आप हर एक निर्देश को समझ सकते थे। यह मूर्खतापूर्ण लगता है, लेकिन तब से Z80 अनुदेश सेट हमेशा मेरे दिमाग में, मेरी स्मृति में बना हुआ है। बात करने के एक मिनट के अंदर मुझे लोगों के नाम याद नहीं रहते, लेकिन मुझे 40 साल पहले लिखा कोड याद आ जाता है। यह अजीब है, यह एक सिंड्रोम जैसा दिखता है"मूर्ख वैज्ञानिक'.

निम्न-स्तरीय अनुकूलन प्रशिक्षण

एंड्रयू: क्या अंदर जाने का कोई आसान तरीका है?

क्लिफ: हां और ना। हम सभी जिस हार्डवेयर का उपयोग करते हैं उसमें समय के साथ बहुत अधिक बदलाव नहीं आया है। आर्म स्मार्टफ़ोन को छोड़कर, हर कोई x86 का उपयोग करता है। यदि आप किसी प्रकार की हार्डकोर एम्बेडिंग नहीं कर रहे हैं, तो आप वही काम कर रहे हैं। ठीक है, अगला. निर्देश भी सदियों से नहीं बदले हैं। आपको विधानसभा में जाकर कुछ लिखना होगा। ज़्यादा तो नहीं, लेकिन समझने के लिए काफ़ी है। आप मुस्कुरा रहे हैं, लेकिन मैं पूरी गंभीरता से बात कर रहा हूं. आपको भाषा और हार्डवेयर के बीच के पत्राचार को समझने की आवश्यकता है। उसके बाद आपको जाकर थोड़ा लिखना होगा और थोड़ी सी खिलौना भाषा के लिए एक छोटा सा खिलौना कंपाइलर बनाना होगा। खिलौने की तरह का मतलब है कि इसे उचित समय में बनाया जाना चाहिए। यह अत्यंत सरल हो सकता है, लेकिन इसमें निर्देश अवश्य उत्पन्न होने चाहिए। एक निर्देश उत्पन्न करने का कार्य आपको उच्च-स्तरीय कोड जो हर कोई लिखता है और हार्डवेयर पर चलने वाले मशीन कोड के बीच पुल के लिए लागत मॉडल को समझने में मदद करेगा। संकलक लिखे जाने के समय यह पत्राचार मस्तिष्क में जला दिया जाएगा। यहां तक ​​कि सबसे सरल संकलक भी. उसके बाद, आप जावा को देखना शुरू कर सकते हैं और यह तथ्य कि इसकी अर्थ संबंधी खाई बहुत गहरी है, और इस पर पुल बनाना कहीं अधिक कठिन है। जावा में, यह समझना अधिक कठिन है कि हमारा पुल अच्छा निकला या ख़राब, किस कारण से यह टूटेगा और किस कारण से नहीं टूटेगा। लेकिन आपको किसी प्रकार के शुरुआती बिंदु की आवश्यकता है जहां आप कोड को देखें और समझें: "हाँ, इस गेटर को हर बार इनलाइन किया जाना चाहिए।" और फिर यह पता चलता है कि कभी-कभी ऐसा होता है, उस स्थिति को छोड़कर जब विधि बहुत बड़ी हो जाती है, और जेआईटी सब कुछ इनलाइन करना शुरू कर देता है। ऐसी जगहों के प्रदर्शन का तुरंत अनुमान लगाया जा सकता है। आम तौर पर गेटर्स अच्छा काम करते हैं, लेकिन फिर आप बड़े हॉट लूप्स को देखते हैं और महसूस करते हैं कि वहां कुछ फ़ंक्शन कॉल तैर रहे हैं जो नहीं जानते कि वे क्या कर रहे हैं। गेटर्स के व्यापक उपयोग के साथ यही समस्या है, उनके इनलाइन न होने का कारण यह है कि यह स्पष्ट नहीं है कि वे गेटर हैं या नहीं। यदि आपके पास बहुत छोटा कोड आधार है, तो आप इसे आसानी से याद रख सकते हैं और फिर कह सकते हैं: यह एक गेटर है, और यह एक सेटर है। एक बड़े कोड बेस में, प्रत्येक फ़ंक्शन का अपना इतिहास होता है, जो सामान्य तौर पर किसी को नहीं पता होता है। प्रोफाइलर का कहना है कि हमने कुछ लूप पर 24% समय खो दिया है और यह समझने के लिए कि यह लूप क्या कर रहा है, हमें प्रत्येक फ़ंक्शन को अंदर देखना होगा। फ़ंक्शन का अध्ययन किए बिना इसे समझना असंभव है, और यह समझने की प्रक्रिया को गंभीर रूप से धीमा कर देता है। इसीलिए मैं गेटर्स और सेटर्स का उपयोग नहीं करता, मैं एक नए स्तर पर पहुंच गया हूं!
लागत मॉडल कहां से प्राप्त करें? खैर, बेशक आप कुछ पढ़ सकते हैं... लेकिन मुझे लगता है कि सबसे अच्छा तरीका अभिनय करना है। एक छोटा कंपाइलर बनाना लागत मॉडल को समझने और उसे अपने दिमाग में फिट करने का सबसे अच्छा तरीका होगा। एक छोटा कंपाइलर जो माइक्रोवेव की प्रोग्रामिंग के लिए उपयुक्त होगा, एक शुरुआती के लिए एक कार्य है। खैर, मेरा मतलब है, यदि आपके पास पहले से ही प्रोग्रामिंग कौशल है, तो यह पर्याप्त होना चाहिए। ये सभी चीजें जैसे एक स्ट्रिंग को पार्स करना जो आपके पास किसी प्रकार की बीजगणितीय अभिव्यक्ति के रूप में है, वहां से गणितीय संचालन के लिए सही क्रम में निर्देश निकालना, रजिस्टरों से सही मान लेना - यह सब एक ही बार में किया जाता है। और जब आप ऐसा करेंगे तो यह आपके मस्तिष्क में अंकित हो जाएगा। मुझे लगता है कि हर कोई जानता है कि कंपाइलर क्या करता है। और इससे लागत मॉडल की समझ मिलेगी.

प्रदर्शन सुधार के व्यावहारिक उदाहरण

एंड्रयू: उत्पादकता पर काम करते समय आपको और क्या ध्यान देना चाहिए?

क्लिफ: डेटा संरचनाएं। वैसे, हाँ, मैंने लंबे समय से इन कक्षाओं को नहीं पढ़ाया है... रॉकेट स्कूल. यह मज़ेदार था, लेकिन इसके लिए बहुत प्रयास की आवश्यकता थी, और मेरे पास भी एक जीवन है! ठीक है। इसलिए, एक बड़ी और दिलचस्प कक्षा में, "आपका प्रदर्शन कहाँ जाता है," मैंने छात्रों को एक उदाहरण दिया: सीएसवी फ़ाइल से ढाई गीगाबाइट फिनटेक डेटा पढ़ा गया और फिर उन्हें बेचे गए उत्पादों की संख्या की गणना करनी थी . नियमित टिक बाज़ार डेटा। 70 के दशक से यूडीपी पैकेट को टेक्स्ट फॉर्मेट में परिवर्तित किया गया। शिकागो मर्केंटाइल एक्सचेंज - मक्खन, मक्का, सोयाबीन जैसी सभी प्रकार की चीजें। इन उत्पादों, लेनदेन की संख्या, धन और वस्तुओं की आवाजाही की औसत मात्रा आदि की गणना करना आवश्यक था। यह बहुत ही सरल व्यापारिक गणित है: उत्पाद कोड ढूंढें (जो हैश तालिका में 1-2 अक्षर है), राशि प्राप्त करें, इसे व्यापार सेट में से एक में जोड़ें, वॉल्यूम जोड़ें, मूल्य जोड़ें और कुछ अन्य चीजें। बहुत ही सरल गणित. खिलौना कार्यान्वयन बहुत सीधा था: सब कुछ एक फ़ाइल में है, मैं फ़ाइल पढ़ता हूं और उसमें आगे बढ़ता हूं, अलग-अलग रिकॉर्ड को जावा स्ट्रिंग्स में विभाजित करता हूं, उनमें आवश्यक चीजों की तलाश करता हूं और ऊपर वर्णित गणित के अनुसार उन्हें जोड़ता हूं। और यह कुछ धीमी गति से काम करता है.

इस दृष्टिकोण के साथ, यह स्पष्ट है कि क्या हो रहा है, और समानांतर कंप्यूटिंग मदद नहीं करेगी, है ना? यह पता चला है कि केवल सही डेटा संरचनाओं को चुनकर प्रदर्शन में पांच गुना वृद्धि हासिल की जा सकती है। और यह अनुभवी प्रोग्रामर को भी आश्चर्यचकित करता है! मेरे विशेष मामले में, चाल यह थी कि आपको हॉट लूप में मेमोरी आवंटन नहीं करना चाहिए। खैर, यह पूरा सच नहीं है, लेकिन सामान्य तौर पर - जब एक्स काफी बड़ा हो तो आपको "एक्स में एक बार" को हाइलाइट नहीं करना चाहिए। जब X ढाई गीगाबाइट है, तो आपको "प्रति अक्षर एक बार", या "प्रति पंक्ति एक बार", या "प्रति फ़ील्ड एक बार", ऐसा कुछ भी आवंटित नहीं करना चाहिए। यहीं समय व्यतीत होता है। यह कैसे काम करता है? कल्पना कीजिए कि मैं कॉल कर रहा हूं String.split() या BufferedReader.readLine(). Readline नेटवर्क पर आए बाइट्स के सेट से एक स्ट्रिंग बनाता है, प्रत्येक लाइन के लिए एक बार, सैकड़ों लाखों लाइनों में से प्रत्येक के लिए। मैं यह पंक्ति लेता हूं, इसका विश्लेषण करता हूं और इसे फेंक देता हूं। मैं इसे क्यों फेंक रहा हूं - ठीक है, मैंने इसे पहले ही संसाधित कर लिया है, बस इतना ही। तो, इन 2.7G से पढ़े गए प्रत्येक बाइट के लिए, पंक्ति में दो अक्षर लिखे जाएंगे, यानी, पहले से ही 5.4G, और मुझे आगे किसी चीज़ के लिए उनकी आवश्यकता नहीं है, इसलिए उन्हें फेंक दिया जाता है। यदि आप मेमोरी बैंडविड्थ को देखें, तो हम 2.7G लोड करते हैं जो प्रोसेसर में मेमोरी और मेमोरी बस के माध्यम से जाता है, और फिर मेमोरी में पड़ी लाइन पर दोगुना भेजा जाता है, और प्रत्येक नई लाइन बनने पर यह सब खराब हो जाता है। लेकिन मुझे इसे पढ़ने की ज़रूरत है, हार्डवेयर इसे पढ़ता है, भले ही बाद में सब कुछ ख़राब हो जाए। और मुझे इसे लिखना होगा क्योंकि मैंने एक लाइन बनाई है और कैश भर गया है - कैश 2.7G को समायोजित नहीं कर सकता है। इसलिए, प्रत्येक बाइट के लिए जो मैं पढ़ता हूं, मैं दो और बाइट पढ़ता हूं और दो और बाइट लिखता हूं, और अंत में उनका अनुपात 4:1 होता है - इस अनुपात में हम मेमोरी बैंडविड्थ बर्बाद कर रहे हैं। और फिर यह पता चलता है कि अगर मैं ऐसा करता हूं String.split() - यह आखिरी बार नहीं है जब मैं ऐसा कर रहा हूं, हो सकता है कि अंदर 6-7 फ़ील्ड और हों। तो सीएसवी को पढ़ने और फिर स्ट्रिंग्स को पार्स करने का क्लासिक कोड उस मेमोरी बैंडविड्थ का लगभग 14:1 बर्बाद करता है जो आप वास्तव में चाहते हैं। यदि आप इन चयनों को फेंक देते हैं, तो आप पांच गुना गति प्राप्त कर सकते हैं।

और यह उतना कठिन नहीं है. यदि आप कोड को सही कोण से देखते हैं, तो समस्या का एहसास होने पर यह सब काफी सरल हो जाता है। आपको मेमोरी आवंटित करना पूरी तरह से बंद नहीं करना चाहिए: एकमात्र समस्या यह है कि आप कुछ आवंटित करते हैं और यह तुरंत समाप्त हो जाता है, और साथ ही यह एक महत्वपूर्ण संसाधन को जला देता है, जो इस मामले में मेमोरी बैंडविड्थ है। और इन सबके परिणामस्वरूप उत्पादकता में गिरावट आती है। x86 पर आपको आमतौर पर प्रोसेसर चक्र को सक्रिय रूप से बर्न करने की आवश्यकता होती है, लेकिन यहां आपने सारी मेमोरी बहुत पहले ही बर्न कर दी है। इसका समाधान डिस्चार्ज की मात्रा को कम करना है। 
समस्या का दूसरा भाग यह है कि यदि आप मेमोरी स्ट्राइप खत्म होने पर प्रोफाइलर चलाते हैं, ठीक उसी समय जब ऐसा होता है, तो आप आमतौर पर कैश के वापस आने का इंतजार कर रहे होते हैं क्योंकि यह आपके द्वारा अभी-अभी उत्पन्न किए गए कचरे से भरा होता है, वे सभी लाइनें। इसलिए, प्रत्येक लोड या स्टोर ऑपरेशन धीमा हो जाता है, क्योंकि इससे कैश मिस हो जाता है - पूरा कैश धीमा हो गया है, कचरा निकलने का इंतजार कर रहा है। इसलिए, प्रोफाइलर पूरे लूप में फैला हुआ गर्म यादृच्छिक शोर दिखाएगा - कोड में कोई अलग गर्म निर्देश या स्थान नहीं होगा। केवल शोर. और यदि आप जीसी चक्रों को देखें, तो वे सभी युवा पीढ़ी के और सुपर फास्ट हैं - अधिकतम माइक्रोसेकंड या मिलीसेकंड। आख़िरकार, यह सारी स्मृति तुरंत मर जाती है। आप अरबों गीगाबाइट आवंटित करते हैं, और वह उन्हें काट देता है, और उन्हें काट देता है, और उन्हें फिर से काट देता है। ये सब बहुत जल्दी होता है. यह पता चला है कि सस्ते जीसी चक्र हैं, पूरे चक्र में गर्म शोर है, लेकिन हम 5x स्पीडअप प्राप्त करना चाहते हैं। इस समय, आपके दिमाग में कुछ बंद होना चाहिए और आवाज़ आनी चाहिए: "यह क्यों है?" मेमोरी स्ट्रिप ओवरफ़्लो क्लासिक डिबगर में प्रदर्शित नहीं होता है; आपको हार्डवेयर प्रदर्शन काउंटर डिबगर चलाने और इसे स्वयं और सीधे देखने की आवश्यकता है। लेकिन इन तीन लक्षणों से सीधे तौर पर इसका संदेह नहीं किया जा सकता. तीसरा लक्षण यह है कि जब आप देखते हैं कि आप क्या हाइलाइट करते हैं, तो प्रोफाइलर से पूछें, और वह जवाब देता है: "आपने एक अरब पंक्तियाँ बनाईं, लेकिन जीसी ने मुफ्त में काम किया।" जैसे ही ऐसा होता है, आपको एहसास होता है कि आपने बहुत सारी वस्तुएं बना ली हैं और पूरी स्मृति लेन को जला दिया है। इसका पता लगाने का एक तरीका है, लेकिन यह स्पष्ट नहीं है। 

समस्या डेटा संरचना में है: जो कुछ भी घटित होता है उसके पीछे की संरचना बहुत बड़ी है, यह डिस्क पर 2.7G है, इसलिए इस चीज़ की प्रतिलिपि बनाना बहुत अवांछनीय है - आप इसे तुरंत नेटवर्क बाइट बफर से लोड करना चाहते हैं रजिस्टरों में, ताकि लाइन में आगे-पीछे पांच बार पढ़ना-लिखना न पड़े। दुर्भाग्य से, जावा आपको डिफ़ॉल्ट रूप से जेडीके के हिस्से के रूप में ऐसी लाइब्रेरी नहीं देता है। लेकिन यह मामूली बात है, है ना? अनिवार्य रूप से, ये कोड की 5-10 पंक्तियाँ हैं जिनका उपयोग आपके स्वयं के बफ़र किए गए स्ट्रिंग लोडर को लागू करने के लिए किया जाएगा, जो अंतर्निहित बाइट बफ़र के चारों ओर एक आवरण होने के साथ-साथ स्ट्रिंग क्लास के व्यवहार को दोहराता है। नतीजतन, यह पता चलता है कि आप लगभग स्ट्रिंग्स के साथ काम कर रहे हैं, लेकिन वास्तव में बफर के पॉइंटर्स वहां जा रहे हैं, और कच्चे बाइट्स कहीं भी कॉपी नहीं किए जाते हैं, और इस प्रकार वही बफर बार-बार पुन: उपयोग किए जाते हैं, और ऑपरेटिंग सिस्टम उन चीज़ों को अपने ऊपर लेने में प्रसन्न होता है जिनके लिए इसे डिज़ाइन किया गया है, जैसे इन बाइट बफ़र्स की छिपी हुई डबल-बफ़रिंग, और अब आप अनावश्यक डेटा की अंतहीन धारा के माध्यम से पीस नहीं रहे हैं। वैसे, क्या आप समझते हैं कि जीसी के साथ काम करते समय, यह गारंटी दी जाती है कि प्रत्येक मेमोरी आवंटन अंतिम जीसी चक्र के बाद प्रोसेसर को दिखाई नहीं देगा? इसलिए, यह सब संभवतः कैश में नहीं हो सकता है, और फिर 100% गारंटीशुदा चूक होती है। x86 पर एक पॉइंटर के साथ काम करते समय, मेमोरी से एक रजिस्टर को घटाने में 1-2 क्लॉक चक्र लगते हैं, और जैसे ही ऐसा होता है, आप भुगतान करते हैं, भुगतान करते हैं, भुगतान करते हैं, क्योंकि मेमोरी पूरी तरह से चालू है नौ कैश - और यह मेमोरी आवंटन की लागत है। वास्तविक कीमत।

दूसरे शब्दों में, डेटा संरचनाओं को बदलना सबसे कठिन काम है। और एक बार जब आपको एहसास होता है कि आपने गलत डेटा संरचना चुनी है जो बाद में प्रदर्शन को खराब कर देगी, तो आमतौर पर बहुत काम करना होगा, लेकिन यदि आप ऐसा नहीं करते हैं, तो चीजें खराब हो जाएंगी। सबसे पहले, आपको डेटा संरचनाओं के बारे में सोचने की ज़रूरत है, यह महत्वपूर्ण है। यहां मुख्य लागत मोटे डेटा संरचनाओं पर आती है, जिनका उपयोग "मैंने डेटा संरचना X को डेटा संरचना Y में कॉपी किया है क्योंकि मुझे Y का आकार बेहतर लगता है" की शैली में उपयोग किया जाने लगा है। लेकिन कॉपी ऑपरेशन (जो सस्ता लगता है) वास्तव में मेमोरी बैंडविड्थ को बर्बाद करता है और यहीं सारा बर्बाद निष्पादन समय दफन हो जाता है। यदि मेरे पास JSON की एक विशाल स्ट्रिंग है और मैं इसे POJO या किसी चीज़ के संरचित DOM ट्री में बदलना चाहता हूं, तो उस स्ट्रिंग को पार्स करने और POJO का निर्माण करने का संचालन, और फिर बाद में POJO तक पहुंचने के परिणामस्वरूप अनावश्यक लागत आएगी - यह है सस्ता नहीं। सिवाय इसके कि आप एक स्ट्रिंग के आसपास दौड़ने की तुलना में पीओजेओ के आसपास बहुत अधिक बार दौड़ते हैं। ऑफहैंड, आप इसके बजाय स्ट्रिंग को डिक्रिप्ट करने का प्रयास कर सकते हैं और वहां से केवल वही निकाल सकते हैं जिसकी आपको आवश्यकता है, इसे किसी पीओजेओ में बदले बिना। यदि यह सब उस पथ पर होता है जहां से अधिकतम प्रदर्शन की आवश्यकता होती है, तो आपके लिए कोई पीओजेओ नहीं है, आपको किसी तरह सीधे लाइन में खोदने की आवश्यकता है।

अपनी खुद की प्रोग्रामिंग भाषा क्यों बनाएं?

एंड्रयू: आपने कहा कि लागत मॉडल को समझने के लिए, आपको अपनी छोटी भाषा में लिखना होगा...

क्लिफ: एक भाषा नहीं, बल्कि एक संकलनकर्ता। एक भाषा और एक कंपाइलर दो अलग चीजें हैं। सबसे महत्वपूर्ण अंतर आपके दिमाग में है। 

एंड्रयू: वैसे, जहां तक ​​मुझे पता है, आप अपनी भाषाएं बनाने का प्रयोग कर रहे हैं। किस लिए?

क्लिफ: क्योंकि में कर सकता हूँ! मैं अर्ध-सेवानिवृत्त हूं, इसलिए यह मेरा शौक है। मैं जीवन भर अन्य लोगों की भाषाओं को लागू करता रहा हूं। मैंने अपनी कोडिंग शैली पर भी बहुत काम किया। और इसलिए भी कि मुझे अन्य भाषाओं में समस्याएँ दिखाई देती हैं। मैं देखता हूं कि परिचित चीजों को करने के बेहतर तरीके हैं। और मैं उनका उपयोग करूंगा. मैं अपने आप में, जावा में, पायथन में, किसी भी अन्य भाषा में समस्याएं देखकर थक गया हूं। अब मैं एक शौक के रूप में रिएक्ट नेटिव, जावास्क्रिप्ट और एल्म में लिखता हूं जो सेवानिवृत्ति के बारे में नहीं है, बल्कि सक्रिय कार्य के बारे में है। मैं पायथन में भी लिखता हूं और, सबसे अधिक संभावना है, जावा बैकएंड के लिए मशीन लर्निंग पर काम करना जारी रखूंगा। कई लोकप्रिय भाषाएँ हैं और उन सभी में दिलचस्प विशेषताएं हैं। हर कोई अपने तरीके से अच्छा है और आप इन सभी विशेषताओं को एक साथ लाने का प्रयास कर सकते हैं। इसलिए, मैं उन चीजों का अध्ययन कर रहा हूं जिनमें मेरी रुचि है, भाषा का व्यवहार, उचित शब्दार्थ के साथ आने की कोशिश कर रहा हूं। और अब तक मैं सफल हो रहा हूँ! फिलहाल मैं मेमोरी सिमेंटिक्स के साथ संघर्ष कर रहा हूं, क्योंकि मैं इसे सी और जावा की तरह रखना चाहता हूं, और लोड और स्टोर के लिए एक मजबूत मेमोरी मॉडल और मेमोरी सिमेंटिक्स प्राप्त करना चाहता हूं। साथ ही, हास्केल की तरह स्वचालित प्रकार का अनुमान लगाएं। यहां, मैं सी और जावा दोनों में मेमोरी कार्य के साथ हास्केल-जैसे प्रकार के अनुमान को मिश्रित करने का प्रयास कर रहा हूं। उदाहरण के लिए, मैं पिछले 2-3 महीनों से यही कर रहा हूँ।

एंड्रयू: यदि आप एक ऐसी भाषा बनाते हैं जो अन्य भाषाओं से बेहतर पहलू लेती है, तो क्या आपको लगता है कि कोई इसके विपरीत कार्य करेगा: आपके विचारों को लेगा और उनका उपयोग करेगा?

क्लिफ: बिल्कुल इसी तरह नई भाषाएँ सामने आती हैं! जावा C के समान क्यों है? क्योंकि C के पास एक अच्छा सिंटैक्स था जिसे हर कोई समझता था और जावा इस सिंटैक्स से प्रेरित था, जिसमें टाइप सेफ्टी, एरे बाउंड चेकिंग, GC को जोड़ा गया और उन्होंने C से कुछ चीजों में सुधार भी किया। उन्होंने अपना खुद का जोड़ा। लेकिन वे काफी प्रेरित हुए, है ना? हर कोई उन दिग्गजों के कंधों पर खड़ा है जो आपसे पहले आए थे - इसी तरह प्रगति होती है।

एंड्रयू: जैसा कि मैं इसे समझता हूं, आपकी भाषा स्मृति सुरक्षित रहेगी। क्या आपने रस्ट से उधार चेकर जैसा कुछ लागू करने के बारे में सोचा है? क्या आपने उसे देखा है, आप उसके बारे में क्या सोचते हैं?

क्लिफ: खैर, मैं सदियों से सी लिख रहा हूं, इस सभी मॉलोक और मुफ्त के साथ, और जीवनकाल को मैन्युअल रूप से प्रबंधित कर रहा हूं। आप जानते हैं, मैन्युअल रूप से नियंत्रित 90-95% जीवन काल की संरचना समान होती है। और इसे मैन्युअल रूप से करना बहुत, बहुत दर्दनाक है। मैं चाहूंगा कि संकलक आपको बस यह बताए कि वहां क्या चल रहा है और आपने अपने कार्यों से क्या हासिल किया है। कुछ चीज़ों के लिए, बॉरो चेकर यह काम लीक से हटकर करता है। और इसे स्वचालित रूप से जानकारी प्रदर्शित करनी चाहिए, सब कुछ समझना चाहिए, और इस समझ को प्रस्तुत करने का मुझ पर बोझ भी नहीं डालना चाहिए। इसे कम से कम स्थानीय एस्केप विश्लेषण करना चाहिए, और केवल यदि यह विफल हो जाता है, तो इसे ऐसे प्रकार के एनोटेशन जोड़ने की आवश्यकता होती है जो जीवनकाल का वर्णन करेंगे - और ऐसी योजना एक उधार चेकर, या वास्तव में किसी भी मौजूदा मेमोरी चेकर की तुलना में बहुत अधिक जटिल है। "सब कुछ ठीक है" और "मुझे कुछ समझ नहीं आ रहा" के बीच चयन - नहीं, कुछ बेहतर होना चाहिए। 
इसलिए, एक ऐसे व्यक्ति के रूप में जिसने सी में बहुत सारे कोड लिखे हैं, मुझे लगता है कि स्वचालित जीवनकाल नियंत्रण के लिए समर्थन होना सबसे महत्वपूर्ण बात है। मैं इस बात से भी तंग आ चुका हूं कि जावा मेमोरी का कितना उपयोग करता है और मुख्य शिकायत जीसी है। जब आप जावा में मेमोरी आवंटित करते हैं, तो आपको वह मेमोरी वापस नहीं मिलेगी जो पिछले GC चक्र में स्थानीय थी। अधिक सटीक स्मृति प्रबंधन वाली भाषाओं में ऐसा नहीं है। यदि आप मॉलोक को कॉल करते हैं, तो आपको तुरंत वह मेमोरी मिल जाती है जो आमतौर पर अभी उपयोग की गई थी। आमतौर पर आप स्मृति के साथ कुछ अस्थायी चीजें करते हैं और तुरंत उसे वापस लौटा देते हैं। और यह तुरंत मॉलोक पूल में लौट आता है, और अगला मॉलोक चक्र इसे फिर से बाहर खींच लेता है। इसलिए, वास्तविक मेमोरी उपयोग एक निश्चित समय में जीवित वस्तुओं के सेट के साथ-साथ लीक तक कम हो जाता है। और अगर सब कुछ पूरी तरह से अशोभनीय तरीके से लीक नहीं होता है, तो अधिकांश मेमोरी कैश और प्रोसेसर में समाप्त हो जाती है, और यह जल्दी से काम करती है। लेकिन मॉलोक और फ्री कॉल के साथ सही क्रम में, सही जगह पर बहुत अधिक मैन्युअल मेमोरी प्रबंधन की आवश्यकता होती है। रस्ट इसे अपने आप ठीक से संभाल सकता है, और कई मामलों में इससे भी बेहतर प्रदर्शन देता है, क्योंकि मेमोरी की खपत केवल वर्तमान गणना तक सीमित हो जाती है - मेमोरी को खाली करने के लिए अगले जीसी चक्र की प्रतीक्षा करने के विपरीत। परिणामस्वरूप, हमें प्रदर्शन में सुधार करने का एक बहुत ही दिलचस्प तरीका मिला। और काफी शक्तिशाली - मेरा मतलब है, मैंने फिनटेक के लिए डेटा संसाधित करते समय ऐसी चीजें कीं, और इससे मुझे लगभग पांच गुना स्पीडअप प्राप्त करने की अनुमति मिली। यह एक बहुत बड़ा बढ़ावा है, खासकर ऐसी दुनिया में जहां प्रोसेसर तेज़ नहीं हो रहे हैं और हम अभी भी सुधार की प्रतीक्षा कर रहे हैं।

प्रदर्शन इंजीनियर कैरियर

एंड्रयू: मैं आम तौर पर करियर के बारे में भी पूछना चाहूँगा। आप हॉटस्पॉट में अपने जेआईटी कार्य से प्रमुखता तक पहुंचे और फिर अज़ुल में चले गए, जो एक जेवीएम कंपनी भी है। लेकिन हम पहले से ही सॉफ्टवेयर से ज्यादा हार्डवेयर पर काम कर रहे थे। और फिर उन्होंने अचानक बिग डेटा और मशीन लर्निंग और फिर धोखाधड़ी का पता लगाना शुरू कर दिया। यह कैसे हो गया? ये विकास के बहुत अलग क्षेत्र हैं।

क्लिफ: मैं काफी समय से प्रोग्रामिंग कर रहा हूं और कई अलग-अलग कक्षाएं लेने में कामयाब रहा हूं। और जब लोग कहते हैं: "ओह, आप ही हैं जिन्होंने जावा के लिए JIT किया!", तो यह हमेशा मज़ेदार होता है। लेकिन उससे पहले, मैं पोस्टस्क्रिप्ट के क्लोन पर काम कर रहा था - वह भाषा जिसे Apple एक बार अपने लेजर प्रिंटर के लिए इस्तेमाल करता था। और उससे पहले मैंने फोर्थ भाषा का कार्यान्वयन किया था। मुझे लगता है कि मेरे लिए सामान्य विषय उपकरण विकास है। अपने पूरे जीवन में मैं ऐसे उपकरण बनाता रहा हूं जिनकी मदद से अन्य लोग अपने अच्छे कार्यक्रम लिखते हैं। लेकिन मैं ओएस विकास के लिए ऑपरेटिंग सिस्टम, ड्राइवर, कर्नेल-स्तरीय डिबगर्स, भाषाओं के विकास में भी शामिल था, जो शुरू में मामूली थे, लेकिन समय के साथ और अधिक जटिल हो गए। लेकिन मुख्य विषय अभी भी उपकरणों का विकास है। मेरे जीवन का एक बड़ा हिस्सा अज़ुल और सन के बीच गुजरा, और यह जावा के बारे में था। लेकिन जब मैं बिग डेटा और मशीन लर्निंग में आया, तो मैंने अपनी फैंसी टोपी वापस रख दी और कहा, "ओह, अब हमारे पास एक गैर-मामूली समस्या है, और बहुत सारी दिलचस्प चीजें चल रही हैं और लोग चीजें कर रहे हैं।" यह विकास का एक महान मार्ग है।

हां, मुझे वास्तव में वितरित कंप्यूटिंग पसंद है। सी में एक छात्र के रूप में मेरी पहली नौकरी एक विज्ञापन परियोजना पर थी। इसे ज़िलॉग Z80 चिप्स पर वितरित कंप्यूटिंग किया गया था जो एक वास्तविक एनालॉग विश्लेषक द्वारा उत्पादित एनालॉग ओसीआर के लिए डेटा एकत्र करता था। यह एक अच्छा और पूरी तरह से पागलपन भरा विषय था। लेकिन समस्याएँ थीं, कुछ भाग सही ढंग से पहचाना नहीं गया था, इसलिए आपको एक तस्वीर निकालनी थी और इसे किसी ऐसे व्यक्ति को दिखाना था जो पहले से ही अपनी आँखों से पढ़ सकता था और रिपोर्ट कर सकता था कि इसमें क्या कहा गया है, और इसलिए डेटा के साथ नौकरियाँ थीं, और ये नौकरियाँ उनकी अपनी भाषा थी. एक बैकएंड था जो यह सब संसाधित करता था - Z80s समानांतर में चल रहे vt100 टर्मिनलों के साथ चल रहा था - प्रति व्यक्ति एक, और Z80 पर एक समानांतर प्रोग्रामिंग मॉडल था। स्टार कॉन्फ़िगरेशन के भीतर सभी Z80s द्वारा साझा की गई मेमोरी का कुछ सामान्य टुकड़ा; बैकप्लेन भी साझा किया गया था, और रैम का आधा हिस्सा नेटवर्क के भीतर साझा किया गया था, और दूसरा आधा निजी था या किसी और चीज़ में चला गया था। साझा... अर्ध-साझा मेमोरी के साथ एक सार्थक रूप से जटिल समानांतर वितरित प्रणाली। यह कब था... मुझे यह भी याद नहीं है, कहीं 80 के दशक के मध्य में। काफ़ी समय पहले. 
हां, मान लीजिए कि 30 साल काफी लंबा समय है। वितरित कंप्यूटिंग से संबंधित समस्याएं काफी लंबे समय से मौजूद हैं; लोग लंबे समय से युद्ध में हैं बियोवुल्फ़-समूह। ऐसे क्लस्टर ऐसे दिखते हैं... उदाहरण के लिए: ईथरनेट है और आपका तेज़ x86 इस ईथरनेट से जुड़ा है, और अब आप नकली साझा मेमोरी प्राप्त करना चाहते हैं, क्योंकि तब कोई भी वितरित कंप्यूटिंग कोडिंग नहीं कर सकता था, यह बहुत कठिन था और इसलिए वहां x86 पर सुरक्षा मेमोरी पृष्ठों के साथ नकली साझा मेमोरी थी, और यदि आपने इस पृष्ठ पर लिखा था, तो हमने अन्य प्रोसेसरों से कहा था कि यदि वे समान साझा मेमोरी तक पहुंचते हैं, तो इसे आपसे लोड करने की आवश्यकता होगी, और इस प्रकार समर्थन के लिए एक प्रोटोकॉल जैसा कुछ होगा कैश सुसंगतता दिखाई दी और इसके लिए सॉफ़्टवेयर। दिलचस्प अवधारणा. निःसंदेह, वास्तविक समस्या कुछ और थी। यह सब काम कर गया, लेकिन आपको जल्दी ही प्रदर्शन संबंधी समस्याएं आ गईं, क्योंकि किसी ने भी प्रदर्शन मॉडल को अच्छे स्तर पर नहीं समझा - वहां मेमोरी एक्सेस पैटर्न क्या थे, यह कैसे सुनिश्चित किया जाए कि नोड्स एक-दूसरे को लगातार पिंग न करें, इत्यादि।

H2O में मैं जो लेकर आया हूं वह यह है कि यह डेवलपर्स स्वयं हैं जो यह निर्धारित करने के लिए जिम्मेदार हैं कि समानता कहां छिपी हुई है और कहां नहीं। मैं एक कोडिंग मॉडल लेकर आया जिसने उच्च-प्रदर्शन कोड लिखना आसान और सरल बना दिया। लेकिन धीमी गति से चलने वाला कोड लिखना कठिन है, यह खराब लगेगा। आपको धीमे कोड लिखने के लिए गंभीरता से प्रयास करने की आवश्यकता है, आपको गैर-मानक तरीकों का उपयोग करना होगा। ब्रेकिंग कोड पहली नज़र में दिखाई देता है। परिणामस्वरूप, आप आमतौर पर ऐसा कोड लिखते हैं जो तेजी से चलता है, लेकिन आपको यह पता लगाना होगा कि साझा मेमोरी के मामले में क्या करना है। यह सब बड़े सरणियों से जुड़ा हुआ है और वहां का व्यवहार समानांतर जावा में गैर-वाष्पशील बड़े सरणियों के समान है। मेरा मतलब है, कल्पना करें कि दो धागे एक समानांतर सरणी में लिखते हैं, उनमें से एक जीतता है, और दूसरा, तदनुसार, हार जाता है, और आप नहीं जानते कि कौन सा है। यदि वे अस्थिर नहीं हैं, तो ऑर्डर वह हो सकता है जो आप चाहते हैं - और यह वास्तव में अच्छी तरह से काम करता है। लोग वास्तव में संचालन के क्रम की परवाह करते हैं, वे अस्थिरता को सही स्थानों पर रखते हैं, और वे सही स्थानों पर स्मृति-संबंधी प्रदर्शन समस्याओं की अपेक्षा करते हैं। अन्यथा, वे बस 1 से एन तक लूप के रूप में कोड लिखेंगे, जहां एन कुछ ट्रिलियन है, इस उम्मीद में कि सभी जटिल मामले स्वचालित रूप से समानांतर हो जाएंगे - और यह वहां काम नहीं करता है। लेकिन H2O में यह न तो जावा है और न ही स्काला; आप चाहें तो इसे "जावा माइनस माइनस" मान सकते हैं। यह एक बहुत ही स्पष्ट प्रोग्रामिंग शैली है और लूप और एरे के साथ सरल सी या जावा कोड लिखने के समान है। लेकिन साथ ही, मेमोरी को टेराबाइट्स में संसाधित किया जा सकता है। मैं अभी भी H2O का उपयोग करता हूं। मैं इसे समय-समय पर विभिन्न परियोजनाओं में उपयोग करता हूं - और यह अभी भी सबसे तेज़ चीज़ है, अपने प्रतिस्पर्धियों की तुलना में दर्जनों गुना तेज़। यदि आप स्तंभ डेटा के साथ बिग डेटा कर रहे हैं, तो H2O को हराना बहुत कठिन है।

तकनीकी चुनौतियाँ

एंड्रयू: आपके पूरे करियर में आपकी सबसे बड़ी चुनौती क्या रही है?

क्लिफ: क्या हम मुद्दे के तकनीकी या गैर-तकनीकी हिस्से पर चर्चा कर रहे हैं? मैं कहूंगा कि सबसे बड़ी चुनौतियाँ तकनीकी नहीं हैं। 
जहाँ तक तकनीकी चुनौतियों का सवाल है। मैंने बस उन्हें हरा दिया। मैं यह भी नहीं जानता कि सबसे बड़ा क्या था, लेकिन कुछ बहुत दिलचस्प थे जिनमें काफी समय लगा, मानसिक संघर्ष हुआ। जब मैं सन गया, तो मुझे यकीन था कि मैं एक तेज़ कंपाइलर बनाऊंगा, और वरिष्ठों के एक समूह ने जवाब में कहा कि मैं कभी सफल नहीं होऊंगा। लेकिन मैंने इस पथ का अनुसरण किया, रजिस्टर एलोकेटर के लिए एक कंपाइलर लिखा, और यह काफी तेज़ था। यह आधुनिक C1 जितना तेज़ था, लेकिन तब आवंटनकर्ता बहुत धीमा था, और अंत में यह एक बड़ी डेटा संरचना समस्या थी। मुझे ग्राफिकल रजिस्टर एलोकेटर लिखने के लिए इसकी आवश्यकता थी और मुझे कोड अभिव्यक्ति और गति के बीच की दुविधा समझ में नहीं आई, जो उस युग में मौजूद थी और बहुत महत्वपूर्ण थी। यह पता चला कि डेटा संरचना आमतौर पर उस समय के x86 पर कैश आकार से अधिक होती है, और इसलिए, अगर मैंने शुरू में मान लिया था कि रजिस्टर आवंटनकर्ता कुल घबराहट समय का 5-10 प्रतिशत काम करेगा, तो वास्तव में यह निकला 50 प्रतिशत।

जैसे-जैसे समय बीतता गया, कंपाइलर साफ और अधिक कुशल होता गया, अधिक मामलों में भयानक कोड उत्पन्न करना बंद कर दिया, और प्रदर्शन तेजी से सी कंपाइलर जैसा दिखने लगा। जब तक, निश्चित रूप से, आप कुछ बकवास नहीं लिखते हैं कि सी भी गति नहीं करता है . यदि आप C जैसा कोड लिखते हैं, तो आपको अधिक मामलों में C जैसा प्रदर्शन मिलेगा। और जितना आगे आप गए, उतनी ही अधिक बार आपको वह कोड मिला जो बिना किसी लक्षण के लेवल सी से मेल खाता था, रजिस्टर एलोकेटर कुछ पूर्ण जैसा दिखने लगा... भले ही आपका कोड तेज या धीमी गति से चलता हो। मैंने बेहतर चयन करने के लिए आवंटनकर्ता पर काम करना जारी रखा। वह धीमा और धीमा होता गया, लेकिन उसने उन मामलों में बेहतर और बेहतर प्रदर्शन दिया, जहां कोई और सामना नहीं कर सका। मैं एक रजिस्टर आवंटनकर्ता में गोता लगा सकता हूं, वहां एक महीने का काम कर सकता हूं, और अचानक पूरा कोड 5% तेजी से निष्पादित होना शुरू हो जाएगा। ऐसा समय-समय पर होता रहा और रजिस्टर आवंटनकर्ता कला का एक नमूना बन गया - हर कोई इसे पसंद करता था या नफरत करता था, और अकादमी के लोगों ने "हर चीज इस तरह से क्यों की जाती है", क्यों नहीं विषय पर सवाल पूछे। लाइन स्कैन, और क्या अंतर है. उत्तर अभी भी वही है: ग्राफ़ रंग पर आधारित एक आवंटनकर्ता और बफर कोड के साथ बहुत सावधानी से काम करना जीत के हथियार के बराबर है, सबसे अच्छा संयोजन जिसे कोई भी हरा नहीं सकता है। और यह एक गैर-स्पष्ट बात है. बाकी सब कुछ जो संकलक वहां करता है वह काफी अच्छी तरह से अध्ययन की गई चीजें हैं, हालांकि उन्हें कला के स्तर पर भी लाया गया है। मैंने हमेशा ऐसे काम किये जो संकलक को कला के काम में बदलने वाले थे। लेकिन इनमें से कुछ भी असाधारण नहीं था - रजिस्टर आवंटनकर्ता को छोड़कर। युक्ति सावधान रहना है छोटा कर देना लोड के तहत और, यदि ऐसा होता है (यदि रुचि हो तो मैं अधिक विस्तार से बता सकता हूं), इसका मतलब है कि आप प्रदर्शन शेड्यूल में गड़बड़ी के जोखिम के बिना, अधिक आक्रामक तरीके से इनलाइन कर सकते हैं। उन दिनों, फुल-स्केल कंपाइलर्स का एक समूह था, जो बाउबल्स और सीटियों से लटका हुआ था, जिसमें रजिस्टर आवंटनकर्ता थे, लेकिन कोई और ऐसा नहीं कर सकता था।

समस्या यह है कि यदि आप उन विधियों को जोड़ते हैं जो इनलाइनिंग के अधीन हैं, तो इनलाइनिंग क्षेत्र को बढ़ाना और बढ़ाना, उपयोग किए गए मानों का सेट तुरंत रजिस्टरों की संख्या से आगे निकल जाता है, और आपको उन्हें काटना होगा। गंभीर स्तर आम तौर पर तब आता है जब आवंटनकर्ता हार मान लेता है, और स्पिल के लिए एक अच्छा उम्मीदवार दूसरे के लायक होता है, आप कुछ आम तौर पर जंगली चीजें बेचेंगे। यहां इनलाइनिंग का मूल्य यह है कि आप कॉलिंग और सेविंग के लिए ओवरहेड, ओवरहेड का हिस्सा खो देते हैं, आप अंदर के मूल्यों को देख सकते हैं और उन्हें और अधिक अनुकूलित कर सकते हैं। इनलाइनिंग की लागत यह है कि बड़ी संख्या में लाइव मान बनते हैं, और यदि आपका रजिस्टर एलोकेटर आवश्यकता से अधिक जल जाता है, तो आप तुरंत हार जाते हैं। इसलिए, अधिकांश आवंटनकर्ताओं को एक समस्या होती है: जब इनलाइनिंग एक निश्चित रेखा को पार कर जाती है, तो दुनिया में हर चीज में कटौती शुरू हो जाती है और उत्पादकता शौचालय में बह सकती है। जो लोग कंपाइलर को लागू करते हैं वे कुछ आंकड़े जोड़ते हैं: उदाहरण के लिए, इनलाइनिंग को रोकने के लिए, कुछ पर्याप्त बड़े आकार से शुरू करना, क्योंकि आवंटन सब कुछ बर्बाद कर देगा। इस प्रकार प्रदर्शन ग्राफ में एक गड़बड़ी बनती है - आप इनलाइन, इनलाइन, प्रदर्शन धीरे-धीरे बढ़ता है - और फिर तेजी! - यह एक तेज जैक की तरह नीचे गिरता है क्योंकि आपने बहुत अधिक लाइन लगाई है। जावा के आगमन से पहले सब कुछ इसी तरह काम करता था। जावा को बहुत अधिक इनलाइनिंग की आवश्यकता होती है, इसलिए मुझे अपने एलोकेटर को और अधिक आक्रामक बनाना पड़ा ताकि यह दुर्घटनाग्रस्त होने के बजाय समतल हो जाए, और यदि आप बहुत अधिक इनलाइन करते हैं, तो यह फैलना शुरू हो जाता है, लेकिन फिर "कोई और अधिक स्पिलिंग नहीं" क्षण आता है। यह एक दिलचस्प अवलोकन है और यह मेरे पास कहीं से भी आया, स्पष्ट नहीं है, लेकिन इसका अच्छा परिणाम मिला। मैंने आक्रामक इनलाइनिंग अपनाई और यह मुझे उन स्थानों पर ले गई जहां जावा और सी प्रदर्शन साथ-साथ काम करते हैं। वे वास्तव में करीब हैं - मैं जावा कोड लिख सकता हूं जो सी कोड और उस जैसी चीजों की तुलना में काफी तेज है, लेकिन औसतन, चीजों की बड़ी तस्वीर में, वे लगभग तुलनीय हैं। मुझे लगता है कि इस योग्यता का एक हिस्सा रजिस्टर आवंटनकर्ता है, जो मुझे यथासंभव मूर्खतापूर्ण तरीके से इनलाइन करने की अनुमति देता है। मैं जो कुछ भी देखता हूं उसे इनलाइन कर देता हूं। यहां सवाल यह है कि क्या आवंटनकर्ता अच्छी तरह से काम करता है, क्या परिणाम बुद्धिमानी से काम करने वाला कोड है। यह एक बड़ी चुनौती थी: यह सब समझना और इसे कार्यान्वित करना।

रजिस्टर आवंटन और मल्टी-कोर के बारे में थोड़ा

व्लादिमीर: रजिस्टर आवंटन जैसी समस्याएँ किसी प्रकार का शाश्वत, अंतहीन विषय लगती हैं। मुझे आश्चर्य है कि क्या कभी कोई ऐसा विचार आया है जो आशाजनक लगा और फिर व्यवहार में विफल हो गया?

क्लिफ: निश्चित रूप से! रजिस्टर आवंटन एक ऐसा क्षेत्र है जिसमें आप एनपी-पूर्ण समस्या को हल करने के लिए कुछ आंकड़े ढूंढने का प्रयास करते हैं। और आप कभी भी सही समाधान प्राप्त नहीं कर सकते, है ना? यह बिल्कुल असंभव है. देखिए, समय से पहले संकलन - यह भी खराब तरीके से काम करता है। यहां बातचीत कुछ औसत मामलों के बारे में है। विशिष्ट प्रदर्शन के बारे में, तो आप जा सकते हैं और कुछ ऐसा माप सकते हैं जो आपको लगता है कि अच्छा विशिष्ट प्रदर्शन है - आखिरकार, आप इसे सुधारने के लिए काम कर रहे हैं! रजिस्टर आवंटन प्रदर्शन से जुड़ा विषय है। एक बार जब आपके पास पहला प्रोटोटाइप होता है, तो यह काम करता है और जो आवश्यक है उसे चित्रित करता है, प्रदर्शन कार्य शुरू होता है। आपको अच्छी तरह से मापना सीखना होगा। यह महत्वपूर्ण क्यों है? यदि आपके पास स्पष्ट डेटा है, तो आप विभिन्न क्षेत्रों को देख सकते हैं और देख सकते हैं: हाँ, इससे यहाँ मदद मिली, लेकिन यहीं सब कुछ ख़राब हो गया! कुछ अच्छे विचार आते हैं, आप नए अनुमान जोड़ते हैं और अचानक सब कुछ औसतन थोड़ा बेहतर काम करने लगता है। या यह प्रारंभ नहीं होता. मेरे पास ऐसे कई मामले थे जहां हम पांच प्रतिशत प्रदर्शन के लिए लड़ रहे थे जो हमारे विकास को पिछले आवंटनकर्ता से अलग करता था। और हर बार ऐसा ही दिखता है: कहीं आप जीतते हैं, कहीं आप हारते हैं। यदि आपके पास अच्छे प्रदर्शन विश्लेषण उपकरण हैं, तो आप खोने वाले विचारों को ढूंढ सकते हैं और समझ सकते हैं कि वे विफल क्यों होते हैं। हो सकता है कि सब कुछ वैसे ही छोड़ देना उचित हो जैसे वह है, या शायद फाइन-ट्यूनिंग के लिए अधिक गंभीर दृष्टिकोण अपनाना, या बाहर जाकर कुछ और ठीक करना। यह चीजों का एक पूरा समूह है! मैंने यह बढ़िया हैक बनाया है, लेकिन मुझे इसकी भी ज़रूरत है, और इसकी, और इसकी - और उनका कुल संयोजन कुछ सुधार देता है। और अकेले लोग असफल हो सकते हैं। यह एनपी-पूर्ण समस्याओं पर प्रदर्शन कार्य की प्रकृति है।

व्लादिमीर: ऐसा महसूस होता है कि एलोकेटर में पेंटिंग जैसी चीजें एक ऐसी समस्या है जिसे पहले ही हल किया जा चुका है। ठीक है, आप जो कह रहे हैं उसके आधार पर यह आपके लिए तय किया गया है, तो क्या यह इसके लायक भी है...

क्लिफ: इसे ऐसे ही हल नहीं किया गया है. यह आप ही हैं जिन्हें इसे "समाधान" में बदलना होगा। कठिन समस्याएँ हैं और उन्हें हल करने की आवश्यकता है। एक बार यह पूरा हो जाने के बाद, उत्पादकता पर काम करने का समय आ गया है। आपको इस कार्य को तदनुसार करने की आवश्यकता है - बेंचमार्क करें, मेट्रिक्स एकत्र करें, उन स्थितियों की व्याख्या करें जब, जब आप पिछले संस्करण में वापस आए, तो आपका पुराना हैक फिर से काम करना शुरू कर दिया (या इसके विपरीत, बंद हो गया)। और जब तक आप कुछ हासिल न कर लें, तब तक हार न मानें। जैसा कि मैंने पहले ही कहा, अगर ऐसे अच्छे विचार हैं जो काम नहीं करते हैं, लेकिन विचारों के रजिस्टरों के आवंटन के क्षेत्र में यह लगभग अंतहीन है। उदाहरण के लिए, आप वैज्ञानिक प्रकाशन पढ़ सकते हैं। हालाँकि अब यह क्षेत्र बहुत धीमी गति से आगे बढ़ना शुरू हो गया है और अपनी युवावस्था की तुलना में अधिक स्पष्ट हो गया है। हालाँकि, इस क्षेत्र में अनगिनत लोग काम कर रहे हैं और उनके सभी विचार आज़माने लायक हैं, वे सभी प्रतीक्षा में हैं। और आप यह नहीं बता सकते कि वे कितने अच्छे हैं जब तक कि आप उन्हें आज़माएँ नहीं। वे आपके एलोकेटर में बाकी सभी चीजों के साथ कितनी अच्छी तरह एकीकृत होते हैं, क्योंकि एक एलोकेटर बहुत सारी चीजें करता है, और कुछ विचार आपके विशिष्ट एलोकेटर में काम नहीं करेंगे, लेकिन दूसरे एलोकेटर में वे आसानी से काम करेंगे। आवंटनकर्ता के लिए जीतने का मुख्य तरीका धीमे सामान को मुख्य पथ के बाहर खींचना और उसे धीमे पथों की सीमाओं के साथ विभाजित होने के लिए मजबूर करना है। इसलिए यदि आप GC चलाना चाहते हैं, धीमा रास्ता अपनाना चाहते हैं, अनुकूलित करना बंद करना चाहते हैं, एक अपवाद फेंकना चाहते हैं, ये सभी चीजें - आप जानते हैं कि ये चीजें अपेक्षाकृत दुर्लभ हैं। और वे वास्तव में दुर्लभ हैं, मैंने जाँच की। आप अतिरिक्त काम करते हैं और यह इन धीमे रास्तों पर बहुत सारे प्रतिबंध हटा देता है, लेकिन इससे वास्तव में कोई फर्क नहीं पड़ता क्योंकि वे धीमे हैं और शायद ही कभी यात्रा की जाती है। उदाहरण के लिए, एक शून्य सूचक - ऐसा कभी नहीं होता, है ना? आपके पास अलग-अलग चीजों के लिए कई रास्ते होने चाहिए, लेकिन उन्हें मुख्य रास्ते में हस्तक्षेप नहीं करना चाहिए। 

व्लादिमीर: आप मल्टी-कोर के बारे में क्या सोचते हैं, जब एक साथ हजारों कोर होते हैं? क्या ये काम की चीज़ है?

क्लिफ: GPU की सफलता दर्शाती है कि यह काफी उपयोगी है!

व्लादिमीर: वे काफी विशिष्ट हैं. सामान्य प्रयोजन प्रोसेसर के बारे में क्या?

क्लिफ: खैर, वह अज़ुल का बिजनेस मॉडल था। इसका उत्तर उस युग में आया जब लोग वास्तव में पूर्वानुमानित प्रदर्शन को पसंद करते थे। उस समय समानांतर कोड लिखना कठिन था। H2O कोडिंग मॉडल अत्यधिक स्केलेबल है, लेकिन यह एक सामान्य प्रयोजन मॉडल नहीं है। शायद GPU का उपयोग करने की तुलना में थोड़ा अधिक सामान्य। क्या हम ऐसी चीज़ को विकसित करने की जटिलता या उसके उपयोग की जटिलता के बारे में बात कर रहे हैं? उदाहरण के लिए, अज़ुल ने मुझे एक दिलचस्प सबक सिखाया, एक गैर-स्पष्ट: छोटे कैश सामान्य हैं। 

जीवन की सबसे बड़ी चुनौती

व्लादिमीर: गैर-तकनीकी चुनौतियों के बारे में क्या?

क्लिफ: सबसे बड़ी चुनौती लोगों के प्रति दयालु और अच्छा होना नहीं था। और परिणामस्वरूप, मैंने खुद को लगातार बेहद संघर्षपूर्ण स्थितियों में पाया। वे जहां मुझे पता था कि चीजें गलत हो रही हैं, लेकिन मुझे नहीं पता था कि उन समस्याओं के साथ कैसे आगे बढ़ना है और मैं उन्हें संभाल नहीं सका। दशकों तक चलने वाली कई दीर्घकालिक समस्याएं इसी तरह पैदा हुईं। यह तथ्य कि जावा में C1 और C2 कंपाइलर हैं, इसका प्रत्यक्ष परिणाम है। तथ्य यह है कि जावा में लगातार दस वर्षों तक कोई बहु-स्तरीय संकलन नहीं था, यह भी एक प्रत्यक्ष परिणाम है। यह स्पष्ट है कि हमें ऐसी प्रणाली की आवश्यकता थी, लेकिन यह स्पष्ट नहीं है कि यह अस्तित्व में क्यों नहीं थी। मुझे एक इंजीनियर या इंजीनियरों के एक समूह से समस्या थी। एक समय की बात है, जब मैंने सन में काम करना शुरू किया था, मैं... ठीक है, केवल तभी नहीं, आम तौर पर हर चीज पर मेरी अपनी राय होती है। और मुझे लगा कि यह सच है कि आप अपना यह सच स्वीकार कर सकते हैं और इसे सीधे बता सकते हैं। खासतौर पर तब जब मैं ज्यादातर समय आश्चर्यजनक रूप से सही था। और यदि आपको यह दृष्टिकोण पसंद नहीं है... खासकर यदि आप स्पष्ट रूप से गलत हैं और बकवास कर रहे हैं... सामान्य तौर पर, कुछ ही लोग संचार के इस रूप को बर्दाश्त कर सकते हैं। हालाँकि कुछ लोग मेरी तरह ऐसा कर सकते थे। मैंने अपना पूरा जीवन गुणात्मक सिद्धांतों पर बनाया है। अगर आप मुझे कुछ गलत दिखाएंगे तो मैं तुरंत पलटकर कहूंगा, आपने बकवास कहा। साथ ही, निश्चित रूप से, मैं माफी मांगता हूं और वह सब, मैं खूबियों, यदि कोई हो, को नोट करूंगा और अन्य सही कार्रवाई करूंगा। दूसरी ओर, कुल समय के आश्चर्यजनक रूप से बड़े प्रतिशत के बारे में मैं आश्चर्यजनक रूप से सही हूँ। और यह लोगों के साथ संबंधों में बहुत अच्छा काम नहीं करता है। मैं अच्छा बनने की कोशिश नहीं कर रहा हूं, लेकिन मैं स्पष्ट रूप से सवाल पूछ रहा हूं। "यह कभी काम नहीं करेगा, क्योंकि एक, दो और तीन।" और वे ऐसे थे, "ओह!" ऐसे और भी परिणाम थे जिन्हें नज़रअंदाज़ करना शायद बेहतर था: उदाहरण के लिए, जिनके कारण मेरी पत्नी से तलाक हुआ और उसके बाद दस साल तक अवसाद में रहना पड़ा।

चुनौती लोगों के साथ एक संघर्ष है, उनकी इस धारणा के साथ कि आप क्या कर सकते हैं या क्या नहीं, क्या महत्वपूर्ण है और क्या नहीं। कोडिंग शैली को लेकर कई चुनौतियाँ थीं। मैं अभी भी बहुत सारे कोड लिखता हूं, और उन दिनों मुझे धीमा भी करना पड़ा क्योंकि मैं बहुत सारे समानांतर कार्य कर रहा था और एक पर ध्यान केंद्रित करने के बजाय उन्हें खराब तरीके से कर रहा था। पीछे मुड़कर देखने पर, मैंने Java JIT कमांड, C2 कमांड के लिए आधा कोड लिखा। अगले सबसे तेज़ कोडर ने आधा धीमा लिखा, अगले ने आधा धीमा लिखा, और यह एक तेजी से गिरावट थी। इस पंक्ति में सातवाँ व्यक्ति बहुत, बहुत धीमा था - ऐसा हमेशा होता है! मैंने बहुत सारे कोड को छुआ। मैंने देखा कि किसने क्या लिखा, बिना किसी अपवाद के, मैंने उनके कोड को देखा, उनमें से प्रत्येक की समीक्षा की, और फिर भी उनमें से किसी से भी अधिक खुद लिखना जारी रखा। यह दृष्टिकोण लोगों के साथ बहुत अच्छा काम नहीं करता है. कुछ लोगों को यह पसंद नहीं है. और जब वे इसे संभाल नहीं पाते, तो सभी प्रकार की शिकायतें शुरू हो जाती हैं। उदाहरण के लिए, एक बार मुझे कोडिंग बंद करने के लिए कहा गया था क्योंकि मैं बहुत अधिक कोड लिख रहा था और यह टीम को खतरे में डाल रहा था, और यह सब मुझे एक मजाक की तरह लग रहा था: दोस्त, अगर टीम के बाकी सदस्य गायब हो जाते हैं और मैं कोड लिखना जारी रखता हूं, तो आप मैं केवल आधी टीमें ही खोऊँगा। दूसरी ओर, यदि मैं कोड लिखना जारी रखता हूं और आप आधी टीम खो देते हैं, तो यह बहुत खराब प्रबंधन जैसा लगता है। मैंने वास्तव में इसके बारे में कभी नहीं सोचा, इसके बारे में कभी बात नहीं की, लेकिन यह अभी भी मेरे दिमाग में कहीं न कहीं था। मेरे मन में विचार घूम रहा था: "क्या तुम सब मुझसे मजाक कर रहे हो?" तो, सबसे बड़ी समस्या थी मैं और लोगों के साथ मेरे रिश्ते। अब मैं खुद को बहुत बेहतर समझता हूं, मैं लंबे समय तक प्रोग्रामर्स के लिए एक टीम लीड था, और अब मैं सीधे लोगों से कहता हूं: आप जानते हैं, मैं वही हूं जो मैं हूं, और आपको मुझसे निपटना होगा - क्या यह ठीक है अगर मैं खड़ा रहता हूं यहाँ? और जब उन्होंने इससे निपटना शुरू किया, तो सब कुछ काम कर गया। वास्तव में, मैं न तो बुरा हूं और न ही अच्छा, मेरे कोई बुरे इरादे या स्वार्थी आकांक्षाएं नहीं हैं, यह सिर्फ मेरा सार है, और मुझे किसी तरह इसके साथ रहने की जरूरत है।

एंड्रयू: अभी हाल ही में हर किसी ने अंतर्मुखी लोगों के लिए आत्म-जागरूकता और सामान्य तौर पर सॉफ्ट स्किल्स के बारे में बात करना शुरू कर दिया है। आप इस बारे में क्या कह सकते हैं?

क्लिफ: हाँ, यही वह अंतर्दृष्टि और सबक था जो मैंने अपनी पत्नी से तलाक के बाद सीखा। तलाक से मैंने जो सीखा, वह था खुद को समझना। इस तरह मैं दूसरे लोगों को समझने लगा। समझें कि यह इंटरैक्शन कैसे काम करता है. इससे एक के बाद एक खोजें होती गईं। इस बात की जागरूकता थी कि मैं कौन हूं और मैं क्या प्रतिनिधित्व करता हूं। मैं क्या कर रहा हूं: या तो मैं कार्य में व्यस्त हूं, या मैं संघर्ष से बच रहा हूं, या कुछ और - और आत्म-जागरूकता का यह स्तर वास्तव में खुद को नियंत्रण में रखने में मदद करता है। इसके बाद सब कुछ बहुत आसान हो जाता है. एक चीज जो मैंने न केवल खुद में, बल्कि अन्य प्रोग्रामर्स में भी खोजी, वह यह है कि जब आप भावनात्मक तनाव की स्थिति में होते हैं तो विचारों को शब्दों में व्यक्त करने में असमर्थता होती है। उदाहरण के लिए, आप वहां बैठकर कोडिंग कर रहे हैं, प्रवाह की स्थिति में, और फिर वे आपके पास दौड़ते हुए आते हैं और उन्माद में चिल्लाने लगते हैं कि कुछ टूट गया है और अब आपके खिलाफ अत्यधिक कदम उठाए जाएंगे। और आप एक शब्द भी नहीं कह सकते क्योंकि आप भावनात्मक तनाव की स्थिति में हैं। अर्जित ज्ञान आपको इस क्षण के लिए तैयारी करने, इससे बचने और पीछे हटने की योजना पर आगे बढ़ने की अनुमति देता है, जिसके बाद आप कुछ कर सकते हैं। तो हाँ, जब आपको यह एहसास होने लगता है कि यह सब कैसे काम करता है, तो यह एक बहुत बड़ी जीवन बदलने वाली घटना है। 
मुझे स्वयं सही शब्द नहीं मिल सके, लेकिन मुझे क्रियाओं का क्रम याद आ गया। मुद्दा यह है कि यह प्रतिक्रिया जितनी शारीरिक है उतनी ही मौखिक भी है, और आपको जगह की आवश्यकता है। ऐसा स्थान, ज़ेन अर्थ में। यह बिल्कुल वही है जिसे समझाने की आवश्यकता है, और फिर तुरंत एक तरफ हट जाएं - पूरी तरह से शारीरिक रूप से दूर हट जाएं। जब मैं मौखिक रूप से चुप रहता हूं, तो मैं स्थिति को भावनात्मक रूप से संसाधित कर सकता हूं। जैसे ही एड्रेनालाईन आपके मस्तिष्क तक पहुंचता है, आपको लड़ाई या उड़ान मोड में बदल देता है, आप अब कुछ भी नहीं कह सकते हैं, नहीं - अब आप एक बेवकूफ हैं, एक कोड़े मारने वाले इंजीनियर हैं, एक सभ्य प्रतिक्रिया देने या हमले को रोकने में भी असमर्थ हैं, और हमलावर स्वतंत्र है बार-बार आक्रमण करना. आपको सबसे पहले फिर से खुद बनना होगा, नियंत्रण हासिल करना होगा, "लड़ो या भागो" मोड से बाहर निकलना होगा।

और इसके लिए हमें मौखिक स्थान की आवश्यकता है। बस जगह खाली है. यदि आप कुछ भी कहते हैं, तो आप ठीक वैसा ही कह सकते हैं, और फिर जाएं और वास्तव में अपने लिए "स्थान" ढूंढें: पार्क में टहलने जाएं, अपने आप को शॉवर में बंद कर लें - इससे कोई फर्क नहीं पड़ता। मुख्य बात उस स्थिति से अस्थायी रूप से अलग होना है। जैसे ही आप कम से कम कुछ सेकंड के लिए स्विच ऑफ करते हैं, नियंत्रण वापस आ जाता है, आप गंभीरता से सोचना शुरू कर देते हैं। "ठीक है, मैं किसी तरह का बेवकूफ नहीं हूं, मैं बेवकूफी भरी चीजें नहीं करता, मैं काफी उपयोगी व्यक्ति हूं।" एक बार जब आप खुद को समझाने में सक्षम हो जाते हैं, तो अब अगले चरण पर आगे बढ़ने का समय है: यह समझना कि क्या हुआ। आप पर हमला किया गया, हमला वहां से हुआ जहां आपने इसकी उम्मीद नहीं की थी, यह एक बेईमान, वीभत्स घात था। यह तो बुरा हुआ। अगला कदम यह समझना है कि हमलावर को इसकी आवश्यकता क्यों थी। में क्यों? शायद इसलिए कि वह ख़ुद गुस्से में है? वह पागल क्यों है? उदाहरण के लिए, क्योंकि उसने खुद को खराब कर लिया और जिम्मेदारी स्वीकार नहीं कर सकता? पूरी स्थिति को सावधानीपूर्वक संभालने का यही तरीका है. लेकिन इसके लिए पैंतरेबाज़ी, मौखिक स्थान के लिए जगह की आवश्यकता होती है। सबसे पहला कदम मौखिक संपर्क तोड़ना है। शब्दों से चर्चा से बचें. इसे रद्द करें, जितनी जल्दी हो सके चले जाएं। यदि यह टेलीफोन पर बातचीत है, तो बस फोन काट दें - यह एक ऐसा कौशल है जो मैंने अपनी पूर्व पत्नी के साथ संवाद करने से सीखा है। यदि बातचीत अच्छी नहीं हो रही है, तो बस "अलविदा" कहें और फोन रख दें। फ़ोन के दूसरी ओर से: "ब्ला ब्ला ब्ला", आप उत्तर देते हैं: "हाँ, अलविदा!" और फ़ोन रख दो. आप बस बातचीत ख़त्म करें. पांच मिनट बाद, जब समझदारी से सोचने की क्षमता आपके पास लौट आती है, तो आप थोड़ा शांत हो जाते हैं, हर चीज के बारे में सोचना संभव हो जाता है कि क्या हुआ और आगे क्या होगा। और केवल भावनाओं में बहकर प्रतिक्रिया देने के बजाय, एक सोच-समझकर प्रतिक्रिया तैयार करना शुरू करें। मेरे लिए, आत्म-जागरूकता में सफलता वास्तव में यह तथ्य थी कि भावनात्मक तनाव के मामले में मैं बोल नहीं सकता। इस स्थिति से बाहर निकलना, यह सोचना और योजना बनाना कि समस्याओं पर कैसे प्रतिक्रिया दें और क्षतिपूर्ति करें - ये उस स्थिति में सही कदम हैं जब आप बोल नहीं सकते। सबसे आसान तरीका उस स्थिति से दूर भागना है जिसमें भावनात्मक तनाव स्वयं प्रकट होता है और इस तनाव में भाग लेना बंद कर दें। उसके बाद आप सोचने में सक्षम हो जाते हैं, जब आप सोच सकते हैं, तो आप बोलने में सक्षम हो जाते हैं, इत्यादि।

वैसे, अदालत में विरोधी वकील आपके साथ ऐसा करने की कोशिश करता है - अब यह स्पष्ट है कि क्यों। क्योंकि वह आपको इस स्थिति तक दबाने की क्षमता रखता है कि उदाहरण के लिए, आप अपना नाम भी नहीं बता सकते। सही मायनों में आप बोल नहीं पाएंगे. यदि आपके साथ ऐसा होता है, और यदि आप जानते हैं कि आप खुद को ऐसी जगह पर पाएंगे जहां मौखिक लड़ाई चल रही है, अदालत जैसी जगह पर, तो आप अपने वकील के साथ आ सकते हैं। वकील आपके लिए खड़ा होगा और मौखिक हमले को रोक देगा, और इसे पूरी तरह से कानूनी तरीके से करेगा, और खोया हुआ ज़ेन स्थान आपके पास वापस आ जाएगा। उदाहरण के लिए, मुझे अपने परिवार को कई बार फोन करना पड़ा, जज इस बारे में काफी दोस्ताना थे, लेकिन विरोधी वकील मुझ पर चिल्लाता रहा, मैं एक शब्द भी नहीं बोल सका। इन मामलों में, मध्यस्थ का उपयोग करना मेरे लिए सबसे अच्छा काम करता है। मध्यस्थ इस सारे दबाव को रोकता है जो आप पर निरंतर प्रवाह में पड़ रहा है, आपको आवश्यक ज़ेन स्थान मिल जाता है, और इसके साथ बोलने की क्षमता वापस आ जाती है। यह ज्ञान का एक पूरा क्षेत्र है जिसमें अध्ययन करने के लिए बहुत कुछ है, अपने भीतर खोजने के लिए बहुत कुछ है, और यह सब उच्च-स्तरीय रणनीतिक निर्णयों में बदल जाता है जो अलग-अलग लोगों के लिए अलग-अलग होते हैं। कुछ लोगों को ऊपर वर्णित समस्याएं नहीं होती हैं; आमतौर पर, जो पेशेवर बिक्री वाले लोग होते हैं उन्हें ये समस्याएं नहीं होती हैं। ये सभी लोग जो शब्दों से अपनी जीविका चलाते हैं - प्रसिद्ध गायक, कवि, धार्मिक नेता और राजनेता, उनके पास हमेशा कहने के लिए कुछ न कुछ होता है। उन्हें ऐसी समस्याएँ नहीं हैं, लेकिन मुझे हैं।

एंड्रयू: यह... अप्रत्याशित था. बहुत अच्छा, हम पहले ही काफी बातें कर चुके हैं और अब इस साक्षात्कार को समाप्त करने का समय आ गया है। हम सम्मेलन में अवश्य मिलेंगे और इस संवाद को जारी रख सकेंगे।' हाइड्रा में मिलते हैं!

आप हाइड्रा 2019 सम्मेलन में क्लिफ के साथ अपनी बातचीत जारी रख सकते हैं, जो 11-12 जुलाई, 2019 को सेंट पीटर्सबर्ग में आयोजित किया जाएगा। वह रिपोर्ट लेकर आएंगे "अज़ुल हार्डवेयर ट्रांजेक्शनल मेमोरी अनुभव". टिकट खरीदे जा सकते हैं आधिकारिक वेबसाइट पर.

स्रोत: www.habr.com