Interprocedural विश्लेषण और अनुकूलन (I)

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

प्रदर्शन पर प्रतिरूपकता का प्रभाव

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

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

1. स्मृति के साथ काम करते समय अस्पष्टता संकल्प के साथ समस्याएं। उदाहरण के लिए, अपनी पिछली पोस्टों में मैंने लूप की मान्यता की समस्या और स्मृति (उर्फ विश्लेषण) के साथ काम करते समय अस्पष्टता को हल करने की समस्या के साथ चर्चा की। यानी यदि कार्यक्रम में सूचक तर्क हैं और / या वैश्विक चर का उपयोग किया जाता है, तो संभावना है कि कई अलग-अलग वस्तुओं के माध्यम से एक ही मेमोरी के साथ काम किया जा रहा है। इस तरह की अस्पष्टता कंपाइलर को लूप्स को पहचानने से रोकती है, माना जाता है कि लूप ऑप्टिमाइज़ेशन में हस्तक्षेप करने वाली निर्भरता बनाता है, और डेटा प्रवाह, आदि का विश्लेषण करना मुश्किल बनाता है। कंपाइलर अक्सर बहु-संस्करण कोड बनाकर ऐसी समस्याओं को हल करने की कोशिश करता है, अर्थात। कोड में रनटाइम सत्यापन कोड सम्मिलित करता है। लेकिन यह कोड "जटिल" होता है और केवल कुछ मामलों में प्रस्तावित निर्भरता होने पर सरल मामलों के लिए अच्छा है, लेकिन अगर बहुत सारे अनसुलझे मुद्दे हैं तो क्या होगा?
2. किसी फ़ंक्शन में जाते समय, वास्तविक तर्कों के कई गुण खो जाते हैं, जो अनुकूलन की गुणवत्ता को प्रभावित कर सकता है। उदाहरण के लिए, स्मृति में वस्तुओं के स्थान के बारे में जानकारी वैश्वीकरण से लाभ को प्रभावित करती है। यदि वास्तविक तर्क स्थिर है, तो इसे फ़ंक्शन के अंदर खींचना भी गणना को सरल कर सकता है। खैर, आदि।
3. अज्ञात गुणों के साथ एक फ़ंक्शन को कॉल करना डेटा स्ट्रीम का विश्लेषण करना मुश्किल बनाता है। इस पर विचार करने की आवश्यकता है कि यह अज्ञात कॉल भाषा के मानक के अनुसार, सभी डेटा को बदल सकती है। (उदाहरण के लिए, ग्लोबल पॉइंटर्स और वैरिएबल्स, ऑब्जेक्ट्स, एक्सेस, जो तर्कों के माध्यम से फ़ंक्शन को पास किए जाते हैं)। यह इस तरह के अनुकूलन के साथ हस्तक्षेप करता है जैसे कि स्थिरांक खींचना, सामान्य उप-रेखाओं को निकालना, और कई अन्य।
4. अज्ञात फ़ंक्शन को कॉल करने वाले लूप को सही तरीके से वर्गीकृत नहीं किया जा सकता है (जैसा कि निश्चित संख्या में पुनरावृत्तियों के साथ होता है)। ऐसा इसलिए है क्योंकि किसी अज्ञात फ़ंक्शन में प्रोग्राम से बाहर हो सकता है। नतीजतन, व्यावहारिक रूप से सभी चक्रीय अनुकूलन अपरिहार्य हैं।
5. अपने आप में एक फ़ंक्शन कॉल करना काफी महंगा है। यह तर्क तैयार करने के लिए आवश्यक है, स्थानीय चर भंडारण के लिए स्टैक पर जगह आवंटित करें, और एक नए पते से निष्पादन के लिए निर्देश लोड करें। यह संभावना है कि ये पते कैश में नहीं होंगे। यदि फ़ंक्शन का शरीर छोटा है, तो ऐसा हो सकता है कि इसके कॉल की लागत इसके संचालन के समय की तुलना में बहुत बड़ी है।
6. स्थैतिक लिंकिंग के साथ, कार्यक्रम में अनावश्यक कोड होंगे - स्रोतों और पुस्तकालयों से अप्रयुक्त कार्य।

शायद लिस्ट बन जाए।

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


आप दो-पास और एक-पास संकलन योजना के लिए कुछ इस तरह आकर्षित कर सकते हैं।

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

इसलिए, यदि आप ऑब्जेक्ट फ़ाइल बनाने के लिए कंपाइलर का उपयोग करते हैं, उदाहरण के लिए –c ऑप्शन के साथ, तो, -Qipo ऑप्शन की मौजूदगी या अनुपस्थिति के आधार पर, विभिन्न इकाइयाँ बनाई जाएंगी। -Qipo के साथ, एक ऑब्जेक्ट फ़ाइल एक पैक आंतरिक प्रतिनिधित्व है, न कि एक नियमित ऑब्जेक्ट फ़ाइल। ऐसी फाइलें लिंकर लिंक और पुस्तकालयों के लिए उपयोगिता बनाने की उपयोगिता को नहीं समझती हैं। ऐसी ऑब्जेक्ट फ़ाइलों के साथ काम करने के लिए, आपको उनके विस्तारित इंटेल समकक्षों xilink और xilib का उपयोग करने की आवश्यकता है। आंतरिक प्रतिनिधित्व वाली ऑब्जेक्ट फ़ाइलों से बनाई गई एक लाइब्रेरी में एक आंतरिक प्रतिनिधित्व के साथ अनुभाग होंगे, जिसका अर्थ है कि इसमें मौजूद उपयोगिताओं को उस समय इंटरप्रोसेरुरल विश्लेषण में भाग लेने में सक्षम होगा जब इस तरह के पुस्तकालय को एप्लिकेशन से जोड़ा जाता है। (स्वाभाविक रूप से, केवल उपयोग करते हुए। इंटेल कंपाइलर और -Qipo विकल्प।) यह इस प्रकार है कि इंटेल कंपाइलर और इंटरप्रोडेक्टोरल विश्लेषण का उपयोग करने से अधिकतम लाभ प्राप्त करने के लिए, आपको बनाए गए पुस्तकालयों का उपयोग करना होगा -Qipo के साथ इंटेल संकलक का उपयोग कर। ताकि इंटरप्रोसेक्शुअल विश्लेषण सिस्टम फ़ंक्शंस के साथ काम कर सके, कंपाइलर को इन फ़ंक्शंस की जानकारी हो।

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

ग्राफ को बुलाओ

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

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

/Qip[-] enable(DEFAULT)/disable single-file IP optimization within files /Qipo[n] enable multi-file IP optimization between files 

खैर, प्लस दो अतिरिक्त विकल्प हैं, जिनका मैं थोड़ी देर बाद उल्लेख करूंगा।

 /Qipo-c generate a multi-file object file (ipo_out.obj) /Qipo-S generate a multi-file assembly file (ipo_out.asm) 

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



औपचारिक रूप से, हम कह सकते हैं कि c-qipo को अधिक संसाधनों की आवश्यकता होती है, और –Qip को कम संसाधनों की आवश्यकता होती है, लेकिन यह अनुकूलन की सबसे खराब गुणवत्ता भी प्रदान करता है।
वास्तविकता में, सब कुछ इतना सरल नहीं है, कम से कम संसाधनों के साथ। बेशक, वास्तव में, एक फ़ाइल के लिए कॉल ग्राफ़ पूरे प्रोजेक्ट के लिए कॉल ग्राफ़ के सबग्राफ नहीं हैं। उदाहरण के लिए, विभिन्न फ़ाइलों के लिए ग्राफ़ में वही फ़ंक्शन हो सकते हैं जो विवरण फ़ाइलों से आए थे और प्रत्येक फ़ाइल के लिए स्थानीय हैं। यह विशेष रूप से बड़ी सी ++ परियोजनाओं के लिए सच है। इस तरह के कार्यों को कुछ फ़ाइलों के लिए कॉल ग्राफ़ में दोहराया जा सकता है। मेरी राय में, हम सशर्त रूप से मान सकते हैं कि ये कार्य कमजोर कार्यों का एक प्रकार का एनालॉग हैं। इसलिए, यदि हम सिंगल-फाइल ऑप्टिमाइज़ेशन मॉडल के साथ प्रत्येक व्यक्तिगत ग्राफ के लिए वर्टिकल की संख्या को सारांशित करते हैं, तो पूर्ण कॉल ग्राफ़ में वर्टिस की संख्या वर्टिकल की संख्या से बहुत बड़ी हो सकती है। एक ही समय में, एकल-फ़ाइल अनुकूलन मॉडल के साथ, इन सभी कमजोर कार्यों को संसाधित किया जाता है और कंपाइलर "टिंकर" उनमें से प्रत्येक के साथ होता है ताकि तब लिंकर निष्पादन योग्य फ़ाइल या लाइब्रेरी में इस फ़ंक्शन का एक संस्करण छोड़ दे। इसके अलावा, मल्टी-फाइल प्रोसेसिंग में काम की मात्रा सबग्राफ और कार्यों को हटाकर कम की जा सकती है जो मुख्य से अप्राप्य हैं। यदि किसी फ़ंक्शन को उसके सभी कॉल में प्रतिस्थापित किया गया है (और कुछ अन्य शर्तें पूरी हो गई हैं), तो फ़ंक्शन को कंपाइलर के अनुकूलन वाले भाग द्वारा संसाधित नहीं किया जाएगा, अर्थात। अंतिम निष्पादन योग्य में इस फ़ंक्शन का मुख्य भाग नहीं होगा। एकल-फ़ाइल मॉडल के लिए, यह केवल तभी सच है जब फ़ंक्शन में एक स्थिर विशेषता है। यही है, सिंगल-फाइल आईपीए के साथ, एक निश्चित संख्या में "मृत" फ़ंक्शन प्रसंस्करण में मिलेंगे।
सामान्य तौर पर, ऐसा हो सकता है कि कुल मिलाकर कंपाइलर c -Qipo की तुलना में बहुत अधिक काम करेगा। एक कार्यक्रम को संकलित करते समय, कॉल के एक बड़े ग्राफ़ के बजाय, आपको कई छोटे ग्राफ़ संसाधित करने होंगे। परिणामस्वरूप, प्रत्येक एकल-फ़ाइल संकलन को पूर्ण कॉल ग्राफ़ के साथ काम करने की तुलना में बहुत कम संसाधनों की आवश्यकता होगी, लेकिन सभी फ़ाइलों को संकलित करने में खर्च किए गए संसाधनों की संख्या पूर्ण कॉल ग्राफ़ के साथ काम करने की तुलना में बहुत बड़ी हो सकती है।
मैं इसका उल्लेख CPU2006 से पहले से ही वर्णित बेंचमार्क 447.dealII के साथ करूंगा। मैंने पहले ही लिखा है कि इस एप्लिकेशन के कॉल के पूर्ण ग्राफ़ में लगभग 320,000 कोने हैं। लगभग 120 फाइलें संकलन में शामिल हैं। सभी संसाधित फ़ाइलों के कॉल ग्राफ़ में सभी कोने की कुल संख्या है ~ 1,500,000 कोने (हालांकि प्रत्येक शीर्ष फ़ाइल में 50,000 से कम कोने हैं)। यानी पूर्ण कॉल ग्राफ़ में सभी कोने की संख्या से 5 गुना अधिक। मैंने सभी समानांतर संकलन विकल्पों को बंद कर दिया और कहा कि -Qipo के साथ कार्यक्रम लगभग 160 के लिए मेरे Nehalem पर संकलित है, जबकि –Qip के साथ संकलन का समय ~ 495 s है, अर्थात 3 गुना अधिक। यदि आप बैकएंड में कार्य किए जाने वाले कार्यों की संख्या -Qipo से गिनते हैं, तो आपको ~ 19500 फ़ंक्शन मिलते हैं। -Qip के साथ एक परियोजना का संकलन करते समय संसाधित कार्यों की कुल संख्या ~ 55000 है। ठीक है, यदि आप निष्पादन योग्य फ़ाइल के आकार को देखते हैं, तो इस एप्लिकेशन के लिए -Qipo के साथ संकलित फ़ाइल –Qip के साथ संकलित फ़ाइल की तुलना में लगभग एक तिहाई छोटी है।
एकल-फ़ाइल अनुकूलन का मुख्य लाभ यह है कि इस मामले में, एक फ़ाइल को संपादित करते समय, आपको संपूर्ण एप्लिकेशन को पूरी तरह से पुनर्निर्माण करने की आवश्यकता नहीं है, लेकिन केवल एक फ़ाइल को फिर से जमा करें और इसे अन्य ऑब्जेक्ट फ़ाइलों से लिंक करें। इसके अलावा, -क्यूप के साथ काम करना समानांतर करना आसान है, लेकिन -क्यूपो के साथ एक एप्लिकेशन बनाना कम समानांतर हो सकता है। हालांकि –Qipo विकल्प में एक संख्यात्मक तर्क शामिल हो सकता है (उदाहरण के लिए, -Qipo2 का अर्थ है दो थ्रेड्स में काम करना), IPA पूर्ण कॉल ग्राफ पर किया जाता है और इस विश्लेषण को समानांतर करने के लिए एक अच्छा तरीका अभी तक आविष्कार नहीं किया गया है, इसलिए काम का यह हिस्सा एक धागे में किया जाता है (या प्रत्येक में दोहराया जाता है) स्ट्रीम) और इसके अलावा, प्रत्येक स्ट्रीम IPA द्वारा एकत्र किए गए डेटा का भार प्राप्त करता है। बैकएंड में सभी कार्यों के प्रसंस्करण को थ्रेड्स के बीच प्रभावी रूप से वितरित किया जा सकता है, लेकिन उपरोक्त कठिनाइयों के कारण, एकल-फ़ाइल मॉडल का उपयोग करने के मामले में इस तरह के स्वचालित समानांतर कम कुशल हैं।

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

 /MP[<n>] create multiple processes that can be used to compile large numbers of source files at the same time 

यदि उपरोक्त 447.deallI को -Qipo में विभिन्न मूल्यों के साथ संकलित किया जाता है, तो संकलन समय इस तरह बदल जाएगा: -Qipo1: 160s, -Qipo2: 136s, -Qipo4: 150s। यानी बहुत जल्द प्रवाह एक दूसरे के साथ हस्तक्षेप करना शुरू करते हैं।
यदि एक ही icl कॉल में हम –Qipo को –Qip से बदल देते हैं (या इसे पूरी तरह से हटा देते हैं, -Qip डिफ़ॉल्ट रूप से काम करेगा) और / MP विकल्प जोड़ें, तो हमें निम्नलिखित मिलते हैं: / MP1: 495s; / एमपी 2: 259 एस; / MP4: 145s; / एमपी 8: 117 एस; / Mp16: 84s

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

test_main1.c:

 #include <stdio.h> #include <stdlib.h> #define N 10000 extern float calculate(float *a, float *b); int main() { float *a,*b,res; int i; a = (float*)malloc(N*sizeof(float)); b = (float*)malloc(N*sizeof(float)); for(i=0;i<N;i++) { a[i] = i; b[i] = 1 - i; } res = calculate(a,b); printf("res = %f", res); } 

test1.c:

 #include <stdio.h> #define N 10000 extern float calc(float a, float b); float calculate(float * restrict a,float * restrict b) { int i; float res; for(i=0;i<N;i++) { res = calc(a[i],b[i]); } return res; } 

test2.c:

 float calc(float a,float b) { return(a+b); } 

 icl -Feaaa.exe -Qparallel -Qpar_report3 test_main.c test1.c test2.c -Qstd=c99 icl -Feaaa.exe -Qipo -Qparallel -Qpar_report3 test_main.c test1.c test2.c -Qstd=c99 

-Qparallel विकल्प का उपयोग यहां किया गया है, जिसमें Intel समानांतर कंपाइलर ऑटो-समांतरक और –Qpar_report3 विकल्प शामिल है, जो इस बारे में जानकारी देता है कि कौन-सा चक्र ऑटो-समांतरक द्वारा संसाधित और अस्वीकृत किया गया था और क्यों।

बिना -Qipo के आउटपुट निम्नलिखित की रिपोर्ट करता है:

 ... test_main.c procedure: main ..\test_main.c(14): (col. 1) remark: LOOP WAS AUTO-PARALLELIZED test1.c procedure: calculate ..\test1.c(11): (col. 1) remark: loop was not parallelized: existence of parallel dependence test2.c procedure: calc 

आउटपुट से - क्यूपो:

 test_main.c test1.c test2.c procedure: main C:\iusers\aanufrie\for_habrahabr\7a\test_main.c(13): (col. 1) remark: LOOP WAS AUTO-PARALLELIZED C:\iusers\aanufrie\for_habrahabr\7a\test_main.c(17): (col. 8) remark: LOOP WAS AUTO-PARALLELIZED 

-Qipo के निष्कर्ष से यह देखा जा सकता है कि चक्र के ऑटो-समानांतरकरण को अंजाम देने के लिए इंटरप्रोडेक्टोरल विश्लेषण ने मदद की।
यह स्पष्ट है कि -Qipo के मामले में, इनलाइनिंग भी मदद करता है, लेकिन अगर आप इनलाइनिंग को अक्षम करते हैं, तो भी कंपाइलर कैल्क फ़ंक्शन का विश्लेषण करके ऑटो-समालोचना की वैधता साबित कर सकेगा।

लेकिन क्या होगा, अगर किसी कारण से, एक बहु-फाइल मॉडल लागू नहीं होता है, उदाहरण के लिए, एक कार्यक्रम बनाने में बहुत समय लगता है और यह आपको सूट नहीं करता है? आप एक फ़ाइल में साझा कार्यों को रखकर एकल-फ़ाइल मॉडल की उपयोगिता बढ़ा सकते हैं। स्थिर विशेषता कार्यों के लिए बहुत उपयोगी है। यदि किसी फ़ंक्शन में यह विशेषता है, तो आईपीए एकल-फ़ाइल ऑपरेशन के दौरान इस फ़ंक्शन के सभी कॉल देखता है, और यदि इन कॉल में कोई भी विशेषताएं हैं, तो उन्हें फ़ंक्शन में खींचा जा सकता है। यदि स्टैटिक फ़ंक्शन के सभी कॉल्स को प्रतिस्थापित किया गया था, तो फ़ंक्शन बॉडी को स्वयं हटाया जा सकता है। वही स्थैतिक वस्तुओं के लिए जाता है। Interprocedural विश्लेषण मानता है कि यह उनके उपयोग के सभी उदाहरणों को देखता है और उनके साथ विभिन्न अनुकूलन कर सकता है। सामान्य तौर पर, एक एकल फ़ाइल के साथ वस्तुओं के दायरे पर कोई भी प्रतिबंध एक बेहतर एकल-फ़ाइल इंटरप्रोडेक्टोरल विश्लेषण करने में मदद कर सकता है।
लेकिन क्या होगा अगर किसी एकल-फ़ाइल के ढांचे के भीतर कोई समस्या हल नहीं हो सकती है, क्योंकि महत्वपूर्ण कार्यक्षमता कई फाइलों के बीच फैली हुई है?
–Qipo-c विकल्प कार्य के किसी प्रकार के मध्यवर्ती मॉडल को व्यवस्थित करने का अवसर प्रदान करता है, अर्थात एक या सभी फ़ाइलों से फ़ंक्शंस पर आधारित कॉल ग्राफ़ न बनाएं, बल्कि सभी फ़ाइलों को समूहों में विभाजित करें। यह सुविधाजनक है यदि आपकी परियोजना कई करीबी परस्पर टुकड़ों में विभाजित है। (उदाहरण के लिए, ऐसी परियोजना हमारा संकलक है, जिसमें सामान्य उपयोगिताओं का उपयोग करने वाले कई घटक हैं और अलग-अलग निर्देशिकाओं में स्थित हैं)। -Qipo-c एक निश्चित फ़ाइल ipo_out.obj के साथ एक ऑब्जेक्ट फ़ाइल बनाता है और कंपाइलर कॉल में सूचीबद्ध फ़ाइलों से सभी फ़ंक्शन इस फ़ाइल में मिलता है। उपरोक्त उदाहरण में, एप्लिकेशन को निम्नानुसार संकलित किया जा सकता है:

 icl -Qipo-c -Qparallel -Qpar_report3 -Qstd=c99 test1.c test2.c icl test_main.c ipo_out.obj 

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

यह सवाल है, लेकिन क्या पाठकों में से किसी ने ऐसी संकलन योजना का उपयोग किया है, या कम से कम इसके बारे में सुना है? एक राय है कि केवल 5% डेवलपर्स प्रदर्शन समस्या में रुचि रखते हैं। अक्सर, कंपाइलर के काम को नियंत्रित करने के लिए उपयोगकर्ता को कुछ अतिरिक्त उत्तोलन प्रदान करने की इच्छा एक सरल प्रश्न पर टिकी हुई है: "किसे इसकी आवश्यकता है और कौन इसका उपयोग करेगा?"

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

और अंत में, -Qipo-S विकल्प उन लोगों के लिए उपयोगी है जो इंटरप्रोडेक्टोरल ऑप्टिमाइज़ेशन के बाद कोडांतरक को अपग्रेड या सीखना चाहते हैं।

यह IPO और IPA के आधार के रूप में कॉल ग्राफ़ के बारे में कहानी का निष्कर्ष निकालता है। मुझे आशा है कि कहानी को आपस में मिलते-जुलते रहने की कोशिश करेंगे और सभी सवालों के जवाब देने की कोशिश करेंगे।