मल्टी-कोर इंटेल कोर 2 प्रोसेसर (भाग 2) के उदाहरण का उपयोग करके स्केलेबिलिटी समस्याओं को खोजें और हल करें

लेख की निरंतरता: भाग 1 , भाग 3 , भाग 4

कैश लाइन दक्षता

खंड 1.1 और 1.2 सबसे बुनियादी मुद्दों में से एक को कवर करते हैं: कैश स्थान में पते के स्थान के केवल भाग का उपयोग करना। और यह न केवल बस यातायात को बढ़ाता है, बल्कि प्रोसेसर कैश की दक्षता को भी कम करता है। यदि कैश में बिताए गए समय के दौरान, कैश लाइन का केवल एक हिस्सा उपयोग किया जाता है, तो एप्लिकेशन इसके कैश के आकार को काफी कम कर देता है। खण्ड १.१ में संकलक के अभ्यास से तात्पर्य उनके आकार के अनुसार स्मृति में संरचनात्मक तत्वों की व्यवस्था करना है। इसलिए, यदि संरचना का पहला तत्व "चार" है, उसके बाद 4-बाइट "int" है, तो कंपाइलर इन तत्वों के बीच 3 और बाइट जोड़ देगा, ताकि उन्हें 4-बाइट ग्रिड पर व्यवस्थित किया जा सके।



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



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



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



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



उपयोग की जाने वाली कैश लाइनों की कुल संख्या को BUS_TRANS_BURST.SELF ईवेंट द्वारा मापा जाता है।

डेटा एक्सेस विश्लेषण पर अधिक विस्तृत नज़र डालने के साथ ही एक और लेख जल्द ही उपलब्ध होगा।



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



यह पता चला है कि सरणी संरचनाओं के बजाय सरणी संरचनाओं का उपयोग करना बेहतर है यदि प्रमुख पहुंच पैटर्न सूची सरणी पर क्रमिक पहुंच है, क्योंकि यह सुनिश्चित करता है कि कैश लाइनों के सभी बाइट्स का उपयोग किया जाता है।

कैश से उतारना

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

double TRIAD(int len, double a1, double * a, double *b, double*c, double*d){ int i; for(i=0; i<len; i++) a[i] = b[i] + a1*d[i]; return; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अधिकांश अनुवादक नियमित अनलोड निर्देश का उपयोग करेंगे या सरणी "ए" के लिए एसएसई अनलोड निर्देश पैक करेंगे। यह कैश लाइन के अनन्य उपयोग के लिए एक अनुरोध को ट्रिगर करेगा, जो इस सरणी के लिए आवश्यक बैंडविड्थ को दोगुना करता है। यदि सरणी को तुरंत आवश्यक नहीं है या पूरे कैश में फिट होने के लिए बहुत बड़ा है, तो यातायात को आधा किया जा सकता है। ऊपर दिए गए उदाहरण में, यदि पुनरावृत्तियों की संख्या "len" 8 से गुणा की गई है जो 3 से विभाजित अंतिम स्तर कैश (LLC) के आकार से अधिक है, तो सरणी "a" के लिए पहली कैश लाइन चक्र के अंत से पहले कैश से अनलोड की जाएगी। यह सुनिश्चित करने के लिए कि इंटेल कंपाइलर बड़ी संख्या में पुनरावृत्तियों के लिए इष्टतम कोड बनाता है, आपको सरणियों को 16 बाइट्स से संरेखित करने की आवश्यकता है और फिर तुरंत इसके सामने दो प्रज्ञा निर्देश जोड़कर लूप को बदल दें।

 #pragm vector aligned #pragma vector nontemporal for(i=0; i<len; i++) a[i] = b[i] + a1*d[i];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



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



आप यह निर्धारित करने के लिए प्रदर्शन घटनाओं का उपयोग कर सकते हैं कि कौन से प्रीफ़ैच हार्डवेयर ब्लॉक सक्षम हैं। L2_LD.SELF.PREFETCH ईवेंट L2 कैश में लोड की गई लाइनों को L2 प्रीफ़ैच ब्लॉक के रूप में मानता है। L1D_PREFETCH.REQUESTS ईवेंट की घटना इंगित करती है कि L1 डेटा कैश प्रीफ़ैच ब्लॉक चालू हैं।



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

1. नेस्टेड छोरों के साथ कुछ पुनरावृत्तियों और बाहरी छोरों में बड़े कदम;
2. नेस्टेड लूप्स डेटा आंदोलन के विपरीत दिशाओं के साथ (बाहरी लूप एक बड़े कदम के साथ आगे बढ़ता है, आंतरिक लूप एक छोटे कदम के साथ वापस जाता है)।

हार्डवेयर प्रीफ़ेटिंग आमतौर पर आंतरिक लूप द्वारा नियंत्रित किया जाता है, इसलिए पहले मामले में प्रीलोडेड लाइनें आंतरिक लूप की पता सीमा के बाहर होगी, और बाहरी लूप के अगले पुनरावृत्ति द्वारा उपयोग नहीं किया जाएगा। दूसरे मामले में, प्रीफ़ैच ब्लॉक पहले से उपयोग की गई लाइनों को लोड करने का प्रयास कर सकता है, अर्थात यह बिल्कुल बेकार होगा। यह स्थिति पुनरावृत्त सॉल्वरों में बहुत आम है और ज्यादातर मामलों में केवल आंतरिक लूप की दिशा और कुछ आवश्यक बियर को बदलकर ठीक किया जा सकता है। दोनों ही मामलों में, लोड और अनलोड निर्देशों द्वारा अनुरोध की गई कई कैश लाइनें खपत होने की संभावना है। यह MEM_LOAD_RETIRED.L2_LINE_MISS ईवेंट का उपयोग करके जांचा जा सकता है, जो केवल डाउनलोड पढ़ता है, और L2_LD.SELF.DEMAND ईवेंट, जो कैश डाउनलोड और डाउनलोड पढ़ता है, जिसमें L1 प्रीफैच ब्लॉकों से किए गए अनुरोध शामिल हैं।



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

अत्यधिक डिस्क सबसिस्टम उपयोग

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



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



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