💂🏼 🤲 👩🏾‍🍳 सीपीयू के लिए अनुकूलन: एक अंधेरे कमरे में एक काली बिल्ली को कैसे खोजना है 💻 🤣 👨‍💻

अमान्य ऑपरेशन विधि:
बिल्ली को शून्य से विभाजित करें,
जिसके बाद यह असीम रूप से बड़ा हो जाएगा,
इसलिए यह याद रखना असंभव होगा।
[AbsurdopediYa]

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

इसलिए, हमारे पास सरणी (बिग-एंडियन <-> लिटिल-एंडियन) के प्रत्येक शब्द में क्रमिक रूप से बाइट्स का काम है और सभी शब्दों को एक (कमी) में समेटें। आइए हम समानांतरकरण के कार्य को छोड़ दें, क्योंकि इसका समाधान तुच्छ के करीब है, और अब तक यह हमारे लिए कोई दिलचस्पी नहीं है।

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

void init() { int i; for (i = 0; i < 1024; i++) buf[i] = i; } unsigned int change_endianess(char *big) { char temp; temp = big[0]; big[0] = big[3]; big[3] = temp; temp = big[1]; big[1] = big[2]; big[2] = temp; return *(unsigned int *)big; } void reduce() { int i, n; unsigned int sum = 0; init(); for (n = 0; n < ITER_NUM; n++){//repeat itarations for (i = 0; i < 1024; i++){ sum += change_endianess((char *)(buf+i));}} printf ("Sum is %d\n", sum); } main () { reduce(); }

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

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

परिणामों से यह स्पष्ट है कि कुछ भी स्पष्ट नहीं है। यह देखा जा सकता है कि कम फ़ंक्शन में कोड निष्पादन का प्रदर्शन परिपूर्ण से काफी दूर है, क्योंकि सीपीआई = 1.67 इष्टतम 0.25 से 6 गुना अधिक है। नहीं, इसका मतलब यह नहीं है कि हमारे पास कोड प्रदर्शन को 6 गुना बढ़ाने की क्षमता है, लेकिन इस तरह के एक सरल चक्र पर कम सीपीआई हासिल करना काफी संभव होगा। हालांकि, सीपीआई उच्च क्यों है यह कहना मुश्किल है। रिटायर स्टॉल मेट्रिक लगभग 0.7 है और हमें बताता है कि निर्देशों के निष्पादन के अंत में 70% चक्रों में पाइपलाइन डाउनटाइम्स हैं। शेष प्रदर्शन संकेतक, एकत्रित प्रोफ़ाइल के परिणामों को देखते हुए, सामान्य हैं। इसके अलावा, यह जानते हुए कि ज्यादातर मामलों में मेमोरी सबसिस्टम प्रदर्शन समस्याओं का कारण है, आप विशेष रूप से मेमोरी एक्सेस विश्लेषण लॉन्च कर सकते हैं। लेकिन वह वही दिखाएगा - स्मृति के साथ कोई समस्या नहीं है। हालाँकि, कोड इतना सरल है, और मेमोरी एक्सेस इतना सुसंगत है कि स्मृति विश्लेषण चलाने के लिए भी यह योग्य नहीं है। उन्हीं कारणों से, शाखा विश्लेषण हमारी मदद नहीं करेगा।

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

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

पहला निष्पादन स्टॉल्स उपाय UOPS_EXECUTED.CORE_STALL_CYCLES और UOPS_EXECUTED.CORE_ACTIVE_CYCLES के काउंटरों के मूल्यों के बीच संबंध है।
इवेंट काउंटर UOPS_EXECUTED.CORE_STALL_CYCLES रिज़र्वेशन स्टेशन किसी भी पोर्ट पर कार्य असाइन नहीं करने पर प्रोसेसर पाइपलाइन के कम्प्यूटेशनल भाग में निष्क्रिय चक्रों की संख्या को मापता है।

इवेंट काउंटर UOPS_EXECUTED.CORE_ACTIVE_CYCLES उचित रूप से उन चक्रों की गणना करता है, जब चार कम्प्यूट पोर्ट में से कम से कम एक और दो रीड / राइट पोर्ट के निष्पादन के लिए एक माइक्रो ऑपरेशन होता है।
UOPS_EXECUTED.CORE_STALL_CYCLES / (UOPS_EXECUTED.CORE_ACTIVE_CYCLES + UOPS_EXECUTED.CORE_STALL_CYCLES) का अनुपात हमें यह पता लगाने की अनुमति देगा कि सिम्युलेटर टाइम डाउनटाइम में कितने निष्पादन समय के अनुरूप है।

वैसे, इन काउंटरों का योग सभी घड़ी चक्रों CPU_CLK_UNHALTED.THREAD का काउंटर मूल्य देना चाहिए। और VTune में, अनुपात UOPS_EXECUTED.CORE_STALL_CYCLES / CPU_CLK_UNHALTED.THREAD का उपयोग निष्पादन स्टॉल मीट्रिक की स्वचालित रूप से गणना करने के लिए किया जाता है।
हमारे मामले में, अनुपात लगभग 0.24 (कुल में से निष्क्रिय समय का एक चौथाई) है, और इसका मतलब है कि यदि हम डाउनटाइम को समाप्त करते हैं, तो हम कंप्यूटर के थ्रूपुट को कम से कम एक चौथाई तक बढ़ा सकते हैं - और यह केवल चार स्लॉट्स में से एक के लिए है।

दूसरा रिटायर स्टॉल्स मीट्रिक UOPS_RETIRED.STALL_CYCLES / CPU_CLK_UNHALTED.THREAD के मूल्यों के बीच का संबंध है, यह दर्शाता है कि कुल कितनी घड़ी चक्रों की स्थिति उस स्थिति से मेल खाती है जहां कोई माइक्रो-ऑपरेशन सेवानिवृत्त नहीं है, हालांकि सैद्धांतिक रूप से, 4 ऑपरेशन तक पूरा किया जा सकता है।
इसका मतलब है कि 70% डाउनटाइम के साथ, अगर हम एक बिल्ली को अच्छी तरह से देखते हैं, तो संचालन के लिए इंतजार करने के कारण को समाप्त करते हुए, हम कम से कम 2.3 बार कार्यक्रम के निष्पादन में तेजी लाने की उम्मीद कर सकते हैं।
सामान्य ज्ञान का उपयोग करते हुए, हम निष्कर्ष निकालते हैं कि एल्गोरिथ्म के निष्पादन में तेजी लाने के लिए, आप कोशिश कर सकते हैं।

यह जानने के लिए कि हमें कहाँ समस्या है, हम दूसरी बिल्ली खोज विधि का उपयोग करते हैं - "डायकोटॉमी विधि": क्रमिक रूप से कमरे को समान भागों में विभाजित करते हैं, या प्रोसेसर कन्वेयर के चरणों को तार्किक भागों में विभाजित करते हैं, जहाँ आप समस्या का कारण खोजने का प्रयास कर सकते हैं। इस विधि का वर्णन Intel® 64 और IA-32 आर्किटेक्चर ऑप्टिमाइज़ेशन रेफरेंस मैनुअल में किया गया है , "प्रदर्शन मॉनिटरिंग इवेंट्स" का उपयोग "प्रदर्शन इवेंट ड्रिल-डाउन और सॉफ़्टवेयर ट्यूनिंग फीडबैक लूप" के रूप में। यहाँ इसका थोड़ा सरल दृश्य है:

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

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

Absurdopedia के अनुसार, Dichotomy Method को कमरे के विभाजन तक ले जाना चाहिए जब तक कि बिल्ली बिंदु पर केंद्रित न हो जाए। हालांकि, प्रोसेसर माइक्रोआर्किटेक्चर के लिए, विधि की संभावनाएं असीमित नहीं हैं और एक निश्चित स्तर पर समाप्त होती हैं। और यहां, सबसे अच्छा संभव तरीका, "स्पीयर विधि" का उपयोग किया जाता है - सबसे प्रभावी वैज्ञानिक तरीकों में से एक, उन मामलों में जहां अन्य, अधिक कठोर और नियमित तरीके, अब मदद नहीं करते हैं।
हमें उन सभी संभावित काउंटरों को मापने की आवश्यकता है जो संसाधनों की कमी को दर्शाते हैं। उनमें से कुछ हैं, और आपको केवल विशिष्ट संसाधनों के साथ किसी भी काउंटर एक्सटेंशन को बदलने की आवश्यकता है। Core i7 के मेरे मोबाइल संस्करण के लिए: RESOURCE_STALLS.LOAD, RESOURCE_STALLS.STORE, RESOURCE_STALLS.ROB_FULL, RESOURCE_STALLS.RS_FULL, RESOURCE_STALLS.OTHER इस डेटा को अलग से एकत्र किया जा सकता है, या सामान्य जानकारी के परिणामों में पाया जा सकता है। कुल संकेतक हमें संकेत देते हैं कि आरओबी-बफर भरने के कारण कन्वेयर अग्रिम को रोकने की समस्या है, और डेटा रिकॉर्डिंग बफर की कमी है।

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

यहां सोर्स व्यू हमें असहमति - असेंबली व्यू के साथ मदद करेगा। स्थान बचाने के लिए, हम उन्हें अलग से रखेंगे, हालांकि वे VTune में पास हैं।

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

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

तो इस निर्देश में क्या समस्या है, या यों कहें कि इसमें कई माइक्रो-ऑपरेशंस हैं, जिसमें यह (रीडिंग एड्रेस, मेमोरी से डेटा पढ़ना और रजिस्टर में समेट का संचालन) शामिल है? यहां, हमेशा की तरह, एक चाल है: आपको या तो डेटा अपलोड के कार्यान्वयन की बारीकियों को जानना होगा और माइक्रोआर्किटेक्चर में डाउनलोड करना होगा, या थोड़ा अलग माइक्रोप्रोसेसर का उपयोग करना होगा। हमारे मोबाइल कोर i7 (कोड नाम नेहेलम) के बजाय, हम एक प्लेटफॉर्म पर एक एक्सॉन प्रोसेसर या एक प्रोसेसर पर कोड नाम Westmere के साथ मापते हैं (इसलिए बोलने के लिए, एक कमरा और अधिक सुसज्जित करें), जिसमें आप अतिरिक्त रूप से काउंटर LOAD_BLOCK.OVERLAP_STORE प्राप्त कर सकते हैं। यह बस asm निर्देश जोड़ने पर जंगली हो जाएगा। सामान्य तौर पर, यह काउंटर संकेत देता है कि लोडिंग डेटा (लोड) के लिए माइक्रो-ऑपरेशन विभिन्न कारणों से अवरुद्ध हैं। इस अलार्म का सबसे आम कारण है कि लोड माइक्रोप्रेशन को पिछले स्टोर माइक्रोप्रेशन द्वारा अवरुद्ध किया जाता है:
- रीड डेटा के कुछ बाइट्स पिछले राइट ऑपरेशन में थे, और कुछ नहीं थे;
- रीडिंग शब्द के बाइट्स पिछले रिकॉर्ड के समान हैं, और रिकॉर्डिंग शब्द आकार में संरेखित है, जबकि रिकॉर्ड के 1-2 बाइट्स शब्द की शुरुआत में संरेखित नहीं होते हैं, या 4-8 बाइट्स होते हैं, और रिकॉर्ड डेटा के साथ संरेखित नहीं किया जाता है;
- रीडिंग शब्द के बाइट्स पिछले रिकॉर्ड के लिए समान हैं, लेकिन रिकॉर्डिंग शब्द आकार में संरेखित नहीं है और रिकॉर्डिंग शब्द की शुरुआत में रीडिंग संरेखित नहीं है।

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

यह ध्यान दिया जाना चाहिए कि, इस मोबाइल प्लेटफ़ॉर्म पर समस्या की जांच करते समय, मुझे संशोधित स्पीयर विधि का उपयोग करना था, क्योंकि एकत्रित काउंटर स्पष्ट रूप से नो स्टोर फ़ॉरवर्डिंग की उपस्थिति का संकेत नहीं देते थे। हमने यहां नेहेलम माइक्रोआर्किटेक्चर के सिकुड़ते संस्करण को खींचा - वेस्मेरे, या एक्सोन; और सामान्य अन्वेषण प्रोफ़ाइल में LOAD_BLOCK.OVERLAP_STORE ईवेंट काउंटर शामिल नहीं था। अगली पीढ़ी के प्रोसेसर - दूसरी पीढ़ी के Intel® Core ™ प्रोसेसर, कोड नाम SandyBridge (पहले से ही वर्तमान पीढ़ी) - में एक विशेष काउंटर LD_BLOCKS_STORE_FORWARD है , जो SandyBridge के लिए सामान्य अन्वेषण के VTune प्रोफ़ाइल में है, जो हमें सीधे समस्या के बारे में बताएगा।

अब यह सोचना बाकी है कि कोड को कैसे ठीक किया जाए और प्रदर्शन की समस्या को हल किया जाए। इसकी घटना के कारणों के विवरण से, यह स्पष्ट है कि ऐसा करने की आवश्यकता क्या है ताकि स्मृति से एक शब्द लोड करना सीधे उसी पते पर बाइट द्वारा लिखे जाने के बाद का पालन नहीं करता है। इसलिए, भविष्य में "इस बिल्ली" की खोज के कार्य से बचने के लिए, आपको कमरे और बिल्ली को अलग करने की आवश्यकता है: हम एक अलग चक्र में सरणी के शब्दों को समेटने का ऑपरेशन करते हैं।

 void reduce() { int i, n; unsigned int sum = 0; init(); for (n = 0; n < ITER_NUM; n++) { for (i = 0; i < 1024; i++) change_endianess((char *)(buf+i)); for (i = 0; i < 1024; i++) sum += buf [i]; } printf ("Sum is %d\n", sum); }

कार्यक्रम के निष्पादन समय में अंतर को प्रोफाइलिंग के परिणामों की तुलना करके देखा जा सकता है।

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

सीपीयू के लिए अनुकूलन: एक अंधेरे कमरे में एक काली बिल्ली को कैसे खोजना है

More articles: