रेड के लिए कोड अनुकूलन के तरीके। भाग 1: कैश प्रभाव

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



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

परिचय

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

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

श्रृंखला में पिछले लेख:

1. Redd में स्थापित FPGAs के लिए सबसे सरल "फर्मवेयर" का विकास, और एक उदाहरण के रूप में मेमोरी टेस्ट का उपयोग करके डिबगिंग।
2. Redd में स्थापित FPGAs के लिए सबसे सरल "फर्मवेयर" का विकास। भाग 2. कार्यक्रम कोड।
3. FPGA आधारित प्रोसेसर प्रणाली में एम्बेड करने के लिए अपने स्वयं के मूल का विकास।
4. FPGA तक पहुंच के उदाहरण पर केंद्रीय प्रोसेसर रेड के लिए कार्यक्रमों का विकास।
5. रेड एफपीजीए में सीपीयू और प्रोसेसर संचार के उदाहरण पर स्ट्रीमिंग प्रोटोकॉल का उपयोग करते हुए पहला प्रयोग।
6. मीरा क्वार्टरसेल, या प्रोसेसर कैसे इस तरह के जीवन में आया है।

एक विशिष्ट प्रणाली का रहस्यमय व्यवहार

चलो एक घड़ी, एक एनआईओएस II / f प्रोसेसर, एक एसडीआरएएम नियंत्रक, और एक आउटपुट पोर्ट को शामिल करके सबसे सरल प्रोसेसर सिस्टम करते हैं। प्लेटफ़ॉर्म डिज़ाइनर में स्पार्टन यह प्रणाली कैसी दिखती है



इसके लिए प्रोग्राम कोड में केवल एक फ़ंक्शन होगा, जिसका शरीर कुछ अजीब दिखता है, क्योंकि इसमें कई दोहराई जाने वाली लाइनें शामिल हैं, लेकिन यह हमारे लिए उपयोगी होगा।


लाइनों के आखिरी में एक ब्रेकपॉइंट लगाएं:

 IOWR (PIO_0_BASE,0,0); 

मैजिकफंक्शन में और प्रोग्राम को चलाएं। पोर्ट से बाहर निकलने पर हमें क्या मिला? बहुत प्रचंड आवेग:



दहशत अच्छा, हाँ। हालांकि, लूप के एक और पुनरावृत्ति को पूरा करने के लिए "लॉन्च" पर फिर से क्लिक करें। और अब बाहर निकलने पर हमें एक सुंदर चिकनी मेहंदी दिखाई देती है:



एक और पुनरावृति। और एक और ... स्थिर मेयर। हम विराम बिंदु को हटाते हैं और काम को गतिकी में देखते हैं - इस तरह के विराम नहीं होते हैं। दालों के अंतहीन फटने हैं।

हमने पहली पास पर आवेगों को क्यों फाड़ दिया? एक दुर्घटना? नहीं। हम डिबगिंग बंद कर देते हैं और इसे फिर से शुरू करते हैं। और फिर से हम फटे हुए आवेग प्राप्त करते हैं। कार्यक्रम के प्रवेश द्वार पर अंतराल हमेशा उत्पन्न होते हैं।

सुराग कैश में है

दरअसल, इस व्यवहार का हल कैश में है। हमारा कार्यक्रम SDRAM में संग्रहीत है। SDRAM से कोड प्राप्त करना तेज़ नहीं है। रीड कमांड देना आवश्यक है, एड्रेस देना आवश्यक है, और एड्रेस में दो भाग होते हैं। आपको थोड़ा इंतजार करना होगा। इसके बाद ही माइक्रोकिरसीट डेटा को बाहर कर देगा। हर बार इस तरह की देरी से बचने के लिए, microcircuit एक नहीं, बल्कि कई लगातार शब्द जारी कर सकता है। हम आज समय चार्ट पर विचार नहीं करेंगे, हम इसे निम्नलिखित लेखों के लिए स्थगित कर देंगे।

खैर, प्रोसेसर कोर ओर, डिफ़ॉल्ट रूप से एक कैश बनाया गया था। यहाँ इसकी सेटिंग्स हैं:



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

ऑसीलोग्राम प्रति लोडिंग ऑपरेशन के लिए प्रति पोर्ट औसतन 8 प्रविष्टियाँ दिखाता है (एक इकाई 4 बार और शून्य 4 बार लिखी गई है)। एक रिकॉर्ड - एक कोडांतरक कमांड, जो मेनू आइटम विंडो चुनकर पता लगाया जा सकता है-> दृश्य देखें-> अन्य:



और उसके बाद डिबग-



यहाँ हमारे तार और संबंधित विधानसभा कोड हैं:



4 बाइट्स की 8 टीमें प्रत्येक। हमें प्रति कैश लाइन में 32 बाइट्स मिलते हैं ... हम अपनी पसंदीदा मदद फ़ाइल C: \ Work \ CachePlay \ software \ CachePlay_bsp \ system.h पर देखते हैं और देखते हैं:

 #define ALT_CPU_ICACHE_LINE_SIZE 32 #define ALT_CPU_ICACHE_LINE_SIZE_LOG2 5 

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

थोड़ा और जटिल प्रयोग

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


हम एक सुंदर सुंदर परिणाम प्राप्त करते हैं, पहले से ही कार्यक्रम के स्थापित मोड में शूट किया जाता है।



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

 ... IOWR (PIO_0_BASE,0,0); IOWR (PIO_0_BASE,0,1); IOWR (PIO_0_BASE,0,0); IOWR (PIO_0_BASE,0,1); IOWR (PIO_0_BASE,0,0); } #define Nops4 __asm__ volatile ("nop");__asm__ volatile ("nop");__asm__ volatile ("nop");__asm__ volatile ("nop"); #define Nops16 Nops4 Nops4 Nops4 Nops4 #define Nops64 Nops16 Nops16 Nops16 Nops16 #define Nops256 Nops64 Nops64 Nops64 Nops64 #define Nops1024 Nops256 Nops256 Nops256 Nops256 volatile void FuncBetween() { Nops1024 } void MagicFunction2() { IOWR (PIO_0_BASE,0,0); IOWR (PIO_0_BASE,0,1); IOWR (PIO_0_BASE,0,0); IOWR (PIO_0_BASE,0,1); IOWR (PIO_0_BASE,0,0); ... 

कार्यक्रम का तर्क नहीं बदला है, लेकिन जब चलाते हैं तो हम फटे हुए दाल प्राप्त करते हैं



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

 volatile void FuncBetween() { Nops1024 Nops256 } 

और फिर से हमें सुंदरता मिलती है:



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

सिद्धांत की बिट

प्रोसेसर में पता फ़ील्ड कैसे विभाजित होता है:



जैसा कि आप देख सकते हैं, पता तीन भागों में विभाजित है। टैग, लाइन और ऑफसेट। ऑफ़सेट फ़ील्ड का आयाम Nios II प्रोसेसर के लिए स्थिर है और हमेशा पाँच बिट्स है, अर्थात यह 32 बाइट्स को संबोधित कर सकता है। "लाइन" फ़ील्ड का आयाम प्रोसेसर को कॉन्फ़िगर करते समय निर्दिष्ट कैश के आकार पर निर्भर करता है। उपरोक्त आंकड़े में, यह काफी बड़ा है। मुझे नहीं पता कि दस्तावेज़ में इतना बड़ा आयाम क्यों है। हमारे पास 4 किलोबाइट का कैश आकार है, जिसका अर्थ है कि कुल बिट गहराई और ऑफसेट 12 बिट हैं। 5 बिट्स एक ऑफसेट लेता है, एक लाइन के लिए 12-5 = 7 बिट्स रहता है।

हमें 128 पंक्तियों की एक निश्चित तालिका मिलती है, प्रत्येक 32 बाइट्स लंबी होती हैं। मैं कहूंगा, पहले 6 पंक्तियाँ:

और इसलिए हमने 0x123 004 पते की ओर रुख किया। यदि आप "महत्वपूर्ण" भाग को नहीं छोड़ते हैं, तो "लाइन + ऑफसेट" जोड़ी 0x004 है। यह जीरो रो रेंज है। इस लाइन में डेटा लोड किया जाएगा। और 0x123 000 से 0x123 01F सीमा तक डेटा के साथ आगे काम कैश के माध्यम से काम करेगा। किन परिस्थितियों में स्ट्रिंग को ओवरलोड किया जाएगा? 0x000 से 0x01F तक की सीमा में समाप्त होने वाले किसी भी अन्य पते तक पहुँचने पर। ठीक है, अर्थात्, यदि हम 0xABC 204 पते की ओर मुड़ते हैं, तो सब कुछ जगह पर रहेगा, क्योंकि निचले पते की सीमा हमारे साथ ओवरलैप नहीं होती है। और 0xABC 804 कुछ भी बर्बाद नहीं करेगा। लेकिन जब पता 0xABC 004 से कोड निष्पादित करते हैं , तो इसके परिणामस्वरूप नई सामग्री को कैश लाइन में लोड किया जाएगा। और पहले से ही 0x123 004 पते पर संक्रमण फिर से एक अधिभार को जन्म देगा। यदि आप लगातार 0xABC 004 और 0x123 004 के बीच कूदते हैं, तो अधिभार लगातार होगा।

आइए इसे चित्र के रूप में चित्रित करने का प्रयास करें। मान लीजिए कि हमारे पास कैश में केवल 8 लाइनें हैं, उन्हें अलग-अलग रंगों में रंगना अधिक सुविधाजनक है। मैं लाइन आकार 0x10 बनाऊंगा, यह चित्र में पतों को चित्रित करने के लिए अधिक सुविधाजनक है (याद रखें कि वास्तविक Nios II में लाइन आकार हमेशा 0x20 बाइट्स है)। मेमोरी सशर्त पृष्ठों पर धड़कता है जो कैश लाइनों के समान आकार के होते हैं। मेमोरी का लाल पृष्ठ हमेशा कैश की लाल रेखा, नारंगी से नारंगी तक जाएगा, और इसी तरह। तदनुसार, पुरानी सामग्री अनलोड की जाएगी।



खैर, वास्तव में, प्रयोग के दौरान कार्यक्रम का व्यवहार अब स्पष्ट है। जब कार्यों को 4 किलोबाइट द्वारा सख्ती से अलग किया गया था, तो उन्होंने समान रंगों के पृष्ठों को मारा। इसलिए कोड

  while (1) { MagicFunction1(); MagicFunction2(); } 

एक के लिए कैश लोड करने के लिए नेतृत्व किया, फिर दूसरे फ़ंक्शन के लिए। और जब रिक्ति 4 नहीं थी, लेकिन 5 किलोबाइट थे, तो फ़ंक्शंस को अलग-अलग रंगों के ब्लॉक में रखा गया था। कोई संघर्ष नहीं था, सब कुछ बिना देरी के काम किया।

निष्कर्ष

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

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

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

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

सबसे चौकस के लिए

संक्षारक पाठक पूछ सकता है: "कोड के चार किलोबाइट डालने पर ऑसिलोग्राम अपर्याप्त रूप से क्यों फट गया था?" सब कुछ सरल है। यदि आप ठीक 4 किलोबाइट डालते हैं, तो हमें स्मृति में फ़ंक्शन करने के लिए निम्नलिखित पते मिलते हैं:

  MagicFunction1(): 0200006c: movhi r2,1024 02000070: movi r4,1 02000074: addi r2,r2,4096 02000078: stwio r4,0(r2) 92 IOWR (PIO_0_BASE,0,0); 0200007c: mov r3,zero 02000080: stwio r3,0(r2) 93 IOWR (PIO_0_BASE,0,1); ... 120 IOWR (PIO_0_BASE,0,0); 020000f0: stwio r3,0(r2) 020000f4: ret 131 Nops1024 FuncBetween(): 020000f8: nop 020000fc: nop 02000100: nop 02000104: nop ... 020010ec: nop 020010f0: nop 020010f4: nop 020010f8: ret 135 IOWR (PIO_0_BASE,0,0); MagicFunction2(): 020010fc: movhi r2,1024 02001100: mov r4,zero 02001104: addi r2,r2,4096 

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

 volatile void FuncBetween() { Nops256 Nops256 Nops256 Nops64 Nops64 Nops64 Nops16 Nops16 } 

बार-बार मैं ध्यान देता हूं कि डालने से नियंत्रण प्राप्त नहीं होता है। यह बस एक दूसरे के सापेक्ष स्मृति में कार्यों की स्थिति को बदलता है। इस प्रविष्टि के साथ, हमें वांछित भयानक हॉरर मिलता है:



मुझे ऐसा लगा कि मुख्य पाठ में डाला गया ऐसा विवरण सभी को मुख्य से विचलित कर देगा, इसलिए मैंने उन्हें एक पोस्टस्क्रिप्ट में डाल दिया।