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

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

स्केलेबिलिटी क्या है?

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



Intel Core2 माइक्रोआर्किटेक्चर पर आधारित प्रोसेसर प्रदर्शन कार्यक्रम हमें इस उद्देश्य के लिए सुविधाजनक मैट्रिक्स प्रदान करते हैं। प्रत्येक कोर की एक प्रदर्शन निगरानी इकाई (PMU) है, और CPU_CLK_UNHALTED.CORE ईवेंट आपको प्रत्येक कोर पर कार्य चक्रों की संख्या निर्धारित करने की अनुमति देता है। यदि VTune ™ प्रदर्शन विश्लेषक का उपयोग सूचना एकत्र करने के लिए किया जाता है, तो यह संख्या उन सभी कोर के लिए संक्षेपित है, जिन्होंने हमारे लिए ब्याज की प्रक्रिया का प्रदर्शन किया है। यही है, यह संख्या आवेदन निष्पादन पर खर्च किए गए प्रभावी चक्रों की संख्या है। इस नंबर को "प्रभावी_ चक्र" कहें।



पीएमयू की एक उपयोगी विशेषता प्रत्येक चक्र पर कुछ दिए गए संख्या (cmask) के साथ घटना के मूल्य की तुलना करने की क्षमता है और यह निर्धारित करती है कि क्या यह अधिक या बराबर (inv = 0) है या क्या यह इस संख्या (inv = 1) से कम है। यदि ऐसी स्थिति निर्दिष्ट की जाती है, तो पीएमयू केवल चक्र की गणना करेगा यदि यह पूरा हो गया है। हालांकि, यह केवल सामान्य प्रयोजन मीटर के लिए संभव है। निश्चित काउंटर, उदाहरण के लिए, घटनाओं के लिए CPU_CLK_UNHALTED.CORE, INST_RETIRED.ANY और CPU_CLK_UNHALTED.REF, को इस ऑपरेशन के अधीन नहीं किया जा सकता है। यदि ईवेंट CPU का मान CPU_CLK_UNHALTED.CORE_P (कार्य चक्रों के काउंटर का सामान्यीकृत संस्करण) की तुलना "2 से कम" स्थिति के साथ किया जाता है (inv = 1), तो काउंटर सभी चक्रों की गणना करेगा। यदि हम सभी प्रक्रियाओं के लिए इस संख्या को जोड़ते हैं और सिस्टम में कोर की संख्या से विभाजित करते हैं, तो हमें कुल प्रक्रिया निष्पादन समय मिलेगा। हम इस नंबर को "total_cycles" कहते हैं।



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



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

सीमित संसाधन

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

1. सिस्टम थ्रूपुट
   
   
   1. मेमोरी बैंडविड्थ
   2. इंटर-सॉकेट संचार बैंडविड्थ
2. डिस्क सबसिस्टम उपयोग
3. कुल कैश वॉल्यूम
4. डेटा पता अनुवाद बफर का आकार (DTLB)
5. कैश लाइनों तक व्यक्तिगत पहुंच
   
   
   1. लाइन में आम तत्व।
   2. साझा तत्वों के बिना साझा लाइनें (झूठी साझाकरण)

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



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

क्षमता

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



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



Bus Latency = BUS_REQUEST_OUSTANDING.SELF/(BUS_TRANS_BRD.SELF - BUS_TRANS_IFETCH.SELF)







ज्यादातर मामलों में, इफैच घटक (अनुदेश लाने वाला) महत्वहीन होता है, खासकर चोटी के थ्रूपुट के मामले में, और इसलिए इसे नजरअंदाज किया जा सकता है।



कई स्रोत हैं जो सिस्टम बस यातायात में योगदान करते हैं। इंटेल कोर 2 प्रोसेसर प्रदर्शन की घटनाओं से आप इन घटकों द्वारा पूर्ण और व्यक्तिगत बस लोडिंग दोनों को निर्धारित करने के लिए कई तरीकों का उपयोग कर सकते हैं। सिस्टम बस संतृप्ति निर्धारित करना बहुत आसान है। इसे डेटा ट्रांसफर के लिए इस्तेमाल किए जाने वाले बस चक्र के हिस्से के रूप में दर्शाया जा सकता है:



BUS_DRDY_CLOCKS.ALL_AGENTS/CPU_CLK_UNHALTED.BUS







या सीधे, कैश लाइनों के भाग के रूप में बस में स्थानांतरित बाइट्स की संख्या के रूप में:



Cacheline_Bandwidth (/) ~ 64*BUS_TRANS_BURST.ALL_AGENTS*core_freq / CPU_CLK_UNHALTED.CORE







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

BUS_TRANS_ * घटनाओं को बस घटकों को अलग करने के लिए पदानुक्रम का उपयोग किया जा सकता है। उनका संक्षिप्त विवरण नीचे दी गई तालिका में प्रस्तुत किया गया है, और वे वीटीएनएफ प्रदर्शन विश्लेषक ऑनलाइन सहायता में भी बहुत विस्तृत हैं।

घटना	विवरण
BUS_TRANS_ANY	बस में सभी लेनदेन: मेम, आईओ, डिफ, आंशिक
BUS_TRANS_MEM	सभी कैश लाइनें, आंशिक और अमान्य
BUS_TRANS_BURST	सभी कैश लाइनें: Brd, RFO, WB, कंबाइंड राइट
BUS_TRANS_BRD	सभी कैशे लाइन पढ़ता है: डेटा, इफेट
BUS_TRANS_IFETCH	सभी अनुदेश कैश लाइनों
BUS_TRANS_RFO	अनन्य उपयोग का अनुरोध करते समय कुल कैश लाइनें
BUS_TRANS_WRB	सभी कैश लाइन प्रविष्टियाँ (संशोधित कैश लाइनें)

बस यातायात को कम करने के कई मानक तरीके हैं जिन्हें आप प्लेटफॉर्म की सीमा तक पहुंचने पर लागू कर सकते हैं। इनमें निम्नलिखित विधियाँ शामिल हैं:

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

पूर्वगामी किसी भी तरह से संभावित विकल्पों की एक विस्तृत सूची होने का दावा नहीं करता है, बल्कि यह सबसे स्पष्ट की एक सूची है। जो भी वास्तव में कोशिश करता है वह कहेगा कि बाद की तुलना में आमतौर पर आसान कहा जाता है।

---

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



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