काल्पनिक और वास्तविक अनुकूलन के बारे में 10 बार, चिकित्सा SSE, और वह सब

एक्स = साइन (ए, बी) * मिनट (एब्स (ए), एब्स (बी)) की गणना करते समय सशर्त संक्रमण के अनुकूलन के बारे में एक पोस्ट के आधार पर, माना जाता है कि 10 बार। संक्षिप्त सारांश:

• अनुकूलन स्पष्ट है, लेकिन आकार काल्पनिक है: 10 बार नहीं, बल्कि 2.5 गुना;
• बेंचमार्क सही ढंग से किया जाना चाहिए: अध्ययन के तहत फ़ंक्शन के बजाय सीपीयू स्टालों, रैम बैंडविड्थ, आदि को न मापें;
• बेंचमार्क सही ढंग से किया जाना चाहिए: अन्यथा वे बेतहाशा कांप सकते हैं;
• प्राथमिकता केवल शांत सेट करें, लेकिन व्यर्थ में छोटे बेंचमार्क पर: + 0.5% गति, -15% घबराना;
• आपको जांच किए गए फ़ंक्शन को मापने की आवश्यकता है और केवल इसे, सही डेटा प्राप्त करने का एकमात्र तरीका है;
• प्रतिशत को गर्म करना आवश्यक है, न्यूनतम एन / सेकंड पर विचार करना आवश्यक है, केवल इस तरह से आप कंपकंपी को दूर करते हैं;
• आपको SSE का उपयोग करने की आवश्यकता है, यह उसके साथ 8.6 गुना निकला, और कोड ... पढ़ा गया।

सामान्य तौर पर, फिर से बेंचमार्क में शास्त्रीय पद्धति संबंधी त्रुटियों का एक गुच्छा। कौन परवाह करता है कि ऐसी गलतियाँ, विवरण, विस्तृत डीब्रीफिंग, अनुकूलन को और अधिक बार कैसे न करें और सबसे महत्वपूर्ण बात, कटौती के तहत स्रोत कोड।

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

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

Moral # 1: लड़कों, परिणाम प्रिंट करें, हमेशा। आप तुरंत त्रुटियों को पकड़ लेंगे, और संकलक "अनावश्यक" लूप को बाहर नहीं फेंकेंगे। यह परिणाम को अस्थिर घोषित करने में भी मदद करता है, लेकिन आपको अभी भी इसे प्रिंट करने की आवश्यकता है।

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

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

इस मामले में, इस तरह के मिश्रण घटित नहीं होते हैं, call_rand () डिस्मास्मा में, इसे इनलाइन करने के प्रयासों के बिना, लेकिन जाहिर है कि कुछ और दुर्भाग्य है। कौन सा, मैं नहीं समझता, लेकिन सीपीयू स्टालों के बारे में काम कर रही परिकल्पना। परिकल्पना यह है कि llr () गणना की शुरुआत में थोड़ी देरी करके, जो कि परीक्षण esi, esi अनुदेश के साथ शुरू होता है, जहां esi सिर्फ रैंड () से वापस आ गया है, हम मूल बेंचमार्क को गति प्रदान कर सकते हैं। उसी समय, चक्र को 2 बार दोहराना आसान है, ज़ाहिर है, यह एक प्रभाव नहीं देता है, गणनाओं को फैलाना आवश्यक है:

10.7 सेकंड, रैंड ()
13.3 सेकंड, रैंड () + llr ()
12.6 सेकंड, रैंड () + llr () + 2x अनरोल

// 2x unroll  , 13.3 sec int a = rand() - RAND_MAX / 2; int b = rand() - RAND_MAX / 2; x += LLR(a,b); a = rand() - RAND_MAX / 2; b = rand() - RAND_MAX / 2; x += LLR(a,b); // 2x unroll c , 12.6 sec int a = rand() - RAND_MAX / 2; int b = rand() - RAND_MAX / 2; int a2 = rand() - RAND_MAX / 2; int b2 = rand() - RAND_MAX / 2; x += LLR(a,b); x += LLR(a2,b2); 

प्रयोगों में से एक में, 12.8 सेकंड तक त्वरण आम तौर पर बेवकूफ डालने asm {nop} द्वारा x + = LLR (ए, बी) से पहले दिया गया था, लेकिन इस तरह के चमत्कार को आत्मविश्वास से दोहराना संभव नहीं था। किसी प्रकार का बेतरतीब उतार-चढ़ाव। लेकिन सामान्य तौर पर, यह स्पष्ट रूप से स्पष्ट है कि भारी रैंड () और लाइट एलआरआर () से भराई को मापना एक व्यवसाय, हम्म, गैर-तुच्छ है। मेरा मानना ​​है कि कहीं न कहीं टेस्ट / जेएक्सएक्स इंस्ट्रक्शन पेयर में स्टॉल होते हैं क्योंकि एक्सप्रेशन को सिर्फ गिना जाता है। हो सकता है कि जिस व्यक्ति के हाथ में वीट्यून है, वह अधिक सटीक रूप से देख पाएगा, क्यों।

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

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

ठीक है, यह पहले से ही उम्मीदों के अनुरूप है, लेकिन अब पर्याप्त तेजी से और अच्छी तरह से नहीं;)

SSE बचाव के लिए आता है। मेरे डेस्कटॉप पर एक नया Core2Duo E8500 है, लेकिन यहां तक ​​कि यह SSE4 भी हो सकता है। हम 4 बार चक्र का विस्तार करते हैं, एक बार में 4 जोड़े गिनते हैं। सीधे माथे पर हम साइन, एब्स की गणना के लिए विनिर्देशों का उपयोग करते हैं।

1.073 सेकंड, llr () बेसलाइन
0.438 सेकंड, llr2 () अनुकूलित, 2.5x
0.125 सेकंड, llr4 () sse + 4x unroll, 8.6x

दिलचस्प है, कोड बहुत पठनीय है। केवल एक चीज यह है कि आपको _mm_sign_epi32 () पर सावधानीपूर्वक टिप्पणी करने की आवश्यकता है। सबसे पहले, वह अचानक 2 तर्क भी लेता है, और जैसे कि यह 1 तर्क के संकेत से गुणा करता है। आपको क्या चाहिए दूसरा, जबकि _mm_sign (0) = 0, 1 नहीं, जैसा कि आप कुछ कार्यों के लिए चाहेंगे। हालांकि, हमारे उद्देश्यों के लिए कोई अंतर नहीं है, हो सकता है। यदि abs (a) या abs (b) 0 है, तो * min (abs) = 0 पर हस्ताक्षर करें, इसलिए कोई त्रुटि नहीं है।

 static inline __m128i LLR4(const int * pa, const int * pb) { __m128i a = *(__m128i*)pa; __m128i b = *(__m128i*)pb; // sign(a,b)*min(abs(a),abs(b)) __m128i absa = _mm_abs_epi32(a); __m128i absb = _mm_abs_epi32(b); __m128i absm = _mm_min_epi32(absa, absb); __m128i ab = _mm_mullo_epi32(a, b); __m128i rr = _mm_sign_epi32(absm, ab); return rr; } 

सीमांत नोट: दिलचस्प रूप से, रजिस्टर घटकों को _mm_hadd_epi32 के माध्यम से रजिस्टर करें ताकि रजिस्टर को मेमोरी में अनलोड किया जा सके और फिर 4 सामान्य इनट्स को जोड़ने से परिणाम उत्पन्न न हो। काश मैंने पहले ही कम से कम कहीं पर, लंबे समय से मैं चाहता हूं कि एचड का प्रभाव देखा था।

एक और नोट: दिलचस्प है, चक्र का आगे विकास भी परिणाम नहीं देता है। जाहिर है, यह पहले से ही मेमोरी पढ़ने की गति पर निर्भर करता है, लगभग 6.4 जीबी / सेकेंड आता है।

त्रुटि # 3 , इसका मतलब है, यह है कि SSE एक्सटेंशन का उपयोग लंबे समय से नहीं किया गया है, किसी कारण के सभी बहादुर अनुकूलन अनिवार्य रूप से i386 के लिए प्लेटफॉर्म के लिए किए जाते हैं।

यह एक विवादास्पद निष्कर्ष है, मैंने लंबे समय से सोचा था कि इसे लिखना है या कैसे। यह "गलती" है या नहीं? मैं व्यक्तिगत रूप से ऐसा सोचता हूं। क्योंकि अगर आप अनुकूलन करते हैं, तो बहुत बड़ा! Kamenti में विद्वान निश्चित रूप से जीत जाएगा, जो नहीं है। आखिरकार, यह संस्करण वेक्टरकृत है और एक समय में 4 जोड़े संख्याओं पर काम करता है, और यह मूल फ़ंक्शन में एक निश्चित रूप से असंगत परिवर्तन है। I386 के लिए प्लस अनुकूलन भी बहुत मूल्यवान हैं, अचानक कार्यक्रम i7 पर नहीं, बल्कि आईटी पुरातत्व के स्मारक पर लॉन्च किया जाएगा। हालांकि, किसी भी मामले में, नैतिकता निश्चित रूप से समान है।

Moral # 3: लड़कों, अब 2013, SSE4 लगभग हर जगह है, SSE2 हर जगह है, तदनुसार कार्य करें, 99% उपयोगकर्ताओं के लिए अनुकूलन (यदि संभव हो), और 1% कमबैक नहीं।

परिणामी SSE संस्करण अब यह देखने के लिए काफी सशक्त है कि विभिन्न लॉन्चों पर समय 0.125 से 0.145 सेकंड तक कैसे नृत्य करता है। लगभग 20% अंतर। ओह ...

त्रुटि # 4 सिर्फ अनुकूलन के कारण प्रकट हुई;) थ्रेड की उच्च प्राथमिकता को सेट करना और प्रक्रिया लगभग 0.5% उत्पादकता देती है, लेकिन किसी भी तरह से घबराना से माप को बचाता है। सबसे पहले, एक निष्क्रिय प्रोसेसर आवृत्ति को रीसेट करता है, लेकिन तुरंत इसे वापस हासिल नहीं करता है। वह 0.1 सेकंड में नहीं, 10+ सेकंड में सफल होता है। दूसरा, भले ही आप 100 बार लघु परीक्षण करें, लेकिन प्रत्येक अलग पुनरावृत्ति का समय अभी भी नृत्य करेगा। शुरुआत में और इन 100 रनों के अंत में दोनों। आप कभी नहीं जानते हैं कि 99% निष्क्रिय के साथ एक कथित निष्क्रिय प्रणाली में यह अभी भी अपने लिए काम करता है और इसे कैसे प्रभावित करता है।

प्रोसेसर को "वार्म अप" किया जाना चाहिए और उसके बाद भी (काफी कम) रन के परिणामों को फ़िल्टर किया जाना चाहिए। बस थोड़ा अधिक पुनरावृत्तियों और औसत करना पर्याप्त नहीं है, कुल समय अभी भी कांप रहा है। पहला "ठंडा" पुनरावृत्तियों को बाहर फेंकना पर्याप्त नहीं है, परिणाम कांप रहा है। आप औसत और विचरण पर विचार कर सकते हैं, आउटलेर को फेंक सकते हैं, जहां एब्स (मूल्य-मीन)> = k * stddev, फिर औसत को पुनर्गणना करते हैं, मैंने कोशिश की, लेकिन यह कांप रहा है!

और कम से कम, ऐसी सरल विधि कांपती है: हम कई रन बनाते हैं (मैं 10 रन करता हूं) और उनमें से एक रन के लिए न्यूनतम समय का चयन करता हूं। यह पता चला है कि इस तरह के एक न्यूनतम स्थान पर निहित है, कई प्रक्षेपणों में अंतर अधिकतम 0.5% है।

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

Moral # 4: लड़कों, प्रतिशत को कम से कम 3 सेकंड और अधिमानतः 10 सेकंड के लिए गर्म करते हैं, और इसके अलावा कम से कम N रन गिनते हैं।

बेंचमार्क के साथ, आप अभी भी बहुत सारी गलतियाँ कर सकते हैं, और शायद अंतिम कोड में (वैसे, यहाँ यह है: gist.github.com/anonymous/5605201 ) कुछ और याद आ रही है, लेकिन आज हमने इन्हें हल कर दिया है। उम्मीद है कि पूरी तरह से बेकार नहीं है।

सतर्क रहें, सही तरीके से मापें, दया के बिना और अंत तक अनुकूलन करें;)