बहुत तेज़, बहुत अधिक मेगाफ़ॉर्मिक: जावा में मेथड कॉल के प्रदर्शन को प्रभावित करता है?

अनुवादक से:

हर जगह अंतिम लेखन के समर्थकों और उनके विरोधियों के बीच का विवाद इंगित और कुंद की बहस का समान है। जैसा कि कुछ अन्य समुदायों में, हमारी कंपनी में यह सुस्त विवाद वर्षों से चल रहा है। और केवल रिचर्ड वारबर्टन के इस लेख ने हमारे जीनियस को ऊपरी हाथ हासिल करने की अनुमति दी।

हम किस बारे में बात कर रहे हैं?

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



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

बेंचमार्किंग पद्धति

इसलिए, मैंने बेंचमार्किंग के लिए अद्भुत JMH फ्रेमवर्क का उपयोग करने का निर्णय लिया। यदि आप सुनिश्चित नहीं हैं कि फ्रेमवर्क आपको सटीक बेंचमार्किंग परिणाम प्राप्त करने में मदद करेगा, तो आपको इस प्रस्तुति को अलेक्सई शिपिलेव (@TheShade), फ्रेमवर्क के लेखक या वास्तव में शांत निट्सन वकार्ट ब्लॉग द्वारा देखना चाहिए, जो बताता है कि यह कैसे मदद करता है।



मेरे मामले में, मैं यह समझना चाहता था कि मेथड कॉल के प्रदर्शन पर क्या प्रभाव पड़ा। मैंने विधि कॉल के विभिन्न रूपों की कोशिश करने और उनमें से लागत को मापने का फैसला किया। मापदंड का एक सेट होने और एक समय में केवल एक कारक के अलग-अलग होने से, हम समझ सकते हैं कि विभिन्न कारक या उनके संयोजन विधि कॉल की लागत को कैसे प्रभावित करते हैं।

इनलाइन

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

class Foo { void bar() { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हम बार विधि को कोड लिखकर कॉल कर सकते हैं जो इस तरह दिखता है:

 Foo foo = new Foo(); foo.bar();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

पदानुक्रम की गहराई और तरीकों के पुनर्वितरण

यदि हम अंतिम कीवर्ड को विधि से हटाने का निर्णय लेते हैं, तो इसका मतलब है कि हम इसे ओवरराइड कर पाएंगे। यह विचार करने के लिए एक और कारक है। इसलिए मैंने विधियां लीं और उन्हें कक्षा के पदानुक्रम के विभिन्न स्तरों पर बुलाया; पदानुक्रम के विभिन्न स्तरों पर पुनर्परिभाषित तरीके भी थे। इसने मुझे यह निर्धारित करने की अनुमति दी कि विधि के ओवरराइड्स के साथ वर्ग पदानुक्रम कितनी गहराई से बातचीत करते हैं।

बहुरूपता

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



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



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



इस प्रकार, 3 प्रकार की कॉल को तुलना और अनुसंधान के लिए प्रतिष्ठित किया जाता है: मोनोमोर्फिक, बिमॉर्फ और मेगामोर्फर कॉल के मामले।

परिणाम

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



इन बेंचमार्क के लिए सोर्स कोड GitHub पर उपलब्ध है । भ्रम से बचने के लिए, मैंने विभिन्न ब्लॉकों में परिणामों का हिस्सा प्रस्तुत किया। पॉलीमॉर्फिक बेंचमार्क पॉलीमॉर्फिक बेंचमार्क का उपयोग करके और बाकी जावाफाइनल बैंचमार्क का उपयोग करके निर्मित किया जाता है।

सरल कॉल

 Benchmark Mode Samples Mean Mean error Units cijJavaFinalBenchmark.finalInvoke avgt 25 2.606 0.007 ns/op cijJavaFinalBenchmark.virtualInvoke avgt 25 2.598 0.008 ns/op cijJavaFinalBenchmark.alwaysOverriddenMethod avgt 25 2.609 0.006 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

सरल कॉलिंग एंबेडिंग

 Benchmark Mode Samples Mean Mean error Units cijJavaFinalBenchmark.inlinableFinalInvoke avgt 25 0.782 0.003 ns/op cijJavaFinalBenchmark.inlinableVirtualInvoke avgt 25 0.780 0.002 ns/op cijJavaFinalBenchmark.inlinableAlwaysOverriddenMethod avgt 25 1.393 0.060 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

वर्ग पदानुक्रम का प्रभाव

 Benchmark Mode Samples Mean Mean error Units cijJavaFinalBenchmark.parentMethod1 avgt 25 2.600 0.008 ns/op cijJavaFinalBenchmark.parentMethod2 avgt 25 2.596 0.007 ns/op cijJavaFinalBenchmark.parentMethod3 avgt 25 2.598 0.006 ns/op cijJavaFinalBenchmark.parentMethod4 avgt 25 2.601 0.006 ns/op cijJavaFinalBenchmark.inlinableParentMethod1 avgt 25 1.373 0.006 ns/op cijJavaFinalBenchmark.inlinableParentMethod2 avgt 25 1.368 0.004 ns/op cijJavaFinalBenchmark.inlinableParentMethod3 avgt 25 1.371 0.004 ns/op cijJavaFinalBenchmark.inlinableParentMethod4 avgt 25 1.371 0.005 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

अंतिम तरीकों पर वर्ग पदानुक्रम का प्रभाव

 Benchmark Mode Samples Mean Mean error Units cijJavaFinalBenchmark.parentFinalMethod1 avgt 25 2.598 0.007 ns/op cijJavaFinalBenchmark.parentFinalMethod2 avgt 25 2.596 0.007 ns/op cijJavaFinalBenchmark.parentFinalMethod3 avgt 25 2.640 0.135 ns/op cijJavaFinalBenchmark.parentFinalMethod4 avgt 25 2.601 0.009 ns/op cijJavaFinalBenchmark.inlinableParentFinalMethod1 avgt 25 1.373 0.004 ns/op cijJavaFinalBenchmark.inlinableParentFinalMethod2 avgt 25 1.375 0.016 ns/op cijJavaFinalBenchmark.inlinableParentFinalMethod3 avgt 25 1.369 0.005 ns/op cijJavaFinalBenchmark.inlinableParentFinalMethod4 avgt 25 1.371 0.003 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यहाँ ऊपर के रूप में एक ही योजना है - अंतिम कीवर्ड का कोई मतलब नहीं है। मैंने सोचा कि यह सैद्धांतिक रूप से यहाँ साबित हो सकता है कि इनलाइनेबलपेरेंटफाइनलमेथोड 4 एंबेडेबल है और टाइप चेकिंग को बाहर करता है, लेकिन यह ऐसा नहीं लगता है।

बहुरूपता

 Monomorphic: 2.816 +- 0.056 ns/op Bimorphic: 3.258 +- 0.195 ns/op Megamorphic: 4.896 +- 0.017 ns/op Inlinable Monomorphic: 1.555 +- 0.007 ns/op Inlinable Bimorphic: 1.555 +- 0.004 ns/op Inlinable Megamorphic: 4.278 +- 0.013 ns/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

हम क्या समझते हैं?

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

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

मैं कहूंगा कि टाइप चेकिंग की कीमत मेरा व्यक्तिगत "बड़ा रहस्योद्घाटन" है। यह कुछ ऐसा है जो मैं देखता हूं कि शायद ही कभी चर्चा की जाती है और अक्सर उपेक्षा की जाती है।

चेतावनी और आगे का काम

बेशक, यह इस मुद्दे पर एकमात्र संभव दृष्टिकोण नहीं है!

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

शायद ये भविष्य के पदों के लिए विषय हैं।



धन्यवाद:

- बेंचमार्क पर प्रतिक्रिया के लिए एलेक्सी शिपिलेव ,

- मार्टिन थॉम्पसन , मार्टिज़न वर्बर्ग, सादिक जाफर और क्रिस वेस्ट के उपयोगकर्ताओं के लिए - मेरे ब्लॉग पर बहुत उपयोगी प्रतिक्रिया और टिप्पणियों के लिए।