.NET में CIL और CLR क्यों आवश्यक हैं?

Question

मैंने यहां यह अच्छी छवि देखी । मैंने सीखा है कि .net भाषा का समर्थन करने वाले सभी संकलन स्रोत कोड को CILप्रारूप में परिवर्तित करते हैं । अब Microsoft कभी भी .NETसभी ऑपरेटिंग सिस्टम के लिए CLR लिखकर सभी ऑपरेटिंग सिस्टम के लिए नहीं ला रहा है। फिर उस CIL को निष्पादित करने के लिए इस तरह के एक मध्यवर्ती कोड प्रारूप और एक CLR क्यों रखें। क्या इससे निपटने के लिए सिरदर्द नहीं है। Microsoft ने ऐसा क्यों चुना?

EDIT इस थोड़े वास्तुकला की कीमत है। यह प्रदर्शन को कम करेगा, नहीं? जावा प्लेटफ़ॉर्म की स्वतंत्रता को बनाए रखने के लिए ऐसा करता है। .NET किस कारण से करता है? संकलक की तरह एक सीधा सादा सी क्यों न रखें। किसी भी तरह से कोड को CIL में बदलने के लिए एक कंपाइलर की भी आवश्यकता होगी यदि मुझे किसी भी नई भाषा को जोड़ने की आवश्यकता है, तो केवल यही अंतर होगा कि वह लक्षित भाषा है। तात सब।

Comments

क्योंकि CIL में कंपाइलर लिखना ज्यादा आसान है। और देशी के लिए एक संकलक की तुलना में प्रत्येक और हर भाषा के मूल निवासी के लिए एक CIL लिखना आसान है।

— ऊदबिलाव

@ratchetfreak: जो अन्य प्लेटफार्मों के लिए CLR को पोर्ट नहीं करने के लिए MS के लिए एक कारण हो सकता है, लेकिन इसकी पहली जगह में CLR होने का एक कारण नहीं है (जो कि वास्तव में एक पोर्ट को आसान बनाता है , इसलिए आपका तर्क MS को कोसने जैसा लगता है क्षमा करें)

— डॉक्टर ब्राउन

इसके अलावा 'एम $' के लिए डाउनवोट करें, यह 1998 क्या है?

— एलन बी

एरिक लिपर्ट इस पर चर्चा करते हैं (तीसरे पैराग्राफ पर शुरू; पहले 2 पैराग्राफ रोजलिन के बारे में हैं)। संक्षिप्त उत्तर यह है कि ओड की टिप्पणी और टेलस्टीन का उत्तर सही है; आपको केवल <ऑपरेटिंग सिस्टम की संख्या> + <<भाषा की संख्या> संकलक के बजाय <ऑपरेटिंग सिस्टम की संख्या> * <भाषाओं की संख्या> संकलक की आवश्यकता है।

— ब्रायन

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

— ब्रायन

Answer 1

क्योंकि उन्हें केवल C # से CIL के लिए एक कंपाइलर लिखने की जरूरत है - जो कि कठिन हिस्सा है। CIL प्रति प्लेटफ़ॉर्म के लिए एक दुभाषिया (या अधिक बार, जस्ट-इन-टाइम कंपाइलर) बनाना C # (प्रति प्लेटफ़ॉर्म) निष्पादन योग्य कोड से कंपाइलर लिखने की तुलना में अपेक्षाकृत आसान है।

इसके अलावा, रनटाइम सीआईएल के लिए संकलित किसी भी चीज़ को संभाल सकता है। यदि आप एक नई भाषा चाहते हैं (जैसे एफ #) तो आपको इसके लिए केवल एक कंपाइलर लिखना होगा और आप ऑटो-जादुई रूप से चीजों के लिए सभी प्लेटफ़ॉर्म समर्थन प्राप्त कर सकते हैं। .NET सपोर्ट करता है।

ओह, और मैं .NET dll ले सकता हूं और फिर से चलाए बिना मोनो के माध्यम से विंडोज़ पर या लिनक्स पर चला सकता हूं (यह मानते हुए कि मेरी सभी निर्भरताएं संतुष्ट हैं)।

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

Comments

"दुभाषिया" `? मैंने सोचा कि एमएस हमेशा केवल एक जेटर प्रदान करता है?

— डॉक ब्राउन

@DocBrown - एह, हाँ - मेरी ओर से मिथ्या नाम। फिक्सिंग।

— तेलस्तीन

+1, क्या आप मेरे संपादन के लिए थोड़ा स्पष्टीकरण जोड़ सकते हैं ताकि मैं इस उत्तर को स्वीकार कर

— सकूं

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

— सियानफिश

@busy_wait: सभी प्रकार की चीजें। विधि inlining, कॉपी प्रचार, अनावश्यक कोड को हटाने, गुणन / विभाजन को पाली में बदलना, readonlyखेतों का उपयोग करके अन्य अंकगणितीय संचालन । पारंपरिक कंपाइलर इनमें से कुछ अनुकूलन कर सकते हैं, लेकिन केवल जब उन्हें स्थैतिक विश्लेषण द्वारा पता लगाया जा सकता है। इसके विपरीत, एक घबराना रनटाइम पर पता लगा सकता है कि (उदाहरण के लिए) कोड का एक अनुभाग कोई उपयोगी काम नहीं कर रहा है क्योंकि यह जो ऑब्जेक्ट या चर संशोधित करता है उसे कहीं और संदर्भित नहीं किया जाता है। मैं jitters पर कोई विशेषज्ञ नहीं हूं, लेकिन यह मूल रूप से गतिशील बनाम स्थिर विश्लेषण की शक्ति का सवाल है।

— आरोनॉट जीप

Answer 2

.NET की एक मध्यवर्ती भाषा (CIL / MSIL) है और एक ही कारण के लिए जावा-प्लेटफ़ॉर्म-स्वतंत्र रनटाइम (CLR) का प्लेटफ़ॉर्म-विशिष्ट कार्यान्वयन है। Microsoft ने C # को सीधे जावा के साथ प्रतिस्पर्धा करने का इरादा किया था, और यह ओएस पर है कि Microsoft लक्ष्य (अपना)।

भले ही .NET के विंडोज प्लेटफॉर्म (या अन्य OSes, जिनमें मोनो / लिनक्स की तरह .NET वर्कलाइक है) का समर्थन किया जाता है, इसके फायदे, जावा के समान हैं:

• प्रबंधित मेमोरी रनटाइम - अप्रबंधित C / C ++ के विपरीत, C # / VB.NET डेवलपर्स को ऑब्जेक्ट लाइफटाइम को सख्ती से नियंत्रित करने के बारे में चिंता करने की आवश्यकता नहीं है। जावा की तरह, सीएलआर में एक कचरा संग्राहक होता है जो स्वचालित रूप से ढेर में वस्तुओं को मुक्त करता है जो गुंजाइश छोड़ देता है। हालांकि यह किसी को अप्रबंधित रनटाइम के लिए मामूली लग सकता है, यह पॉइंटर अंकगणित के "काले जादू" को हतोत्साहित करने का चरम माध्यमिक लाभ है जो कि C / C ++ में इतना आम है।
• प्लेटफार्म इंडिपेंडेंस - विंडोज विस्टा और विंडोज 7 विंडोज एक्सपी से अलग तरह से काम करते हैं। विंडोज 8 अभी भी अलग तरह से काम करता है। विंडोज 8 सहित विंडोज मोबाइल संस्करण फिर से अलग तरीके से काम करते हैं। विभिन्न हार्डवेयर, विभिन्न वास्तुकला, विभिन्न क्षमताओं। जबकि लक्ष्य वातावरण अभी भी एक .NET डेवलपर के लिए मायने रखता है, इन सभी OS के लिए संगत C / C ++ प्रोग्राम बनाने के लिए ज्ञात की तुलना में विशेष ज्ञान की मात्रा बहुत कम है। AC # देव को मुफ्त में बहुत कुछ मिलता है।
• वेब एप्लिकेशन समर्थन - मैंने अभी तक C ++ में जमीन से लिखे गए क्लाइंट-फेसिंग, सर्वर-स्क्रिप्टेड वेब एप्लिकेशन को नहीं देखा है। वेब सर्वर , सुनिश्चित, अपाचे, आईएसएस, वे सभी आम तौर पर गति / दक्षता कारणों से एक अप्रबंधित रनटाइम के खिलाफ चलते हैं। हालाँकि, C ++ वेब अनुप्रयोगों के निर्माण के लिए उपयोग की जाने वाली भाषा नहीं है। C # है (जैसा कि जावा है)। इसे अगली पीढ़ी के Microsoft के ASP प्रतिमान का समर्थन करने के लिए जमीन से डिज़ाइन किया गया था। यह एक सैंडबॉक्स में चलाने के लिए डिज़ाइन किया गया कोड है; कौन सा सैंडबॉक्स (ASP.NET प्लग इन आईएसएस या "डेस्कटॉप" सीएलआर) अपेक्षाकृत महत्वहीन है।
• भाषा / रनटाइम स्वतंत्रता - A C ++ कंपाइलर C ++ स्रोत कोड लेता है और एक मशीन भाषा का उपयोग करके एक प्रोसेसर आर्किटेक्चर के लिए असेंबली कोड तैयार करता है। एक अलग वास्तुकला और / या मशीन की भाषा का समर्थन करने के लिए, एक पूरी तरह से नया संकलक लिखा जाना चाहिए (और रनटाइम लाइब्रेरीज़ का एक नया सेट संकलित होना चाहिए)। AC # कंपाइलर C # सोर्स कोड लेता है और CIL का उत्पादन करता है, जो हार्डवेयर-विशिष्ट JITer मशीन कोड में अनुवाद करता है। वही JITER किसी भी CIL प्रोग्राम का अनुवाद कर सकता है, चाहे कोई भी स्रोत भाषा हो (और कई हैं; C #, VB.NET, F #, और "आयरन" लैंग्वेज पोर्ट्स जैसे IronHaskell, IronRuby, IronLisp, आदि का होस्ट)। एक ही कंपाइलर एक भाषा को CIL में बदल सकता है जो कि कोई भी JITer चला सकता है, कोई फर्क नहीं पड़ता हार्डवेयर।
• "सही" कोड पर ध्यान दें - सी ++ देवों के लिए, कुछ करने के लिए बहुत सारे "सही" तरीके हैं, जो सबसे महत्वपूर्ण है, इसके आधार पर; मेमोरी दक्षता, सीपीयू दक्षता, हार्डवेयर स्वतंत्रता, ओएस स्वतंत्रता, आदि। कोड इनमें से प्रत्येक की प्राथमिकता होने पर काफी भिन्न दिख सकता है। C # को एक ऐसे समूह द्वारा डिजाइन किया गया था जो फाउलर और उनके सहयोगियों के वैचारिक पाठों को ध्यान में रखता था (जो कि C ++ समुदाय के भीतर कोड डिज़ाइन में सुधार करने के लिए काम कर रहे थे, जो एक समुदाय को ऑब्जेक्ट-ओरिएंटेड सिद्धांतों को सिखाते हैं, जो कि मुख्य रूप से C से ऊपर चले गए), साथ ही पहले आने वाली भाषाओं द्वारा सीखे गए व्यावहारिक सबक (जावा सहित, और सर्वशक्तिमान वस्तु के लिए इसके निकट-कट्टरपंथी आज्ञाकारिता, जब एक अच्छा पुराना C ++ शैली फ़ंक्शन पॉइंटर काम को बहुत अधिक सफाई से करेगा और कोई कम वस्तु नहीं- उन्मुख)।

एंटीट्रस्ट कारणों से, एमएस सावधान है कि एंड्रॉइड, मैक ओएसएक्स / आईओएस और लिनक्स जैसे अन्य प्रमुख प्लेटफार्मों में "हस्तक्षेप" को बहुत अधिक नहीं देखा जाए; हालाँकि, यह वास्तव में इन तीनों प्लेटफार्मों के लिए विकासशील टीमें हैं। OSX के लिए Office का एक MS-विकसित संस्करण है, iOS और Android के लिए Office इंटरॉप एप्लिकेशन (Skype अब Microsoft उत्पाद) सहित कई अनुप्रयोग हैं जो लिनक्स पर चलते हैं, और Microsoft को लिनक्स कर्नेल में योगदान देते हुए देखा गया है (मुख्य रूप से एक में वर्चुअलाइजेशन मानसिकता)।

Comments

"मैंने अभी तक C ++ में जमीन से लिखे गए क्लाइंट-फेसिंग, सर्वर-स्क्रिप्टेड वेब एप्लिकेशन को नहीं देखा है।" - आप पुराने दिनों के सीजीआई कहां लगाते हैं? मेरे बहुत पहले वेब एप्लिकेशन (जितने भी तुच्छ थे) वे 100% सी। बैक थे (मिड '90 के दशक) .c लिखने के लिए .c और .h कोगी में मानक कार्य करने के लिए (' स्क्रिप्टिंग ') भाषाएं थीं। दृश्य पर भी उभर रहा है)।

एचएम ... सीजीआई, सीजीआई ... मुझे लगता है कि मैंने इसके बारे में सुना है, लेकिन मैं कीथ के साथ हूं, मैं वास्तव में एक देख पा रहा हूं :)

— DXM

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

जावा के साथ समानता के महत्व को कम मत समझो। रवि ने जेवीएम के अपने बंदरगाह के लिए एमएस पर मुकदमा दायर किया और कुछ कानूनी बिंदुओं (मूर्खतापूर्ण, आईएमएचओ) को जीता। CIL और CLR उसी से प्रेरित होते हैं, और आप देखेंगे कि J # उतना ही करीब है, जितना जावा में हो सकता है, बिना आगे की कानूनी कार्रवाई के। एक बड़ा अंतर यह है कि सीएलआर भाषा अज्ञेय है। आप वास्तव में C #, F #, और J # के मिश्रण में एक प्रोग्राम लिख सकते हैं यदि ऐसा है तो इसकी आवश्यकता है। बस जावा को अन्य भाषाओं में पुस्तकालयों के साथ मिलाने और एक स्थिर कार्यक्रम प्राप्त करने का प्रयास करें।

— RBerteig

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

— RBerteig

Answer 3

Windows OS विभिन्न CPU प्रकारों के लिए उपलब्ध है, आज ज्यादातर x64, x86, Intel, ARM हैं।

CIL / CLR उस हार्डवेयर प्लेटफ़ॉर्म से स्वतंत्र है - ये अंतर IL निष्पादन वातावरण द्वारा "अमूर्त दूर" हैं। उदाहरण के लिए, "किसी भी सीपीयू" के लिए संकलित एक .NET असेंबली आमतौर पर Win64 पर 64 बिट प्रक्रिया के रूप में निष्पादित की जा सकती है, और Win32 32 बिट प्रक्रिया के रूप में, विभिन्न निष्पादनयोग्य प्रदान करने की आवश्यकता के बिना।

अधिक जानकारी के लिए, CIL मेटाडेटा को असेंबली में संग्रहीत करने की अनुमति देता है जो देशी DLL के साथ आसानी से संभव नहीं है (यह संभव है, एमएस ने COM घटकों के साथ पहले भी ऐसा किया था, लेकिन उस तकनीक को .NET घटकों के रूप में संभालना कभी आसान नहीं था)। यह सॉफ्टवेयर घटकों के निर्माण को एक नरक बहुत सरल बनाता है और सभी .NET भाषाओं में प्रतिबिंब / आत्मनिरीक्षण की नींव है ।

Comments

बस इसमें थोड़ा सा जोड़ने के लिए, न केवल वे अलग-अलग सीपीयू प्रकारों की अनुमति देते हैं, बल्कि अलग-अलग संस्करण (कोर i3 / i5 / i7) और विक्रेताओं (इंटेल बनाम एएमडी) के साथ एक ही सीपीयू प्रकार (उदाहरण के लिए सभी x 64) अलग हो सकते हैं असेंबली निर्देशों के सेट जो जेआईटी संकलक लाभ लेने में सक्षम होंगे

— DXM

@DXM: और आप जानते हैं कि JIT वास्तव में क्या करता है? या यह एक काल्पनिक बात है?

— डॉक ब्राउन

कम से कम एक MSDN ब्लॉग का दावा है कि JIT कंपाइलर ऐसा करता है (या किया, 8 साल पहले)।

@DocBrown: जाहिर है मेरे पास कोई संदर्भ सामग्री नहीं है, लेकिन मुझे लगा कि मुझे इस बारे में कुछ समय पहले पढ़ना याद था। धन्यवाद डेलन, लिंक खोजने के लिए। यह समझ में आता है क्योंकि हम जानते हैं कि चिप निर्माता मानक x86-x64 के शीर्ष पर अपने स्वयं के निर्देशों को जोड़ना पसंद करते हैं, इसलिए यदि मशीन लाभ उठा सकती है तो यह क्यों नहीं होगा?

— DXM