हार्डवेयर त्वरक प्रोग्रामिंग का भविष्य

नवीनतम सुपर कंप्यूटरों में से कई हार्डवेयर त्वरक पर आधारित हैं। 11/2013 से TOP500 के अनुसार दो सबसे तेज़ सिस्टम शामिल हैं। त्वरक को साधारण पीसी पर भी वितरित किया जाता है और यहां तक ​​कि पोर्टेबल उपकरणों पर भी दिखाई देता है, जो आगे त्वरक प्रोग्रामिंग में बढ़ती रुचि के लिए योगदान देता है।

त्वरक का इतना व्यापक उपयोग उनके उच्च प्रदर्शन, ऊर्जा दक्षता और कम लागत का परिणाम है। उदाहरण के लिए, अगर हम Xeon E5-2687W और GTX 680 की तुलना करते हैं, तो मार्च 2012 में जारी किया गया, हम देख सकते हैं कि GTX 680 चार गुना सस्ता है, इसमें एकल परिशुद्धता संचालन का 8 गुना अधिक प्रदर्शन और 4 गुना अधिक मेमोरी बैंडविड्थ है, और यह भी प्रदान करता है डॉलर के संदर्भ में 30 गुना अधिक प्रदर्शन और प्रति वाट 6 गुना अधिक प्रदर्शन। इन तुलनात्मक परिणामों के आधार पर, हर जगह और हमेशा त्वरक का उपयोग किया जाना चाहिए। ऐसा क्यों नहीं हो रहा है?

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

जीपीयू का उपयोग करने के प्रारंभिक प्रयास, जो वर्तमान में सबसे प्रसिद्ध प्रकार के त्वरक हैं, गैर-ग्राफिकल अनुप्रयोगों को तेज करने के लिए बोझिल थे और उन्हें shader कोड के रूप में गणना की प्रस्तुति की आवश्यकता थी जो एक सीमित नियंत्रण प्रवाह का समर्थन करता था और पूर्णांक संचालन का समर्थन नहीं करता था। धीरे-धीरे, इन प्रतिबंधों को हटा दिया गया, जो ग्राफिक चिप्स पर कम्प्यूटेशन के व्यापक प्रसार में योगदान देता है और गैर-ग्राफिक क्षेत्रों के विशेषज्ञों को उन्हें प्रोग्राम करने की अनुमति देता है। इस दिशा में सबसे महत्वपूर्ण कदम CUDA प्रोग्रामिंग भाषा की रिहाई के साथ लिया गया था। यह अतिरिक्त क्वालिफायर और कीवर्ड्स के साथ C / C ++ का विस्तार करता है, साथ ही कार्यों के पुस्तकालयों और कोड के भागों को लॉन्च करने के लिए एक तंत्र, जिसे कर्नेल, GPU कहा जाता है।

CUDA के प्रारंभिक अपनाने, इस तथ्य के साथ संयुक्त है कि यह एक मालिकाना उत्पाद है और उच्च-गुणवत्ता वाले CUDA कोड को लिखने में कठिनाई होती है, जिससे OpenCL, C ++ AMP और OpenACC सहित त्वरक प्रोग्रामिंग के लिए अन्य दृष्टिकोणों का निर्माण होता है। OpenCL CUDA का एक गैर-मालिकाना समकक्ष है और कई बड़ी कंपनियों के समर्थन का आनंद उठाता है। यह केवल NVidia चिप्स तक सीमित नहीं है, बल्कि AMD GPU, मल्टी-कोर CPU, MIC (Intel Xeon Phi), DSP और FPGA को भी सपोर्ट करता है, जो इसे पोर्टेबल बनाता है। हालांकि, CUDA की तरह, यह बहुत कम स्तर है। इसे प्रोग्रामर को सीधे डेटा की गति को नियंत्रित करने की आवश्यकता होती है, इसे सीधे मेमोरी पदानुक्रम में चर के भंडारण स्थानों को निर्धारित करने और मैन्युअल रूप से कोड में समानता को लागू करने की आवश्यकता होती है। C ++ त्वरित द्रव्यमान समानतावाद (C ++ AMP) मध्य स्तर पर काम करता है। यह आपको सी ++ में पहले से ही समानांतर एल्गोरिदम का वर्णन करने की अनुमति देता है और प्रोग्रामर से सभी निम्न-स्तरीय कोड छुपाता है। "प्रत्येक के लिए" बयान समानांतर कोड encapsulate करता है। सी ++ एएमपी विंडोज से जुड़ा हुआ है, अभी तक सीपीयू का समर्थन नहीं करता है और बड़े स्टार्टअप ओवरहेड्स से ग्रस्त है, जो इसकी मदद से अल्पकालिक कोड में तेजी लाने के लिए व्यावहारिक रूप से अक्षम बनाता है।

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

यह समझने के लिए कि भविष्य में हार्डवेयर एक्सेलेरेटर का प्रोग्रामिंग क्षेत्र कैसे विकसित होगा, यह पता लगाने के लायक है कि अन्य हार्डवेयर त्वरक के साथ अतीत में एक समान प्रक्रिया कैसे आगे बढ़ी। उदाहरण के लिए, शुरुआती उन्नत पीसी में एक अतिरिक्त प्रोसेसर था - एक कोप्रोसेसर जो फ्लोटिंग पॉइंट गणना करता है। बाद में इसे एक केंद्रीय प्रोसेसर - सीपीयू - के साथ चिप पर एकीकृत किया गया था और अब यह इसका एक अभिन्न हिस्सा है। उनके पास केवल अलग रजिस्टर और अंकगणितीय तर्क उपकरण (ALU) हैं। बाद में SIMD प्रोसेसर एक्सटेंशन (MMX, SSE, AltiVec और AVX) को अलग-अलग चिप्स के रूप में जारी नहीं किया गया था, लेकिन अब वे प्रोसेसर कोर में भी पूरी तरह से एकीकृत हो गए हैं। फ्लोटिंग पॉइंट ऑपरेशंस की तरह, SIMD निर्देशों को अलग ALU में गणना की जाती है और अपने स्वयं के रजिस्टरों का उपयोग किया जाता है।

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

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

कुछ त्वरक पहले से ही पारंपरिक प्रोसेसर के साथ एक चिप पर संयोजित किए गए हैं, जैसे कि एएमडी एपीयू (एक्सबॉक्स वन में इस्तेमाल किया गया), इंटेल प्रोसेसर के साथ एकीकृत एचडी-ग्राफिक्स और एनवीआईडीआईए से टेग्रा एसओसी। हालांकि, एक्सीलरेटर संभवतः एक अलग कोर बने रहेंगे क्योंकि पारंपरिक प्रोसेसर कोर के साथ उन्हें उसी सीमा तक जोड़ना मुश्किल है, जैसा कि गणितीय कॉपोरेसर और SIMD एक्सटेंशन के साथ किया गया था, अर्थात, रजिस्टरों के सेट में कटौती और केंद्रीय प्रोसेसर के हिस्से के लिए एक अलग ALU। । अंत में, त्वरक इतनी तेजी से, समानांतर और ऊर्जा-कुशल हैं, जो सीपीयू से अलग आर्किटेक्चर के कारण हैं, जैसे कि एक डिस्कनेक्ट कैश, पूरी तरह से अलग पाइपलाइन कार्यान्वयन, जीडीआरडी 5 मेमोरी, और परिमाण का एक आदेश अधिक रजिस्टरों और मल्टीथ्रेडिंग। नतीजतन, त्वरक पर कोड चलाने की जटिलता अभी भी बनी हुई है। चूँकि एक नियम के रूप में सिंगल चिप पर बने प्रोसेसर कोर में मेमोरी पदानुक्रम का केवल निम्न स्तर होता है, इसलिए, सीपीयू और एक्सेलेरेटर के बीच डेटा विनिमय दर में संभवतः वृद्धि होगी, लेकिन यह एक अड़चन बनी रहेगी।

उपकरणों के बीच डेटा विनिमय की प्रक्रियाओं को स्पष्ट रूप से नियंत्रित करने की आवश्यकता त्रुटियों का एक महत्वपूर्ण स्रोत है और प्रोग्रामर पर भारी बोझ पड़ता है। यह अक्सर छोटे एल्गोरिदम के लिए होता है कि गणना के मुकाबले डेटा के आदान-प्रदान को व्यवस्थित करने के लिए अधिक कोड लिखना पड़ता है। इस बोझ को खत्म करना उच्च स्तरीय प्रोग्रामिंग दृष्टिकोणों जैसे C ++ AMP और OpenACC के मुख्य लाभों में से एक है। यहां तक ​​कि निम्न-स्तरीय कार्यान्वयन इस समस्या को हल करने के उद्देश्य से हैं। उदाहरण के लिए, अच्छी तरह से डीबग की गई और एकीकृत मेमोरी एक्सेस मुख्य सुधारों में से एक है जो CUDA, OpenCL और NVIDIA GPU हार्डवेयर समाधानों के नवीनतम संस्करणों में किए गए हैं। फिर भी, अच्छा प्रदर्शन प्राप्त करने के लिए आमतौर पर प्रोग्रामर की मदद की आवश्यकता होती है, यहां तक ​​कि बहुत उच्च-स्तरीय समाधानों जैसे कि ओपनएसीसी में भी। विशेष रूप से, आवश्यक स्थानों पर मेमोरी आवंटित करना और डेटा को स्थानांतरित करना अक्सर मैन्युअल रूप से करने की आवश्यकता होती है।

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

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

C ++ AMP और OpenACC एक अलग दृष्टिकोण का उपयोग करते हैं - स्वचालन उपकरण। इस दृष्टिकोण के साथ, कड़ी मेहनत को कंपाइलर को स्थानांतरित कर दिया जाता है। इसकी सफलता मौजूदा सॉफ्टवेयर टूल्स की गुणवत्ता और जटिलता पर निर्भर करती है और जैसा कि कहा गया है, अक्सर एक प्रोग्रामर के हस्तक्षेप की आवश्यकता होती है। फिर भी, अधिकांश प्रोग्रामर इस दृष्टिकोण का उपयोग करके अच्छे परिणाम प्राप्त कर सकते हैं, जो पुस्तकालयों से पूर्वनिर्धारित कार्यों का उपयोग करने के लिए सीमित नहीं है। यह SQL के "इंटर्नल" विशेषज्ञों के कितने समूहों को लागू करने के समान है, जो सामान्य डेवलपर्स को भविष्य में तैयार-अनुकूलित अनुकूलित कोड का उपयोग करने की अनुमति देता है।

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

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

हार्डवेयर विशेषताओं और ऊपर वर्णित विकास प्रक्रिया को ध्यान में रखते हुए, हम कह सकते हैं कि भविष्य के प्रोसेसर चिप्स में कई क्लस्टर अपनी स्मृति के साथ होंगे। प्रत्येक क्लस्टर में कई कोर होंगे, लेकिन सभी कोर कार्यात्मक रूप से समान नहीं होंगे। प्रत्येक बहु-थ्रेडेड कोर में कई कंप्यूटिंग इकाइयां (यानी, कार्यात्मक इकाइयां या ALU) शामिल होंगी और प्रत्येक कंप्यूटिंग इकाई SIMD कमांड को निष्पादित करेगी। यहां तक ​​कि अगर भविष्य के चिप्स एक बार में यह सब शामिल नहीं करेंगे, तो उन सभी में एक महत्वपूर्ण समानता होगी, अर्थात्, समानता के स्तरों का एक पदानुक्रम। इस तरह की प्रणालियों के लिए कुशल और पोर्टेबल कार्यक्रम बनाने के लिए, हम प्रस्ताव देते हैं कि जिसे हम प्रचुर-समानांतर तकनीक कहते हैं। यह एक सामान्यीकरण है कि कैसे एक प्रोग्रामर MPI प्रोग्राम को अलग-अलग संख्या में कंप्यूटिंग नोड्स या एक OpenMP कोड को अलग-अलग संख्या में कोर या थ्रेड्स के साथ जोड़ देता है।

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

हमने एन-बॉडी के सीधे मॉडलिंग की समस्या पर इस दृष्टिकोण का परीक्षण किया । हमने OpenCL का उपयोग करके व्यापक समानता के साथ एल्गोरिदम का एकमात्र कार्यान्वयन लिखा था और चार पूरी तरह से अलग हार्डवेयर आर्किटेक्चर पर मापा गया था: NVIDIA GeForce Titan GPU, AMD Radeon 7970 GPU, Intel Xeon E5-2690 CPU और Intel Xeon Phi 5150P MIC। यह मानते हुए कि सभी फ्लोटिंग-पॉइंट ऑपरेशंस में से 54% FMA ऑपरेशंस (FMA - मल्टीप्लेक्शन ऑफ़ संचय के साथ) नहीं थे, व्यापक समानता ने NVIDIA टाइटन के लिए 75% सैद्धांतिक शिखर, Radeon के लिए 95%, CPU के लिए 80.5% और परफॉर्मेंस को प्राप्त करना संभव बना दिया। MIC के लिए 80%। यह सिर्फ एक अलग उदाहरण है, लेकिन इसके परिणाम बहुत उत्साहजनक हैं। वास्तव में, हमारा मानना ​​है कि मौजूदा और भविष्य के हार्डवेयर त्वरक प्रणालियों के लिए पोर्टेबल हाइ-परफॉर्मेंस प्रोग्राम लिखने के लिए कुछ समय के लिए व्यापक समरूपता ही एकमात्र तरीका होगा।

[ स्रोत ]
9 जनवरी 2014
कामिल रॉकी और मार्टिन बर्टशर