💪🏼 💞 🕺 Intel® VTune ™ एम्पलीफायर XE 2013 में मल्टीथ्रेडिंग और कार्य विश्लेषण 🗝️ 🤛🏻 🥀

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

परिचय

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

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

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

चित्र 1

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

Fig.2

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

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

3 चित्र

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

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

चित्र 4

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

उदाहरण

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

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

class MyReadFilter: public tbb::filter { FILE* input_file; DataItem* next_item; /*override*/ void* operator()(void*); public: MyReadFilter( FILE* in ); };

 MyReadFilter:: MyReadFilter( FILE* in ) : filter(serial_in_order), input_file(in), next_item(DataItem*) { }

 class MyWriteFilter: public tbb::filter { FILE* output_file; /*override*/ void* operator()(void*); public: MyWriteFilter( FILE* out ); };

 MyWriteFilter:: MyWriteFilter( FILE* out ) : filter(serial_in_order), output_file(out), { }

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

 void* MyReadFilter::operator()(void*) { // ALLOCATEMEMORY // READ A DATA ITEM FROM FILE // PUT DATA ITEM TO CONTAINER }

 void* MyWriteFilter::operator()(void*) { // GET DATA ITEM FROM CONTAINER // WRITE THE DATA ITEM TO FILE // DEALLOCATE MEMORY }

हमारे प्रक्रिया चरण को थ्रेड्स के समानांतर में निष्पादित किया जा सकता है, इसलिए हम इसे समानांतर फ़िल्टर वर्ग के रूप में परिभाषित करते हैं, और ऑपरेटर () विधि में डेटा प्रवाह प्रसंस्करण एल्गोरिदम का "मांस" होना चाहिए।

 class MyProcessFilter: public tbb::filter { public: MyProcessFilter(); /*override*/void* operator()( void* item ); }; MyProcessFilter:: MyProcessFilter() : tbb::filter(parallel) {}

 void* MyProcessFilter::operator()( void* item ) { // FIND A CURRENT DATA ITEM IN CONTAINER // PROCESS THE ITEM }

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

  tbb::pipeline pipeline; MyReadFilter r_filter( input_file ); pipeline.add_filter( r_filter ); MyProcessFilter p_filter; pipeline.add_filter(p_filter ); MyWriteFilter w_filter( output_file ); pipeline.add_filter( w_filter ); pipeline.run(2*nthreads)

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

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

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

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

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

चित्र 5।

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

चित्र 6।

कार्यक्रम के परिणामस्वरूप समानांतरवाद हिस्टोग्राम से, हम देखते हैं कि हम अधिकतम दक्षता से बहुत दूर हैं: मूल रूप से 4 थ्रेड्स से कम में आवेदन निष्पादित किया गया था। (हिस्टोग्राम में नीली पट्टियां उस समय को दिखाती हैं जब एप्लिकेशन Y अक्ष के साथ X थ्रेड्स पर काम करता है। आदर्श रूप से, हम समसामयिक स्तर 4 [4] के साथ एक कॉलम देखना चाहेंगे, जिसका अर्थ होगा कि हमारा आवेदन हर समय 4 थ्रेड्स में काम करता है) ।
यहां तक कि बॉटम-अप व्यू में परिणामों पर एक त्वरित नज़र थ्रेड्स के बीच होने वाली अत्यधिक सिंक्रनाइज़ेशन को देखने के लिए पर्याप्त है (चित्र 7)। आप पीले बदलावों पर मंडरा सकते हैं और पॉप-अप विंडो में इस सिंक्रोनाइज़ेशन के स्रोत का लिंक देख सकते हैं।

चित्र 7।

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

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

अपने स्रोत में उपयोगकर्ता एपीआई से हेडर फ़ाइल शामिल करें
```
 #include "ittnotify.h" 
```
कार्य के डोमेन को परिभाषित करें। यह अलग-अलग डोमेन में किए गए अलग-अलग कार्यों के लिए अक्सर बहुत सुविधाजनक होता है, उदाहरण के लिए, विभिन्न समानांतर इन्फ्रास्ट्रक्चर (टीबीबी, ओपनएमपी, आदि) में धागे द्वारा।
```
 __itt_domain* domain = __itt_domain_create("PipelineTaskDomain"); 
```

एक कार्य संभाल को परिभाषित करें जो मंच का वर्णन करता है।

 __itt_string_handle* hFileReadSubtask = __itt_string_handle_create("Read"); __itt_string_handle* hFileWriteSubtask = __itt_string_handle_create("Write"); __itt_string_handle* hDoSquareSubtask = __itt_string_handle_create("Do Square");

अब सोर्स कोड को लपेटें, जो इंस्ट्रूमेंटिंग एपीआई फंक्शंस के लिए कॉल के साथ कार्य के चरणों में निष्पादित होता है: __itt_task_begin और __itt_task_end । उदाहरण के लिए, पढ़ने और लिखने के चरण निम्नानुसार सहज हो सकते हैं:
```
 void* MyReadFilter::operator()(void*) { __itt_task_begin(domain, __itt_null, __itt_null, hFileReadSubtask); // ALLOCATE MEMORY // READ A DATA ITEM FROM FILE // PUT DATA ITEM TO CONTAINER __itt_task_end(domain); } 
```
```
 void* MyWriteFilter::operator()(void*) { __itt_task_begin(domain, __itt_null, __itt_null, hFileWriteSubtask); // GET DATA ITEM FROM CONTAINER // WRITE THE DATA ITEM TO FILE // DEALLOCATE MEMORY __itt_task_end(domain); } 
```
उसी तरह, आप प्रक्रिया चरण को भी लपेट सकते हैं। (उत्पाद एपीआई में उपयोगकर्ता एपीआई कार्यों के बारे में अधिक जानकारी प्राप्त की जा सकती है)।
```
 void* MyProcessFilter::operator()( void* item ) { __itt_task_begin(domain, __itt_null, __itt_null, hDoSquareSubtask); // FIND A CURRENT DATA ITEM IN CONTAINER // PROCESS THE ITEM __itt_task_end(domain); } 
```
अपने प्रोजेक्ट में VTune एम्पलीफायर हेडर फ़ाइलों में पथ जोड़ने के लिए याद रखें:
$ (VTUNE_AMPLIFIER_XE_2013_DIR) शामिल हैं
सांख्यिकीय रूप से अपने निष्पादन योग्य मॉड्यूल को libittnotify.lib लाइब्रेरी से लिंक करें, जिस पथ पर स्थित है
$ (VTUNE_AMPLIFIER_XE_2013_DIR) lib [32 | 64] आपके सिस्टम के "बिटनेस" पर निर्भर करता है।

और अंत में, यह हमारे लिए विश्लेषण कॉन्फ़िगरेशन विंडो (छवि 8) में उपयोगकर्ता कार्यों के विश्लेषण को सक्षम करने और किसी भी प्रकार के प्रोफाइलिंग को शुरू करने के लिए रहता है जिसकी हमें ज़रूरत है।

चित्र 8।

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

चित्र 9।

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

अंजीर। 10।

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

चित्र 11।

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

चित्र 12।

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

चित्र 13।

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

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

चित्र 14।

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

चित्र 15।

निष्कर्ष

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

Intel® VTune ™ एम्पलीफायर XE 2013 में मल्टीथ्रेडिंग और कार्य विश्लेषण

परिचय

उदाहरण

निष्कर्ष

More articles: