क्लिफ क्लिक — Cratus चे CTO (प्रक्रिया सुधारण्यासाठी IoT सेन्सर्स), अनेक स्टार्टअपचे संस्थापक आणि सह-संस्थापक (रॉकेट रिअलटाइम स्कूल, न्यूरेन्सिक आणि H2O.ai सह) अनेक यशस्वी एक्झिटसह. क्लिफने वयाच्या १५ व्या वर्षी पहिला कंपाइलर लिहिला (टीआरएस झेड-८० साठी पास्कल)! जावा मधील C15 (नोड्स IR चा समुद्र) वरील कामासाठी तो प्रसिद्ध आहे. या कंपायलरने जगाला दाखवून दिले की JIT उच्च-गुणवत्तेचा कोड तयार करू शकते, जे जावाच्या मुख्य आधुनिक सॉफ्टवेअर प्लॅटफॉर्मपैकी एक म्हणून उदयास आलेले घटक होते. त्यानंतर Cliff ने Azul Systems ला शुद्ध Java सॉफ्टवेअरसह 80-कोर मेनफ्रेम तयार करण्यात मदत केली जी 2 मिलीसेकंदांच्या आत 864-गीगाबाइटच्या ढीगावर GC पॉजला सपोर्ट करते. सर्वसाधारणपणे, क्लिफने जेव्हीएमच्या सर्व पैलूंवर कार्य करण्यास व्यवस्थापित केले.

 
ही हॅब्रापोस्ट क्लिफची उत्तम मुलाखत आहे. आम्ही खालील विषयांवर बोलू:

• निम्न-स्तरीय ऑप्टिमायझेशनवर संक्रमण
• मोठे रिफॅक्टरिंग कसे करावे
• किंमत मॉडेल
• निम्न-स्तरीय ऑप्टिमायझेशन प्रशिक्षण
• कामगिरी सुधारण्याची व्यावहारिक उदाहरणे
• तुमची स्वतःची प्रोग्रामिंग भाषा का तयार करा
• कामगिरी अभियंता कारकीर्द
• तांत्रिक आव्हाने
• नोंदणी वाटप आणि मल्टी-कोर बद्दल थोडेसे
• आयुष्यातील सर्वात मोठे आव्हान

मुलाखत द्वारे आयोजित केली जाते:

• आंद्रे सतारिन Amazon Web Services कडून. त्याच्या कारकिर्दीत, तो पूर्णपणे भिन्न प्रकल्पांमध्ये काम करण्यात यशस्वी झाला: त्याने Yandex मधील NewSQL वितरित डेटाबेस, कॅस्परस्की लॅबमधील क्लाउड डिटेक्शन सिस्टम, Mail.ru मधील मल्टीप्लेअर गेम आणि ड्यूश बँकेत परकीय चलन दर मोजण्यासाठी सेवा तपासली. मोठ्या प्रमाणात बॅकएंड आणि वितरित प्रणालीची चाचणी घेण्यात स्वारस्य आहे.
• व्लादिमीर सिटनिकोव्ह Netcracker कडून. NetCracker OS च्या कार्यक्षमतेवर आणि स्केलेबिलिटीवर दहा वर्षांचे काम, टेलिकॉम ऑपरेटरद्वारे नेटवर्क आणि नेटवर्क उपकरणे व्यवस्थापन प्रक्रिया स्वयंचलित करण्यासाठी वापरले जाणारे सॉफ्टवेअर. Java आणि Oracle डेटाबेस कार्यप्रदर्शन समस्यांमध्ये स्वारस्य आहे. अधिकृत PostgreSQL JDBC ड्राइव्हरमध्ये डझनहून अधिक कामगिरी सुधारणांचे लेखक.

निम्न-स्तरीय ऑप्टिमायझेशनवर संक्रमण

आंद्रेई: JIT संकलन, Java आणि सर्वसाधारणपणे कार्यप्रदर्शन कार्याच्या जगात तुम्ही एक मोठे नाव आहात, बरोबर? 

उंच कडा: असं आहे!

आंद्रेई: कार्यप्रदर्शन कार्याबद्दल काही सामान्य प्रश्नांपासून सुरुवात करूया. CPU स्तरावर काम करण्यासारख्या उच्च-स्तरीय आणि निम्न-स्तरीय ऑप्टिमायझेशनमधील निवडीबद्दल तुम्हाला काय वाटते?

उंच कडा: होय, येथे सर्वकाही सोपे आहे. सर्वात वेगवान कोड असा आहे जो कधीही चालत नाही. म्हणून, आपल्याला नेहमी उच्च पातळीपासून प्रारंभ करणे आवश्यक आहे, अल्गोरिदमवर कार्य करा. काही मोठ्या स्थिरांकांनी हस्तक्षेप केल्याशिवाय चांगले O नोटेशन वाईट O नोटेशनला हरवेल. खालच्या स्तराच्या गोष्टी शेवटच्या जातात. सामान्यतः, जर तुम्ही तुमचा उर्वरित स्टॅक पुरेसा ऑप्टिमाइझ केला असेल आणि तरीही काही मनोरंजक सामग्री शिल्लक असेल, तर ती कमी पातळी आहे. पण उच्च पातळीपासून सुरुवात कशी करावी? पुरेसे उच्च-स्तरीय काम झाले आहे हे तुम्हाला कसे कळेल? बरं... नाही. तयार पाककृती नाहीत. आपल्याला समस्या समजून घेणे आवश्यक आहे, आपण काय करणार आहात हे ठरवा (जेणेकरुन भविष्यात अनावश्यक पावले उचलू नयेत) आणि नंतर आपण प्रोफाइलर उघड करू शकता, जे काहीतरी उपयुक्त सांगू शकेल. काही क्षणी, तुम्हाला स्वतःला जाणवेल की तुम्ही अनावश्यक गोष्टींपासून मुक्त झाला आहात आणि काही निम्न-स्तरीय फाइन ट्यूनिंग करण्याची वेळ आली आहे. ही नक्कीच एक विशेष प्रकारची कला आहे. असे बरेच लोक आहेत जे अनावश्यक गोष्टी करत आहेत, परंतु इतक्या वेगाने पुढे जात आहेत की त्यांना उत्पादकतेबद्दल काळजी करण्यास वेळ नाही. पण हा प्रश्न स्पष्टपणे उठेपर्यंत आहे. सामान्यतः ९९% वेळेला मी काय करतो याची कोणीही पर्वा करत नाही, जोपर्यंत एखादी महत्त्वाची गोष्ट गंभीर मार्गावर येते ज्याची कोणालाच पर्वा नसते. आणि इथे प्रत्येकजण तुम्हाला "सुरुवातीपासूनच नीट का काम करत नाही" याविषयी चिडवायला लागतो. सर्वसाधारणपणे, कामगिरीमध्ये सुधारणा करण्यासाठी नेहमीच काहीतरी असते. पण ९९% वेळेस तुमच्याकडे लीड नसते! आपण फक्त काहीतरी कार्य करण्याचा प्रयत्न करत आहात आणि प्रक्रियेत आपल्याला काय महत्वाचे आहे ते समजते. हा तुकडा परिपूर्ण असणे आवश्यक आहे हे आपण कधीही आधीच ओळखू शकत नाही, म्हणून, खरं तर, आपण प्रत्येक गोष्टीत परिपूर्ण असणे आवश्यक आहे. पण हे अशक्य आहे आणि तुम्ही ते करत नाही. निराकरण करण्यासाठी नेहमी बर्‍याच गोष्टी असतात - आणि ते पूर्णपणे सामान्य आहे.

मोठे रिफॅक्टरिंग कसे करावे

आंद्रेई: तुम्ही कामगिरीवर कसे काम करता? ही एक क्रॉस कटिंग समस्या आहे. उदाहरणार्थ, बर्याच विद्यमान कार्यक्षमतेच्या छेदनबिंदूमुळे उद्भवलेल्या समस्यांवर तुम्हाला कधी काम करावे लागले आहे का?

उंच कडा: मी ते टाळण्याचा प्रयत्न करतो. कार्यप्रदर्शन ही समस्या असेल हे मला माहीत असल्यास, मी कोडिंग सुरू करण्यापूर्वी, विशेषत: डेटा स्ट्रक्चर्ससह त्याबद्दल विचार करतो. पण बऱ्याचदा तुम्हाला हे सगळं खूप नंतर कळतं. आणि मग तुम्हाला अत्यंत उपायांकडे जावे लागेल आणि मी ज्याला “पुनर्लेखन आणि विजय” म्हणतो ते करावे लागेल: तुम्हाला एक मोठा तुकडा घ्यावा लागेल. कार्यप्रदर्शन समस्यांमुळे किंवा इतर कशामुळे काही कोड अद्याप पुन्हा लिहावे लागतील. कोड पुन्हा लिहिण्याचे कारण काहीही असो, लहान तुकड्यापेक्षा मोठा तुकडा पुन्हा लिहिणे जवळजवळ नेहमीच चांगले असते. या क्षणी, प्रत्येकजण भीतीने थरथर कापायला लागतो: "अरे देवा, तू इतका कोड स्पर्श करू शकत नाही!" पण खरं तर, हा दृष्टीकोन जवळजवळ नेहमीच चांगला कार्य करतो. तुम्हाला ताबडतोब एक मोठी समस्या स्वीकारण्याची आवश्यकता आहे, त्याभोवती एक मोठे वर्तुळ काढा आणि म्हणा: मी वर्तुळात सर्वकाही पुन्हा लिहीन. सीमा त्याच्या आतील सामग्रीपेक्षा खूपच लहान आहे जी बदलणे आवश्यक आहे. आणि जर अशा सीमारेषेचे वर्णन तुम्हाला आत काम पूर्ण करण्यास अनुमती देते, तर तुमचे हात मोकळे आहेत, तुम्हाला पाहिजे ते करा. एकदा आपण समस्या समजून घेतल्यावर, पुनर्लेखन प्रक्रिया खूप सोपी आहे, म्हणून एक मोठा चावा घ्या!
त्याच वेळी, जेव्हा तुम्ही मोठ्या प्रमाणात पुनर्लेखन करता आणि लक्षात येते की कार्यप्रदर्शन ही समस्या आहे, तेव्हा तुम्ही लगेच त्याबद्दल काळजी करू शकता. हे सहसा "डेटा कॉपी करू नका, शक्य तितका डेटा व्यवस्थापित करा, लहान करा" यासारख्या साध्या गोष्टींमध्ये बदलते. मोठ्या पुनर्लेखनामध्ये, कार्यप्रदर्शन सुधारण्याचे मानक मार्ग आहेत. आणि ते जवळजवळ नेहमीच डेटाभोवती फिरतात.

किंमत मॉडेल

आंद्रेई: एका पॉडकास्टमध्ये तुम्ही उत्पादकतेच्या संदर्भात किमतीच्या मॉडेल्सबद्दल बोललात. तुम्हाला यातून काय म्हणायचे आहे ते तुम्ही स्पष्ट करू शकाल?

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

आंद्रेई: आणि तुम्ही तुमच्या डोक्यात इतका खंड कसा ठेवू शकता? हे अधिक अनुभवाने साध्य होते का? असा अनुभव कुठून येतो?

उंच कडा: बरं, मला माझा अनुभव सर्वात सोप्या मार्गाने मिळाला नाही. मी त्या दिवसात असेंब्लीमध्ये प्रोग्राम केला होता जेव्हा तुम्ही प्रत्येक सूचना समजू शकता. हे मूर्खपणाचे वाटते, परंतु तेव्हापासून Z80 सूचना संच नेहमी माझ्या डोक्यात, माझ्या आठवणीत राहिला आहे. मला बोलण्याच्या एका मिनिटात लोकांची नावे आठवत नाहीत, पण 40 वर्षांपूर्वी लिहिलेला कोड आठवतो. हे मजेदार आहे, हे सिंड्रोमसारखे दिसते "मूर्ख शास्त्रज्ञ».

निम्न-स्तरीय ऑप्टिमायझेशन प्रशिक्षण

आंद्रेई: आत जाण्याचा सोपा मार्ग आहे का?

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

कामगिरी सुधारण्याची व्यावहारिक उदाहरणे

आंद्रेई: उत्पादकतेवर काम करताना आणखी कशाकडे लक्ष द्यावे?

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

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

आणि ते इतके अवघड नाही. जर तुम्ही कोडला उजव्या कोनातून पाहिल्यास, तुम्हाला समस्या लक्षात आल्यावर हे सर्व अगदी सोपे होईल. आपण मेमरी वाटप करणे पूर्णपणे थांबवू नये: फक्त समस्या अशी आहे की आपण काहीतरी वाटप केले आणि ते त्वरित मरते आणि त्याच वेळी ते एक महत्त्वपूर्ण संसाधन बर्न करते, जे या प्रकरणात मेमरी बँडविड्थ आहे. आणि या सर्वाचा परिणाम उत्पादकता कमी होण्यात होतो. x86 वर तुम्हाला प्रोसेसर सायकल सक्रियपणे बर्न करणे आवश्यक आहे, परंतु येथे तुम्ही सर्व मेमरी खूप पूर्वी बर्न केली आहे. डिस्चार्जचे प्रमाण कमी करणे हा उपाय आहे. 
समस्येचा दुसरा भाग असा आहे की मेमरी स्ट्राइप संपल्यावर तुम्ही प्रोफाइलर चालवल्यास, जेव्हा ते घडते, तेव्हा तुम्ही सहसा कॅशे परत येण्याची वाट पाहत आहात कारण ते तुम्ही नुकतेच तयार केलेल्या कचऱ्याने भरलेले आहे, त्या सर्व ओळी. म्हणून, प्रत्येक लोड किंवा स्टोअर ऑपरेशन मंद होते, कारण यामुळे कॅशे चुकते - संपूर्ण कॅशे मंद झाला आहे, कचरा सोडण्याची वाट पाहत आहे. म्हणून, प्रोफाइलर संपूर्ण लूपमध्ये फक्त उबदार यादृच्छिक आवाज दर्शवेल - कोडमध्ये कोणतीही वेगळी गरम सूचना किंवा स्थान नसेल. फक्त आवाज. आणि जर तुम्ही GC सायकल बघितली तर ती सर्व यंग जनरेशन आणि सुपर फास्ट - मायक्रोसेकंद किंवा मिलीसेकंद कमाल आहेत. शेवटी, ही सर्व स्मृती त्वरित मरते. तुम्ही अब्जावधी गीगाबाइट्स वाटप करता, आणि तो त्यांना कापतो, आणि कापतो आणि पुन्हा कापतो. हे सर्व फार लवकर घडते. असे दिसून आले की स्वस्त GC सायकल आहेत, संपूर्ण सायकलमध्ये उबदार आवाज आहे, परंतु आम्हाला 5x स्पीडअप मिळवायचा आहे. या क्षणी, काहीतरी तुमच्या डोक्यात बंद झाले पाहिजे आणि आवाज आला: "हे का आहे?!" मेमरी स्ट्रिप ओव्हरफ्लो क्लासिक डीबगरमध्ये प्रदर्शित होत नाही; तुम्हाला हार्डवेअर कार्यप्रदर्शन काउंटर डीबगर चालवावे लागेल आणि ते स्वतः आणि थेट पहावे लागेल. परंतु या तीन लक्षणांवरून याचा थेट संशय येऊ शकत नाही. तिसरे लक्षण म्हणजे तुम्ही काय हायलाइट करता ते पाहता, प्रोफाइलरला विचारा आणि तो उत्तर देतो: "तुम्ही अब्जावधी पंक्ती बनवल्या, पण GC ने विनामूल्य काम केले." हे घडताच, तुम्हाला समजेल की तुम्ही खूप जास्त वस्तू तयार केल्या आहेत आणि संपूर्ण मेमरी लेन जाळून टाकली आहे. हे शोधण्याचा एक मार्ग आहे, परंतु ते स्पष्ट नाही. 

समस्या डेटा स्ट्रक्चरमध्ये आहे: जे घडते ते सर्व काही अंतर्भूत असलेली बेअर स्ट्रक्चर, ती खूप मोठी आहे, ती डिस्कवर 2.7G आहे, त्यामुळे या गोष्टीची प्रत बनवणे अत्यंत अवांछित आहे - तुम्हाला ते नेटवर्क बाइट बफरमधून लगेच लोड करायचे आहे. रजिस्टरमध्ये, जेणेकरून ओळ पुढे-मागे पाच वेळा वाचू नये. दुर्दैवाने, Java तुम्हाला डीफॉल्टनुसार JDK चा भाग म्हणून अशी लायब्ररी देत ​​नाही. पण हे क्षुल्लक आहे, बरोबर? मूलत:, या कोडच्या 5-10 ओळी आहेत ज्याचा वापर तुमचा स्वतःचा बफर केलेला स्ट्रिंग लोडर अंमलात आणण्यासाठी केला जाईल, जे स्ट्रिंग क्लासच्या वर्तनाची पुनरावृत्ती करते, तर अंतर्निहित बाइट बफरभोवती एक आवरण असते. परिणामी, असे दिसून आले की आपण जवळजवळ स्ट्रिंगसह कार्य करत आहात, परंतु प्रत्यक्षात बफरचे पॉइंटर्स तेथे हलत आहेत, आणि कच्चे बाइट्स कुठेही कॉपी केले जात नाहीत आणि अशा प्रकारे तेच बफर पुन्हा पुन्हा वापरले जातात आणि या बाइट बफरचे छुपे दुहेरी-बफरिंग सारख्या गोष्टींसाठी ऑपरेटिंग सिस्टीम स्वत: ला घेण्यास आनंदित आहे आणि आपण अनावश्यक डेटाच्या अंतहीन प्रवाहातून जात नाही. तसे, तुम्हाला समजले आहे की GC सह काम करताना, प्रत्येक मेमरी वाटप शेवटच्या GC सायकल नंतर प्रोसेसरला दिसणार नाही याची हमी दिली जाते? म्हणून, हे सर्व शक्यतो कॅशेमध्ये असू शकत नाही आणि नंतर 100% हमी चुकते. पॉइंटरसह काम करताना, x86 वर, मेमरीमधून रजिस्टर वजा करण्यासाठी 1-2 घड्याळाची चक्रे लागतात आणि हे घडताच, तुम्ही पैसे द्या, पैसे द्या, पैसे द्या, कारण मेमरी सर्व चालू आहे. नऊ कॅशे - आणि ही मेमरी वाटपाची किंमत आहे. वास्तविक मूल्य.

दुसऱ्या शब्दांत, डेटा संरचना बदलणे सर्वात कठीण गोष्ट आहे. आणि एकदा का तुम्हाला समजले की तुम्ही चुकीची डेटा रचना निवडली आहे जी नंतर कार्यक्षमतेला नष्ट करेल, सहसा बरेच काम करायचे असते, परंतु जर तुम्ही तसे केले नाही तर गोष्टी आणखी वाईट होतील. सर्व प्रथम, आपल्याला डेटा स्ट्रक्चर्सबद्दल विचार करणे आवश्यक आहे, हे महत्वाचे आहे. येथे मुख्य किंमत फॅट डेटा स्ट्रक्चर्सवर पडते, जी "मी डेटा स्ट्रक्चर X डेटा स्ट्रक्चर Y मध्ये कॉपी केली आहे कारण मला Y चा आकार अधिक आवडतो" या शैलीत वापरला जाऊ लागला आहे. परंतु कॉपी ऑपरेशन (जे स्वस्त वाटते) प्रत्यक्षात मेमरी बँडविड्थ वाया घालवते आणि तिथेच सर्व वाया गेलेल्या अंमलबजावणीचा वेळ दफन केला जातो. माझ्याकडे JSON ची एक मोठी स्ट्रिंग असल्यास आणि मला ती POJO च्या संरचित DOM ट्रीमध्ये किंवा कशात तरी बदलायची असल्यास, ती स्ट्रिंग पार्स करणे आणि POJO बनवणे, आणि नंतर POJO मध्ये पुन्हा प्रवेश करणे, याचा परिणाम अनावश्यक खर्च होईल - हे आहे स्वस्त नाही. तुम्ही POJO च्या भोवती स्ट्रिंगच्या आसपास धावत असल्याशिवाय. ऑफहँड, तुम्ही त्याऐवजी स्ट्रिंग डिक्रिप्ट करण्याचा प्रयत्न करू शकता आणि ते कोणत्याही POJO मध्ये न बदलता तेथून तुम्हाला आवश्यक तेच काढू शकता. जर हे सर्व अशा मार्गावर घडले की ज्यातून जास्तीत जास्त कामगिरी आवश्यक आहे, तुमच्यासाठी कोणतेही POJO नाहीत, तर तुम्हाला थेट लाइनमध्ये जावे लागेल.

तुमची स्वतःची प्रोग्रामिंग भाषा का तयार करा

आंद्रेई: तुम्ही म्हणालात की खर्चाचे मॉडेल समजून घेण्यासाठी तुम्हाला तुमची स्वतःची छोटी भाषा लिहावी लागेल...

उंच कडा: भाषा नाही तर संकलक. भाषा आणि संकलक या दोन भिन्न गोष्टी आहेत. सर्वात महत्वाचा फरक आपल्या डोक्यात आहे. 

आंद्रेई: तसे, माझ्या माहितीनुसार तुम्ही तुमच्या स्वतःच्या भाषा तयार करण्याचा प्रयोग करत आहात. कशासाठी?

उंच कडा: कारण मी करू शकतो! मी अर्ध-निवृत्त आहे, त्यामुळे हा माझा छंद आहे. मी आयुष्यभर इतर लोकांच्या भाषा राबवत आलो आहे. मी माझ्या कोडिंग शैलीवरही खूप काम केले. आणि कारण मला इतर भाषांमध्ये समस्या दिसतात. मी पाहतो की परिचित गोष्टी करण्याचे आणखी चांगले मार्ग आहेत. आणि मी त्यांचा वापर करेन. मी फक्त स्वतःमध्ये, Java मध्ये, Python मध्ये, इतर कोणत्याही भाषेतील समस्या पाहून कंटाळलो आहे. मी आता रिऍक्ट नेटिव्ह, JavaScript आणि Elm मध्ये एक छंद म्हणून लिहितो जे निवृत्तीबद्दल नाही तर सक्रिय कामाबद्दल आहे. मी पायथनमध्ये देखील लिहितो आणि बहुधा, Java बॅकएंडसाठी मशीन लर्निंगवर काम करत राहीन. बर्‍याच लोकप्रिय भाषा आहेत आणि त्या सर्वांमध्ये मनोरंजक वैशिष्ट्ये आहेत. प्रत्येकजण त्यांच्या स्वत: च्या मार्गाने चांगला आहे आणि आपण या सर्व वैशिष्ट्यांना एकत्र आणण्याचा प्रयत्न करू शकता. म्हणून, मी माझ्या आवडीच्या गोष्टींचा अभ्यास करत आहे, भाषेचे वर्तन, वाजवी शब्दार्थ मांडण्याचा प्रयत्न करत आहे. आणि आतापर्यंत मी यशस्वी आहे! याक्षणी मी मेमरी सिमेंटिक्सशी झुंजत आहे, कारण मला ते C आणि Java प्रमाणे हवे आहे आणि लोड आणि स्टोअरसाठी एक मजबूत मेमरी मॉडेल आणि मेमरी सिमेंटिक्स मिळवायचे आहेत. त्याच वेळी, हॅस्केल प्रमाणे स्वयंचलित प्रकार अनुमान काढा. येथे, मी सी आणि जावा दोन्हीमध्ये मेमरी वर्कसह हास्केल-समान प्रकार अनुमान मिसळण्याचा प्रयत्न करीत आहे. मी गेल्या २-३ महिन्यांपासून हेच ​​करतोय, उदाहरणार्थ.

आंद्रेई: जर तुम्ही अशी भाषा तयार केली की जी इतर भाषांमधून चांगले पैलू घेते, तर तुम्हाला असे वाटते की कोणीतरी उलट करेल: तुमच्या कल्पना घ्या आणि त्यांचा वापर करा?

उंच कडा: नवीन भाषा अशाच दिसतात! जावा सी सारखा का आहे? कारण C चा एक चांगला सिंटॅक्स होता जो सर्वांना समजला होता आणि Java ला या सिंटॅक्समुळे प्रेरणा मिळाली होती, टाइप सेफ्टी, अॅरे बाउंड चेकिंग, GC, आणि त्यांनी C मधून काही गोष्टी सुधारल्या. त्यांनी स्वतःची जोडणी केली. पण त्यांना खूप प्रेरणा मिळाली, बरोबर? प्रत्येकजण आपल्या आधी आलेल्या दिग्गजांच्या खांद्यावर उभा आहे - अशीच प्रगती होते.

आंद्रेई: मला समजले म्हणून तुमची भाषा स्मृती सुरक्षित राहील. रस्टकडून उधार चेकरसारखे काहीतरी अंमलात आणण्याचा विचार केला आहे का? तू त्याच्याकडे बघितलंस का, तुला त्याच्याबद्दल काय वाटतं?

उंच कडा: बरं, मी युगानुयुगे C लिहित आहे, हे सर्व malloc आणि विनामूल्य, आणि व्यक्तिचलितपणे आयुष्यभर व्यवस्थापित करत आहे. तुम्हाला माहिती आहे, 90-95% मॅन्युअली नियंत्रित आयुर्मानाची रचना समान असते. आणि ते स्वहस्ते करणे खूप, खूप वेदनादायक आहे. तेथे काय चालले आहे आणि तुम्ही तुमच्या कृतीतून काय साध्य केले हे कंपाइलरने तुम्हाला सांगावे असे मला वाटते. काही गोष्टींसाठी, बोरो चेकर हे बॉक्सच्या बाहेर करतो. आणि त्यात आपोआप माहिती प्रदर्शित झाली पाहिजे, सर्व काही समजले पाहिजे आणि ही समज मांडण्याचे माझ्यावर ओझेही नाही. त्याने किमान स्थानिक सुटका विश्लेषण करणे आवश्यक आहे, आणि केवळ ते अयशस्वी झाले तरच त्याला जीवनकालाचे वर्णन करणार्‍या प्रकारचे भाष्य जोडणे आवश्यक आहे - आणि अशी योजना कर्ज तपासकापेक्षा किंवा खरोखर अस्तित्वात असलेल्या कोणत्याही मेमरी तपासकापेक्षा खूपच गुंतागुंतीची आहे. "सर्व काही ठीक आहे" आणि "मला काहीही समजत नाही" मधील निवड - नाही, काहीतरी चांगले असले पाहिजे. 
म्हणून, ज्याने C मध्ये बरेच कोड लिहिले आहे, मला वाटते की स्वयंचलित आजीवन नियंत्रणासाठी समर्थन असणे ही सर्वात महत्वाची गोष्ट आहे. जावा किती मेमरी वापरते याचा मला कंटाळा आला आहे आणि मुख्य तक्रार जीसी आहे. जेव्हा तुम्ही Java मध्ये मेमरी वाटप करता, तेव्हा तुम्हाला मागील GC सायकलमध्ये स्थानिक असलेली मेमरी परत मिळणार नाही. अधिक अचूक मेमरी व्यवस्थापन असलेल्या भाषांमध्ये हे घडत नाही. तुम्ही malloc कॉल केल्यास, तुम्हाला लगेच मेमरी मिळते जी सामान्यतः नुकतीच वापरली जाते. सहसा तुम्ही मेमरीसह काही तात्पुरत्या गोष्टी करता आणि लगेच त्या परत करा. आणि ते ताबडतोब malloc पूलमध्ये परत येते आणि पुढील malloc सायकल पुन्हा बाहेर काढते. त्यामुळे, वास्तविक मेमरी वापर एका दिलेल्या वेळी जिवंत वस्तूंच्या संचापर्यंत कमी केला जातो, तसेच गळती होते. आणि जर सर्व काही पूर्णपणे अशोभनीय मार्गाने गळती होत नसेल तर, बहुतेक मेमरी कॅशे आणि प्रोसेसरमध्ये संपते आणि ते त्वरीत कार्य करते. पण malloc सह पुष्कळ मॅन्युअल मेमरी व्यवस्थापन आवश्यक आहे आणि योग्य क्रमाने, योग्य ठिकाणी फ्री कॉल केला आहे. रस्ट स्वतःच हे योग्यरित्या हाताळू शकते आणि बर्‍याच प्रकरणांमध्ये आणखी चांगले कार्यप्रदर्शन देऊ शकते, कारण मेमरी वापर फक्त वर्तमान गणनेपर्यंत संकुचित केला जातो - मेमरी मोकळी करण्यासाठी पुढील GC सायकलची वाट पाहण्याच्या विरूद्ध. परिणामी, आम्हाला कार्यप्रदर्शन सुधारण्याचा एक अतिशय मनोरंजक मार्ग मिळाला. आणि जोरदार शक्तिशाली - म्हणजे, फिनटेकसाठी डेटावर प्रक्रिया करताना मी अशा गोष्टी केल्या आणि यामुळे मला सुमारे पाच पट वेग मिळू शकला. हे खूप मोठे प्रोत्साहन आहे, विशेषत: अशा जगात जेथे प्रोसेसर वेगवान होत नाहीत आणि आम्ही अजूनही सुधारणांची वाट पाहत आहोत.

कामगिरी अभियंता कारकीर्द

आंद्रेई: मला सर्वसाधारणपणे करिअरबद्दल देखील विचारायचे आहे. तुम्‍ही हॉटस्‍पॉटवरील तुमच्‍या जेआयटी कामामुळे प्रसिद्धी मिळवली आणि नंतर अझुलमध्‍ये स्‍थानांतरित झाला, जी देखील एक JVM कंपनी आहे. पण आम्ही आधीच सॉफ्टवेअरपेक्षा हार्डवेअरवर जास्त काम करत होतो. आणि मग त्यांनी अचानक बिग डेटा आणि मशीन लर्निंगकडे आणि नंतर फसवणूक शोधण्याकडे स्विच केले. हे कसे घडले? ही विकासाची खूप वेगळी क्षेत्रे आहेत.

उंच कडा: मी बर्‍याच काळापासून प्रोग्रामिंग करत आहे आणि मी बरेच वेगवेगळे वर्ग घेण्यास व्यवस्थापित केले आहे. आणि जेव्हा लोक म्हणतात: “अरे, तूच आहेस ज्याने Java साठी JIT केले!”, हे नेहमीच मजेदार असते. पण त्याआधी, मी पोस्टस्क्रिप्टच्या क्लोनवर काम करत होतो - ती भाषा जी ऍपलने त्याच्या लेझर प्रिंटरसाठी वापरली होती. आणि त्याआधी मी फोर्थ भाषेची अंमलबजावणी केली. मला वाटते की माझ्यासाठी सामान्य थीम साधन विकास आहे. माझे संपूर्ण आयुष्य मी अशी साधने बनवत आलो आहे ज्याद्वारे इतर लोक त्यांचे छान कार्यक्रम लिहितात. परंतु मी ऑपरेटिंग सिस्टम, ड्रायव्हर्स, कर्नल-लेव्हल डीबगर, ओएस डेव्हलपमेंटसाठी भाषांच्या विकासामध्ये देखील सामील होतो, जे क्षुल्लकपणे सुरू झाले, परंतु कालांतराने अधिकाधिक जटिल होत गेले. परंतु मुख्य विषय अजूनही साधनांचा विकास आहे. माझ्या आयुष्याचा एक मोठा भाग अझुल आणि सन मध्ये गेला आणि तो जावा बद्दल होता. पण जेव्हा मी बिग डेटा आणि मशीन लर्निंगमध्ये प्रवेश केला, तेव्हा मी माझी फॅन्सी हॅट परत घातली आणि म्हणालो, "अरे, आता आमच्याकडे एक क्षुल्लक समस्या आहे, आणि बर्याच मनोरंजक गोष्टी चालू आहेत आणि लोक गोष्टी करत आहेत." हा एक उत्तम विकास मार्ग आहे.

होय, मला खरोखर वितरित संगणन आवडते. सी मध्ये विद्यार्थी म्हणून माझी पहिली नोकरी जाहिरात प्रोजेक्टवर होती. हे Zilog Z80 चिप्सवर संगणकीय पद्धतीने वितरीत केले गेले ज्याने वास्तविक अॅनालॉग विश्लेषकाद्वारे तयार केलेल्या analog OCR साठी डेटा संकलित केला. तो एक मस्त आणि पूर्णपणे वेडा विषय होता. परंतु काही समस्या होत्या, काही भाग योग्यरित्या ओळखला गेला नाही, म्हणून तुम्हाला एक चित्र काढून ते एखाद्या व्यक्तीला दाखवावे लागले जे आधीच त्यांच्या डोळ्यांनी वाचू शकतील आणि ते काय बोलले आहे याची तक्रार करू शकतील, आणि म्हणून डेटासह नोकर्‍या होत्या आणि या नोकर्‍या त्यांची स्वतःची भाषा होती. एक बॅकएंड होता ज्याने या सर्वांवर प्रक्रिया केली - Z80s vt100 टर्मिनल्सच्या समांतर चालत होते - प्रति व्यक्ती एक, आणि Z80 वर एक समांतर प्रोग्रामिंग मॉडेल होते. सर्व Z80 द्वारे तारा कॉन्फिगरेशनमध्ये सामायिक केलेल्या मेमरीचा काही सामान्य भाग; बॅकप्लेन देखील सामायिक केले गेले आणि अर्धा RAM नेटवर्कमध्ये सामायिक केला गेला आणि दुसरा अर्धा खाजगी होता किंवा दुसर्‍या कशावर गेला. सामायिक... अर्ध-सामायिक मेमरीसह अर्थपूर्णपणे जटिल समांतर वितरित प्रणाली. हे कधी होते... मला आठवतही नाही, ८० च्या दशकाच्या मध्यात कुठेतरी. खूप पूर्वीपासून. 
होय, समजू की 30 वर्षे खूप पूर्वीची आहेत. वितरित संगणनाशी संबंधित समस्या बर्याच काळापासून अस्तित्वात आहेत; लोक बर्याच काळापासून युद्ध करत आहेत बियोवुल्फ़- क्लस्टर्स. असे क्लस्टर सारखे दिसतात... उदाहरणार्थ: इथरनेट आहे आणि तुमचा वेगवान x86 या इथरनेटशी जोडला गेला आहे, आणि आता तुम्हाला बनावट सामायिक मेमरी मिळवायची आहे, कारण तेव्हा कोणीही वितरित संगणन कोडिंग करू शकत नव्हते, ते खूप कठीण होते आणि त्यामुळे x86 वरील संरक्षण मेमरी पृष्ठांसह बनावट सामायिक मेमरी होती, आणि जर तुम्ही या पृष्ठावर लिहिले, तर आम्ही इतर प्रोसेसरना सांगितले की जर त्यांनी समान सामायिक मेमरीमध्ये प्रवेश केला तर ते तुमच्याकडून लोड केले जाणे आवश्यक आहे आणि अशा प्रकारे समर्थन करण्यासाठी प्रोटोकॉलसारखे काहीतरी कॅशे सुसंगतता दिसून आली आणि यासाठी सॉफ्टवेअर. मनोरंजक संकल्पना. खरी अडचण अर्थातच काही वेगळीच होती. या सर्वांनी कार्य केले, परंतु आपल्याला कार्यप्रदर्शन समस्या त्वरीत आल्या, कारण कोणालाही कार्यप्रदर्शन मॉडेल्स चांगल्या पातळीवर समजले नाहीत - तेथे कोणते मेमरी ऍक्सेस पॅटर्न आहेत, नोड्स एकमेकांना सतत पिंग करत नाहीत याची खात्री कशी करावी इत्यादी.

मी H2O मध्ये जे समोर आणले ते असे आहे की समांतरता कुठे लपलेली आहे आणि कुठे नाही हे ठरवण्यासाठी स्वतः विकासक जबाबदार आहेत. मी कोडिंग मॉडेल घेऊन आलो ज्यामुळे उच्च-कार्यक्षमता कोड लिहिणे सोपे आणि सोपे होते. पण हळू चालणारा कोड लिहिणे कठीण आहे, ते वाईट दिसेल. आपल्याला हळू कोड लिहिण्याचा गंभीरपणे प्रयत्न करणे आवश्यक आहे, आपल्याला मानक नसलेल्या पद्धती वापराव्या लागतील. ब्रेकिंग कोड पहिल्या दृष्टीक्षेपात दृश्यमान आहे. परिणामी, तुम्ही सहसा जलद चालणारा कोड लिहिता, परंतु सामायिक मेमरीच्या बाबतीत काय करावे हे तुम्हाला शोधून काढावे लागेल. हे सर्व मोठ्या अॅरेशी जोडलेले आहे आणि तेथील वर्तन समांतर Java मधील नॉन-व्होलॅटाइल लार्ज अॅरेसारखेच आहे. म्हणजे, कल्पना करा की दोन थ्रेड्स समांतर अॅरेवर लिहितात, त्यापैकी एक जिंकतो आणि दुसरा हरतो, आणि तुम्हाला माहित नाही की कोणते आहे. जर ते अस्थिर नसतील, तर ऑर्डर आपल्याला पाहिजे ते असू शकते - आणि हे खरोखर चांगले कार्य करते. लोक ऑपरेशन्सच्या क्रमाची खरोखर काळजी घेतात, ते योग्य ठिकाणी अस्थिर ठेवतात आणि त्यांना योग्य ठिकाणी मेमरी-संबंधित कार्यप्रदर्शन समस्यांची अपेक्षा असते. अन्यथा, ते फक्त 1 ते N पर्यंत लूपच्या स्वरूपात कोड लिहतील, जेथे N काही ट्रिलियन्स आहे, या आशेने की सर्व जटिल प्रकरणे आपोआप समांतर होतील - आणि ते तेथे कार्य करत नाही. परंतु H2O मध्ये हे Java किंवा Scala नाही; तुम्हाला हवे असल्यास तुम्ही "Java वजा वजा" म्हणून विचार करू शकता. ही एक अतिशय स्पष्ट प्रोग्रामिंग शैली आहे आणि लूप आणि अॅरेसह साधे C किंवा Java कोड लिहिण्यासारखे आहे. परंतु त्याच वेळी, मेमरीवर टेराबाइट्समध्ये प्रक्रिया केली जाऊ शकते. मी अजूनही H2O वापरतो. मी ते वेळोवेळी वेगवेगळ्या प्रकल्पांमध्ये वापरतो - आणि तरीही ती सर्वात वेगवान गोष्ट आहे, त्याच्या प्रतिस्पर्ध्यांपेक्षा डझनभर पटीने वेगवान आहे. जर तुम्ही स्तंभीय डेटासह बिग डेटा करत असाल, तर H2O वर मात करणे खूप कठीण आहे.

तांत्रिक आव्हाने

आंद्रेई: तुमच्या संपूर्ण कारकिर्दीत तुमचे सर्वात मोठे आव्हान कोणते आहे?

उंच कडा: आपण समस्येच्या तांत्रिक किंवा गैर-तांत्रिक भागावर चर्चा करत आहोत का? मी म्हणेन की सर्वात मोठी आव्हाने तांत्रिक नाहीत. 
तांत्रिक आव्हानांसाठी. मी फक्त त्यांचा पराभव केला. मला सर्वात मोठा काय होता हे देखील माहित नाही, परंतु काही खूपच मनोरंजक होते ज्यांना थोडा वेळ लागला, मानसिक संघर्ष. मी सनला गेलो तेव्हा मला खात्री होती की मी एक जलद संकलक बनवणार आहे आणि मी कधीही यशस्वी होणार नाही असे प्रतिसादात वरिष्ठांनी सांगितले. पण मी या मार्गाचा अवलंब केला, रजिस्टर वाटप करणाऱ्यावर एक कंपाइलर लिहिला आणि ते खूप जलद होते. हे आधुनिक C1 प्रमाणेच वेगवान होते, परंतु त्यावेळेस वाटप करणारा खूपच हळू होता, आणि दृष्टीक्षेपात ही एक मोठी डेटा संरचना समस्या होती. मला ग्राफिकल रेजिस्टर ऍलोकेटर लिहिण्यासाठी त्याची गरज होती आणि कोड एक्स्प्रेसिव्हनेस आणि स्पीड मधील दुविधा मला समजली नाही, जी त्या काळात अस्तित्वात होती आणि खूप महत्वाची होती. असे दिसून आले की डेटा संरचना सामान्यत: त्या वेळच्या x86s वर कॅशे आकारापेक्षा जास्त असते आणि म्हणूनच, जर मी सुरुवातीला असे गृहीत धरले की रजिस्टर वाटप करणारा एकूण गोंधळाच्या वेळेच्या 5-10 टक्के काम करेल, तर प्रत्यक्षात ते असे झाले. 50 टक्के.

जसजसा काळ पुढे सरकत गेला, तसतसा कंपायलर अधिक स्वच्छ आणि कार्यक्षम बनला, अधिक प्रकरणांमध्ये भयंकर कोड निर्माण करणे थांबवले आणि C कंपायलर जे तयार करतो त्याप्रमाणे कार्यप्रदर्शन वाढू लागले. अर्थातच, आपण असे काही बकवास लिहितो की C देखील वेग वाढवत नाही. . तुम्ही C सारखा कोड लिहिल्यास, तुम्हाला अधिक प्रकरणांमध्ये C सारखे कार्यप्रदर्शन मिळेल. आणि तुम्ही जितके पुढे गेलात, तितक्या वेळा तुम्हाला असे कोड मिळतात की जे लेव्हल C सोबत असिम्प्टोटिकपणे एकरूप होते, रजिस्टर वाटप करणारा काहीतरी पूर्ण दिसू लागला... तुमचा कोड वेगवान किंवा हळू चालतो याची पर्वा न करता. मी वाटपकर्त्यावर काम करत राहिलो जेणेकरून ते अधिक चांगले निवडतील. तो हळू आणि हळू झाला, परंतु इतर कोणीही सामना करू शकत नाही अशा परिस्थितीत त्याने चांगली आणि चांगली कामगिरी दिली. मी रजिस्टर ऍलोकेटरमध्ये जाऊ शकतो, तिथे एक महिना काम करू शकतो आणि अचानक संपूर्ण कोड 5% वेगाने कार्यान्वित होऊ शकतो. हे वेळोवेळी घडले आणि नोंदणीचे वाटप करणारा एक कलाकृती बनला - प्रत्येकाला ते आवडले किंवा त्याचा तिरस्कार झाला आणि अकादमीतील लोकांनी "सर्व काही अशा प्रकारे का केले जाते" या विषयावर प्रश्न विचारले, का नाही. ओळ स्कॅन, आणि काय फरक आहे. उत्तर अजूनही सारखेच आहे: ग्राफ कलरिंगवर आधारित वाटप करणारा आणि बफर कोडसह अत्यंत काळजीपूर्वक कार्य करणे हे विजयाच्या शस्त्रासारखे आहे, सर्वोत्तम संयोजन ज्याला कोणीही पराभूत करू शकत नाही. आणि ही एक नॉन-स्पष्ट गोष्ट आहे. संकलक तेथे जे काही करतो त्या बर्‍यापैकी अभ्यासलेल्या गोष्टी आहेत, जरी त्या देखील कलेच्या पातळीवर आणल्या गेल्या आहेत. मी नेहमी अशा गोष्टी केल्या ज्या कंपायलरला कलाकृतीमध्ये बदलायला हव्या होत्या. परंतु यापैकी काहीही असामान्य नव्हते - रजिस्टर वाटपकर्त्याशिवाय. युक्ती सावधगिरी बाळगणे आहे कापून लोड अंतर्गत आणि, जर असे घडले (स्वारस्य असल्यास मी अधिक तपशीलवार स्पष्ट करू शकतो), याचा अर्थ असा की कार्यप्रदर्शन शेड्यूलमध्ये घसरण होण्याच्या जोखमीशिवाय तुम्ही अधिक आक्रमकपणे इनलाइन करू शकता. त्या दिवसांत, पूर्ण-स्केल कंपाइलर्सचा एक समूह होता, ज्यात बाऊबल्स आणि शिट्ट्या टांगलेल्या होत्या, ज्यात रजिस्टर वाटप करणारे होते, परंतु इतर कोणीही करू शकत नव्हते.

समस्या अशी आहे की जर तुम्ही इनलाइनिंग क्षेत्रामध्ये इनलाइनिंग, वाढ आणि वाढ करण्याच्या अधीन असलेल्या पद्धती जोडल्या तर, वापरलेल्या मूल्यांचा संच त्वरित नोंदणीच्या संख्येपेक्षा जास्त असेल आणि तुम्हाला ते कापावे लागतील. जेव्हा वाटपकर्त्याने हार पत्करली तेव्हा गंभीर पातळी येते आणि गळतीसाठी एक चांगला उमेदवार दुसर्‍या किमतीचा असतो, आपण काही सामान्यतः जंगली गोष्टी विकू शकता. येथे इनलाइनिंगचे मूल्य असे आहे की आपण कॉलिंग आणि सेव्हिंगसाठी ओव्हरहेड, ओव्हरहेडचा काही भाग गमावला आहे, आपण आतील मूल्ये पाहू शकता आणि त्यांना अधिक अनुकूल करू शकता. इनलाइनिंगची किंमत अशी आहे की मोठ्या प्रमाणात लाइव्ह व्हॅल्यूज तयार होतात आणि जर तुमचा रजिस्टर ऍलोकेटर आवश्यकतेपेक्षा जास्त जळला तर तुम्ही लगेच गमावाल. म्हणून, बहुतेक वाटपकर्त्यांना एक समस्या आहे: जेव्हा इनलाइनिंग विशिष्ट रेषा ओलांडते तेव्हा जगातील प्रत्येक गोष्ट कमी होऊ लागते आणि उत्पादनक्षमता शौचालयात खाली आणली जाऊ शकते. जे कंपाइलर अंमलात आणतात ते काही ह्युरिस्टिक्स जोडतात: उदाहरणार्थ, इनलाइनिंग थांबवणे, काही मोठ्या आकारापासून सुरू करणे, कारण वाटप सर्वकाही खराब करेल. अशा प्रकारे कामगिरीच्या आलेखात एक किंक तयार होते - तुम्ही इनलाइन, इनलाइन, कामगिरी हळूहळू वाढते - आणि नंतर बूम! - ते स्विफ्ट जॅकसारखे खाली पडते कारण तुम्ही खूप रेंगाळले आहे. जावाच्या आगमनापूर्वी सर्वकाही अशा प्रकारे कार्य करत होते. Java ला खूप जास्त इनलाइनिंगची आवश्यकता आहे, म्हणून मला माझा वाटप करणारा अधिक आक्रमक बनवावा लागला जेणेकरून ते क्रॅश होण्याऐवजी बाहेर पडेल आणि जर तुम्ही खूप जास्त इनलाइन केले तर ते सांडण्यास सुरवात होते, परंतु "नो मोअर स्पिलिंग" क्षण अजूनही येतो. हे एक मनोरंजक निरीक्षण आहे आणि ते माझ्याकडे कोठेही आले नाही, स्पष्ट नाही, परंतु त्याचा चांगला फायदा झाला. मी आक्रमक इनलाइनिंग केले आणि ते मला अशा ठिकाणी घेऊन गेले जेथे Java आणि C कार्यप्रदर्शन शेजारी शेजारी काम करते. ते खरोखर जवळ आहेत - मी जावा कोड लिहू शकतो जो C कोडपेक्षा लक्षणीयरीत्या वेगवान आहे आणि त्यासारख्या गोष्टी, परंतु सरासरी, गोष्टींच्या मोठ्या चित्रात, ते अंदाजे तुलनात्मक आहेत. मला वाटते की या गुणवत्तेचा एक भाग म्हणजे रजिस्टर वाटप करणारा, जो मला शक्य तितक्या मूर्खपणे इनलाइन करण्याची परवानगी देतो. मी जे काही पाहतो ते मी फक्त इनलाइन करतो. येथे प्रश्न असा आहे की वाटपकर्ता चांगले कार्य करतो की नाही, परिणाम हुशारीने काम करणारा कोड आहे का. हे एक मोठे आव्हान होते: हे सर्व समजून घेणे आणि ते कार्यान्वित करणे.

नोंदणी वाटप आणि मल्टी-कोर बद्दल थोडेसे

Владимир: रजिस्टर वाटप सारख्या समस्या काहीशा चिरंतन, अंतहीन विषयासारख्या वाटतात. मला आश्चर्य वाटते की अशी एखादी कल्पना कधी आली आहे जी आशादायक वाटली आणि नंतर सरावात अयशस्वी झाली?

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

Владимир: एखाद्याला अशी भावना येते की वाटपकर्त्यांमध्ये पेंटिंगसारख्या गोष्टी ही एक समस्या आहे जी आधीच सोडवली गेली आहे. बरं, हे तुमच्यासाठी ठरवलं आहे, तुम्ही काय म्हणत आहात याचा विचार करून, मग ते योग्य आहे का...

उंच कडा: हे तसे सोडवले जात नाही. तुम्हीच ते "निराकरण" मध्ये बदलले पाहिजे. कठीण समस्या आहेत आणि त्यांचे निराकरण करणे आवश्यक आहे. एकदा हे पूर्ण झाल्यावर, उत्पादकतेवर काम करण्याची वेळ आली आहे. तुम्हाला त्यानुसार या कामाशी संपर्क साधण्याची आवश्यकता आहे - बेंचमार्क करा, मेट्रिक्स गोळा करा, जेव्हा तुम्ही मागील आवृत्तीवर परत आला तेव्हा तुमच्या जुन्या हॅकने पुन्हा काम करण्यास सुरुवात केली (किंवा उलट, थांबली) परिस्थिती स्पष्ट करा. आणि जोपर्यंत तुम्ही काही साध्य करत नाही तोपर्यंत हार मानू नका. मी आधीच म्हटल्याप्रमाणे, जर काही छान कल्पना असतील ज्या कार्य करत नाहीत, परंतु कल्पनांच्या नोंदणीच्या वाटपाच्या क्षेत्रात ते अंदाजे अंतहीन आहे. आपण, उदाहरणार्थ, वैज्ञानिक प्रकाशने वाचू शकता. जरी आता हे क्षेत्र अधिक हळूहळू हलू लागले आहे आणि तरुणपणापेक्षा अधिक स्पष्ट झाले आहे. तथापि, या क्षेत्रात असंख्य लोक कार्यरत आहेत आणि त्यांच्या सर्व कल्पना आजमावण्यासारख्या आहेत, ते सर्व पंखांमध्ये प्रतीक्षा करीत आहेत. आणि तुम्ही प्रयत्न केल्याशिवाय ते किती चांगले आहेत हे तुम्ही सांगू शकत नाही. ते तुमच्या वाटपकर्त्यामध्ये इतर सर्व गोष्टींशी किती चांगले एकत्र करतात, कारण एक वाटपकर्ता बर्‍याच गोष्टी करतो आणि काही कल्पना तुमच्या विशिष्ट वाटपकर्त्यामध्ये कार्य करणार नाहीत, परंतु दुसर्‍या वाटपकर्त्यामध्ये त्या सहजपणे काम करतील. वाटपकर्त्यासाठी जिंकण्याचा मुख्य मार्ग म्हणजे मंद सामग्री मुख्य मार्गाच्या बाहेर खेचणे आणि धीमे मार्गांच्या सीमेवर विभाजित करण्यास भाग पाडणे. म्हणून जर तुम्हाला GC चालवायचा असेल तर, धीमे मार्ग घ्या, deoptimize करा, अपवाद टाका, हे सर्व - तुम्हाला माहित आहे की या गोष्टी तुलनेने दुर्मिळ आहेत. आणि ते खरोखर दुर्मिळ आहेत, मी तपासले. तुम्ही अतिरिक्त काम करता आणि यामुळे या धीमे मार्गांवरील बरेच निर्बंध दूर होतात, परंतु ते धीमे आणि क्वचितच प्रवास करत असल्यामुळे काही फरक पडत नाही. उदाहरणार्थ, शून्य पॉइंटर - हे कधीच होत नाही, बरोबर? आपल्याकडे वेगवेगळ्या गोष्टींसाठी अनेक मार्ग असणे आवश्यक आहे, परंतु त्यांनी मुख्य मार्गात व्यत्यय आणू नये. 

Владимир: जेव्हा एकाच वेळी हजारो कोर असतात तेव्हा मल्टी-कोरबद्दल तुम्हाला काय वाटते? ही उपयुक्त गोष्ट आहे का?

उंच कडा: जीपीयूचे यश हे दर्शवते की ते बरेच उपयुक्त आहे!

Владимир: ते बरेच विशिष्ट आहेत. सामान्य उद्देश प्रोसेसर बद्दल काय?

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

आयुष्यातील सर्वात मोठे आव्हान

Владимир: गैर-तांत्रिक आव्हानांचे काय?

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

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

आंद्रेई: नुकतेच प्रत्येकजण अंतर्मुख व्यक्तींसाठी आत्म-जागरूकता आणि सर्वसाधारणपणे सॉफ्ट स्किल्सबद्दल बोलू लागला. याबद्दल काय सांगाल?

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

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

तसे, कोर्टात, विरोधी वकील तुमच्याशी असे करण्याचा प्रयत्न करतो - आता हे का स्पष्ट झाले आहे. कारण त्याच्यात तुम्हाला अशा अवस्थेपर्यंत दाबून ठेवण्याची क्षमता आहे की तुम्ही तुमचे नाव देखील उच्चारू शकत नाही, उदाहरणार्थ. अगदी खऱ्या अर्थाने, आपण बोलू शकणार नाही. जर तुमच्या बाबतीत असे घडले असेल आणि जर तुम्हाला माहित असेल की तुम्ही शाब्दिक भांडणे सुरू असलेल्या ठिकाणी, कोर्टासारख्या ठिकाणी, तर तुम्ही तुमच्या वकिलासोबत येऊ शकता. वकील तुमच्या बाजूने उभा राहील आणि शाब्दिक हल्ला थांबवेल, आणि ते पूर्णपणे कायदेशीर मार्गाने करेल आणि गमावलेली झेन जागा तुमच्याकडे परत येईल. उदाहरणार्थ, मला माझ्या कुटुंबाला दोन वेळा कॉल करावा लागला, न्यायाधीश याबद्दल खूप मैत्रीपूर्ण होते, परंतु विरोधी वकील माझ्यावर ओरडला आणि ओरडला, मला एक शब्दही ऐकू येत नव्हता. या प्रकरणांमध्ये, मध्यस्थ वापरणे माझ्यासाठी सर्वोत्तम आहे. मध्यस्थ सतत प्रवाहात तुमच्यावर ओतत असलेला हा सर्व दबाव थांबवतो, तुम्हाला आवश्यक झेन जागा मिळते आणि त्यासोबत बोलण्याची क्षमता परत मिळते. हे ज्ञानाचे एक संपूर्ण क्षेत्र आहे ज्यामध्ये अभ्यास करण्यासारखे बरेच काही आहे, स्वतःमध्ये शोधण्यासारखे बरेच काही आहे आणि हे सर्व उच्च-स्तरीय धोरणात्मक निर्णयांमध्ये बदलते जे वेगवेगळ्या लोकांसाठी भिन्न असतात. काही लोकांना वर वर्णन केलेल्या समस्या नसतात; सहसा, जे लोक व्यावसायिक विक्री करतात त्यांच्याकडे त्या नसतात. शब्दांच्या जोरावर उदरनिर्वाह करणारे हे सर्व लोक - प्रसिद्ध गायक, कवी, धार्मिक नेते आणि राजकारणी, त्यांच्याकडे नेहमीच काहीतरी बोलायचे असते. त्यांना अशा समस्या नाहीत, परंतु मला आहे.

आंद्रेई: हे अनपेक्षित होते. छान, आम्ही आधीच खूप बोललो आहोत आणि ही मुलाखत संपवण्याची वेळ आली आहे. आम्ही परिषदेत नक्कीच भेटू आणि हा संवाद पुढे चालू ठेवू शकू. हायड्रा येथे भेटू!

सेंट पीटर्सबर्ग येथे 2019-11 जुलै 12 रोजी होणाऱ्या हायड्रा 2019 परिषदेत तुम्ही क्लिफसोबत तुमचे संभाषण सुरू ठेवू शकता. तो अहवाल घेऊन येईल "अझुल हार्डवेअर व्यवहार मेमरी अनुभव". तिकिटे खरेदी करता येतील अधिकृत वेबसाइटवर.

स्त्रोत: www.habr.com