संस्करण एक से जावा में ठीक करने के लिए हजारों चीजें: ओरेकल के सर्गेई कुक्सेंको के साथ एक महान साक्षात्कार

सर्गेई कुक्सेंको एक प्रदर्शन इंजीनियर है जिसने जावा को अभी तक 1.0 संस्करण में देखा है। इस समय के दौरान, वह मोबाइल, क्लाइंट, सर्वर एप्लिकेशन और वर्चुअल मशीनों के विकास में भाग लेने में सफल रहे। 2005 से, जावा प्रदर्शन में लगा हुआ है और वर्तमान में JDK प्रदर्शन को बेहतर बनाने के लिए Oracle में काम कर रहा है। जोकर और जेपोट में सबसे लोकप्रिय वक्ताओं में से एक।

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

• प्रदर्शन की संस्कृति;
• कब और क्या अनुकूलित किया जाना चाहिए, भाषा और पुस्तकालय का प्रारंभिक डिजाइन;
• आगे अनुकूलन के लिए होनहार क्षेत्र;
• विकास में कैसे भाग लेते हैं और अनुकूलन द्वारा क्या तोड़ा जा सकता है;
• कंपाइलर ट्रिक, रजिस्टर प्लेसमेंट;
• क्या कीमा बनाया हुआ मांस से एक बिल्ली को इकट्ठा करना संभव है;
• जब परीक्षण लगातार पांच दिनों और अन्य घरेलू दिनचर्या के लिए काम करते हैं;
• एक प्रदर्शन इंजीनियर कैसे बनें;
• अगले जोकर के लिए एक रिपोर्ट तैयार करना।

उत्पादकता के पंथ के बारे में

ओलेग: आप हमारे पुराने वक्ता हैं, और यह हमारा पहला साक्षात्कार नहीं है। थोड़ा बताओ, अब तुम कौन हो, क्या कर रहे हो?

सेर्गेई: मैं वैसा ही हूं जैसा मैंने कई साल पहले किया था, और मैं वही काम कर रहा हूं। मैं जावा प्रदर्शन टीम में काम करता हूं और ओरेकल जावा मशीनों, ओपनजेडके के प्रदर्शन के लिए जिम्मेदार हूं।

ओलेग: फिर मेरे पास कुछ हद तक ट्रोल सवाल है: यहां आप एक प्रदर्शन इंजीनियर हैं, और आपकी रिपोर्ट सभी प्रकार के प्रदर्शन के बारे में हैं। क्या आपको नहीं लगता कि प्रदर्शन का मुद्दा कुछ हद तक खत्म हो गया है? हर कोई उसके साथ भागता है, लेकिन क्या यह आवश्यक है?

सर्गेई: यह एक अच्छा सवाल है। यह सब दूसरे पर निर्भर करता है। इस तरह के दर्शकों का ध्यान अत्यधिक माना जा सकता है। दूसरी ओर व्यावसायिक उत्पादकता, पैसा है।

यह असली पैसा है जो लोग अमेज़ॅन के कुछ प्रकार के बादलों पर हार्डवेयर पर खर्च करते हैं। यदि आप अपने अनुरोधों को जल्दी से संसाधित नहीं करते हैं - तो यही है, आप ग्राहकों को खो देते हैं, पैसा खो देते हैं, बाकी सब खो देते हैं। इसलिए, प्रदर्शन का अनुरोध, निश्चित रूप से, हमेशा होता है। सवाल यह है कि यह प्रत्येक मामले में कितना महत्वपूर्ण है। मैं उच्च-आवृत्ति ट्रेडिंग के बारे में चुप हूं।

ओलेग: वैसे, क्या आपको लगता है कि जावा इसके लिए उपयुक्त है?

सर्गेई: क्या आपके पास पीटर लॉरी जैसे व्यक्ति से मिलने का अवसर है?

ओलेग: क्रॉनिकल सॉफ्टवेयर के सीईओ कौन हैं, ओपनएचएफटी के डेवलपर्स?

सर्गेई: यह लंदन का एक बहुत प्रसिद्ध मित्र है जो सम्मेलनों में बहुत यात्रा करता है। वे उच्च-आवृत्ति ट्रेडिंग में जावा में काम करते हैं, वे महान रहते हैं।

ओलेग: क्या वे इसे जावा पर कर रहे हैं या इसे जावा से मूल कोड कहा जाता है? फिर भी, एक अंतर है।

सर्गेई: मैं इस स्तर पर नहीं जानता, उसने यह नहीं बताया। सिद्धांत रूप में, यदि वांछित है, तो वह सभी आवश्यक है जो जावा में ही प्राप्त किया जा सकता है।

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

सर्गेई: मुझे नहीं पता कि यह कैसे हुआ। रूसी सम्मेलन में उत्पादकता का पंथ अमेरिकी एक की तुलना में बहुत अधिक है। हो सकता है कि यह खुद दर्शकों को प्रतिबिंबित करे। हम पर लोग उत्पादकता में अधिक संलग्न होना चाहते हैं, यह उनके लिए दिलचस्प है। और अमेरिका में, वे और अधिक भुगतान करना चाहते हैं जो वे अधिक भुगतान करते हैं। लेकिन यह एक परिकल्पना, अनुमान है। ऐसा ही हुआ।

कब और क्या अनुकूलित करने की आवश्यकता है

ओलेग: आपने कहा कि अभी भी प्रदर्शन के लिए अनुरोध है। आपको किस बिंदु पर प्रदर्शन के बारे में सोचना शुरू करना चाहिए? कब होगा वज्र प्रहार?

सर्गेई: यह एक सामान्य सार प्रश्न है। पिछले सम्मेलनों में से एक से एक बार फिर से एलेक्सी शिपिलेव के मुख्य वक्ता के रूप में बदल जाना बेहतर है, जहां उन्होंने यह सब अच्छी तरह से चित्रित किया है।

ओलेग: हाँ, मुझे "नाम का वक्र" याद है।

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

अगर हमने API में एक SortedSet को हिलाया (हालाँकि किसी को भी किसी को छाँटने की जरूरत नहीं है), और फिर यह हमारे पूरे सिस्टम में फैल गया, तो इस बात को दर्द और मुश्किल से निकालना होगा।

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

केस स्टडी: मैं java.math.BigDecimal वर्ग के आसपास स्क्वाट करता था। विभिन्न पक्षों से किसी भी तरह इसे फैलाने के लिए एक बड़ा अनुरोध था। एक अच्छा पर्याप्त, विशेष मामला है जब हमारा बिगडिमल "बिग" नहीं है, यह सिर्फ दशमलव है, और आपको उन्हें पढ़ने की आवश्यकता है।

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

ओलेग: क्या यह इस बात का पालन करता है कि एक मानक पुस्तकालय विकसित करते समय यह डिजाइनरों को छोड़ने और हर जगह बिल्डरों को करने के लायक है?

सेर्गेई: यह देर हो रही है।

ओलेग: अगर बहुत देर नहीं हुई, तो क्या यह एक अच्छा विचार होगा?

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

ओलेग: ठीक है, अब हर कोई DI-चौखटे का उपयोग करता है जो आपको अपनी पसंद के अनुसार समीपता को मोड़ने और कुछ भी जोड़ने की अनुमति देता है। भाषा के मूल डिजाइन में, क्या आप कुछ इस तरह जोड़ सकते हैं, अंतर्निहित निर्भरता इंजेक्शन कंटेनर?

सेर्गेई: भाषा के शुरुआती डिजाइन के बारे में मेरी बहुत विशिष्ट राय है। यदि आप जावा 1.0 के इतिहास को याद करते हैं, तो यह काफी गंभीर समय का दबाव था, सब कुछ जल्दी से किया जाना था।

हजारों चीजें हैं जो मैं व्यक्तिगत रूप से पहले संस्करण से तय देखना चाहता हूं। लेकिन मुझे डर है कि अगर इस हज़ार में से एक को भी चुना जाता है, तो एक-दो-तीन, और वे पहले जावा के समय बनना शुरू कर देते थे, तब जावा बाहर नहीं आता था। यह एक मानक उदाहरण है कि सबसे अच्छा अच्छे का दुश्मन है।

जावा में और क्या अनुकूलित किया जा सकता है

ओलेग: साधारण लोग केवल अपनी परियोजना में कुछ ठीक कर सकते हैं, और आप, जेडीके में प्रदर्शन इंजीनियरों के रूप में, तुरंत सैकड़ों हजारों परियोजनाओं को प्रभावित करते हैं। सवाल उठता है: जावा विकास के 20 से अधिक वर्षों में, क्या जेडीके में कोई क्षेत्र रहा है जहां कोर इंजीनियरों के हस्तक्षेप से ध्यान देने योग्य प्रभाव हो सकता है? और यह "ध्यान देने योग्य प्रभाव" कितना ध्यान देने योग्य है?

सेर्गेई: सबसे पहले, अब जावा 10 साल पहले के हार्डवेयर पर बिल्कुल भी काम नहीं करता है। लोहा और लोहा 10 साल पहले दो बड़े अंतर हैं, और विभिन्न अनुकूलन करने की सलाह दी जाती है।

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

ओलेग: आप कैसे सुनिश्चित हो सकते हैं? आप औपचारिक रूप से कोड का सत्यापन नहीं करते हैं। एक "सुनिश्चित करें" क्या है?

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

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

सर्गेई: किस अवधि के लिए यह नहीं बदला है?

ओलेग: उदाहरण के लिए, पिछले 10 साल।

सर्गेई: हाँ, एक दशक पहले हार्डवेयर पर एक एवीएक्स -51 है?

ओलेग: नहीं। वह, शायद, हमेशा आधुनिक में मौजूद नहीं है?

सर्गेई: मैं निश्चित रूप से नहीं है। हमारे पास इसकी प्रयोगशाला में है, लेकिन यह सभी संकलक द्वारा कब्जा कर लिया गया है। वे अब तक पंगा ले रहे हैं, इसलिए मैंने नहीं देखा।

ओलेग: क्या AVX-512 समर्थन को एक विशिष्ट विशेषता का उदाहरण माना जा सकता है?

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

ओलेग: क्या वे किसी तरह हार्डवेयर में तेजी लाते हैं?

सर्गेई: यह सब विशिष्ट एल्गोरिदम पर निर्भर करता है। बहुत अच्छी तरह से त्वरित एल्गोरिदम हैं। वैसे, 10 साल पहले यह इंटेल हार्डवेयर पर काम नहीं करता था, लेकिन एईएस-इकाइयों को त्वरण के साथ 5-6 कैसे अच्छे निर्देश दिखाई दिए। यह सब एक न्यूनतम समय अंतराल के साथ लागू किया गया था।

ओलेग: GPU के बारे में क्या, वे भी matrices गुणा करने में सक्षम हैं?

सर्गेई: जीपीयू के बारे में - एक अलग बातचीत। हमारे पास इसके लिए एक पनामा परियोजना है जिसमें ये सभी कार्य किए जाते हैं, और किसी दिन यह जावा मेनलाइन पर सभी अच्छाइयों के साथ पहुंचेगा।

ओलेग: मेरे पास परिचितों की एक जोड़ी है जो वित्तीय गणित में, सशर्त रूप से लगे हुए हैं। कुछ बिंदु से, वे हमेशा कंप्यूटिंग के लिए C ++ पर स्विच करते हैं और दावा करते हैं कि प्रबंधित मंच से इन सभी अनुकूलन और हार्डवेयर का उपयोग करने के लिए बहुत असुविधाजनक है। क्या इसमें सुधार किया जा सकता है?

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

हमारे पास दो बड़ी छतरी परियोजनाएं हैं: वल्लाह और पनामा, जो कि GPU जैसी सुविधाओं को इकट्ठा करना चाहिए। वल्हाला और पनामा के जंक्शन पर एक वेक्टर एपीआई बैठता है जो हमारे SIMD / SSE / AVX निर्देशों के साथ सीधे जावा कोड से काम करता है, और इनलाइन प्रकारों के साथ ही वलहला उस दिशा में सभी बड़े कदम हैं।

अनुकूलन द्वारा क्या तोड़ा जा सकता है, विकास में कैसे भाग लिया जाए

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

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

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

ओलेग: विशुद्ध रूप से संगठनात्मक, यहां आपके पास एक परियोजना है, प्रदर्शन के साथ किसी प्रकार की समस्या है, लेकिन यह कई परियोजनाओं के जंक्शन पर है। आगे क्या करना है? इसे कैसे हल करें? यह पता चला है कि यह पहले से ही परियोजनाओं और लोगों के बीच एक व्यापार-बंद है, न कि कुछ सार कार्यों के बीच।

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

यदि कोड पहले से मौजूद है, तो यह पहले से ही काम करता है। आदर्श स्थिति में, आप इस समस्या को ठीक करते हैं, या, यदि आप इसे पूरी तरह से ठीक नहीं कर सकते, तो आप प्रोटोटाइप को ब्लर कर देते हैं, फिर आप कोड के मालिक के पास आते हैं और कहते हैं: "यहाँ प्रोटोटाइप है, हम क्या करेंगे?" इसके अलावा, हम इस मामले को विशेष रूप से प्रत्येक मामले के लिए हल करते हैं।

ओलेग: हमारे यहाँ ऐसे लोग हैं जो इस प्रक्रिया में भाग नहीं ले सकते हैं, ये अंतिम उपयोगकर्ता हैं।

सर्गेई: वे बिल्कुल भाग नहीं ले सकते हैं कि उन्हें ओरेकल में उनके वेतन के लिए भुगतान नहीं किया जाएगा। यदि आपको वेतन की आवश्यकता नहीं है, तो OpenJDK पर आएं और भाग लें।

ओलेग: यह कितना वास्तविक है? OpenJDK में आप जैसे कुछ सामान्य लोग हैं, और जहां आम लोग हैं, और आप कहां हैं। मान लीजिए कि मेरे लिए कुछ धीमा हो रहा है, मुझे क्या करना चाहिए और कैसे करना चाहिए?

सर्गेई: यदि आप समस्या को नहीं जानते हैं, तो यह एक अलग प्रश्न है, क्या कोई आपके लिए समाधान खोजेगा, यह एक क्षेत्र, उदाहरण के रूप में एक प्रश्न है, और इसी तरह। यहां तक ​​कि अगर आप समस्या को नहीं जानते हैं, तो यह समझ में आता है, शायद, OpenJDK में लिखना और पूछना। अगर यह कुछ ऐसा है जिसे कोई तुरंत सिर में क्लिक करता है, तो लोग इसे पकड़ लेंगे। यदि यह किसी के लिए कोई दिलचस्पी नहीं है, तो यह अनुत्तरित लटका रहेगा।

ओलेग: मान लीजिए कि मैं समस्या जानता हूं और यह भी जानता हूं कि क्या तय करने की जरूरत है।

सर्गेई: यदि आप समस्या जानते हैं, तो आप ओपनजेडके में आते हैं, कागज के सभी आवश्यक टुकड़ों पर हस्ताक्षर करते हैं, एक पैच पेश करते हैं, इसे संशोधित और डाला जाता है।

ओलेग: यह इतना आसान है?

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

ओलेग: संयुक्त राज्य अमेरिका में छुट्टियां रूस में आमतौर पर समान तिथियों के बारे में होती हैं?

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

कंपाइलर ट्रिक्स, प्लेसमेंट रजिस्टर करें

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

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

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

वैसे, संकलक के बारे में - न केवल जावा संकलक के बारे में, बल्कि सामान्य रूप से। मूर का कानून है, जो एक कानून नहीं है, लेकिन सिर्फ एक अनुभवजन्य अवलोकन है कि ट्रांजिस्टर की संख्या हर साल और डेढ़ गुना हो जाती है।

और वास्तव में समान कानून ( प्रोबस्टिंग का नियम ) है कि संशोधन के बिना कोड प्रदर्शन में हर डेढ़ से दो साल में 4 प्रतिशत की वृद्धि होती है। यह 4 प्रतिशत है जो अंत उपयोगकर्ताओं को केवल संकलक के विकास से मुफ्त में मिलता है। हार्डवेयर नहीं, अर्थात् संकलक।

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

सेर्गेई: नहीं, यह सिर्फ प्रौद्योगिकी विकास की बात है। जब मैंने प्रदर्शन पर काम करना शुरू किया तो मैंने कंपाइलर छोड़ दिया। लेकिन एक बार जब मैं सगाई कर रहा था, और मेरे लिए सबसे बड़ी खोज 2005 या 2006 में हुई थी। मुझे इसके बारे में 2008 में पता चला क्योंकि मैंने समय पर लेख नहीं पढ़ा था।

किसी भी कोड पीढ़ी का एक बहुत ही महत्वपूर्ण कार्य रजिस्टर आवंटन है। यह ज्ञात है कि सामान्य तौर पर, यह समस्या एनपी-पूर्ण है। इसे हल करना बहुत मुश्किल है, और इसलिए सभी कंपाइलर गुणवत्ता के अलग-अलग डिग्री के साथ किसी प्रकार के अनुमानित एल्गोरिदम को चलाने की कोशिश करते हैं।

और यहां एक लेख आता है जहां लोग यह साबित करते हैं कि कुछ मामलों में जो बड़ी संख्या में कंपाइलरों को कवर करते हैं और कुछ प्रतिबंधों के साथ बड़ी संख्या में आंतरिक प्रतिनिधित्व करते हैं, रजिस्टर आवंटन के कार्य के लिए एक सटीक बहुपद एल्गोरिथ्म मौजूद है। हुर्रे, चलो चलें!

यह 2005 में हुआ था, पहले किए गए संकलक यह नहीं जानते थे।

ओलेग: अब आप जावा के लिए एक नया आवंटन कर सकते हैं?

सर्गेई: अब जब एक सैद्धांतिक समाधान है, तो इसे फिर से लिखा जा सकता है। मैं विवरण में नहीं आया, लेकिन मुझे पता है कि एक्सेलसियर के लोगों ने एल्गोरिथ्म को लागू किया था।

ओलेग: हमने हाल ही में क्लिफ क्लिक के साथ एक साक्षात्कार किया, और उन्होंने जावा के लिए लिखे जाने वाले पागल जटिल और पागल प्रतिभा के आवंटन के बारे में बात की। एक और लिखना नहीं चाहते?

सर्गेई: नहीं।

ओलेग: क्या कुछ सामान्य है?

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

ओलेग: क्या जेडीके में काम के कोई क्षेत्र हैं जहां सभी इंजन कम्पार्टमेंट कंपाइलर या प्रदर्शन जादू सतह पर टूट जाते हैं? आप कहते हैं कि आपको सामान्य सामान्य कोड लिखने की ज़रूरत है और सबकुछ ठीक हो जाएगा, लेकिन यह संदिग्ध लगता है।

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

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

ओलेग: आप कुछ सरल चीजों को ट्रैक करने की कोशिश कर सकते हैं, जैसे: स्मृति का यह टुकड़ा मालिकों को बदल रहा है और इस दिशा में वस्तुओं के बीच घूम रहा है।

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

(ऐसा प्रतीत हो सकता है कि उसी वीडियो को गलती से यहां डुप्लिकेट कर दिया गया था। वास्तव में, सब कुछ सरल है, हैबर ने गलत चित्र को कैश किया है)

हम कीमा बनाया हुआ मांस से एक बिल्ली इकट्ठा करते हैं

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

: , . , . , . , . , , , . ?

: : « ».

: , . , . , ? . — , . , , - , .

: , ?

: , ? , . ?

: , - ?

: , — , . - . ? , , , , . , .

: .

: , 1 . , , . , - , - .

performance-

: OpenJDK . ? C++ . — -?

: , , . . OpenJDK 15 . 15 .

: , , . .

: ! , , . , , , , , . , . : , , ( , ), — . , , .

: , ?

: , , Java.

: ?

: , , Valhalla.

: - , , — , ? ? .

: , . — . , , , . , , . . 2-3 , , , , — , .

, , inline-, Java Joker. . , Java- , runtime-. red flag: runtime- 0. ? , out of order- — .

, . , . ? . . baseline, , 5-6 , — . , , - 2 — - . 3% - , . 3% ?

: , ?

: , . performance-, . , , — .

, , . performance- — , - performance- - , . , , .

, , , , performance- — class libraries hotspot, .

«» performance

: , - performance-, . , , ?

: . ? , performance- performance-.

, : , , Oracle, Twitter, Netflix , - . , — . , performance- , .

- , , performance- , ? , , .

, performance- — . : - performance review, , , , , . — performance .

: « , ...», , — . , - — , , , .

Joker

: Joker . ?

: inline-, .

: , value-?

: , , . . , . value Java- . value, value, by value, - by value, value type. , .

. , , , Rémi Forax - , inline-. , , Kotlin inline- , value- Java, .

. value-, , , mvt (minimum value types), LW 1. LW 2 — , . , , , . , , , , performance- , , , , .

: , - -?

: , - . , , , , invokedynamic .

: , , , , .

: , , , . — , , . , ?

: , , , .

: . , , inline- generic- , inline-. , .

: , - ?

: : inline- LW2 . value-, generic, .

« Java -? Valhalla» Joker , - 25-26 2019 . , .