नए मल्टीस्कूल न्यूरोपैसर के लिए सी कंपाइलर का विकास

सिस्टम और टूल सॉफ्टवेयर के डेवलपर्स के एक सम्मेलन में - ओएस डीएवाई 2016, जिसे 9-10 जून, 2016 (कजान) में एकाधिकार में आयोजित किया गया था, जब बहुकोशिकीय वास्तुकला पर एक रिपोर्ट पर चर्चा की गई थी, विचार व्यक्त किया गया था कि यह कृत्रिम बुद्धि की समस्याओं को हल करने में सबसे प्रभावी होगा। एआई कार्यों पर केंद्रित एक नए सामान्य-प्रयोजन प्रोसेसर के विकास की शर्तें इस वर्ष विकसित हुई हैं।

न्यूरोप्रोसेसर एस 2 मल्टिलेट, जिसकी परियोजना को पहली बार हुआवेई इनोवेशन फोरम 2019 में प्रस्तुत किया गया था, मल्टीसेल आर्किटेक्चर का एक और विकास है। यह पहले से बनाई गई बहुस्तरीय आदेशों की प्रणाली, अर्थात् नए प्रकार के छोटे आकार के डेटा (निश्चित और अस्थायी बिंदु के साथ) और उनके साथ संचालन से भिन्न होता है। कोशिकाओं की संख्या में वृद्धि हुई थी - 256 और आवृत्ति - 2.5 गीगाहर्ट्ज, जो 16F पर 81.9 TFlops का एक चरम प्रदर्शन प्रदान करना चाहिए और, तदनुसार, इसे तंत्रिका गणना के संदर्भ में, आधुनिक विशेष ASICICUs (TPU-3: 90 TFlops) की क्षमताओं के साथ तुलना करें। 16F)।

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

पिछले लेख में कंपाइलर ऑप्टिमाइज़ेशन का उल्लेख किया गया है जो लागू करने लायक है। यदि आप पहले से ही परिचित नहीं हैं, तो आप बहुकोशिकीय वास्तुकला पर सामग्री पा सकते हैं।

दो स्थिरांक के साथ दो-तर्क कमांड उत्पन्न करना

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

उदाहरण के लिए:

load_l func wr_l @1, #SP 

द्वारा प्रतिस्थापित किया जा सकता है:

 wr_l func, #SP 

या एक ही बार में दो टीमें:

 load_l [foo] load_l [bar] add_l @1, @2 

दो निरंतर पते हैं, और उनसे पढ़ने को भी सीधे कमांड के तर्कों में प्रतिस्थापित किया जा सकता है:

 add_l [foo], [bar] 

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

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

आधार इकाइयों के बीच आभासी रजिस्टरों के हस्तांतरण का अनुकूलन

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

Phi नोड SSA (स्टेटिक सिंगल असाइन्मेंट) फॉर्म का एक परिणाम है जिसमें LLVM प्रेजेंटेशन लैंग्वेज का प्रतिनिधित्व किया जाता है। इस रूप में, एक चर (या, एलएलवीएम आईआर के मामले में - वर्चुअल रजिस्टर) केवल एक बार लिखा जा सकता है। उदाहरण के लिए, यह छद्म कोड:

 a = 1; if (v < 10) a = 2; else a = 3; b = a; 

एसएसए के रूप में प्रस्तुत नहीं किया गया है, क्योंकि चर के मूल्य को अधिलेखित किया जा सकता है। यदि आप phi नोड का उपयोग करते हैं, तो कोड को इस रूप में फिर से लिखा जा सकता है:

 a1 = 1; if (v < 10) a2 = 2; else a3 = 3; b = phi(a2, a3); 

Phi नोड a2 या a3 का चयन करता है, इस पर निर्भर करता है कि नियंत्रण प्रवाह कहां से आया है:

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

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

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

 result := add_l [A], [B] ; ;    ; wr_l @result, C 

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

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

Phi होस्ट को स्मृति के बजाय एक स्विच का उपयोग करने की अनुमति देने के लिए, निम्नलिखित किया गया था:

1. वर्तमान आधार इकाई में सभी फी नोड्स गिने जाते हैं (और कई हो सकते हैं), क्रम संख्या के साथ चिह्नित हैं और इस क्रम में हैं
2. प्रत्येक phi नोड के लिए, इसे शुरू करने वाले मूल ब्लॉक को बायपास किया जाता है, इसी phi नोड के सीरियल नंबर द्वारा चिह्नित स्विच ( लोडु_क ) में मानों को लोड करने के लिए कमांड उन्हें जोड़ा जाता है।
3. नोड के phi निर्देश को भी अपने सीरियल नंबर के साथ loadu_q द्वारा प्रतिस्थापित किया गया है
4. सभी जोड़े गए आदेशों को दिए गए क्रम में पुन: व्यवस्थित किया गया है

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

इनिशियलाइज़र्स फ़ाइ नोड्स के साथ पैराग्राफ:

 LBB1_27: LBB1_30: SR4 := loadu_q @1 setjf_l @0, LBB1_31 setjf_l @0, LBB1_31 SR4 := loadu_q [#SP + 8] SR5 := loadu_q [#SP + 16] SR5 := loadu_q [#SP] SR6 := loadu_l 0x1 SR6 := add_l @SR4, 0xffffffff SR7 := add_l @SR6, [@SR4] loadu_q @SR5 wr_l @SR7, @SR4 loadu_q @SR6 loadu_q @SR6 complete loadu_q @SR5 complete 

दो फी नोड्स वाला एक पैराग्राफ:

 LBB1_31: SR4 := loadu_q @2 SR5 := loadu_q @2 SR6 := loadu_l [#SP + 124] SR7 := loadu_l [#SP + 120] setjf_l @0, @SR7 setrg_q #RETV, @SR4 wr_l @SR5, @SR6 setrg_q #SP, #SP + 120 complete 

इससे पहले, loadu_q कमांड के बजाय , मेमोरी से लिखा और पढ़ा जाएगा।
इस अनुकूलन को लागू करने की प्रक्रिया में, कुछ ऐसी समस्याएं भी थीं जो पहले से नहीं थीं:

• कुछ मौजूदा कोड ऑप्टिमाइज़ेशन स्थानों में आदेशों को पुनर्व्यवस्थित करते हैं, उदाहरण के लिए, अगले पैराग्राफ का पता वर्तमान की शुरुआत में, या मेमोरी के स्थान को क्रमशः पैराग्राफ के आरंभ / अंत में रीड / राइट कमांड लिखते हैं। फ़ाइ नोड्स (प्रोसेसर निर्देश से पहले तथाकथित एलएलवीएम निर्देश) के साथ संचालन के बाद ये अनुकूलन होते हैं, इसलिए वे अक्सर लोडू_क कमांड के अंतर्निहित आदेश को बाधित करते हैं। इन अनुकूलन के काम को बाधित नहीं करने के लिए, मुझे एक अलग एलएलवीएम पास बनाना था, जो कमांड के साथ अन्य सभी जोड़तोड़ के बाद सही क्रम में फी नोड्स के लिए आदेशों की व्यवस्था करता है।
• यह पता चला कि एक स्थिति उत्पन्न हो सकती है जिसमें एक आधार इकाई दो अलग-अलग आधार इकाइयों के लिए फी नोड्स को इनिशियलाइज़ करती है। यही है, संकेतित एल्गोरिथ्म का पालन करते हुए, इन बेस ब्लॉकों को प्रत्येक phi नोड के लिए loadu_q initializing कमांड में जोड़ा जाएगा। इस स्थिति में, भले ही उनके पास केवल एक फी नोड हो, प्रारंभिक अनुभाग में 2 लोडु_क कमांड होंगे , जो, तार्किक रूप से, दोनों को अंतिम स्थान पर होना चाहिए, जो निश्चित रूप से असंभव है। सौभाग्य से, ऐसी स्थितियां काफी दुर्लभ हैं, इसलिए यदि कोई ऐसी आधार इकाई है जिसमें phi नोड्स को एक से अधिक आधार इकाई के लिए आरंभीकृत किया जाता है, तो केवल पहला ही एल्गोरिदम के अनुसार स्विच का उपयोग करता है, बाकी के लिए - पहले की तरह, मेमोरी के माध्यम से।

फी नोड्स के इस सभी अनुकूलन को थोड़ा और पूरक किया जा सकता है। उदाहरण के लिए, यदि आप ऊपर दिए गए अनुच्छेद LBB1_30 को देखते हैं, तो आप देख सकते हैं कि loadu_q लोड मानों को कमांड करता है जो कहीं और उपयोग नहीं किए जाते हैं। यही है, यदि आप loadu_q को हटाते हैं और एक ही क्रम में इन मानों को बनाने वाले कमांड सेट करते हैं, तो अगले अनुभाग में loadu_q @ 2 कमांड भी सही मानों को लोड करेंगे।

मानक

वर्तमान अनुकूलन परिणामों को CoreMark और WhetStone बेंचमार्क पर परीक्षण किया गया था, जिसका विवरण पिछले लेख में पाया जा सकता है। पुराने परिणामों (S1 कोर पर संकलक के पिछले संस्करण) की तुलना में S2 कोर पर CoreMark परिणामों के साथ शुरू करते हैं।

रिश्तेदार CoreMark / मेगाहर्ट्ज मान हिस्टोग्राम में दिखाए गए हैं:



केवल फी नोड्स के अनुकूलन के कारण त्वरण का अनुमान लगाने के लिए, आप 1600 MHz की आवृत्ति के लिए S1 और S2 कोर पर एक मल्टीसेल पर CoreMark संकेतक को पुनर्गणना कर सकते हैं: वे क्रमशः 1147 और 1224 हैं, जिसका अर्थ है 6.7% की वृद्धि।

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

वेटस्टोन स्कोरकार्ड:

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

संकलक अनुकूलन के त्वरण का मूल्यांकन करने के लिए, WhetStone को पिछले संस्करण में भी संकलित किया गया था और S2 के वर्तमान संस्करण पर लॉन्च किया गया था। नए संकलक पर कुल संकेतक 0.3068 MWIPS / MHz बनाम 0.3267 MWIPS / MHz था, अर्थात जो उपरोक्त अनुकूलन के कारण 6.5% का त्वरण दर्शाता है।

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