स्मार्ट कंपाइलरों के लिए एक उज्जवल भविष्य की ओर

अब मशीन लर्निंग और आर्टिफिशियल इंटेलिजेंस का विषय बेहद लोकप्रिय है, इस समय, कंप्यूटर, कंप्यूटिंग और एल्गोरिदम की कंप्यूटिंग शक्ति के लिए धन्यवाद, जो लंबे समय से उत्पन्न हुए हैं और उन्हें लागू किया जा सकता है। लगभग हर दिन आप इस क्षेत्र में नई उपलब्धियों के बारे में समाचार पढ़ सकते हैं। इसके अलावा, लगभग सभी क्षेत्रों में मशीन लर्निंग का उपयोग किया जाता है ... और संकलक का विकास कोई अपवाद नहीं है। हालांकि, क्षेत्र काफी विशिष्ट है और स्मार्ट कंपाइलर बनाने में इसकी अपनी विशेषताएं और कठिनाइयाँ हैं। इसी समय, इस विषय पर बहुत सारे अध्ययन हैं और वे अकादमिक वातावरण और विभिन्न कंपनियों के भीतर लंबे समय तक आयोजित किए गए हैं।

कंपाइलर बनाते समय मशीन सीखने के तरीकों को लागू करने के लिए वास्तव में कहाँ कोशिश कर रहे हैं? और अब तक "स्मार्ट" कंपाइलर डेवलपर के दैनिक जीवन का हिस्सा क्यों नहीं बन गए हैं?

संकलक विकास में मशीन सीखने का उपयोग करने के लिए विकल्प

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

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

किसी व्यक्ति के लिए यह अनुमान लगाना कठिन है कि कौन सी अनुकूलन अनुकूलन एक अच्छा परिणाम देगा और जो प्रतिगमन को जन्म दे सकता है, क्योंकि इसके लिए आपको उपयोग किए जाने वाले अनुमानी एल्गोरिदम की पेचीदगियों के बारे में अच्छी समझ होनी चाहिए, उपयोग किए गए कंपाइलर की संरचना और मार्ग का एक अच्छा ज्ञान, और पूरी तरह से संकलित कार्यक्रम का कोड भी जानते हैं, जो वर्तमान अनुप्रयोग विकास प्रक्रिया असंभव है। परिणामस्वरूप, किसी व्यक्ति के लिए एक कार्यक्रम के लिए सर्वश्रेष्ठ संकलन विकल्पों की पहचान करना प्रदर्शन और कोड आकारों के विकल्पों और माप के विभिन्न संयोजनों की संपूर्ण खोज का कार्य बन जाता है।

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

मौजूदा अनुसंधान और समाधान

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

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

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

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

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

LLVM से संबंधित एक शोध, LLVMTuner है , जो इलिनोइस विश्वविद्यालय में I. चेन और डब्ल्यू। एडवे द्वारा विकसित एक सॉफ्टवेयर उत्पाद है। 2017 में, उस समय उपलब्ध परिणामों का वर्णन करते हुए एक रिपोर्ट प्रस्तुत की गई थी। इस कार्य में, हमने व्यक्तिगत "हॉट" साइकल को अनुकूलित किया। यह ढांचा बड़े कार्यक्रमों के स्वचालित विन्यास के लिए बनाया गया है। LLVMTuner LLVM IR मिडलवेयर पर चलता है, गर्म छोरों की पहचान करने के लिए प्रोफाइलिंग का उपयोग करता है, और फिर स्वचालित रूप से उनके लिए उत्तराधिकार को समायोजित करता है। फोकस शीर्ष-स्तरीय चक्रों पर है। चयनित चक्र और किसी भी कॉल फ़ंक्शन को एक अलग मॉड्यूल में स्थानांतरित किया जाता है, जिसे आगे आवश्यक अनुकूलन के अधीन किया जाता है। यह समाधान आपको बड़े कार्यक्रमों में बेहतर प्रदर्शन प्राप्त करने की अनुमति देता है।

मौजूदा समस्याएं

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

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

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

लेकिन, सबसे पहले, यह सवाल उन तत्वों की पहचान करने के लिए उठता है जिनके लिए विशेषताओं को इकट्ठा करना आवश्यक है। अद्वितीय पहचानकर्ताओं की गणना करने के कई तरीके हैं, जिन्हें सभी अनुकूलन के दौरान बचाया जा सकता है, उदाहरण के लिए:

• एएसटी आधारित फ्रंट एंड हैश
• फ्रंट-एंड पार्सिंग में निर्दिष्ट अद्वितीय संख्या
• सीएफजी (नियंत्रण-प्रवाह ग्राफ) में एक चेकसम (एलएलवीएम में पीजीओ (प्रोफाइल-निर्देशित ऑप्टिमाइज़ेशन के समान) का उपयोग करके आर्क्स के आधार पर उत्पन्न 64-बिट संख्या)

हालांकि, आपको परिवर्तनों के दौरान इन पहचानकर्ताओं को ठीक से सहेजने की आवश्यकता है, जब तत्व एक में विलय कर सकते हैं, विभाजित हो सकते हैं, नए बना सकते हैं और मूल लोगों को हटा सकते हैं, जो एक आसान काम नहीं है।

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



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

यह अनुमान लगाना कठिन है कि स्मार्ट कंपाइलर कब व्यापक हो जाएंगे। आधुनिक कंपाइलरों में अन्य समस्याएं भी हैं जिन्हें इस विधि द्वारा हल करने की संभावना नहीं है, और जो इस समय संभवतः अधिक प्राथमिकता हैं। हालाँकि, कंपाइलर पहले से बहुत अधिक बुद्धिमान हो गए हैं, क्योंकि वे अपनी उपस्थिति के भोर में थे, और यह प्रक्रिया जारी रहेगी, हालांकि यह अधिकांश डेवलपर्स की तुलना में कुछ धीमा हो सकता है।