.NET कोड संकलन या जटिलता?

Question

क्यू 1) सी # प्रारंभ में आईएल के लिए क्यों संकलित किया गया है और फिर रनटाइम पर जेआईटी ने वर्चुअल मशीन (?) के शीर्ष पर अनुपालन किया और चलाया। या क्या यह जेआईटी देशी मशीन कोड का पालन करता है?

क्यू 2) यदि दूसरा सत्य है (जेआईटी मूल मशीन कोड का पालन करता है), तो कोड .NET सैंडबॉक्स कहां चलता है?

क्यू 3) इसके अतिरिक्त, आईएल को पहले स्थान पर संकलित कोड क्यों है। क्यों न केवल देशी मशीन कोड को संकलित क्यों करें? एमएस से एनजेन नामक एक उपकरण है लेकिन यह वैकल्पिक क्यों है?

Answer 1

आईएल जेआईटीएड (जेआईटी = जस्ट इन टाइम) है, जो प्रक्रिया के चलते मूल मशीन कोड में संकलित है।

वर्चुअल मशीन परत का उपयोग .NET को प्लेटफॉर्म पर निरंतर तरीके से व्यवहार करने की अनुमति देता है (उदाहरण के लिए एक इंट 32 बिट या 64-बिट मशीन पर चल रहे हैं चाहे यह 32 बिट्स हो, यह नहीं है सी ++ के साथ मामला)।

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

Answer 2

1. सी # सीआईएल (या आईएल), क्योंकि यह नेट भाषाओं के बाकी के साथ एक मंच साझा करता है (जो कारण है कि आप सी # में एक DLL लिखने और VB.NET में उपयोग कर सकते हैं या करने के लिए संकलित किया गया है परेशानी के बिना एफ #)। CLR तब जेआईटी कोड को मूल मशीन कोड में संकलित करेगा।

.NET कई प्लेटफार्मों पर भी चलाया जा सकता है (मोनो ऑन * एनआईक्स और ओएस एक्स)। यदि सी # देशी कोड में संकलित है, तो यह लगभग उतना आसान नहीं होगा।

2. कोई सैंडबॉक्स नहीं है।

3. # 1

Answer 3

A1) इस तरह यह है के जवाब में कवर मंच नास्तिक (विंडोज, लिनक्स, मैक) और यह भी आपके वर्तमान हार्डवेयर के लिए विशिष्ट अनुकूलन का उपयोग कर सकते हैं। जब यह जेआईटी संकलित हो जाता है तो यह मशीन कोड के लिए होता है।

ए 2) संपूर्ण ढांचा (.NET ढांचा) सभी सैंडबॉक्स है, इसलिए आप अपने ऐप के माध्यम से जो भी कॉल कर सकते हैं, वह .NET फ्रेमवर्क सैंडबॉक्स के माध्यम से जाएगा।

ए 3) उत्तर 1 में, यह .NET बाइनरी को विभिन्न प्लेटफार्मों में काम करने और फ्लाई पर क्लाइंट मशीन में विशिष्ट अनुकूलन करने की अनुमति देता है।

Answer 4

आप अपने .NET असेंबली के मूल संस्करण बनाने के लिए NGEN का उपयोग कर सकते हैं। ऐसा करने का मतलब है कि जेआईटी को रनटाइम पर ऐसा करने की ज़रूरत नहीं है।

.NET को पहले आईएल में संकलित किया गया है और उसके बाद देशी है क्योंकि जेआईटी को मौजूदा सीपीयू के लिए आईएल कोड अनुकूलित करने के लिए डिज़ाइन किया गया था, कोड कोड चल रहा है।

.NET कोड को compatability के लिए आईएल में संकलित किया गया है। चूंकि आप सी #, वीबीएनईटी आदि का उपयोग करके कोड बना सकते हैं, इसलिए देशी कोड को संकलित करने के लिए जेआईटी को एक सामान्य निर्देश सेट (आईएल) की आवश्यकता होती है। यदि जेआईटी को भाषाओं के बारे में पता होना चाहिए, तो एक नई .NET भाषा जारी होने पर जेआईटी को अद्यतन करने की आवश्यकता होगी।

मुझे सैंडबॉक्स प्रश्न के बारे में निश्चित नहीं है, मेरा सबसे अच्छा अनुमान यह है कि एक .NET ऐप 3 एप्लिकेशन डोमेन के साथ चलता है।एक डोमेन में .NET रनटाइम्स (mscorlib, system.dll, आदि) शामिल हैं, किसी अन्य डोमेन में आपका .NET कोड होता है, और मुझे याद नहीं है कि दूसरे डोमेन के लिए क्या है। http://my.safaribooksonline.com/9780321584090

Answer 5

संकलित .NET कोड आईएल बन जाता है जो जावा के ऑब्जेक्ट कोड के समान ही एक मध्यवर्ती भाषा है। हां NGen उपकरण का उपयोग कर देशी मशीन कोड उत्पन्न करना संभव है। एनजीन परिणामस्वरूप देशी छवि को मशीन पर बांधता है, इसलिए ngen'd बाइनरी को एक अलग सिस्टम में कॉपी करने से अपेक्षित परिणाम नहीं मिलेंगे। इंटरमीडिएट कोड के लिए संकलन रनटाइम फैसलों के लिए अनुमति देता है जिसे अन्यथा (आसानी से) स्थिर रूप से टाइप की गई भाषा जैसे सी ++ के साथ नहीं किया जा सकता है, यह विभिन्न हार्डवेयर आर्किटेक्चर पर कोड के कामकाज की अनुमति देता है क्योंकि कोड तब वर्णनात्मक हो जाता है यह समझ में आता है कि यह थोड़ा-सा होना चाहिए (उदाहरण के लिए 32 या 64) - नैदानिक ​​तरीके, मशीन-विशिष्ट कोड के विपरीत जो केवल 32-बिट सिस्टम या 64-बिट सिस्टम पर काम करता है लेकिन दोनों नहीं।

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

Answer 6

A1) JIT देशी मशीन कोड

A2) को संकलित .net में सैंडबॉक्स जैसी कोई अवधि नहीं है। इसके बजाय AppDomains है। और वे चलाता CLR के हिस्से के रूप (अर्थात निष्पादन की प्रक्रिया के हिस्से के रूप में) जेफरी रिक्टर से

A3) NGen कमियां:

• NGen'd फ़ाइलें सिंक्रनाइज़ेशन से बाहर निकल सकते हैं। जब सीएलआर एक एनजीएनएड फ़ाइल लोड करता है, तो यह पहले संकलित कोड और वर्तमान निष्पादन पर्यावरण के बारे में विशेषताओं की संख्या की तुलना करता है। यदि इनमें से कोई भी विशेषता मेल नहीं खाती है, तो NGen'd फ़ाइल नहीं हो सकती है, और इसके बजाय सामान्य जेआईटी कंपाइलर प्रक्रिया का उपयोग किया जाता है।

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

• अति निष्पादन-समय प्रदर्शन। कोड संकलित करते समय, एनजीएन निष्पादन पर्यावरण के बारे में मान्यताओं को जेआईटी कंपाइलर के रूप में नहीं कर सकता है। यह NGen.exe को निम्न कोड का उत्पादन करने का कारण बनता है। उदाहरण के लिए, एनजीएन कुछ CPU निर्देशों के उपयोग को अनुकूलित नहीं करेगा; यह स्थैतिक क्षेत्र के उपयोग के लिए संकेत जोड़ता है क्योंकि स्थिर फ़ील्ड के वास्तविक पते को रन टाइम तक ज्ञात नहीं है। एनजीएन कोड कंट्रोलर्स को कॉल करने के लिए कोड सम्मिलित करता है क्योंकि यह उस क्रम को नहीं जानता है जिसमें कोड निष्पादित करेगा और यदि कोई क्लास कन्स्ट्रक्टर पहले से ही कॉल किया जा चुका है।