चलिए विराम देते हैं। धागा तुल्यकालन में सुधार के लिए रास्ता

ठहराव - एक अस्थायी चुप्पी, एक संगीत के काम की आवाज़ में एक विराम या उसके किसी हिस्से या एक व्यक्तिगत आवाज़ के रूप में।
[विकिपीडिया]

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


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

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



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



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

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

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



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



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

हम यहां क्या देखते हैं: समय का मुख्य उपभोक्ता लाइब्रेरी फ़ंक्शन wa_yield_4 है, जिसे कम्प्यूटपोट फ़ंक्शन में महत्वपूर्ण खंड प्रविष्टियों के ढेर पर कहा जाता है, और जो अंततः x86_pause फ़ंक्शन को कॉल करेगा।



यह देखना आसान है (असेंबली व्यू में स्विच करना) कि बाद वाले पॉज़ असेंबली टूल को इनवाइट करेंगे।



Wait_sleep के रूप में, इसे x86_pause भी कहा जाता है, लेकिन यह समानांतर क्षेत्र की शुरुआत और अंत में प्रतीक्षा करने के लिए जिम्मेदार है।

अब देखते हैं कि कर्नेल कॉल में क्या गया (प्रतीक जो उपकरण द्वारा resolvable नहीं हैं, इसलिए मॉड्यूल का नाम कोष्ठक [vmlinux] में है)। यहाँ हम देखते हैं कि महत्वपूर्ण खंड पर कब्जा करने के प्रयास में "पुस्तकालय प्रस्थान" का अधिकांश हिस्सा गिल्ड लाइब्रेरी समारोह के माध्यम से हुआ।



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

KMP_LIBRARY - रन-टाइम निष्पादन मोड [सीरियल | टर्नअराउंड | थ्रूपुट (डिफ़ॉल्ट)]
KMP_BLOCKTIME - सोने से पहले प्रतीक्षा करने का समय [0 | एन (डिफ़ॉल्ट 200 एमएस) | अनंत]

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

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



अब मुख्य प्रतीक्षा समय wa_sleep फ़ंक्शन में है, जिसे समानांतर क्षेत्र बनाते और नष्ट करते समय कहा जाता है, और महत्वपूर्ण सेक्शन (अधिग्रहण_लॉक) को कैप्चर करने से wa_yield_4 के कारण होने वाले ठहराव कम हो गए हैं, जाहिर तौर पर इस तथ्य के कारण कि थ्रेड्स को सेक्शन को कैप्चर करने के अधिक मौके मिले।



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