Gcc vs Intel C ++ कंपाइलर: लिनक्स के लिए फाइनरडर इंजन का निर्माण

इस लेख को लिखने के लिए एक पूर्वापेक्षा फाइनराइडर इंजन के प्रदर्शन में सुधार करने की पूरी तरह से स्वाभाविक इच्छा थी।



यह माना जाता है कि इंटेल से संकलक जीसीसी की तुलना में बहुत तेज कोड का उत्पादन करता है। और एफआर इंजन को किसी अन्य संकलक के साथ संकलित करके कुछ भी किए बिना मान्यता की गति को बढ़ाना अच्छा होगा।



फिलहाल, फाइनराइडर इंजन को नवीनतम संकलक द्वारा निर्मित नहीं किया जा रहा है - gcc 4.2.4। यह कुछ और आधुनिक करने के लिए आगे बढ़ने का समय है। हमने दो विकल्पों पर विचार किया - यह gcc का नया संस्करण है - 4.4.4, और Intel से Intel - Intel C ++ कंपाइलर (icc)।



एक नए कंपाइलर के लिए एक बड़ी परियोजना को पोर्ट करना सबसे आसान काम नहीं हो सकता है, इसलिए शुरुआत के लिए हमने बेंचमार्क पर कंपाइलरों का परीक्षण करने का फैसला किया।



यहां इंटेल Core2 डुओ प्रोसेसर पर संक्षिप्त परिणाम दिए गए हैं:



_{इंटेल पॉव्रे टेस्ट टाइम (सेकंड)}



एएमडी में, यह देखना भी दिलचस्प था:



_{AMD Povray परीक्षण समय (सेकंड)}



संक्षेप में झंडे के बारे में:

-O1, -O2 और -O3 अनुकूलन के विभिन्न स्तर हैं।

Gcc के लिए, –O3 को सबसे अच्छा विकल्प माना जाता है, और इसका उपयोग लगभग हर जगह किया जाता है जब FineReader इंजन का निर्माण किया जाता है।

Icc के लिए, -O2 को इष्टतम विकल्प माना जाता है, और -O3 में कुछ अतिरिक्त लूप ऑप्टिमाइज़ेशन शामिल हैं, जो, हालांकि, काम नहीं कर सकते हैं।

-mtune = core2 -march = core2 -msse3 - एक विशिष्ट प्रोसेसर के लिए अनुकूलन, इस मामले में, Core2 -o के लिए।

-xT इंटेल से कंपाइलर के लिए एक समान ध्वज है।

-प्रोफाइल-उपयोग-पीजीओ



एक विशिष्ट प्रोसेसर के लिए अनुकूलन के साथ टेस्ट सिर्फ मनोरंजन के लिए दिए गए हैं। एक प्रोसेसर के लिए अनुकूलन के साथ बनाया गया एक बाइनरी दूसरे पर शुरू नहीं हो सकता है। FineReader इंजन एक विशिष्ट प्रोसेसर से बँधा नहीं होना चाहिए, इसलिए, ऐसे अनुकूलन का उपयोग नहीं किया जा सकता है।



तो, जाहिर है, एक प्रदर्शन लाभ संभव है: एक इंटेल प्रोसेसर पर icc काफी तेजी से बढ़ता है। एएमडी पर, यह अधिक विनम्रता से व्यवहार करता है, लेकिन फिर भी जीसीसी की तुलना में अच्छी वृद्धि देता है।

यह हम सभी के लिए आगे बढ़ने के लिए समय है - फाइनरडर इंजन बनाने के लिए। हमने अलग-अलग कंपाइलरों के साथ फाइनराइडर इंजन संकलित किया, छवि पैकेज पर मान्यता शुरू की। यहाँ परिणाम हैं:



_{विभिन्न कंपाइलरों द्वारा संकलित FREngine का समय चल रहा है (प्रति पृष्ठ सेकंड)}



अप्रत्याशित परिणाम। बेंचमार्क पर माप के साथ gcc-4.4.4 / gcc-4.2.4 का अनुपात काफी सुसंगत है, और अपेक्षाओं से थोड़ा अधिक है। लेकिन icc का क्या? वह न केवल नए gcc को खो देता है, बल्कि दो साल पहले gcc को भी खो देता है!



हम सत्य के लिए चले गए, और यहाँ हम क्या पता लगाने में कामयाब रहे: कुछ (बल्कि दुर्लभ) मामलों में, icc में लूप के अनुकूलन के साथ समस्याएँ हैं। यहाँ वह कोड है जो मैंने प्रोफाइलिंग के परिणामों के आधार पर लिखने में कामयाब रहा है:

static const int aim = ..;

static const int range = ..;



int process( int * line, int size )

{

int result = 0;

for ( int i = 0; i < size; i++ ) {

if ( line[i] == aim ) {

result += 2;

} else {

if ( line[i] < aim - range || line[i] > aim + range ) {

result--;

} else {

result++;

}

}

}

return result;

}



* This source code was highlighted with Source Code Highlighter .

विभिन्न इनपुट डेटा पर फ़ंक्शन चलाना, हमें कुछ इस तरह मिला:



_{साइकिल चलाने का समय (ms)}



अन्य अनुकूलन झंडे जोड़ने से मूर्त परिणाम नहीं मिले, इसलिए मैंने केवल मुख्य दिए।

दुर्भाग्य से, इंटेल स्पष्ट रूप से संकेत नहीं देता है कि वे शामिल हैं -O1, -O2 और -O3, इसलिए यह पता लगाना संभव नहीं था कि किस अनुकूलन ने कोड को धीमा कर दिया। वास्तव में, ज्यादातर मामलों में, icc बेहतर रूप से छोरों का अनुकूलन करता है, लेकिन कुछ विशेष मामलों (जैसे ऊपर वाला) में, कठिनाइयां पैदा होती हैं।



प्रोफाइलिंग की मदद से, एक और, अधिक गंभीर समस्या का पता लगाना संभव था। आईसीसी द्वारा संकलित लाईनएडर इंजन के संस्करण के लिए प्रोफाइलर रिपोर्ट में, काफी उच्च स्थिति एक समान रेखा थी:



Namespace::A::GetValue() const ( )







जबकि जीसीसी से संस्करण में ऐसा कोई फ़ंक्शन नहीं था।

A :: GetValue () कई क्षेत्रों से युक्त एक सरल संरचना देता है। सबसे अधिक बार, इस पद्धति को प्रपत्र के निर्माण में वैश्विक स्थिर ऑब्जेक्ट के लिए कहा जाता है



GlobalConstObject.GetValue().GetField()







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



gcc ऐसा करता है (कम से कम यह अनावश्यक निर्माण से बचा जाता है), हालांकि -O2 या -O3 अनुकूलन के साथ icc सब कुछ छोड़ देता है जैसा कि यह है। और इस तरह के कॉल की संख्या को देखते हुए, यह जगह महत्वपूर्ण हो जाती है, हालांकि यहां कोई उपयोगी काम नहीं किया जा रहा है।



अब उपचार के तरीकों के बारे में:



1) स्वचालित। Icc में एक अद्भुत -ipo ध्वज है, जो संकलक को इंटरप्रोसेक्शुअल ऑप्टिमाइज़ेशन करने के लिए कहता है, वह भी फाइलों के बीच। इसके बारे में इंटेल का ऑप्टिमाइज़ेशन मैनुअल क्या कहता है:

IPO संकलक को आपके कोड का विश्लेषण करने की अनुमति देता है जिससे आप विभिन्न प्रकार के अनुकूलन से लाभ उठा सकते हैं:

• कॉल, जंप, शाखाओं और लूप के इनलाइन फ़ंक्शन विस्तार।

• तर्कों, वैश्विक चरों और वापसी मूल्यों के लिए इंटरप्रोसेरुरल निरंतर प्रसार।

• अधिक अनुकूलन और पाश अपरिवर्तनीय कोड की पहचान करने के लिए मॉड्यूल-स्तरीय स्थिर चर की निगरानी करना।

• कोड आकार को कम करने के लिए मृत कोड उन्मूलन।

• कॉल विलोपन और कॉल आंदोलन की पहचान करने के लिए फ़ंक्शन विशेषताओं का प्रसार

लूप-इनवेरिएंट कोड की पहचान आगे के लिए अनुकूलन के लिए लूप-इन्वारिएंट कोड।

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



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







अंतिम पंक्ति icc द्वारा संकलित संस्करण है, जहां सबसे महत्वपूर्ण स्थानों में कॉल श्रृंखला को एक निरंतर द्वारा प्रतिस्थापित किया गया है। जैसा कि आप देख सकते हैं, इसने icc को gcc-4.2.4 की तुलना में अधिक तेज़ी से चलाने की अनुमति दी है, लेकिन अभी भी gcc-4.4.4 की तुलना में धीमी है।

आप ऐसे सभी महत्वपूर्ण स्थानों को पकड़ने और कोड को मैन्युअल रूप से सही करने का प्रयास कर सकते हैं। दोष स्पष्ट है - इसमें बहुत समय और प्रयास लगेगा।



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



इसलिए, हम संक्षेप में बताते हैं। इंटेल C ++ कंपाइलर संभावित रूप से अच्छा है। लेकिन ऊपर वर्णित सुविधाओं और कोड की एक बड़ी मात्रा के कारण, हमने फैसला किया कि यह एक महत्वपूर्ण गति लाभ नहीं देता है - पोर्टिंग में शामिल श्रम को औचित्य देने और इस संकलक के लिए कोड को "तेज" करने के लिए पर्याप्त महत्वपूर्ण है।