Runtime: सर्वेक्षण: मूल निवासी AOT

मैं इस मुद्दे में जोड़ने के लिए सर्वोत्तम क्षेत्र लेबल का पता नहीं लगा सका। यदि आपके पास लिखने की अनुमति है तो कृपया ठीक एक क्षेत्र लेबल जोड़कर मुझे सीखने में मदद करें।

टाइपो की तरह दिखता है - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) शायद यह "इसका एक हिस्सा" होना चाहिए?

मैं इस मुद्दे को देखकर बहुत खुश हूँ! मैं

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

@ सर्जियो0694 यूडब्ल्यूपी प्रश्न के लिए धन्यवाद। मैं सहमत हूं, मुझे लगता है कि यह उल्लेख करना समझ में आता है कि यदि आपने ओपन सोर्स संस्करण का उपयोग किया था तो नोट्स और उपयोग कोरर्ट का उत्तर दें।

इस सर्वेक्षण को पोस्ट करने के लिए धन्यवाद!

मैं इस बात को लेकर भी असमंजस में था कि यूडब्ल्यूपी देव के रूप में कुछ सवालों के जवाब कैसे दूं, जिन्होंने केवल .NET नेटिव का इस्तेमाल किया है। UWP के .NET नेटिव टूलचेन के बारे में मेरी कई राय है लेकिन मुझे वास्तव में उन्हें लिखने के लिए जगह नहीं दिखी। पूरी तरह से ठीक है अगर यह इस सर्वेक्षण के दायरे से बाहर है लेकिन यह स्पष्ट करने लायक हो सकता है।

मुझे यह भी संदेह है "क्योंकि .NET नेटिव यूडब्ल्यूपी रिलीज बिल्ड के लिए डिफ़ॉल्ट है और स्टोर में आवश्यक है" शायद सबसे आम कारण है कि लोग एओटी का उपयोग क्यों करते हैं लेकिन यह प्रश्न 5 के लिए पूर्व-आबादी वाले उत्तरों में से एक नहीं है।

जीयूआई विकल्पों में एवलोनिया को शामिल करने के लिए धन्यवाद :) हमने पहले कोरआरटी ​​+ एवलोनिया के साथ प्रयोग किया है और परिणाम बहुत खूबसूरत देशी जीयूआई ऐप्स थे: डी हालांकि हमने 2 साल हो जाने के बाद से कंपैट बनाए रखा है ...

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

प्रकाशित अनुप्रयोगों को अनुकूलित करने के लिए मौजूदा विकल्प उन अधिकांश परिदृश्यों के लिए अच्छी तरह से काम करते हैं जिन्हें .NET आज लक्षित करता है।

...

एओटी ज्यादातर जीयूआई ऐप्स में मायने रखता है। वहीं इस पर फोकस करने की जरूरत है। मुझे वेबएप, सेवाओं आदि की आवश्यकता नहीं दिख रही है

मैं असहमत हूं। सर्वश्रेष्ठ अंतिम उपयोगकर्ता UX के लिए, गेम इंजन , सर्वर रहित माइक्रोसर्विसेज , डेस्कटॉप GUI एप्लिकेशन , iOS और Android एप्लिकेशन, WASM आधारित क्लाइंट साइड SPA/लाइब्रेरी और बुनियादी CLI टूल (~ कुछ MB) के लिए AOT w/स्टैटिक लिंकिंग की आवश्यकता होती है।

मैंने कामना की है कि पिछले कुछ वर्षों में सी# में उपरोक्त सभी परिदृश्यों को आजमाते हुए मैं आसानी से एओटी अपना कोड संकलित कर सकूं और मुझे लगता है कि एलएलवीएम आधारित भाषाओं जैसे रस्ट की तुलना में .NET भारी रूप से गायब है।

वर्तमान प्रकाशन विकल्प "अच्छी तरह से काम करते हैं" दिखाई देने का कारण यह है कि .NET ऐतिहासिक रूप से उपरोक्त परिदृश्यों के लिए उपयुक्त नहीं रहा है और लोग C# का उपयोग करते समय अपने स्वयं के AOT (जैसे: Unity, UWP, Mono) को लागू करते हैं। आंशिक AOT समाधान जैसे मूल छवि के रूप में (उदाहरण के लिए, रेडीटॉरन) मोनोलिथिक सर्वर अनुप्रयोगों या बड़े डेस्कटॉप क्लाइंट अनुप्रयोगों के लिए कोल्ड स्टार्ट परिदृश्यों में "मदद" कर सकता है लेकिन बाइनरी आकार अभी भी एक पूर्ण एओटी रनटाइम की तुलना में कई गुना बड़ा है।

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

असली मुद्दा यह है कि वर्तमान में बहुत सारे रनटाइम/कोड जेनरेटर/टूलचेन/प्रयोग अपने स्वयं के क्विर्क के साथ उपलब्ध हैं: IL2CPP/बर्स्ट (यूनिटी), मोनो का एओटी बैकएंड (ज़ामरीन/ब्लेज़र/यूनो), .NET नेटिव/कोरआरटी ​​(यूडब्ल्यूपी), मोनो का LLVM बैकएंड, CrossGen/ReadyToRun (.NET Core), आदि। और यह केवल अस्वीकार्य है कि .NET में मानकीकृत AOT संकलन टूलचेन नहीं है।

यदि इन सभी टीमों ने अपने इंजीनियरिंग प्रयासों को कोरआरटी, मोनो एलएलवीएम बैकएंड या अब छोड़े गए डॉटनेट/लिलिक जैसे कुछ सामान्य पर संयुक्त किया होता तो एओटी .NET डेवलपर्स के लिए एक बेहतर अनुभव होता।

AOT w/स्थैतिक लिंकिंग अब बड़ी संख्या में डेवलपर्स के लिए सुलभ है, जिसमें जनता के लिए CI/CD है और यह अब केवल प्रदर्शन में मामूली वृद्धि के लिए एक झुंझलाहट नहीं है।

सी # एंडगेम: नेटिव कोड, नेटिव यूआई, तेज और आसान इंटरऑप, नेटिव एक्सपोर्ट और परफॉर्मेंस ओरिएंटेड एपीआई (जैसे, System.IO.Pipelines, System.Text.Json)।

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

मैंने सर्वेक्षण का उत्तर दे दिया है, लेकिन ईमानदारी से कहूं तो .NET Core 1.0 के शुरू होने के बाद से मुझे लगातार सर्वेक्षण नहीं मिलते हैं, बिना किसी स्पष्ट दिशा के जहां चीजें जा रही हैं।

.NET नेटिव वही है जो .NET को साथ में होना चाहिए था, जब एक्सट-वीओएस प्रोजेक्ट शुरू हुआ था, और सिंगुलैरिटी और मिडोरी का अनुभव है कि आप लोग निश्चित रूप से संबंधित हो सकते हैं, या उनके साथ कुछ आंतरिक सर्वर भी प्राप्त कर सकते हैं।

यहां तक ​​​​कि जावा ने अपनी लापता एओटी क्षमताओं को पकड़ने का फैसला किया है, टीम यह नहीं पूछ रही है कि हम किस कार्यभार को काम करना चाहते हैं।

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

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

मैं चाहता हूं कि .NET लगातार फलता-फूलता रहे और परिदृश्य की परवाह किए बिना पहला विकल्प हो, और अगर कुछ भी वर्कफ़्लो को संभालने के लिए है जहाँ Microsoft अभी भी हमें .NET के साथ C++ का उपयोग करने के लिए मजबूर करता है, जो अन्य AOT संकलित भाषाओं के साथ समस्या नहीं है।

मैंने सर्वेक्षण का उत्तर दे दिया है, लेकिन ईमानदारी से कहूं तो .NET Core 1.0 के शुरू होने के बाद से मुझे लगातार सर्वेक्षण नहीं मिलते हैं, बिना किसी स्पष्ट दिशा के जहां चीजें जा रही हैं।

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

@jkotas मैंने देखा कि इस सर्वेक्षण के लिए दो अलग-अलग लिंक फैल रहे हैं, क्या यह ठीक है?
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce उन साथी देवों से पूछें जिन्होंने क्रॉस प्लेटफॉर्म जीयूआई, डब्ल्यूसीएफ और ईएफ टूलिंग समर्थन के संबंध में समान सर्वेक्षणों का उत्तर दिया है, इससे कितनी मदद मिली है।

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

मेरे लिए एकमात्र स्वीकार्य एओटी समाधान है जब यह रिलीज मोड में बिना किसी जेआईटी के एक वास्तविक मूल एप्लिकेशन उत्पन्न करता है (कोई साइड-बाय-साइड समाधान उपनाम तैयार-टू-रन नहीं) और जब यह सभी पर काम करता है .NET प्रोजेक्ट डेवलपर्स काम कर रहे हैं पर। इसमें विशेष रूप से विनफॉर्म और डब्ल्यूपीएफ शामिल हैं। सबसे अच्छी स्थिति में इसे बिना किसी रनटाइम निर्भरता के बिना 3mb से 80mb तक खुद को फूलाए बिना स्टैंडअलोन काम करना चाहिए।

तकनीकी कारणों से ऐसे मामले हो सकते हैं/एपिस एओटी समर्थन नहीं कर सकता। "सभी पर" कहने का अर्थ है सभी एपीआई का समर्थन नहीं करना, लेकिन सभी प्रकार के प्रोजेक्ट .NET कोर का समर्थन करता है: dll / winforms / wpf / winui / कंसोल / माउ / ... .NET फ्रेमवर्क से .NET कोर में बदलने के समान कुछ जो सबसे अधिक अनुमति देता है मेरे मन में यही है कि डेवलपर्स अपने मौजूदा एप्लिकेशन को अपने हाथ में लें।

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

मैं हमेशा प्रतिबिंब के साथ मुद्दों को बहुत कुछ देखता हूं, और मेरा मानना ​​​​है कि वास्तव में इससे कोई फर्क नहीं पड़ता कि एएसपीनेट कोर एक बड़ा निष्पादन योग्य बनाता है।

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

मैं हमेशा प्रतिबिंब के साथ मुद्दों को बहुत कुछ देखता हूं, और मेरा मानना ​​​​है कि वास्तव में इससे कोई फर्क नहीं पड़ता कि एएसपीनेट कोर एक बड़ा निष्पादन योग्य बनाता है।

Blazor WebAssembly की रिलीज के साथ मुझे लगता है कि निष्पादन योग्य आकार और निष्पादन की गति भी बहुत मायने रखती है और यह एओटी से काफी लाभ उठा सकती है। लेकिन किसी भी कारण से इसका विशेष रूप से सर्वेक्षण में उल्लेख भी नहीं किया गया था।

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

@jkotas मैंने देखा कि इस सर्वेक्षण के लिए दो अलग-अलग लिंक फैल रहे हैं, क्या यह ठीक है?

हां, हम अलग-अलग पोस्ट के लिए अलग-अलग सर्वेमोनकी लिंक का इस्तेमाल करते हैं। सभी लिंक एक ही सर्वेक्षण की ओर इशारा करते हैं। यह हमें यह देखने की अनुमति देता है कि लोगों को सर्वेक्षण कहां मिला, इसके आधार पर प्रतिक्रियाओं का वितरण कैसे भिन्न होता है।

gamedev के लिए हमें इसकी आवश्यकता है, मैंने अपने गेम इंजन https://github.com/amerkoleci/alimer_sharp पर c++ का उपयोग करके देशी इंजन के पक्ष में काम करना निलंबित कर दिया है, मैं DirectX ans vulkan के लिए भी बाइंडिंग बनाए रखता हूं, यहां प्रदर्शन की आवश्यकता है

gamedev के लिए हमें इसकी आवश्यकता है, मैंने अपने गेम इंजन https://github.com/amerkoleci/alimer_sharp पर c++ का उपयोग करके देशी इंजन के पक्ष में काम करना निलंबित कर दिया है, मैं DirectX ans vulkan के लिए भी बाइंडिंग बनाए रखता हूं, यहां प्रदर्शन की आवश्यकता है

यहां समान परिदृश्य 😄, सिवाय इसके कि मैंने इसे निलंबित नहीं किया। मुझे बेहतर स्टार्टअप समय के लिए एओटी पसंद है, लेकिन (और मेरे मामले में, अधिक महत्वपूर्ण बात), अधिक अनुकूलित कोड रखने का अवसर - मैं 10% स्पीडअप के लिए बिल्ड समय में 50% की वृद्धि के साथ ठीक हूं, जो स्पष्ट रूप से है ' टी वास्तव में एक JIT . का रवैया

मैं 10% स्पीडअप के लिए निर्माण समय में 50% की वृद्धि के साथ ठीक हूं, जो स्पष्ट रूप से वास्तव में एक जेआईटी का रवैया नहीं है

यह वास्तव में एक बड़े माध्यमिक कारणों में से एक है जो मैं एक अलग पारिस्थितिकी तंत्र में स्विच करने के बजाय .NET में एओटी चाहता हूं। मैं बड़ी सी ++ या जंग परियोजनाओं की तुलना में बड़ी .NET परियोजनाओं के तेज़ संकलन समय से पूरी तरह से खराब हो गया हूं।

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

मैंने कोरआरटी ​​क्रिएट क्रॉस प्लेटफॉर्म (और क्रॉस प्लेटफॉर्म) नेटिव लाइब्रेरी का इस्तेमाल किया था।

आईओएस और कंसोल प्लेटफॉर्म में गेम इंजन के लिए एओटी डब्ल्यू/स्टैटिक लिंकिंग की तत्काल आवश्यकता है जो जीआईटी को अक्षम करता है, और कई एओटी संकलन मोड भी चाहता है:

1. पूर्ण एओटी
2. हाइब्रिड एओटी जो जीआईटी + एओटी या दुभाषिया + एओटी रन मोड का समर्थन करता है
   खेल उद्योग के लिए वास्तव में महत्वपूर्ण है हाइब्रिड एओटी, यह गेम चेंजर हो सकता है

आईओएस और कंसोल प्लेटफॉर्म में गेम इंजन के लिए एओटी डब्ल्यू/स्टैटिक लिंकिंग की तत्काल आवश्यकता है जो जीआईटी को अक्षम करता है, और कई एओटी संकलन मोड भी चाहता है:

1. पूर्ण एओटी
2. हाइब्रिड एओटी जो जीआईटी + एओटी या दुभाषिया + एओटी रन मोड का समर्थन करता है
   खेल उद्योग के लिए वास्तव में महत्वपूर्ण है हाइब्रिड एओटी, यह गेम चेंजर हो सकता है

जैसे आईओएस प्लेटफॉर्म पर मोनो, एओटी+इंटरप्रेटर रन मोड।

पूर्ण एओटी, सिंगल एक्सई, स्वतंत्र रनटाइम और अनावश्यक कोड क्लिपिंग यह निश्चित रूप से मुझे क्रेयगैसम एक्सडी बनाता है

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

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

हम उच्च प्रदर्शन, उच्च मापनीयता वाले वित्तीय/वैज्ञानिक सिमुलेटर विकसित करते हैं। उपयोगकर्ता द्वारा बनाए गए मॉडल की जटिलता के आधार पर हमारे सिमुलेशन कुछ मिनटों से लेकर कई दिनों तक कहीं भी चल सकते हैं।

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

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

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

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

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

सामान्य तौर पर, मैं जेआईटी और एओटी दोनों प्रौद्योगिकियों में अधिक निवेश देखना पसंद करूंगा।

cc @AndyAyersMS

आईओएस और कंसोल प्लेटफॉर्म में गेम इंजन के लिए एओटी डब्ल्यू/स्टेटिक लिंकिंग की तत्काल आवश्यकता है जो जीआईटी को अक्षम करता है,

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

इसलिए हम 3 पॉपलर गेम कंसोल (XBox One; PlayStation 4 और Nintendo स्विच) पर CoreRT को चलाने पर विचार कर रहे हैं। अवधारणा का एक प्रारंभिक प्रोफेसर दिखाता है कि यह वास्तव में काम करता है (अभी भी कुछ सीमाओं के साथ) लेकिन मोनो आधारित समाधान की तुलना में पहले से ही एक महत्वपूर्ण रन टाइम प्रदर्शन सुधार के साथ।

लेकिन गेम कंसोल के आसपास एनडीए की स्थिति के साथ इस उपयोग के कारण के लिए आधिकारिक समर्थन आधिकारिक मूल एओटी को पहले स्थान पर प्राप्त करने से कहीं अधिक दूर है।

हमारे लिए, जेआईटी प्रदर्शन के साथ थोड़ा नाजुक (यहां तक ​​कि कम नियतात्मक) बन गया है, क्योंकि हमारा कोड आधार विकास के साथ बदलता है।

@ jpapp05 मुझे आपके ऐप के बारे में और विशेष रूप से उपरोक्त मुद्दे के बारे में और अधिक सुनना अच्छा लगेगा, क्योंकि यह मेरी प्रमुख चिंताओं में से एक है। बेझिझक मुझसे ऑफ़लाइन संपर्क करें (प्रोफ़ाइल में ईमेल के माध्यम से) अगर इससे मदद मिलती है।

हाय @AndyAyersMS , यह बहुत अच्छा होगा। मैं आपसे ऑफ़लाइन संपर्क करूंगा क्योंकि मैं थोड़ी अधिक स्वतंत्र रूप से बात कर सकता हूं लेकिन मुझे दूसरों के लाभ के लिए हमारी चर्चाओं से कोई सारांश वापस पोस्ट करने में खुशी हो रही है।

मुझे नहीं पता कि यह एक समस्या भी है या नहीं, लेकिन यहाँ सिर्फ इसका उल्लेख करना है।
हमारे लिए एक महत्वपूर्ण विशेषता रनटाइम पर देशी असेंबलियों को अनलोड अनलोड करने की क्षमता होगी।

@movedoa NativeLibrary एपीआई देखें https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=netcore-3.1

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

शायद जीवन को आसान बनाने के लिए, एक चेकबॉक्स लगाएं जो कहता है:
मूल संकलन (केवल विंडोज़ 10 डेस्कटॉप के लिए काम करता है!)
यार, वह करो और मुझे अब एओटी की परवाह नहीं है। अगर यह ASP.NET कोर के लिए काम करता है, तो बढ़िया! यदि नहीं, तो मुझे वास्तव में परवाह नहीं है।

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

हर कोई याद नहीं रखता (या जानता है) कि .NET कोड को आसानी से विघटित किया जा सकता है

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

@jcbeppler आप गलत हैं, यह बाइटकोड बनाम देशी की एक आम गलतफहमी है, यह सिर्फ सही उपकरण होने की बात है।

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

हेक्स-रे सिर्फ एक संभावित समाधान है, चुनने के लिए अन्य हैं।

@MostHated हाँ, मुझे मिल गया। वास्तव में .NET में एक सॉफ्टवेयर को डीकंपाइल करना इतना आसान है कि यह ओपन सोर्स जैसा है और कई कंपनियां नहीं चाहती कि उनका सॉफ्टवेयर ओपन सोर्स हो। "मुफ्त लंच जैसी कोई चीज नहीं होती"

@pjmlp मुझे डिकंपाइल बनाम डिस्सेप्लर के बीच का अंतर पता है। मैं अपने सॉफ़्टवेयर को अलग करने के खिलाफ कुछ नहीं कर सकता लेकिन मूल संकलन सॉफ़्टवेयर को और अधिक सुरक्षित बना सकता है क्योंकि व्यक्ति बहुत ही सरल अपघटन नहीं कर सकता है। एक अलग किया गया सॉफ़्टवेयर निश्चित रूप से अजीब लगेगा और अलग किया गया कोड सही ढंग से भी नहीं चल सकता है।

@jcbeppler आप गलत हैं, यह बाइटकोड बनाम देशी की एक आम गलतफहमी है, यह सिर्फ सही उपकरण होने की बात है।

वर्तमान में एक .NET प्रोग्राम विघटित हो गया है जो पूरे स्रोत कोड को प्रकट करता है। इसमें सभी विधि नाम और चर नाम भी शामिल हैं। यह डिबगिंग के लिए अच्छा है और अपवाद होने पर हमें "पठनीय" स्टैकट्रेस रखने की अनुमति देता है। हालाँकि यह एक बहुत बड़ी सुरक्षा खामी है और एक कारण है कि .NET ऑबफस्केटर्स के लिए एक बड़ा बाजार है।

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

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

मैं इस सर्वेक्षण के परिणाम को लेकर उत्सुक हूं। क्या लोगों ने मतदान कैसे किया, इस पर उन्हें सार्वजनिक करने की कोई योजना है?

@Symbai यह किसी भी चीज़ से सुरक्षा नहीं है, जैसा कि कोई भी Android डेवलपर जिसने NDK को अपने IP की सुरक्षा के साधन के रूप में उपयोग करने का प्रयास किया है, आपको बताएगा। जिन एप्लिकेशन का आप संक्षेप में उल्लेख करते हैं, वे सिंगल क्लिक के साथ भी ऐसा ही कर सकते हैं, और भले ही वे आमतौर पर सी या सी ++ कोड को मूल स्रोत कोड के रूप में मानते हैं, वे आपके एल्गोरिदम को चुराने के लिए पर्याप्त हैं।

मैं एओटी चाहता हूं, ऐसे परिदृश्यों के लिए जहां .NET जंग, गो, स्विफ्ट, सी ++, जावा (ग्रालवीएम), डेस्कटॉप, कंसोल, और मोबाइल/आईओटी अनुप्रयोगों के खिलाफ दीर्घकालिक खो देगा जहां स्टार्टअप समय वास्तव में महत्वपूर्ण है, स्मृति उपयोग पर उच्च बाधाएं हैं और असेंबली लोड पर JIT के कारण गति में कमी सहनीय नहीं है, जैसे कुछ ASP.NET परिदृश्यों पर AOT कोड प्रासंगिक हो सकता है जब कोई अपने 100 K8S पॉड इंस्टेंस को स्केल कर रहा हो।

दूसरी तरफ, मैं जेआईटी क्षमताओं को बनाए रखने के लिए प्रासंगिक हूं, और उन परिदृश्यों में भी सुधार करता हूं जहां जेआईटी जाने का रास्ता है।

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

@Symbai यह किसी भी चीज़ से सुरक्षा नहीं है, जैसा कि कोई भी Android डेवलपर जिसने NDK को अपने IP की सुरक्षा के साधन के रूप में उपयोग करने का प्रयास किया है, आपको बताएगा। जिन एप्लिकेशन का आप संक्षेप में उल्लेख करते हैं, वे सिंगल क्लिक के साथ भी ऐसा ही कर सकते हैं, और भले ही वे आमतौर पर सी या सी ++ कोड को मूल स्रोत कोड के रूप में मानते हैं, वे आपके एल्गोरिदम को चुराने के लिए पर्याप्त हैं।

एक एल्गोरिदम चोरी करना जिसके साथ मैं रह सकता हूं, लेकिन वह नहीं जो .NET आज अनुमति देता है (उदाहरण के लिए डब्ल्यूपीएफ), जहां एक व्यक्ति के पास वीएस प्रोजेक्ट के रूप में चलाने के लिए आपका पूरा आवेदन खूबसूरती से और आसानी से तैयार है। मुझे लगता है कि मूल संकलन के साथ UWP अच्छा काम करता है, अगर कोई इसे अलग करना चाहता है, तो ठीक है, शुभकामनाएँ! मैं हमेशा नेटिव कंपाइलेशन का इस्तेमाल करूंगा, चाहे कुछ भी हो। Android दुनिया के बारे में मैं बात नहीं कर सकता, एक बार Xamarin फॉर्म के साथ AOT की कोशिश की और यह वास्तव में मेरी अपेक्षा के अनुरूप काम नहीं किया।

मुझे लगता है कि मूल संकलन के साथ UWP अच्छा काम करता है, अगर कोई इसे अलग करना चाहता है, तो ठीक है, शुभकामनाएँ! मैं हमेशा नेटिव कंपाइलेशन का इस्तेमाल करूंगा, चाहे कुछ भी हो। Android दुनिया के बारे में मैं बात नहीं कर सकता, एक बार Xamarin फॉर्म के साथ AOT की कोशिश की और यह वास्तव में मेरी अपेक्षा के अनुरूप काम नहीं किया।

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

अगर मैं कोई किताब लिखता हूं, तो उसे प्रकाशित करने से पहले किसी से उसका जापानी में अनुवाद करवाएं - मुझे लगता है कि मैं वास्तव में चतुर हूं, क्योंकि मैं जापानी नहीं समझता, और न ही मेरा कोई दोस्त। वास्तविकता यह है कि, वहाँ पूरे देश हैं जो उस पुस्तक को पढ़ सकते हैं - और अगर मैं अन्यथा दिखावा करता हूँ तो मैं खुद को बेवकूफ बनाने के अलावा और कुछ नहीं कर रहा हूँ।

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

यह मुझे, शून्य पूर्व अनुभव वाला कोई व्यक्ति, कुछ भी नहीं जाने के लिए दो सप्ताह, एक ऐसा प्रोग्राम रखने के लिए जो न केवल उनकी एन्क्रिप्टेड डेटा फ़ाइलों को डिक्रिप्ट कर सकता है, बल्कि उनके स्वामित्व डेटा प्रारूपों को एक्सएमएल/जेएसओएन में भी परिवर्तित कर सकता है।

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

एक ऐसा प्रोग्राम रखने के लिए जो न केवल उनकी एन्क्रिप्टेड डेटा फ़ाइलों को डिक्रिप्ट कर सकता है

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

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

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

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

मैं वास्तव में .NET टीम का शुक्रगुजार हूं कि हमें "सुरक्षा" चुनने के लिए एक कारण के रूप में हम AOT ❤ चाहते हैं। यह दर्शाता है कि वे कुछ लोगों की ज़रूरतों से अवगत हैं। और अगर चुनावों से पता चलता है कि आदमी इसके लिए वोट करता है, तो हमारे पास आखिरकार एक मौका हो सकता है कि एओटी कार्यान्वयन सी ++ कंपाइलर की तरह ही इस पर ध्यान देगा। एफवाईआई: एओटी वास्तव में कितनी सुरक्षा है, इस बारे में और चर्चा से बचने के लिए मैंने इसे उद्धरणों में रखा है, इस पर विचारों की बात बहुत व्यापक है, जैसा कि हमने पहले ही देखा होगा।

सुरक्षा सभी या कुछ भी नहीं है। आईएल को हटाने से एक निर्धारित हमलावर को किसी एप्लिकेशन को उलटने से नहीं रोकता है। लेकिन यह बाधाएं पैदा करता है जो व्यावहारिक अर्थों में प्रासंगिक हैं। यह गहराई से रक्षा है। यही कारण है कि IL obfuscation उत्पादों का उपयोग करना तर्कसंगत हो सकता है।

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

@ सिंबाई

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

हेक्स-रे सी के लिए अच्छा काम करता है, और इसमें निर्णय प्रक्रिया में मदद करने के लिए मैक्रोज़ हैं।

सी स्रोत होने के कारण यह बच्चों को सी ++ या डेल्फी में बदलने के लिए खेलता है।

साथ ही अब हमारे पास उन लोगों की मदद करने के लिए एआई है जो पर्याप्त कुशल नहीं हैं।

स्ट्रिप्ड बायनेरिज़ की तंत्रिका रिवर्स इंजीनियरिंग

हेक्स-रे सी के लिए अच्छा काम करता है, और इसमें निर्णय प्रक्रिया में मदद करने के लिए मैक्रोज़ हैं।

क्या आप हेक्स-रे के लिए काम करते हैं या किसी ऐसी कंपनी के लिए काम करते हैं जो ओफ़्फ़ुसेशन सॉफ़्टवेयर बेचती है? यह लगता है कि।

वैसे भी, भले ही आप इसे C में बदल दें, कोड एक अच्छे C# आर्किटेक्चर से बहुत दूर होगा। यहां तक ​​​​कि अगर आपको कोड के टुकड़े मिलते हैं, तो आपको इसे बदलने, सुधारने, आदि के लिए अच्छी मात्रा में प्रयास करना होगा ....
यदि आपके लिए मूल संकलन अप्रासंगिक है, तो ठीक है। लेकिन कई लोगों के लिए यह प्रासंगिक है।

BTW: आप JIT संकलन को ध्यान में रखते हुए बहुत रुचि रखते हैं और साथ ही आपको सॉफ़्टवेयर को अलग करने का बहुत अनुभव है। मैं सोच रहा हूं कि आपको इसका इस्तेमाल क्यों और कहां करना पड़ा?!

भले ही आप में से कोई भी आईएल बनाम मशीन कोड के अपघटन की आसानी के बारे में कैसा महसूस करता हो, यह इस तथ्य को नहीं बदलता है कि यह वास्तविक व्यवसायों में एक वास्तविक आवश्यकता है। (और हम इस बारे में बहस कर सकते हैं कि गायों के घर आने तक यह आवश्यकता कितनी वैध या अमान्य हो सकती है।)

मेरे पिछले नियोक्ता ने स्पष्ट रूप से इस कारण से .NET या JVM टूल को बाहरी रूप से शिपिंग करने से मना किया था। मेरे जाने से ठीक पहले एक टीम ने उच्च अधिकारियों को आश्वस्त किया कि उन्हें भारी ओफ़्फ़ुसेशन के साथ एक उपकरण शिप करने दिया जाए, लेकिन अन्यथा हम कॉर्पोरेट नीति को संतुष्ट करने के लिए C++ में बाहरी उपकरण लिख रहे थे।

यह चर्चा पटरी से उतर गई है। यदि आप सभी चाहते हैं कि एओटी आईपी सुरक्षा के लिए प्रासंगिक है या नहीं, तो कृपया इसे कहीं और करें।

हेक्स-रे सी के लिए अच्छा काम करता है, और इसमें निर्णय प्रक्रिया में मदद करने के लिए मैक्रोज़ हैं।

क्या आप हेक्स-रे के लिए काम करते हैं या किसी ऐसी कंपनी के लिए काम करते हैं जो ओफ़्फ़ुसेशन सॉफ़्टवेयर बेचती है? यह लगता है कि।

वैसे भी, भले ही आप इसे C में बदल दें, कोड एक अच्छे C# आर्किटेक्चर से बहुत दूर होगा। यहां तक ​​​​कि अगर आपको कोड के टुकड़े मिलते हैं, तो आपको इसे बदलने, सुधारने, आदि के लिए अच्छी मात्रा में प्रयास करना होगा ....
यदि आपके लिए मूल संकलन अप्रासंगिक है, तो ठीक है। लेकिन कई लोगों के लिए यह प्रासंगिक है।

BTW: आप JIT संकलन को ध्यान में रखते हुए बहुत रुचि रखते हैं और साथ ही आपको सॉफ़्टवेयर को अलग करने का बहुत अनुभव है। मैं सोच रहा हूं कि आपको इसका इस्तेमाल क्यों और कहां करना पड़ा?!

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

संपादित करें: मेरी टिप्पणियों को भी रोक रहा है। बस व्यक्तिगत हमले का जवाब देना चाहता था।

क्लाउड नेटिव और डब्ल्यूपीएफ एओटी होना चाहिए।
विंडोज क्लाइंट कोई रनटाइम नहीं! कोई JIT . नहीं

सर्वेक्षण के परिणाम पोस्ट किए गए हैं - https://github.com/dotnet/runtime/issues/41522। अब हम उन लोगों से संपर्क करने की प्रक्रिया में हैं जिन्होंने अपनी संपर्क जानकारी प्रदान की और कुछ अतिरिक्त अनुवर्ती प्रश्न हैं।

आईओएस और कंसोल प्लेटफॉर्म में गेम इंजन के लिए एओटी डब्ल्यू/स्टेटिक लिंकिंग की तत्काल आवश्यकता है जो जीआईटी को अक्षम करता है,

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

इसलिए हम 3 पॉपलर गेम कंसोल (XBox One; PlayStation 4 और Nintendo स्विच) पर CoreRT को चलाने पर विचार कर रहे हैं। अवधारणा का एक प्रारंभिक प्रोफेसर दिखाता है कि यह वास्तव में काम करता है (अभी भी कुछ सीमाओं के साथ) लेकिन मोनो आधारित समाधान की तुलना में पहले से ही एक महत्वपूर्ण रन टाइम प्रदर्शन सुधार के साथ।

लेकिन गेम कंसोल के आसपास एनडीए की स्थिति के साथ इस उपयोग के कारण के लिए आधिकारिक समर्थन आधिकारिक मूल एओटी को पहले स्थान पर प्राप्त करने से कहीं अधिक दूर है।

@RalfKornmannEnvision क्या आप LLVM कोडजन के साथ Xamarin Xbox One/PS4 मोनो पोर्ट का उपयोग कर रहे हैं?

@RalfKornmannEnvision क्या आप LLVM कोडजन के साथ Xamarin Xbox One/PS4 मोनो पोर्ट का उपयोग कर रहे हैं?

@lateralusX जैसा कि एकीकरण किसी और द्वारा किया गया था, मुझे कोई विवरण नहीं पता है। लेकिन जहां तक ​​मुझे पता है उन्होंने मोनो पोर्ट का इस्तेमाल किया जो कि XBox One/PS4 के लिए दिए गए हैं और स्विच के लिए एक साधारण पोर्ट बनाया है। खुद।

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

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

अपनी जांच के हिस्से के रूप में मैं Xamarin Android का उपयोग करके मुख्य घटक के साथ एक बेंचमार्क बनाता हूं और इसे टेग्रा X1 आधारित डिवाइस पर चलाता हूं यह देखने के लिए कि क्या हमने मोनो के हमारे कस्टम स्विच पोर्ट के साथ किसी समस्या के कारण प्रदर्शन खो दिया है। दुर्भाग्य से ज़ामरीन परियोजना का प्रदर्शन स्विच पर हमने जो देखा है उससे अलग नहीं था।

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

@RalfKornmannEnvision ठीक है, आपकी जानकारी और प्रतिक्रिया के लिए धन्यवाद, सभी बहुत मूल्यवान हैं।