अनुप्रयोग स्केलेबिलिटी पर डेटा बस लोडिंग का प्रभाव

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

नीचे सिस्टम में मेमोरी बस की स्थिति दिखाने वाली एक तस्वीर है। बाईं ओर कोर 2 के "एंटीडिलुवियन" वास्तुकला के लिए एक आरेख है, कम पुराने के लिए दाईं ओर - नेहेलम। बाद के सभी इंटेल आर्किटेक्चर में नेहेलम (इंटेल एमआईसी के अपवाद के साथ) के समान योजना है।



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

आइए देखें कि बस लोड स्केलेबिलिटी को कैसे प्रभावित करता है। ऐसा करने के लिए, हम एक सरल प्रोग्राम लिखेंगे जो एक चक्र में एक आयामी सरणी के तत्वों को पढ़ेगा और लिखेगा।



हम इस कार्यक्रम को विभिन्न थ्रेड्स और एक अलग STEP पैरामीटर के साथ चलाएंगे। STEP पैरामीटर कैश लाइन के उपयोग से मेल खाता है। हमें याद है कि प्रोसेसर 64 बाइट्स के भागों में मेमोरी के साथ आदान-प्रदान करता है, जिसे कैश लाइनें कहा जाता है। अगर हमें सिर्फ एक बाइट पढ़ने की ज़रूरत है, तो प्रोसेसर मेमोरी से 64 बाइट्स डाउनलोड करेगा। ऐसा डेटा विनिमय स्थानिक इलाके के सिद्धांत के कारण होता है । यह पहला सिद्धांत है जो कैश को रेखांकित करता है। प्रोसेसर, जैसा कि यह था, मानता है कि अगर हम मेमोरी से किसी ऐरे का कुछ मूल्य पढ़ते हैं, तो अगले चरण में हमें उसी ऐरे से अगला मान पढ़ने की जरूरत है। इसलिए, बस पर लोड को कम करने के लिए डेटा को एक-दूसरे के करीब रखना महत्वपूर्ण है। इस प्रकार, STEP = 1 के साथ, कैश लाइन का उपयोग 100% है, STEP = 4 के साथ, उपयोग 25% है, STEP = 8, उपयोग 12.5% ​​है और STEP = 64 पर, उपयोग 1.56% है। वास्तव में, अंतिम पैरामीटर का अर्थ है आंतरिक लूप के प्रत्येक पुनरावृत्ति पर एक नई कैश लाइन डाउनलोड करना।

एक और ध्यान दें: परीक्षण कार्यक्रम इंटेल कंपाइलर द्वारा –no-vec विकल्प के साथ वेक्टर के बजाय स्केलर कोड प्राप्त करने के लिए संकलित किया गया था। यह सिद्धांत की समझ को सुविधाजनक बनाने के लिए "सुंदर डेटा" प्राप्त करने के लिए किया गया था।



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



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

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



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



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

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

अब इस लेख के मुख्य प्रश्न का उत्तर दें: "और आप कैसे समझते हैं कि एप्लिकेशन की खराब मापनीयता डेटा बस के उच्च भार के कारण होती है?"।
इस प्रश्न का उत्तर देने के लिए, हमें VTune Amplifer का उपयोग करके इन चरणों का पालन करना चाहिए:

1. हमारे सिस्टम में डेटा बस के लिए पीक लोड को मापें
2. पता करें कि हमारे आवेदन में थ्रेड्स की संख्या में वृद्धि के आधार पर बस लोड कैसे बदलता है
3. यदि हम देखते हैं कि थ्रेड्स की संख्या में वृद्धि के साथ, बस लोड जल्दी से चरम मूल्यों (बिंदु 1 में मापा जाता है) तक पहुंचता है, तो यह हमारी परेशानी (खराब स्केलेबिलिटी) का कारण है। उसी समय, हमें यह समझना चाहिए कि अन्य कारण (उदाहरण के लिए, झूठे-साझाकरण) हैं जिन्हें हमने पहले ही सत्यापित कर लिया है।

चोटी के भार का निर्धारण करने के लिए, हम पैरामीटर STEP = 64 के साथ पहले उदाहरण से परीक्षण कार्यक्रम लेते हैं।



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

अब आइए वास्तविक जीवन से एक उदाहरण देखें। विनिर्देश CPU2006 पैकेज से 470.lbm एप्लिकेशन लें। यह हाइड्रोडायनामिक्स (पूर्ण नाम Lattice Boltzhausen) की समस्याओं को हल करने के लिए प्रसिद्ध विधि के संस्करणों में से एक है। इस संस्करण को इस तरह से लिखा गया है कि प्रोसेसर से लोड संतुलन को मेमोरी बस में स्थानांतरित किया जाए। आइए, नेहेलम पर आधारित दोहरे सॉकेट सर्वर पर एप्लिकेशन लॉन्च करें और स्केलेबिलिटी को देखें।



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

अब इस एप्लिकेशन के हॉट लूप पर एक नज़र डालें।



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



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



और परिणाम:



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



आठ कोर पर आठ एकल-थ्रेडेड प्रतियों के एक साथ निष्पादन में 252 सेकंड लगते हैं, जो कि बहु-थ्रेडेड संस्करण के लगातार आठ से कम है, जिसमें 8 * 37 = 296 सेकंड लगते हैं। इससे पता चलता है कि बहु-थ्रेडेड संस्करण में समानांतरण से जुड़ी कुछ एल्गोरिथम समस्याएं हैं। लेकिन वह एक और कहानी है।