C / C ++ कंपाइलर कैसे बनाते हैं खराब कोड

यह लेख का अनुवाद है " कैसे भयानक कोड बनाने में सी / सी ++ संकलक को धोखा देने के लिए? ", मूल के लेखक एटर सुलेमान हैं।

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



इससे पहले कि मैं पूरी तरह से कंपाइलरों की चर्चा में गोता लगाऊं, मैं एक छोटा सा डिस्क्लेमर जोड़ना चाहता हूं: हालांकि मुझे लगता है कि मौजूदा कंपाइलर्स में सुधार की जरूरत है, मुझे भी लगता है कि कंपाइलर्स में हमेशा अड़चनें आएंगी जहां प्रोग्रामर को उनकी थोड़ी मदद करने की जरूरत होगी।

compilers

संकलक आपके कोड को उच्च-स्तरीय भाषा में लेता है और इसे मशीन कोड में परिवर्तित करता है। कंपाइलर की कार्य योजना कुछ इस प्रकार है:

1. कोड की पार्सिंग करें और इसके मध्यवर्ती प्रतिनिधित्व का निर्माण करें।
2. मध्यवर्ती प्रस्तुति का अनुकूलन करें।
3. मशीन कोड जनरेट करें।
4. लिंक (लेआउट)।

कोड को ऑप्टिमाइज़ करने के लिए कंपाइलर को एक बहुत बड़ा विश्लेषण करने की आवश्यकता होती है। एक साधारण उदाहरण मृत कोड (DCE) को हटा रहा है। DCE निष्पादित करते समय, कंपाइलर उस प्रोग्राम से कोड को बाहर कर देता है जिसका निष्पादन प्रोग्राम के परिणाम को प्रभावित नहीं करता है। उदाहरण के लिए, लाइनों 3 और 4 में लूप को संकलक द्वारा बाहर रखा जाएगा, क्योंकि लूप का परिणाम कहीं भी उपयोग नहीं किया जाता है।

1: void foo(){ 2: int x; 3: for(int i = 0; i < N; i++) 4: x += i; 5: } 

DCE प्रदर्शन करते समय, कंपाइलर डेटा स्ट्रीम का एक डिफ-यूज़ विश्लेषण यह निर्धारित करने के लिए करता है कि कौन से चर का उपयोग नहीं किया गया है। यह इन अप्रयुक्त चर को लिखने वाली पंक्तियों को हटा देता है। संकलक के लिए DCE और इसी तरह के अन्य अनुकूलन करने में सक्षम होने के लिए, यह 100% निश्चितता के साथ पता लगाने में सक्षम होना चाहिए कि क्या चर एक्सेस किया जाएगा। यह वह जगह है जहाँ संकलक को खोलने के लिए संभावनाओं को खोलना है। हम कई प्रसिद्ध अड़चनों का उपयोग कर सकते हैं।

फंक्शन कॉल

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

फ़ंक्शन कॉल की कई परतों को जोड़ना, आदर्श रूप से अलग-अलग फ़ाइलों में भी बिखरे हुए हैं, अक्सर कंपाइलर को भ्रमित करने का एक अच्छा तरीका है।

आइए इस उदाहरण को देखें:

 void foo(){ int x; for(int i = 0; i < N; i++) x += bar(i); } 

और दूसरी फाइल में:

 int bar(int i){ return i; } 

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

संकेत

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

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

 for(int i = 0; i < N; i++) *a++ = *b++ + *c++; 

सावधानीपूर्वक अध्ययन के बाद, एक व्यक्ति यह समझ सकता है कि कोड वास्तव में सिर्फ निम्नलिखित करता है:

 for(int i = 0; i < N; i++) a[i] = b[i] + c[i]; a += N; b += N; c += N; 

पहला कोड कंपाइलर को भ्रमित करता है। यहां तक ​​कि अगर लूप पुनरावृत्तियां स्वतंत्र हैं, तो संकलक उन्हें इस तरह नहीं मानते हैं; इस कारण से, यह किसी दिए गए कोड को वेक्टर नहीं कर सकता है। लेकिन दूसरा - शायद।

संदर्भ के लिए: वेक्टर कोड 5 गुना तेजी से चलता है। मल्टी-थ्रेडेड प्रसंस्करण का उपयोग करके प्रोग्रामर के थोड़े प्रयास से 4 कोर पर 4 गुना वृद्धि दे सकते हैं। एक ही कोड, स्वचालित रूप से वेक्टरकृत, बिना किसी प्रयास के 5 गुना की गति बढ़ाता है। मैंने Intel C Compiler (ICC) 9.1 और GCC 4.1 की कोशिश की। परिणाम आईसीसी के लिए हैं।

यदि अधिक विचार नहीं हैं, तो वैश्विक चर का उपयोग करें

वैश्विक चर कई कारणों से बुराई माने जाते हैं। मैं एक और लाऊंगा। क्योंकि उनके पास वैश्विक गुंजाइश है, वैश्विक चर का उपयोग करने वाले कोड को कंपाइलर द्वारा पूरी तरह से अनुकूलित नहीं किया जा सकता है। उदाहरण के लिए, मैंने देखा कि यदि चर N स्थानीय है, तो निम्न कोड 30% तेजी से चलता N , वैश्विक नहीं।

 for(int i = 0; i < N; i++) a[i] = b[i] + c[i]; 

जब आप वेरिएबल N ग्लोबल घोषित करते हैं, तो कंपाइलर इसे मेमोरी में छोड़ देता है और इसे लूप में लोड करने के निर्देश जोड़ता है। यदि N स्थानीय घोषित किया N , तो संकलक इसे रजिस्टर में लोड करता है। आप संकलक के इस व्यवहार को दोष दे सकते हैं (क्योंकि एन volatile नहीं है), लेकिन आपको जो है उसके साथ काम करना होगा।

निष्कर्ष

जब आप C / C ++ में कोड लिखते हैं, तो IPA और पॉइंटर्स को याद रखना महत्वपूर्ण है। तो आप कंपाइलर जनरेट कोड की मदद कर सकते हैं जो तेजी से चलेगा।

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