Runtime: एक स्तरीय JIT . का परिचय दें

बातचीत की योजना बनाने में @GSPP Tiering एक निरंतर विषय है। मेरी धारणा यह है कि यह _कब_ की बात है, न कि _if_ की, अगर इससे कोई सांत्वना मिलती है। जहां तक ​​_why_ यह पहले से मौजूद नहीं है, मुझे लगता है कि ऐसा इसलिए है क्योंकि, ऐतिहासिक रूप से, कथित संभावित लाभ ने कई कोडजेन मोड की बढ़ी हुई जटिलता और जोखिम को प्रबंधित करने के लिए आवश्यक अतिरिक्त विकास संसाधनों को उचित नहीं ठहराया। हालांकि, मुझे वास्तव में विशेषज्ञों को इस पर बोलने देना चाहिए, इसलिए मैं उन्हें जोड़ दूंगा।

/cc @dotnet/jit-contrib @russellhadley

किसी तरह मुझे संदेह है कि यह अभी भी क्रॉसजेन/एनजीएन, रेडी टू रन और कोरर्ट की दुनिया में प्रासंगिक है।

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

लेकिन अभी तक .NET के लिए सभी कोड जेनरेटर ने दो लक्ष्यों के बीच एक असंभव संतुलन बनाने की कोशिश की है, जो न तो बहुत अच्छी तरह से पूरा कर रहा है। आइए उस संतुलनकारी कार्य से छुटकारा पाएं ताकि हम अनुकूलन को 11 में बदल सकें।

लेकिन अभी तक .NET के लिए सभी कोड जेनरेटर ने दो लक्ष्यों के बीच एक असंभव संतुलन बनाने की कोशिश की है, जो न तो बहुत अच्छी तरह से पूरा कर रहा है। आइए उस संतुलनकारी कार्य से छुटकारा पाएं ताकि हम अनुकूलन को 11 में बदल सकें।

मैं सहमत हूं लेकिन इसे ठीक करने के लिए दुभाषिया जैसी चीजों की आवश्यकता नहीं है। बस एक अच्छा क्रॉसजेन कंपाइलर, यह एक बेहतर RyuJIT या LLILC हो।

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

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

वेब ऐप्स को किसी एनजीएन-स्टाइल प्रोसेसिंग की आवश्यकता नहीं होनी चाहिए। यह परिनियोजन पाइपलाइन में अच्छी तरह फिट नहीं होता है। बड़ी बाइनरी को ngen करने में बहुत समय लगता है (भले ही लगभग सभी कोड गतिशील रूप से मृत या ठंडे हों)।

साथ ही, वेब ऐप को डिबग और परीक्षण करते समय आप यथार्थवादी प्रदर्शन देने के लिए एनजीएन पर भरोसा नहीं कर सकते हैं।

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

Tiering हर परिदृश्य में हमेशा के लिए सब कुछ हल कर देता है। लगभग बोलना :) यह वास्तव में हमें JITs के वादे पर ले जा सकता है: प्रदर्शन _beyond_ प्राप्त करें जो एक C कंपाइलर कर सकता है।

RyuJIT का वर्तमान कार्यान्वयन जैसा कि अब है, टियर 1 के लिए काफी अच्छा है... सवाल यह है: क्या इस तथ्य के बाद चलने वाले गर्म पथों के लिए टियर 2 चरम अनुकूलन JIT का कोई मतलब होगा? अनिवार्य रूप से जब हमें पता चलता है या यह जानने के लिए पर्याप्त रनटाइम जानकारी है कि कुछ गर्म है या जब शुरू से ही इसका उपयोग करने के लिए कहा जाता है।

RyuJIT स्तर 1 होने के लिए काफी अच्छा है। इसके साथ समस्या यह है कि एक दुभाषिया के पास _far_ तेज स्टार्टअप समय होगा (मेरे अनुमान में)। दूसरी समस्या यह है कि टियर 2 को आगे बढ़ाने के लिए टियर 1 कोड को निष्पादित करने की स्थानीय स्थिति को नए टियर 2 कोड (OSR) में स्थानांतरित किया जाना चाहिए। इसके लिए RyuJIT परिवर्तन की आवश्यकता है। एक दुभाषिया जोड़ना, मुझे लगता है, एक ही समय में बेहतर स्टार्टअप विलंबता के साथ एक सस्ता रास्ता होगा।

इससे भी सस्ता विकल्प यह होगा कि रनिंग कोड को टियर 2 कोड से रिप्लेस न किया जाए। इसके बजाय, टियर 1 कोड स्वाभाविक रूप से वापस आने तक प्रतीक्षा करें। यह एक समस्या हो सकती है यदि कोड लंबे समय तक चलने वाले हॉट लूप में प्रवेश करता है। यह उस तरह से टियर 2 के प्रदर्शन पर कभी नहीं पहुंचेगा।

मुझे लगता है कि यह बहुत बुरा नहीं होगा और इसे v1 रणनीति के रूप में इस्तेमाल किया जा सकता है। कम करने वाले विचार उपलब्ध हैं जैसे कि एक विशेषता को गर्म के रूप में चिह्नित करना (यह वर्तमान जेआईटी रणनीति के साथ भी मौजूद होना चाहिए)।

@GSPP यह सच है, लेकिन इसका मतलब यह नहीं है कि आप इसे अगले भाग में नहीं जान पाएंगे। यदि जिटेड कोड और इंस्ट्रूमेंटेशन लगातार बना रहता है, तो दूसरा निष्पादन आपको अभी भी टियर 2 कोड (कुछ स्टार्टअप समय की कीमत पर) मिलेगा --- जो एक बार के लिए मुझे व्यक्तिगत रूप से परवाह नहीं है क्योंकि मैं ज्यादातर सर्वर कोड लिखता हूं।

JIT की तुलना में दुभाषिया लिखना सस्ता लगता है।

एक नया दुभाषिया लिखने के बजाय, क्या अक्षम अनुकूलन के साथ RyuJIT को चलाने का कोई मतलब हो सकता है? क्या इससे स्टार्टअप समय में काफी सुधार होगा?

एक उच्च गुणवत्ता वाला कोड जनरेटर बनाया जाना चाहिए। यह हो सकता है वीसी

क्या आप सी 2, विजुअल सी ++ बैकएंड के बारे में बात कर रहे हैं? यह क्रॉस-प्लेटफ़ॉर्म नहीं है और ओपन सोर्स नहीं है। मुझे संदेह है कि दोनों को ठीक करना जल्द ही कभी भी होगा।

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

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

LLVM एक बढ़िया विकल्प प्रतीत होता है। मेरा मानना ​​​​है कि कई भाषाएं वर्तमान में एलएलवीएम को जीसी के साथ और सामान्य रूप से प्रबंधित रनटाइम के साथ काम करने में रुचि रखती हैं।

इस विषय पर एक दिलचस्प लेख: Apple ने हाल ही में अपने JavaScript JIT के अंतिम स्तर को LLVM से दूर ले जाया है: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ । हम उनके सामने आने वाली समान समस्याओं का सामना कर सकते हैं: धीमी संकलन समय और एलएलवीएम की स्रोत भाषा के ज्ञान की कमी।

RyuJIT की तुलना में 10x धीमी गति दूसरे स्तर के लिए पूरी तरह से स्वीकार्य होगी।

मुझे नहीं लगता कि स्रोत भाषा (जो एक सच्ची चिंता है) के ज्ञान की कमी एलएलवीएम की वास्तुकला में निहित है। मेरा मानना ​​​​है कि कई टीमें एलएलवीएम को एक ऐसे राज्य में ले जाने में व्यस्त हैं, जहां स्रोत भाषा के ज्ञान का अधिक आसानी से उपयोग किया जा सकता है। _All_ गैर-सी उच्च-स्तरीय भाषाओं में LLVM पर संकलन करते समय यह समस्या होती है।

WebKIT FTL/B3 प्रोजेक्ट .NET की तुलना में सफल होने के लिए एक कठिन स्थिति में है क्योंकि कोड चलाते समय उन्हें उत्कृष्ट होना चाहिए जो _in Total_ कुछ सौ मिलीसेकंड का समय लेता है और फिर बाहर निकलता है। यह वेब पेजों को चलाने वाले जावास्क्रिप्ट वर्कलोड की प्रकृति है। .NET उस स्थान पर नहीं है।

@GSPP मुझे यकीन है कि आप शायद LLILC के बारे में जानते होंगे। अगर नहीं तो देख लीजिए।

हम कुछ समय से सीएलआर अवधारणाओं के लिए एलएलवीएम समर्थन पर काम कर रहे हैं और हमने ईएच और जीसी दोनों सुधारों में निवेश किया है। दोनों पर अभी काफी कुछ करना बाकी है। इसके अलावा कुछ अज्ञात मात्रा में काम जीसी की उपस्थिति में ठीक से काम कर रहे अनुकूलन प्राप्त करते हैं।

एलएलआईएलसी रुका हुआ लगता है। यह है?
18 अप्रैल 2016 को शाम 7:32 बजे, "एंडी एयर्स" नोटिफिकेशन @github.com ने लिखा:

@GSPP https://github.com/GSPP मुझे यकीन है कि आप शायद LLILC के बारे में जानते होंगे
https://github.com/dotnet/llilc। अगर नहीं तो देख लीजिए।

हम कुछ समय से सीएलआर अवधारणाओं के लिए एलएलवीएम समर्थन पर काम कर रहे हैं और हमारे पास है
ईएच और जीसी सुधार दोनों में निवेश किया। अभी काफी कुछ करना बाकी है
दोनों। इसके अलावा कुछ अज्ञात मात्रा में कार्य अनुकूलन प्राप्त करते हैं
जीसी की उपस्थिति में ठीक से काम करना।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/dotnet/coreclr/issues/4331#issuecomment -211630483

@drbo - LLILC इस समय बैक बर्नर पर है - MS टीम RyuJIT में लाए गए अधिक लक्ष्य प्राप्त करने के साथ-साथ उन मुद्दों को ठीक करने पर ध्यान केंद्रित कर रही है जो CoreCLR ड्राइव के रूप में रिलीज़ होने के लिए आते हैं और यह हमारे पूरे समय में बहुत अधिक लगता है। यह मेरी TODO सूची (मेरे प्रचुर खाली समय में) पर है कि हम LLILC के साथ कितनी दूर (वर्तमान में) प्राप्त हुए हैं, इसके आधार पर एक सीखी गई पोस्ट को लिखना है, लेकिन मुझे अभी तक यह नहीं मिला है।
स्तर पर, इस विषय ने पिछले कुछ वर्षों में बहुत सारी चर्चाएँ उत्पन्न की हैं। मुझे लगता है कि कुछ नए वर्कलोड के साथ-साथ छवियों को चलाने के लिए तैयार संस्करण के नए अतिरिक्त को देखते हुए, हम कैसे और कहाँ स्तर पर एक नया नज़र डालेंगे।

@russellhadley क्या आपके पास पोस्ट लिखने का खाली समय था?

मैं परिकल्पना करता हूं, प्रचारित स्टैक स्लॉट और gcroots के अनुकूलन को तोड़ने और धीमी गति से झटके के समय के बारे में कुछ नहीं होना चाहिए ... मुझे परियोजना के कोड को बेहतर ढंग से देखना चाहिए।

मुझे यह भी आश्चर्य है कि क्या यह संभव और लाभदायक है कि सीधे SelectionDAG में कूदें और LLVM बैकएंड का हिस्सा प्रदर्शन करें। कम से कम कुछ झाँकें और प्रचार की प्रतिलिपि बनाएँ... यदि उदाहरण के लिए रजिस्टरों को gcroot पदोन्नति LLILC में समर्थित है

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

क्या इस पर और विचार हुए हैं? @russellhadley CoreCLR जारी की गई है और RyuJIT को (कम से कम) 86 पोर्ट दिया गया है - रोडमैप पर आगे क्या है?

इस पर काम की शुरुआत के लिए dotnet/coreclr#10478 देखें।

साथ ही डॉटनेट/कोरक्लर#12193

@noahfalk , क्या आप कृपया प्रबंधित कोड से तुरंत एक स्तरीय 2 संकलन को मजबूर करने के लिए रनटाइम को बताने का एक तरीका प्रदान कर सकते हैं? अधिकांश उपयोग के मामलों के लिए टियरड संकलन एक बहुत अच्छा विचार है, लेकिन मैं एक ऐसे प्रोजेक्ट पर काम कर रहा हूं जहां स्टार्टअप समय अप्रासंगिक है लेकिन थ्रूपुट और स्थिर विलंबता आवश्यक है।

मेरे सिर के ऊपर से, यह या तो हो सकता है:

• कॉन्फ़िगरेशन फ़ाइल में एक नई सेटिंग, <gcServer enabled="true" /> की तरह एक स्विच जेआईटी को हमेशा टियर 1 छोड़ने के लिए मजबूर करने के लिए
• या ऐसा कुछ RuntimeHelpers.PrepareMethod , जिसे कोड द्वारा उन सभी विधियों पर बुलाया जाएगा जो हॉट पाथ के हिस्से हैं (हम इसका उपयोग स्टार्टअप पर अपने कोड को प्री-जेआईटी करने के लिए कर रहे हैं)। इससे डेवलपर को अधिक स्वतंत्रता देने का फायदा होता है, जिसे पता होना चाहिए कि हॉट पाथ क्या है। इस पद्धति का एक अतिरिक्त अधिभार ठीक रहेगा।

दी, कुछ परियोजनाओं को इससे लाभ होगा, लेकिन मैं डिफ़ॉल्ट रूप से जेआईटी लंघन अनुकूलन से चिंतित हूं, और मैं यह बताने में सक्षम नहीं हूं कि मैं इसके बजाय अपने कोड को भारी रूप से अनुकूलित करूंगा।

मुझे पता है कि आपने डिज़ाइन दस्तावेज़ में निम्नलिखित लिखा है:

स्व-संशोधित कोड करने के लिए प्रबंधित कोड API से सुलभ नई बिल्ड पाइपलाइन चरण जोड़ें।

जो बहुत दिलचस्प लगता है लेकिन मुझे पूरा यकीन नहीं है कि इसमें जो कुछ मैं पूछ रहा हूं उसे शामिल किया गया है।

साथ ही एक संबंधित प्रश्न: दूसरा जेआईटी पास कब शुरू होगा? n वीं बार किसी विधि को कब बुलाया जा रहा है? क्या जेआईटी उस धागे पर होगा जिस पर विधि चलनी चाहिए थी? यदि ऐसा है, तो वह विधि कॉल से पहले देरी का परिचय देगा। यदि आप अधिक आक्रामक अनुकूलन लागू करते हैं तो यह विलंब वर्तमान JIT समय से अधिक लंबा होगा, जो एक समस्या बन सकता है।

यह तब होना चाहिए जब विधि को पर्याप्त समय कहा जाता है, या यदि लूप
पर्याप्त पुनरावृत्तियों को निष्पादित करता है (मंच पर प्रतिस्थापन)। यह होना चाहिए
पृष्ठभूमि धागे पर अतुल्यकालिक रूप से।

29 जून, 2017 को शाम 7:01 बजे, "लुकास ट्रज़ेस्निवेस्की" सूचनाएं @github.com
लिखा था:

@noahfalk https://github.com/noahfalk , क्या आप कृपया कोई रास्ता बता सकते हैं
से तुरंत एक टियर 2 संकलन को बाध्य करने के लिए रनटाइम को बताने के लिए
प्रबंधित कोड ही? अधिकांश के लिए स्तरीय संकलन एक बहुत अच्छा विचार है
मामलों का उपयोग करें, लेकिन मैं एक ऐसे प्रोजेक्ट पर काम कर रहा हूं जहां स्टार्टअप समय अप्रासंगिक है
लेकिन थ्रूपुट और एक स्थिर विलंबता आवश्यक है।

मेरे सिर के ऊपर से, यह या तो हो सकता है:

• कॉन्फ़िग फ़ाइल में एक नई सेटिंग, एक स्विच की तरह enable="true" /> JIT को हमेशा टियर 1 छोड़ने के लिए मजबूर करने के लिए
• या RuntimeHelpers.PrepareMethod जैसा कुछ, जो होगा
  सभी विधियों पर कोड द्वारा बुलाया जाता है जो गर्म पथ के भाग हैं (हम हैं
  इसका उपयोग स्टार्टअप पर हमारे कोड को प्री-जेआईटी करने के लिए करें)। इसका फायदा है
  डेवलपर को अधिक से अधिक स्वतंत्रता देना, जिसे पता होना चाहिए कि क्या
  गर्म पथ है। इस पद्धति का एक अतिरिक्त अधिभार ठीक रहेगा।

माना, इससे कुछ परियोजनाओं को लाभ होगा, लेकिन मैं इससे चिंतित हूं
डिफ़ॉल्ट रूप से जेआईटी लंघन अनुकूलन, और मैं इसे बताने में सक्षम नहीं हूं
मैं इसके बजाय अपने कोड को भारी रूप से अनुकूलित करना चाहता हूं।

मुझे पता है कि आपने डिज़ाइन दस्तावेज़ में निम्नलिखित लिखा है:

करने के लिए प्रबंधित कोड API से सुलभ नई बिल्ड पाइपलाइन चरण जोड़ें
स्व-संशोधित कोड।

जो बहुत दिलचस्प लगता है लेकिन मुझे पूरा यकीन नहीं है कि इसमें क्या शामिल है

मैं यहाँ पूछ रहा हूँ।

साथ ही एक संबंधित प्रश्न: दूसरा जेआईटी पास कब शुरू होगा? जब एक
विधि को n वीं बार बुलाया जा रहा है? क्या जेआईटी पर होगा
वह धागा जिस पर विधि चलाना चाहिए था? यदि ऐसा है, तो वह परिचय देगा a
विधि कॉल से पहले देरी। यदि आप अधिक आक्रामक लागू करते हैं
अनुकूलन यह विलंब वर्तमान JIT समय से अधिक लंबा होगा, जो
मुद्दा बन सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/coreclr/issues/4331#issuecomment-312130920 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AGGWB2WbZ2qVBjRIQWS86MStTSa1ODfoks5sJCzOgaJpZM4IHWs8
.

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

साथ ही एक संबंधित प्रश्न: दूसरा जेआईटी पास कब शुरू होगा?

यह एक ऐसी नीति है जिसके समय के साथ विकसित होने की बहुत संभावना है। वर्तमान प्रोटोटाइप कार्यान्वयन एक सरल नीति का उपयोग करता है: "क्या विधि को> = 30 बार कहा गया है"
https://github.com/dotnet/coreclr/blob/master/src/vm/tieredcompilation.cpp#L89
https://github.com/dotnet/coreclr/blob/master/src/vm/tieredcompilation.cpp#L122

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

@DemiMarie - हमारे पास अब नीति के हिस्से के रूप में लूप पुनरावृत्तियों को ट्रैक करने वाला कुछ भी नहीं है, लेकिन यह भविष्य के लिए एक दिलचस्प संभावना है।

क्या प्रोफाइलिंग, सट्टा अनुकूलन, और . पर कोई विचार आया है?
अनुकूलन ? JVM यह सब करता है।

29 जून, 2017 को रात 8:58 बजे, "नूह फाल्क" नोटिफिकेशन @github.com ने लिखा:

@ltrzesniewski https://github.com/ltrzesniewski - इसके लिए धन्यवाद
प्रतिक्रिया! निश्चित रूप से मुझे आशा है कि विस्तृत संकलन विशाल . के लिए उपयोगी होगा
अधिकांश प्रोजेक्ट लेकिन ट्रेडऑफ़ हर प्रोजेक्ट के लिए आदर्श नहीं हो सकते हैं।
मैं अनुमान लगा रहा हूं कि हम एक पर्यावरण चर को जगह में छोड़ देंगे
tiered jitting को अक्षम करें, जिस स्थिति में आप रनटाइम व्यवहार को बनाए रखते हैं
अब उच्च गुणवत्ता के साथ है (लेकिन उत्पन्न करने के लिए धीमा) सामने की ओर झुकना। है
एक पर्यावरण चर सेट करना आपके ऐप के लिए कुछ उचित है?
अन्य विकल्प भी संभव हैं, मैं सिर्फ पर्यावरण की ओर आकर्षित हूं
चर क्योंकि यह सबसे सरल कॉन्फ़िगरेशन विकल्पों में से एक है जिसका हम उपयोग कर सकते हैं।

साथ ही एक संबंधित प्रश्न: दूसरा जेआईटी पास कब शुरू होगा?

यह एक ऐसी नीति है जिसके समय के साथ विकसित होने की बहुत संभावना है। द करेंट
प्रोटोटाइप कार्यान्वयन एक सरल नीति का उपयोग करता है: "क्या यह तरीका है
कॉल किया>= 30 बार"
https://github.com/dotnet/coreclr/blob/master/src/vm/
tieredcompilation.cpp#L89
https://github.com/dotnet/coreclr/blob/master/src/vm/
tieredcompilation.cpp#L122

सुविधाजनक रूप से यह बहुत ही सरल नीति इस पर एक अच्छा पूर्ण सुधार सुझाती है
मेरी मशीन, भले ही यह सिर्फ एक अनुमान हो। बेहतर नीतियां बनाने के लिए
हमें कुछ वास्तविक दुनिया के उपयोग की प्रतिक्रिया प्राप्त करने और उस प्रतिक्रिया को प्राप्त करने की आवश्यकता है
की आवश्यकता होगी कि कोर यांत्रिकी विभिन्न प्रकार के यथोचित रूप से मजबूत हों
परिदृश्य इसलिए मेरी योजना है कि पहले मजबूती/संगत में सुधार करें और फिर करें
ट्यूनिंग नीति के लिए और अधिक अन्वेषण।

@DemiMarie https://github.com/demimarie - हमारे पास ऐसा कुछ भी नहीं है
लूप पुनरावृत्तियों को अब नीति के हिस्से के रूप में ट्रैक करता है, लेकिन यह एक दिलचस्प है
भविष्य के लिए संभावना।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/coreclr/issues/4331#issuecomment-312146470 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AGGWB5m2qCnOKJsaXFCFigI3J6Ql8PMQks5sJEgZgaJpZM4IHWs8
.

@noahfalk एक पर्यावरण चर निश्चित रूप से एक समाधान नहीं है जो आपको इस एप्लिकेशन को एप्लिकेशन द्वारा नियंत्रित करने की अनुमति देगा। सर्वर/सेवा ऐप्स के लिए आपको आमतौर पर परवाह नहीं है कि एप्लिकेशन को स्टार्टअप में कितना समय लगता है (मुझे पता है कि हम प्रदर्शन की कीमत पर नहीं हैं)। एक डेटाबेस इंजन विकसित करना, मैं आपको पहले हाथ से बता सकता हूं, हमें इसे शुरू से ही जितनी जल्दी हो सके काम करने की आवश्यकता है और यहां तक ​​कि संभावित नए ग्राहकों द्वारा किए गए असाधारण पथ या बेंचमार्क पर भी।

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

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

संपादित करें: कुछ शैली के मुद्दे।

@redknightlois - अनुवर्ती कार्रवाई के लिए धन्यवाद

एक पर्यावरण चर निश्चित रूप से एक समाधान नहीं है जो आपको इस एप्लिकेशन को एप्लिकेशन द्वारा नियंत्रित करने की अनुमति देगा।

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

set COMPLUS_EXPERIMENTAL_TieredCompilation=1
MyApp.exe
set COMPLUS_EXPERIMENTAL_TieredCompilation=0

हम जो परवाह करते हैं वह यह है कि [हम नहीं] उपयोगकर्ता को इसकी परवाह करने के लिए मजबूर करते हैं

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

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

क्या प्रोफाइलिंग, सट्टा अनुकूलन, और . पर कोई विचार आया है?
अनुकूलन ?

@DemiMarie - वे निश्चित रूप से बातचीत में आए हैं और मुझे लगता है कि बहुत से लोग उत्साहित हैं कि स्तरीय संकलन इन संभावनाओं को खोलता है। केवल अपने लिए बोलते हुए, मैं अपनी दृष्टि को और ऊंचा करने से पहले मूलभूत स्तरीय संकलन क्षमताओं को वितरित करने पर ध्यान केंद्रित करने की कोशिश कर रहा हूं। हमारे समुदाय के अन्य लोग शायद पहले से ही अन्य अनुप्रयोगों पर मुझे आगे बढ़ा रहे हैं।

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

पर्यावरण चर अक्सर प्रति-उपयोगकर्ता या प्रति-सिस्टम सेट किए जाते हैं, जिसका रनटाइम के कई संस्करणों में ऐसी सभी प्रक्रियाओं को प्रभावित करने का संभावित नकारात्मक प्रभाव होता है। एक प्रति-ऐप कॉन्फ़िगरेशन फ़ाइल एक बेहतर समाधान की तरह लगती है (भले ही प्रति-उपयोगकर्ता/प्रति-सिस्टम भी उपलब्ध हो) - डेस्कटॉप कॉन्फ़िगरेशन मानों की तरह कुछ जिसे ऐप.कॉन्फ़िग में सेट किया जा सकता है, लेकिन एनवी वर्र्स या रजिस्ट्री का भी उपयोग करें .

मुझे लगता है कि हम सबसे आम पथ को लागू करेंगे जो प्रति-आवेदन है। सिस्टम-व्यापी सेटिंग्स भी उपयोगी हो सकती हैं, लेकिन मुझे नहीं लगता कि फीचर लागू होने से पहले हमें इसके बारे में सोचना होगा।

कृपया ध्यान दें कि हमने किसी भी विस्तार से काम नहीं किया है कि अनुकूलन के लिए दूसरे स्तर के जिट को क्या करना चाहिए, हालांकि हमारे पास कुछ विचार हैं। यह वही कर सकता है जो आज जिट करता है, लेकिन काफी संभावना है कि यह और भी करेगा।

तो मैं कुछ संभावित जटिलताओं की ओर इशारा करता हूं ....

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

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

ऐसा कहे जाने के बाद...

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

यदि आप एक उपयुक्त सादृश्य के रूप में देशी कंपाइलरों में क्या होता है, तो प्रदर्शन बनाम संकलन समय/कोड आकार ट्रेडऑफ उच्च अनुकूलन स्तरों पर बहुत खराब हो सकता है, उदाहरण के लिए प्रदर्शन में कुल 1-2% सुधार के लिए 10x लंबा संकलन। पहेली की कुंजी यह जानना है कि कौन से तरीके मायने रखते हैं, और ऐसा करने का एकमात्र तरीका यह है कि या तो प्रोग्रामर को पता चले या सिस्टम के लिए इसे अपने लिए समझ लिया जाए।

@AndyAyersMS मुझे लगता है कि आपने वहां कील ठोक दी। "आक्रामक अनुकूलन" विशेषता का इलाज करने वाला जेआईटी संभवत: जेआईटी के लिए पर्याप्त जानकारी नहीं होने के कारण अधिकांश मुद्दों को हल करेगा, जो कि उस प्रतिक्रिया को प्रदान करने के लिए प्रथम-स्तरीय जीआईटी के बिना अलगाव बेहतर कोड का उत्पादन कर सकता है।

@redknightlois विशेषता काम नहीं करेगी यदि हम अधिक स्तरीय चाहते हैं: - T3 JIT, T4 JIT, ... मुझे यकीन नहीं है कि दो स्तर पर्याप्त नहीं हैं, लेकिन हमें कम से कम इस संभावना पर विचार करना चाहिए।

एमपीजीओ के समान कुछ का उपयोग करने में सक्षम होना बहुत अच्छा होगा ताकि दूसरे स्तर के जेट कोड के साथ चलना शुरू हो सके। प्रथम-स्तरीय को पूरी तरह से दरकिनार करने के बजाय तेजी से अग्रेषित करना।

@AndyAyersMS , क्या यह तथ्य है कि अज़ुल ने एलएलवीएम का उपयोग करके जेवीएम के लिए एक प्रबंधित जेआईटी लागू किया है, जिससे सीएलआर में एलएलवीएम को एकीकृत करना आसान हो गया है? इस प्रक्रिया में स्पष्ट रूप से परिवर्तनों को एलएलवीएम में अपस्ट्रीम में धकेल दिया गया था।

बस ठीक है, मैंने किसी विशेष कार्य के लिए कई कार्य आइटम बनाए हैं जो हमें जमीन से बाहर निकलने के लिए करने की आवश्यकता है (#12609, dotnet/coreclr#12610, dotnet/coreclr#12611, dotnet/coreclr#12612, dotnet/coreclr #12617)। यदि आपकी रुचि सीधे उनमें से किसी एक से संबंधित है, तो बेझिझक अपनी टिप्पणी उन पर जोड़ें। किसी भी अन्य विषय के लिए, मुझे लगता है कि चर्चा यहाँ रहेगी, या कोई भी किसी विशिष्ट उप-विषय के लिए एक मुद्दा बना सकता है यदि उसमें पर्याप्त रुचि हो तो इसे अपने दम पर विभाजित करने के लिए।

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

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

सीएलआर के लिए आवश्यक एलएलवीएम समर्थन में महत्वपूर्ण अंतर थे (और संभवतः अभी भी हैं) जीसी और ईएच दोनों में जावा के लिए क्या आवश्यक है, और प्रतिबंधों में एक को ऑप्टिमाइज़र पर रखना चाहिए। केवल एक उदाहरण का हवाला देते हुए: सीएलआर जीसी वर्तमान में प्रबंधित पॉइंटर्स को बर्दाश्त नहीं कर सकता है जो वस्तुओं के अंत को इंगित करते हैं। जावा इसे आधार/व्युत्पन्न युग्मित रिपोर्टिंग तंत्र के माध्यम से संभालता है। हमें या तो इस प्रकार की युग्मित रिपोर्टिंग के लिए सीएलआर में समर्थन देना होगा या एलएलवीएम के ऑप्टिमाइज़र पास को प्रतिबंधित करना होगा ताकि इस प्रकार के पॉइंटर्स कभी न बनाएं। उसके ऊपर, LLILC jit धीमा था और हमें यकीन नहीं था कि अंततः यह किस प्रकार की कोड गुणवत्ता उत्पन्न कर सकता है।

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

@AndyAyersMS हो सकता है कि आप एलएलवीएम में इसकी सीमाओं के आसपास काम करने के बजाय आवश्यक बदलाव पेश कर सकें।

क्या मल्टीकोर जेआईटी और इसका प्रोफाइल ऑप्टिमाइजेशन कोरक्लर के साथ काम करता है?

@benaadams - हाँ मल्टीकोर जेआईटी काम करता है। मुझे याद नहीं है कि कौन सा (यदि कोई है) परिदृश्य जहां यह डिफ़ॉल्ट रूप से सक्षम है, लेकिन आप इसे कॉन्फ़िगरेशन के माध्यम से चालू कर सकते हैं: https://github.com/dotnet/coreclr/blob/master/src/inc/clrconfigvalues.h# एल548

मैंने हाफ-टॉय कंपाइलर लिखा है और मैंने देखा है कि ज्यादातर समय हार्ड हिटिंग ऑप्टिमाइजेशन को उसी इंफ्रास्ट्रक्चर पर काफी ओके किया जा सकता है और हायर टियर ऑप्टिमाइज़र में बहुत कम चीजें की जा सकती हैं।

मेरा मतलब यह है: यदि कोई फ़ंक्शन कई बार हिट होता है, तो पैरामीटर इस प्रकार हैं:

• इनलाइन निर्देश संख्या बढ़ाएँ
• अधिक "उन्नत" रजिस्टर आवंटक का उपयोग करें (एलएलवीएम-जैसे बैकट्रैकिंग कलरेटर या फुल-कलराइज़र)
• अनुकूलन के अधिक पास करें, हो सकता है कि कुछ स्थानीय ज्ञान के साथ विशिष्ट हों। उदाहरण के लिए: यदि ऑब्जेक्ट को विधि में घोषित किया गया है और बड़े इनलाइन फ़ंक्शन के शरीर में असाइन नहीं किया गया है, तो पूर्ण ऑब्जेक्ट आवंटन को स्टैक आवंटन में बदलने की अनुमति दें।
• अधिकांश हिट ऑब्जेक्ट्स के लिए PIC का उपयोग करें जहाँ CHA संभव नहीं है। यहां तक ​​​​कि StringBuilder उदाहरण के लिए बहुत अधिक संभावना नहीं है, कोड को हर बार के रूप में चिह्नित किया जा सकता है क्योंकि इसे StringBuilder के साथ मारा गया था, अंदर बुलाए गए सभी तरीकों को सुरक्षित रूप से विचलित किया जा सकता है और SB की पहुंच के सामने एक टाइप-गार्ड सेट किया गया है।

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

@noahfalk , @kouvel और अन्य की कड़ी मेहनत की बदौलत अब हमारे पास टियरिंग के लिए एक ठोस आधार है।

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

क्या वर्तमान व्यवहार कहीं वर्णित है? मुझे केवल यह मिला लेकिन यह विशेष रूप से टियरिंग के बजाय कार्यान्वयन विवरण के बारे में अधिक है।

मेरा मानना ​​​​है कि हम जल्द ही किसी प्रकार का सारांश राइटअप उपलब्ध कराने जा रहे हैं, जिसमें से कुछ डेटा हमने एकत्र किया है।

COMPlus_TieredCompilation=1 सेट करके 2.1 में टियरिंग को सक्षम किया जा सकता है। यदि आप इसे आजमाते हैं, तो कृपया वापस रिपोर्ट करें कि आपको क्या मिला ....

हाल के पीआर (https://github.com/dotnet/coreclr/pull/17840, https://github.com/dotnet/sdk/pull/2201) के साथ आपके पास एक रनटाइम कॉन्फिग के रूप में स्तरीय संकलन निर्दिष्ट करने की क्षमता भी है। जेसन प्रॉपर्टी या एमएसबिल्ड प्रोजेक्ट प्रॉपर्टी। इस कार्यक्षमता का उपयोग करने के लिए आपको बहुत हाल के निर्माणों की आवश्यकता होगी जबकि पर्यावरण चर कुछ समय के लिए आसपास रहा है।

जैसा कि हमने @jkotas Tiered JIT के साथ पहले चर्चा की है, स्टार्टअप समय में सुधार कर सकता है। जब हम मूल छवियों का उपयोग करते हैं तो क्या यह काम करता है?
हमने Tizen फोन पर कई ऐप्स के लिए माप किए हैं और परिणाम हैं:

सिस्टम डीएलएल | ऐप डीएलएल | टियर | समय, एस
-----------|----------|----------|-------
R2R |R2R |नहीं |2.68
R2R |R2R |हाँ |2.61 (-3%)
R2R |नहीं |नहीं |4.40
R2R |नहीं |हाँ |3.63 (-17%)

हम एफएनवी मोड की भी जांच करेंगे, लेकिन ऐसा लगता है कि जब कोई चित्र नहीं होता है तो यह अच्छा काम करता है।

cc @gbalykov @nkaretnikov2

FYI करें, स्तरीय संकलन अब .NET कोर के लिए डिफ़ॉल्ट है: https://github.com/dotnet/coreclr/pull/19525

@alpencolt , R2R जैसे AOT संकलन का उपयोग करते समय स्टार्टअप समय में सुधार कम हो सकता है। स्टार्टअप समय में सुधार वर्तमान में कम अनुकूलन के साथ अधिक तेज़ी से झटके से आता है, और एओटी संकलन का उपयोग करते समय जेआईटी के लिए कम होगा। कुछ विधियाँ पूर्व-जेनरेट नहीं होती हैं, जैसे कुछ जेनरिक, IL स्टब्स और अन्य गतिशील विधियाँ। एओटी संकलन का उपयोग करते समय भी कुछ जेनरिक स्टार्टअप के दौरान टियरिंग से लाभान्वित हो सकते हैं।

मैं इस मुद्दे को बंद करने जा रहा हूं, क्योंकि @kouvel की प्रतिबद्धता के साथ मुझे लगता है कि शीर्षक में पूछना हासिल कर लिया है: डी लोगों का स्वागत है चर्चा जारी रखने और/या अनुरोधित सुधार जैसे अधिक विशिष्ट विषयों पर नए मुद्दों को खोलने के लिए, प्रश्न, या विशेष जांच। अगर किसी को लगता है कि यह समय से पहले बंद हो गया है तो हमें बताएं।

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

@ डैक्सियन-डीबीडब्ल्यू हां बहुत ज्यादा; रनटाइम पर जीआईटी क्रॉस-असेंबली इनलाइनिंग (डीएलएस के बीच) कर सकता है; रनटाइम स्थिरांक के आधार पर शाखा उन्मूलन ( readonly static ); आदि

@benaadams और एक अच्छी तरह से डिज़ाइन किया गया AOT कंपाइलर नहीं कर सका?

मुझे इसके बारे में कुछ जानकारी https://blogs.msdn.microsoft.com/dotnet/2018/08/02/tiered-compilation-preview-in-net-core-2-1/ पर मिली:

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

हाँ, यह "एक अच्छी तरह से डिज़ाइन नहीं किया गया AOT" का एक उदाहरण है। मैं

पूर्व-संकलित छवियों में वर्जनिंग बाधाएं और सीपीयू निर्देश बाधाएं हैं जो कुछ प्रकार के अनुकूलन को प्रतिबंधित करती हैं।

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

और एक अच्छी तरह से डिज़ाइन किया गया एओटी कंपाइलर नहीं कर सका?

एओटी कंपाइलर को लिंक-टाइम ऑप्टिमाइज़ेशन (क्रॉस-असेंबली इनलाइनिंग के लिए) और प्रोफाइल-गाइडेड ऑप्टिमाइज़ेशन (रनटाइम स्थिरांक के लिए) की आवश्यकता होती है। इस बीच, एओटी कंपाइलर को सिम कोड के लिए बिल्ड-टाइम पर "बॉटम-लाइन" हार्डवेयर जानकारी (जैसे -mavx2 gcc/clang में) की आवश्यकता होती है।

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

किसकी प्रतीक्षा? मैं यहां काफी फॉलो नहीं करता। एओटी कंपाइलर इंट्रिनिक्स को अस्वीकार क्यों करेगा?

और एक अच्छी तरह से डिज़ाइन किया गया एओटी कंपाइलर नहीं कर सका?

एओटी कंपाइलर को लिंक-टाइम ऑप्टिमाइज़ेशन (क्रॉस-असेंबली इनलाइनिंग के लिए) और प्रोफाइल-गाइडेड ऑप्टिमाइज़ेशन (रनटाइम स्थिरांक के लिए) की आवश्यकता होती है। इस बीच, एओटी कंपाइलर को सिम कोड के लिए बिल्ड-टाइम पर "बॉटम-लाइन" हार्डवेयर जानकारी (जैसे जीसीसी/क्लैंग में -mavx2) की आवश्यकता होती है।

हाँ, जैसा कि मैंने कहा, "एक अच्छी तरह से डिज़ाइन किया गया AOT कंपाइलर।" मैं

@masonwheeler अलग परिदृश्य; क्रॉसजेन एओटी है जो जीआईटी के साथ काम करता है और पूर्ण एप्लिकेशन पुनर्संयोजन और पुनर्वितरण की आवश्यकता के बिना डीएलएस की सर्विसिंग/पैचिंग की अनुमति देता है। यह Tier0 की तुलना में बेहतर कोड जनरेशन प्रदान करता है और Tier1 की तुलना में तेज़ स्टार्ट-अप के साथ; लेकिन प्लेटफॉर्म न्यूट्रल नहीं है।

Tier0, crossgen और Tier1 सभी एक साथ मिलकर coreclr . में एक साथ काम करते हैं

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

corert आवेदन की इस शैली को एओटी करेगा।

हालाँकि; कुछ प्रकार की शाखा उन्मूलन करते हैं जो कि जित कर सकता है, वैकल्पिक पथों के लिए बड़ी मात्रा में अतिरिक्त एएसएम पीढ़ी की आवश्यकता होगी; और सही पेड़ का रनटाइम पैचिंग

उदाहरण के लिए किसी विधि का उपयोग करने वाला कोई भी कोड (जहां Tier1 Jit सभी if s को हटा देगा)

readonly static _numProcs = Environment.ProcessorCount;

public void DoThing()
{
    if (_numProcs == 1) 
    {
       // Single proc path
    }
    else if (_numProcs == 2) 
    {
       // Two proc path
    }
    else
    {
       // Multi proc path
    }
}

@बेनादम्स

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

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

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

और कंपाइलर, जो स्थानीय सिस्टम पर रहता है, AOT प्रबंधित कोड को संकलित करता है...

यह पिछला एनजीएन मॉडल है जिसमें पूर्ण ढांचे का उपयोग किया गया है; हालांकि यह नहीं लगता कि इसने फ्रेमवर्क कोड को एप्लिकेशन कोड में इनलाइन करने वाली एकल असेंबली बनाई है? .NET Core 2.1 पर चलने वाले Bing.com में दो दृष्टिकोणों के बीच अंतर को उजागर किया गया था! ब्लॉग भेजा

तैयार करने के लिए छवियाँ

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

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

एओटी सबसे अच्छा काम करता है जब एओटी समय और रनटाइम के बीच बदल सकने वाली चीजों का सेट छोटा होता है और ऐसे परिवर्तनों का प्रभाव स्थानीयकृत होता है, ताकि एओटी ऑप्टिमाइज़ेशन के लिए उपलब्ध विस्तृत दायरा उन चीजों को दर्शाता है जो हमेशा सच होनी चाहिए (या शायद एक छोटी सी हो विकल्पों की संख्या)।

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

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

@AndyAyersMS मैंने कभी नहीं माना है कि .NET AOT समाधान "शुद्ध AOT-only" समाधान होना चाहिए, ठीक उन्हीं कारणों के लिए जिनका आप यहाँ वर्णन कर रहे हैं। आवश्यकतानुसार नया कोड बनाने के लिए JIT का होना बहुत महत्वपूर्ण है। लेकिन जिन स्थितियों में इसकी आवश्यकता है, वे अल्पमत में हैं, और इसलिए मुझे लगता है कि टाइप सिस्टम के लिए एंडर्स हेजल्सबर्ग के नियम को यहां लाभकारी रूप से लागू किया जा सकता है:

जहां संभव हो स्थिर, आवश्यक होने पर गतिशील।

सिस्टम से.लिंक.एक्सप्रेशन
सार्वजनिक टीडीलेगेट संकलन (बूल वरीयता व्याख्या);

क्या तरजीही संकलन काम करना जारी रखता है यदि वरीयता व्याख्या सत्य है?