ओपनएमपी में अनुकूलन

परियोजना का क्रमिक विकास हमेशा की तरह हुआ।

अनुदान के तहत प्राप्त धन के कुछ हिस्सों के लिए, व्यक्तिगत कंप्यूटर उपकरणों के बेड़े को अपडेट किया गया था। नतीजतन, गणना अब एक लंबे समय से पीड़ित लैपटॉप पर नहीं, बल्कि बोर्ड पर एक छद्म-आठ-कोर इंटेल कोर i7-2600 और 8 जीबी रैम के साथ पूरी तरह से स्वीकार्य मशीन पर की जाती है। और विकास इंटेल फोरट्रान कंपाइलर 12 / इंटेल समानांतर स्टूडियो XE 2011 कनेक्टेड के सभी संस्करण के साथ विजुअल स्टूडियो 2005 (ड्रीमस्पार्क प्रोग्राम के माध्यम से प्राप्त) के तहत किया जाता है (यह सब विन 7 के तहत काम करता है)। OpenMP एक समानांतर API के रूप में शामिल है।

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

अपडेट: पोस्ट, सामान्य रूप से, एक ग्रे वर्किंग डेली रूटीन है, और इसमें कोई भी खोज शामिल नहीं है।

गंदी गंदी चाल

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

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

मामूली बग को ठीक करता है

अनुकूलन करने के लिए क्या किया गया है?

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

 !$OMP PARALLEL DO NUM_THREADS(Threads_number) SCHEDULE(DYNAMIC) & !$OMP PRIVATE(...) & !$OMP COPYIN(...) & !$OMP DEFAULT(SHARED) 

चरों की सूची को यहां छोड़ दिया गया है उनके साथ, कोड लगभग एक दर्जन लाइनें लेता है।

कोड में ऐसी नौ जगहें हैं। नौ अड़चनें जिसके माध्यम से एम। एव्डोकिमोव के हवाले से यह कार्यक्रम "झांकता है, लेकिन क्रॉल करता है।"

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

100x100 के लिए:

200x200 के लिए:


जाहिर है, जैसे-जैसे गणना की हिस्सेदारी बढ़ती है, परिणाम बेहतर होते जाते हैं, लेकिन ऐसी इच्छा को बुलाने की कोई इच्छा नहीं है।

KMP_BLOCKTIME मान को 200 ms से बढ़ाकर 10 सूत्र तक नींद की कमी को एक ही तरीके से लागू करने से मदद मिली।

छोटी बकवास दुर्लभ है

अचानक, एल्गोरिथ्म में प्रवाह द्वारा गठित "स्पैटो-टेम्पोरल" संरचना पर एक कठोर नज़र डाली गई थी। और सभी एक बार जगह में गिर गए। कमजोर बिंदु निर्देश था

 !$OMP PARALLEL DO NUM_THREADS(Threads_number) SCHEDULE(DYNAMIC) 

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


कार्यक्रम के समानांतर हिस्से की संरचना का पूर्ण पुनर्गठन किया गया था। अब प्रवाह आरेख इस तरह दिखता है:

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

और स्रोत पाठ में, निर्देशों की संरचना इस तरह दिखती है:

 Time_cycle: do n = 0, Nt, 1 !$OMP PARALLEL NUM_THREADS(Threads_number) & !$OMP PRIVATE(...) & !$OMP COPYIN(...) & !$OMP DEFAULT(SHARED) !$OMP DO SCHEDULE(DYNAMIC) ... !$OMP END DO ...  7    !$OMP SINGLE ...    !$OMP END SINGLE !$OMP DO SCHEDULE(DYNAMIC) ... !$OMP END DO !$OMP END PARALLEL enddo Tyme_Cycle 

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

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

नतीजतन, कोड के सही समानांतर निष्पादन का समय बढ़ रहा है। 3x200 ग्रिड पर, VTune नोड इस परिणाम को दर्शाता है:


एक 100x100 ग्रिड पर - यह:


अंत में, 200x200 पर - यह:


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

सवाल उठता है कि क्या इसके लायक समय और प्रयास को अनुकूलित करने के लिए काम किया जाता है? कार्यक्रम की वास्तविक गति की जाँच करें। प्रक्षेपण को आठ धाराओं के साथ एक ही तीन अलग-अलग ग्रिड पर किया गया था, और एक निश्चित नियंत्रण बिंदु के लिए समय मापा गया था। सभी मामलों में नियंत्रण बिंदु अलग-अलग हैं, इसलिए, अलग-अलग ग्रिड के बीच पूर्ण शब्दों में तुलना करना सही नहीं होगा - 3 x 200 के लिए 1 मिलियन पुनरावृत्तियों, 100 x 100 के लिए 500 हजार और 200 x 200 नोड के लिए 200 हजार। कोष्ठक में दूसरी पंक्ति कार्यक्रम के दो संस्करणों के बीच निष्पादन समय में सापेक्ष अंतर दिखाती है।

ग्रिड आकार	लीड समय, एस
अनुकूलन से पहले 3 x 200	94.4
3 x 200, अनुकूलित	70.0 (-26%)
अनुकूलन से पहले 100 x 100	352
100 x 100, अनुकूलित	285 (-19%)
अनुकूलन से पहले 200 x 200	543
200 x 200, अनुकूलित	436 (-19%)

यह काफी स्पष्ट है कि किए गए अनुकूलन ने एक अच्छा प्रदर्शन बढ़ाया है।

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

3x200 ग्रिड, 1 मिलियन पुनरावृत्तियों:

अनुकूलन से पहले धागे की संख्या	लीड समय, एस
1	80.9
2	88.7
3	84.4
4	83.7
8	94.4
अनुकूलन के बाद थ्रेड्स की संख्या	लीड समय, एस
1	87.9
2	145
3	113
4	97.8
8	70.0

ग्रिड 100x100, 500 हजार पुनरावृत्तियों:

अनुकूलन से पहले धागे की संख्या	लीड समय, एस
1	918
2	736
3	536
4	431
8	352
अनुकूलन के बाद थ्रेड्स की संख्या	लीड समय, एस
1	845
2	528
3	434
4	381
8	285

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

निष्कर्ष? मुख्य निष्कर्ष एक है - यह देखें कि कार्यक्रम में धागे कैसे पैदा होते हैं और मर जाते हैं। उनके जीवन का विस्तार करना उपयोगी हो सकता है।

प्रवाह के अनुपात-लौकिक संरचना का एहसास पुनर्व्यवस्था, विशेष रूप से, यहाँ वर्णित है:
OpenMP * का उपयोग करके थ्रेड्स के बीच कुशल लोड संतुलन । यह सिर्फ एक समाधान के साथ आने के बाद ही पढ़ा गया था। मैं कुछ दिन बचा लेता, एह।