C ++ एलियासिंग, चालाक अनुकूलन और डरपोक बग के बारे में

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

अलियासिंग के बारे में

अलियासिंग क्या है? बहुत सरल है। यह तब होता है जब एक ही मेमोरी लोकेशन पर कई अलग-अलग पॉइंटर्स दिखाए जाते हैं। उदाहरण के लिए।

int A; int * B = &A; int * C = &A; 

इस उदाहरण में, चर ए में अचानक तीन अलग-अलग नाम (उपनाम) हैं: ए, * बी, * सी। यह पूरी तरह से कानूनी कोड है। कंपाइलर सभी 3 नामों को सफलतापूर्वक प्रोसेस करेगा, अगर A को कुछ लिखा जाता है, तो * B और इसके विपरीत से पढ़ना संभव होगा, सब कुछ ठीक है।

अनुकूलन और __restrict के बारे में

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

 void SumIt ( int * out, const int * in, int count ) { for ( int i=0; i<count; i++ ) (*out) += *in++; } 

बाहर के पैरामीटर के साथ एक सामान्य कार्य, कुछ भी परेशानी नहीं दिखाता है। लेकिन वह है किसी ने भी संकलक को यह गारंटी नहीं दी कि * आउट एड्रेस * पर आउट-वेरिएबल निर्णायक रूप से * इन-एड्रेस पर इन-डेटा के साथ इंटरसेक्ट नहीं करता है। उन्हें खुद इस तरह की धारणा बनाने का कोई अधिकार नहीं है: आप कभी नहीं जानते कि कोई व्यक्ति कैसे और क्यों लिखना चाहता है? इसलिए, आंतरिक लूप के प्रत्येक पुनरावृत्ति पर, * मेमोरी को वापस लिखा जाता है, यहां तक ​​कि अनुकूलन के अधिकतम स्तर पर भी। डिसमिस (gcc -O3 -S, 4.4.3, ubuntu x64) ऐसा दिखता है।

 .L7: addq $4, %rax addl (%rsi), %ecx cmpq %rdx, %rax movq %rax, %rsi movl %ecx, (%rdi) ; <--  ! jne .L7 

हालांकि, आप संकलक को बता सकते हैं कि बाहर के साथ अंतर नहीं है। इसके लिए, मानवता __restrict संशोधक के साथ आया था।

 void SumIt ( int * __restrict out, const int * __restrict in, int count ) { for ( int i=0; i<count; i++ ) (*out) += *in++; } 

 .L14: addq $4, %rax addl (%rsi), %ecx cmpq %rdx, %rax movq %rax, %rsi jne .L14 movl %ecx, (%rdi) 

खैर, सोचिए, 1 निर्देश? प्रोसेसर अब स्मार्ट हैं, एक मोटी कैश और पाइपलाइनों का एक गुच्छा है। इस मिनी-उदाहरण में, रिकॉर्ड, निश्चित रूप से, तुरंत कैश किया गया है, अतिरिक्त निर्देश को कुछ के साथ समानता माना जाता है, और अंतर भी नहीं मापा जा सकता है?

 1783293664 in 103818 usec 1783293664 in 69818 usec 

वास्तव में नहीं। संभव। ओह, त्वरण लगभग 1.5 गुना है। यहां कभी-कभी एक निर्देश (और दो संशोधक) की कीमत होती है। आमतौर पर यह सभी समान है, लेकिन अच्छी तरह से भरी हुई आंतरिक छोरों के लिए यह उपयोगी है।

सख्त अलियासिंग और बग्स के बारे में

जैसा कि आप देख सकते हैं, एलियासिंग को समाप्त करने से एक अच्छी गति में सुधार हो सकता है। जाहिर है, इन विचारों से, C99 मानक, और इस C ++ के माध्यम से, एक सख्त अलियासिंग नियम पेश किया। मानक पढ़ने और समझने के कौशल वाले लोगों के लिए संदर्भ: एन 1 124, 6.5 (7)। एक सामान्य व्यक्ति वास्तव में वहां देखना नहीं चाहता: उदाहरण के लिए, इस पैराग्राफ में कोई सख्त शब्द या उपनाम नहीं है। ;) (यह किसी भी तरह से जल्दी से केवल इसे खोजने के लिए संभव था क्योंकि फुटनोट नंबर 74 में अलियासिड शब्द शामिल है।) हालांकि, विशेष रूप से महत्वपूर्ण अर्थ "उंगलियों पर" को काफी सरल रूप से समझाया जा सकता है।

सख्त अलियासिंग मोड में, कंपाइलर का मानना ​​है कि "पर्याप्त रूप से भिन्न" प्रकार के पॉइंटर्स द्वारा इंगित की गई वस्तुओं को एक ही मेमोरी स्थान में संग्रहीत नहीं किया जा सकता है, और अनुकूलन के लिए इसका उपयोग कर सकते हैं।

जो बिल्कुल महत्वपूर्ण नहीं है जब बिंदु या तो वास्तव में अलग-अलग स्थानों पर दिखते हैं, या एक दूसरे से बहुत दूर उपयोग किए जाते हैं। लेकिन घातक रूप से, जब पॉइंटर्स एक ही मेमोरी की ओर इशारा करते हैं, तो उनका उपयोग साइड-साइड किया जाता है, और कंपाइलर gcc होता है।

 #include <stdio.h> typedef unsigned int DWORD; typedef unsigned short WORD; inline DWORD SwapWords ( DWORD val ) { WORD * p = (WORD*) &val; WORD t; t = p[0]; p[0] = p[1]; p[1] = t; return val; } int main() { printf ( "%d\n", SwapWords(1) ); return 0; } 

यह साधारण प्रोग्राम या तो 65536 प्रिंट करता है जब g ++ test.cpp, या 1 का निर्माण करते समय g ++ -O3 test.cpp का निर्माण करते हैं। ये क्या!?

तथ्य यह है कि -O2 से शुरू होकर, -fstrict-aliasing स्वचालित रूप से चालू होता है। और कंपाइलर सोचता है कि * पी मूल रूप से नहीं दिखा सकता है कि वैल कहाँ संग्रहीत है। और सफलतापूर्वक, यह व्यवसाय मृत्यु का अनुकूलन करता है: यदि यह नहीं हो सकता है, तो तर्क का मूल्य हमारे पास वापस आ जाएगा; इसलिए स्वेपस्क्रिप्ट (1) को केवल स्थिर 1 द्वारा प्रतिस्थापित किया जा सकता है।

इसके अलावा, इस उदाहरण में, समस्या, वास्तव में, बहुत अधिक नहीं है। यदि आप सक्षम करते हैं -Wall (या कम-से-कम निर्णय-अलियासिंग), तो संकलक ईमानदारी से समझ से बाहर की चीजों की शिकायत करेगा।

 test.cpp:8: warning: dereferencing pointer 'p.14' does break strict-aliasing rules 

जिसे ठीक करना मुश्किल नहीं है। किंडरगार्टन विधि शापित सख्त अलियासिंग को पूरी तरह से -fno- सख्त-अलियासिंग कुंजी के साथ अक्षम करना है। वैधानिक सुधारात्मक विधि, जो वास्तव में हर जगह और हर जगह काम करती है, संघ के माध्यम से मूल्य को फैलाना है। ऐसा लगता है कि किसी भी कंपाइलर ने दया के साथ यूनियन फील्ड को एक-दूसरे के साथ रहने दिया। संकेत के साथ कोई भी चाल सैद्धांतिक रूप से बग़ल में (अपरिभाषित व्यवहार) परिणाम दे सकती है, gcc के मामले में सिद्धांत व्यवहार में बदलना मुश्किल नहीं है और इसके विपरीत (-fstrict-aliasing)।

 inline DWORD SwapWords ( DWORD val ) { union { DWORD d; WORD v[2]; } u; ud = val; WORD t = uv[0]; uv[0] = uv[1]; uv[1] = t; return ud; } 

राह-राह? लेकिन अफसोस, एक छोटा है, लेकिन: -विस्तार-अलियासिंग कुछ भी गारंटी नहीं देता है । यह उन सभी मामलों को पकड़ने के लिए पर्याप्त नहीं है, जो वर्तमान संकलन मोड के साथ संगत नहीं हैं। मेरे पास पर्याप्त रूप से छोटा और इसलिए उदाहरणात्मक उदाहरण नहीं है (यह बहुत लंबा है), इसलिए मुझे एक शब्द लेना है: काफी भरा हुआ मांस, एक फफूंद या दो, और सख्त अलियासिंग चतुराई से प्रच्छन्न है और vorning नहीं देता है। एसटीएल और / या बूस्ट के सक्रिय उपयोग के साथ एक कार्यक्रम में, मुझे संदेह है कि कोड के विल्स में कहीं न कहीं सख्त अलियासिंग का उल्लंघन करना बहुत आसान होना चाहिए। थर्ड पार्टीज़ भी इस बात की गवाही देती हैं कि * * शून्य करने के लिए ट्रिक के साथ और इसके विपरीत सफलतापूर्वक कम से कम gcc 4.1.x पर चेतावनी को दबा दिया, जबकि कुटिल कोड की पीढ़ी को छोड़ दें, बिल्कुल।

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

 inline uint64_t GetIt ( const DWORD * p ) { return *(uint64_t*)p; } int main() { DWORD buf[10]; uint64_t t; buf[0] = 1; buf[1] = 2; t = GetIt(buf); buf[2] = 3; buf[3] = 4; printf ( "%d, %d, %d, %d\n", buf[0], buf[1], int(t>>32), int(t) ); return 0; } 

यह फिर से एक अप्रत्याशित संख्या में प्रिंट करता है: 1, 2, 32573, -648193368। पिछले उदाहरण के विपरीत, जहां कंपाइलर ने फ़ंक्शन की पूर्ण अनुपस्थिति के लिए स्वेपस्क्रिप्ट () फ़ंक्शन को सरल बनाया, यह ठीक वही है जहां पढ़ने और लिखने को फिर से व्यवस्थित किया जाता है। संकलक निष्कर्ष निकालता है कि GetIt (buf) buf की सामग्री पर निर्भर नहीं करता है, और इसलिए GetIt () के लिए एक "कॉल" को पॉप करता है जहां यह फिट दिखता है। यह बफर भरने से पहले आवश्यक हो जाता है।

 mov (%rsp),%r8 ; t = GetIt(buf) ... movl $0x1,(%rsp) ; buf[0] = 1 movl $0x2,0x4(%rsp) ; buf[1] = 2 movl $0x3,0x8(%rsp) ; buf[2] = 3 movl $0x4,0xc(%rsp) ; buf[3] = 4 mov %r8d,%r9d ; r9 = int(t) shr $0x20,%r8 ; r8 = int(t>>32) callq 0x400510 <__printf_chk@plt> 

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

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

साइड-नोट: सख्त अलियासिंग के कारण सभी प्रकार की अन्य बारीकियों और चाल के बारे में, आप कॉमरेड पर क्लासिक विस्तृत पोस्ट पढ़ सकते हैं। माइक एक्टन, सेलपरफॉर्मेंस .beyond3d.com / articles / 2006 / 06 / understanding-strict-aliasing.html

MSVC के बारे में क्या?

सख्त अलियासिंग के बारे में कोई समस्या नहीं है। इसके अलावा, इसे चालू करने की कोई संभावना नहीं है। जाहिर तौर पर, एमएस ने फैसला किया कि दुनिया में एलियासिंग के बारे में पतली रेक के बिना दुनिया में C99- अनुरूप कोड सामान्य से बहुत कम है, इसलिए जटिलता पैदा करने की कोई जरूरत नहीं है। एक शैक्षिक मिशन जीसीसी द्वारा किया जाता है, ठीक है, कभी-कभी चुपचाप भी, लेकिन एक दूसरा, इसके बिना नहीं।

इसका स्वचालित रूप से मतलब है कि अनुकूलन के बारे में चाल और संकेत के लिए __restrict कुछ और महत्वपूर्ण हैं। कहो, शून्य के लिए SumIt (int64_t * out, const int * in, int count), सख्त नियम के अनुसार, gcc को "अनुमान" करने का अधिकार है कि यह संभावना नहीं है कि बाहर बीच में निहित है; MSVC को इस बारे में अनुमान लगाने की गारंटी नहीं दी जाएगी। आपको या तो इसे मैन्युअल रूप से प्रतिबंधित करना होगा, या प्रविष्टियों को मैन्युअल रूप से कम करना होगा। वह रजिस्टर में एक स्थानीय चर डाल सकता है।

यह समझना महत्वपूर्ण है कि कक्षा का एक सदस्य भी इस सूचक पर स्थित डेटा है। इसलिए, एक पाश में एक वर्ग के सदस्य के लिए एक निरंतर संदर्भ स्मृति के निरंतर पीड़ा में संकलित किया जा सकता है।

कुल मिलाकर

1. आप एक आंतरिक लूप लिखते हैं, उपनाम के बारे में और __restrict के बारे में याद रखें।
2. सूचक को परिवर्तित करें, सख्त अलियासिंग और पुन: व्यवस्थित करने वाले दुष्प्रभावों की परमाणु क्षमता के बारे में याद रखें।
3. जीसीसी का उपयोग करें, डिफ़ॉल्ट-एस्ट्रिंजेंट-अलियासिंग को याद रखें, अनदेखा न करें -पूरा करें।
4. MSVC का उपयोग करें, सख्त-अलियासिंग-शैली अनुकूलन की मजबूर अनुपस्थिति को याद रखें, हाथ से अनुकूलित करें।
5. आपको सख्त एलियासिंग के बारे में एक चेतावनी दिखाई देती है, इसे सुलझाएं, शायद एक यूबी थ्रेड।
6. क्या सख्त अलियासिंग के बारे में चेतावनी नहीं दी जाती है? लेकिन वह है। गोफर की तरह।
6.1। कंपाइलर झूठ, vorings अविश्वसनीय हैं, -कभी-कभी काम करता है (चालू होना चाहिए!), लेकिन गारंटी नहीं देता है।
6.2। आप खुद पर बिल्कुल भी भरोसा नहीं कर सकते, केवल बेंचमार्क, डिस्मास, प्रार्थना और उपवास।