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

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

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

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

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

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

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

क्लिफ : यह बात है!

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

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

बहुत सारे रिफैक्टरिंग कैसे करें

एंड्रयू : आप प्रदर्शन पर कैसे काम करते हैं? यह एक क्रॉस-कटिंग मुद्दा है। उदाहरण के लिए, क्या आपको मौजूदा कार्यक्षमता की एक बड़ी राशि के चौराहे से उत्पन्न समस्याओं पर काम करना है?

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

लागत मॉडल

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

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

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

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

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

एंड्रयू : व्यापार में आने का कोई सरल तरीका है?

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

उत्पादकता में सुधार के केस स्टडीज

एंड्रयू : प्रदर्शन पर काम करते समय और क्या ध्यान देने योग्य है?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

: ?

: ? , – .
. . , , , , . Sun, , , , . , , . , C1, , – . , . , x86- , , 5-10 , 50 .

, , , , C. , , - , C . C, C . , , C, - … , . , . , , . , , 5% . - – , « », , . : , , . . , – , . , . - – . , , ( , ), , , . , , , .

, , , , , , . , , , - . , , , . , , , , . , : , . , , - : , , - , . – , , – ! – , . Java. Java , , , , – , « ». , , . , Java C . – Java, C , , , . , – , . , . , , . : .

: - . , , - , ?

: ! – , NP- - . , ? . , Ahead of Time – . - . , , – , ! – , . , , . . ? , : , , - ! - , . . , , . : - , - . , , . , , , , - . ! , , , – . . NP- .

: , – . , , , , …

: . «». . , . – , , , ( , ). , - . , , , . , , . , . , , . , , . , , - , – . – . , GC, , , , – , . , . , , . , – , ? , .

: , ? ?

: GPU , !

: . ?

: , - Azul. , . . H2O , . , GPU. ? , Azul, : – .

: ?

: , … . , . , , , , . , , . , Java C1 C2 – . , Java – . , , – . … . - , Sun, … , , . , . , . … … , . , , . . - , : . , , , , , , . , . . , . « , , ». : «!». , , , : , .

– , , , . . , , , , . , Java JIT, C2. , – . , – ! . , , , , , , . . . , . , , , , : , , . , – . , , - . : « ?». , . , , : , , – ? , . , , , , , , - .

: , -. ?

: , , . – . . , . . . : , , - – . . , , – , . , , , , - , . , . , , - . , , – , .
, . , – , , . , . , – . , . , , « », , – , , , , . , , « ».

. . - , , «»: , – . – . , , . «, -, , ». , : , . , , . . – , . , ? , ? ? , ? . , . – . . , . – – , . , « » . : «--», : «, !» . . , , , , . , . , . , – , . – , . , , , .

, – , . , , . , . , , , , . , , . , , , , . . , , , . , , , , . , , , . , – , , , . , .

: … . , . . Hydra!

Hydra 2019, 11-12 2019 -. «The Azul Hardware Transactional Memory experience» . .