🤳🏼 🖐️ 🏓 मल्टी-कोर इंटेल कोर 2 प्रोसेसर (भाग 4) के उदाहरण का उपयोग करके स्केलेबिलिटी समस्याओं को खोजें और हल करें 🤙🏾 🙃 🙉

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

संभवत: सबसे सरल उदाहरण सरणी तत्वों के मूल्यों के समानांतर योग के लिए एल्गोरिदम है। इस स्थिति में, प्रत्येक थ्रेड तत्वों के अपने सेट को संक्षेप में प्रस्तुत करेगा। यह एल्गोरिथम इस तरह दिख सकता है:

int sum(int* data, int* sum, int size, int tid) { int i; for(i=0; i < size; i++) *sum += data[i]*data[i]; return *sum; }

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

हालांकि, सभी कंपाइलर इतने स्मार्ट नहीं हैं। यदि फ़ंक्शन इस तरह घोषित किया जाता है:

int sum(int* data, volatile int* sum, int size, int tid)

तब संकलक को "मेमोरी" को रजिस्टर मेमोरी में स्थानांतरित करने के लिए मना किया जाता है, जो कैश लाइन के लिए एक लड़ाई की गारंटी देता है। ऊपर बताई गई घटनाएं नदी में बाढ़ ला देंगी।

दूसरे उदाहरण के रूप में, आइए एक सरणी में एक बहुत ही सरल तीन-नेस्टेड क्रमबद्ध लूप लें जो हमारी चर्चा के लिए उत्कृष्ट है।

 #define MAXTHR 4 #define ITERS 1000 #define SIZE 1000 int aa[MAXTHR][SIZE]; volatile int i[MAXTHR], j[MAXTHR], k[MAXTHR], n[MAXTHR], tmp[MAXTHR]; int sort(int *a, int size, int tid) //a = aa[tid][0] { n[tid] = 0; for (k[tid]=0; k[tid] < ITERS/2; k[tid]++){ for (i[tid] = 0; i[tid] < size-1; i[tid]++){ for (j[tid] = i[tid]+1; j[tid] < size; j[tid]++){ if (a[i[tid]] > a[j[tid]]){ tmp[tid] = a[i[tid]]; a[i[tid]] = a[j[tid]]; a[j[tid]] = tmp[tid]; n[tid]++; } } } for (i[tid] = 0; i[tid] < size-1; i[tid]++){ for (j[tid] = i[tid]+1; j[tid] < size; j[tid]++){ if (a[i[tid]] < a[j[tid]]){ tmp[tid] = a[i[tid]]; a[i[tid]] = a[j[tid]]; a[j[tid]] = tmp[tid]; n[tid]++; } } } } return n[tid]; }

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

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

मान लीजिए कि हमने VTune विश्लेषक का उपयोग करके डेटा एकत्र किया है, तो हम घटना की मात्रा के बीच संबंधों को देखते हैं। EXT_SNOOP.ALL_AGENTS_HITM की संख्या BUS_HITM_DRV के लगभग बराबर है। आइए ध्यान दें कि एप्लिकेशन लॉन्च से लॉन्च तक कैसे व्यवहार करता है, घटनाओं का क्या होता है। MEM_LOAD_RETIRED.L2_MISS, MEM_LOAD_RETIRED.L2_LINE_MISS से बहुत अधिक है। MEM_LOAD_RETIRED.L2_LINE_MISS की संख्या, बस पर प्रसारित कैश लाइनों की संख्या से बहुत कम है, जो कि BUS_TRANS_BURST.SELF द्वारा जज हैं। सबसे बड़ा योगदान BUS_TRANS_RFO.SELF ईवेंट द्वारा मापा गया अनन्य उपयोग अनुरोधों (RFO) के लिए किया जाता है। हम BUS_TRANS_BURST.SELF द्वारा मापी गई बस यातायात में RFO के योगदान का अनुमान लगाते हैं।

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

इसलिए, यह निर्धारित करने के लिए कि क्या कैश लाइनों के लिए प्रतिस्पर्धा है, बुनियादी मूल्यों को निर्धारित करने के लिए एकल-थ्रेडेड खाते के साथ डेटा एकत्र करना बुद्धिमान होगा, और उसके बाद ही बहु-थ्रेडेड लोगों के साथ। झूठी लाइन साझाकरण की पहचान करने के लिए, संभवतः VT_L विश्लेषक में स्रोत कोड को देखते समय MEM_LOAD_RETIRED.L2_MISS, इस घटना की चोटियों की संख्या और स्थान की तुलना करना सबसे अच्छा है। आमतौर पर, सब कुछ तुरंत स्पष्ट हो जाता है, अगर आप EXT_SNOOPS.ALL_AGENTS.HITM पर भी ध्यान देते हैं।

एक्सेस ब्लॉकिंग संघर्षों का पता लगाना भी काफी सरल है। L2_LOCK.SELF.E_STATE घटना तब होती है जब एक म्यूटेक्स लॉक बनाने के लिए एक एक्सेस लॉक (xchg इंस्ट्रक्शन के अलावा) का उपयोग किया जाता है। यदि लॉक की गई वस्तु को संशोधित किया गया है, तो L2_LOCK.SELF.M_STATE घटना भी घटित होगी। IP प्रीफ़ैच ब्लॉक के कारण, MEM_LOAD_RETIRE.L2_LINE_MISS ईवेंट हमारी खोज के लिए प्रभावी नहीं है। इस मामले में, चोटियों MEM_LOAD_RETIRED.L2_MISS के साथ L2_LD.LOCK.E_STATE जब VTune विश्लेषक में स्रोत कोड को देखते हुए घटना की तस्वीर को स्पष्ट करते हैं। EXT_SNOOP.HITM.ALL_AGENTS फिर से इन मामलों में मौजूद है।

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

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

निष्कर्ष

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

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

निष्कर्ष

More articles: