कुछ प्रोग्रामिंग लैंग्वेज दूसरों की तुलना में "तेज" या "धीमी" क्यों हैं?

Question

मैंने देखा है कि कुछ एप्लिकेशन या एल्गोरिदम जो प्रोग्रामिंग लैंग्वेज पर बनाए जाते हैं, कहते हैं कि C ++ / Rust तेजी से या स्नैपीयर कहते हैं, जो कि जावा / Node.js पर बने हैं, उसी मशीन पर चलते हैं। इस बारे में मेरे पास कुछ सवाल हैं:

1. ऐसा क्यों होता है?
2. प्रोग्रामिंग भाषा की "गति" को क्या नियंत्रित करता है?
3. यह स्मृति प्रबंधन के साथ कुछ भी करना है?

अगर कोई मेरे लिए इसे तोड़ता है तो मैं वास्तव में सराहना करूंगा

Comments

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

— क्राइसिस -ऑन स्ट्राइक-

तेज या धीमी भाषा जैसी कोई चीज नहीं है।

— राफेल

उस ने कहा, जावा और जावास्क्रिप्ट से संबंधित कुछ भी एक साथ जोड़ना अपमानजनक है।

— राफेल

मैं इसे बंद करने के बीच फटा हुआ हूं क्योंकि बहुत व्यापक है (पाठ्यपुस्तकों को संबंधित विषयों के बारे में लिखा जा सकता है!) या डुप्लिकेट । सामुदायिक वोट, कृपया!

— राफेल

यह सवाल भी काफी कुछ वैसा ही है जैसा एक प्रोग्रामिंग भाषा की गति निर्धारित करता है

— vzn

Answer 1

प्रोग्रामिंग भाषा डिजाइन और कार्यान्वयन में, बड़ी संख्या में विकल्प हैं जो प्रदर्शन को प्रभावित कर सकते हैं। मैं केवल कुछ का उल्लेख करूंगा।

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

विभिन्न संकलक / व्याख्याकार अलग-अलग अनुकूलन करते हैं।

यदि भाषा में स्वचालित मेमोरी प्रबंधन है, तो इसके कार्यान्वयन को कचरा संग्रह करना है। यह एक रनटाइम लागत है, लेकिन प्रोग्रामर को एक त्रुटि-ग्रस्त कार्य से राहत देता है।

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

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

कुछ भाषाएं हमेशा रनटाइम त्रुटियों को एक समझदार तरीके से रिपोर्ट करती हैं। यदि आप a[100]जावा में लिखते हैं जहां aकेवल 20 तत्व हैं, तो आपको एक रनटाइम अपवाद मिलता है। सी में, यह अपरिभाषित व्यवहार का कारण होगा, जिसका अर्थ है कि कार्यक्रम दुर्घटनाग्रस्त हो सकता है, स्मृति में कुछ यादृच्छिक डेटा को अधिलेखित कर सकता है, या यहां तक ​​कि बिल्कुल कुछ भी कर सकता है (आईएसओ सी मानक कोई सीमा नहीं है)। इसके लिए रनटाइम चेक की आवश्यकता होती है, लेकिन प्रोग्रामर को बहुत अच्छे शब्दार्थ प्रदान करता है।

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

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

1   700327  Unagi                       Java,C++,C#,PHP,Haskell
2   268752  天羽々斬                     C++, Ruby, Python, Haskell, Java, JavaScript
3   243456  Cult of the Bound Variable  C++, Standard ML, Python

उनमें से किसी ने एक भी भाषा का इस्तेमाल नहीं किया।

Comments

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

— डेरेक एल्किंस

इसके अलावा, कुछ भाषाएँ उचित रूप से निर्दोष चीजों की गारंटी देती हैं जो कंपाइलर के अनुकूलन की क्षमता को प्रभावित कर सकती हैं, C ++ बनाम FORTRAN में सख्त अलियासिंग देखें

— PlasmaHH

इसलिए मैं @DerekElkins द्वारा टिप्पणी को रद्द कर सकता हूं। बहुत बार उस उद्धरण का संदर्भ गायब होता है, कभी-कभी इस निष्कर्ष पर भी जाता है कि यह वकालत करता है कि सभी अनुकूलन बुराई है।

— पाइप

@DerekElkins विडंबना यह है कि आप शायद सबसे महत्वपूर्ण हिस्सा चूक गए: दो वाक्यों के तुरंत बाद। "एक अच्छे प्रोग्रामर को इस तरह के तर्क से शालीनता में नहीं लिया जाएगा, वह महत्वपूर्ण कोड को ध्यान से देखने के लिए बुद्धिमान होगा; लेकिन उसके बाद ही उस कोड की पहचान की गई है। अक्सर यह प्राथमिकता होती है कि कौन से हिस्सों के बारे में प्राथमिकता तय की जाए। कार्यक्रम वास्तव में महत्वपूर्ण हैं, क्योंकि माप उपकरणों का उपयोग करने वाले प्रोग्रामर का सार्वभौमिक अनुभव रहा है कि उनके सहज अनुमान विफल हो जाते हैं। " PDF p268

— 8bittree

@DerekElkins स्पष्ट होने के लिए, मैं आपके मुंह में ऐसे शब्द नहीं डालना चाहता जो आप यह दावा कर रहे थे, लेकिन अक्सर मैं लोगों को आधार उद्धरण में बस थोड़ा सा जोड़कर आता हूं, और यह सोचकर कि नुथ समयपूर्व अनुकूलन 3 की वकालत कर रहे थे समय का%, जब पूरा लेख यह स्पष्ट करता है कि वह हमेशा समय से पहले अनुकूलन का विरोध करता है, लगभग हमेशा छोटे अनुकूलन का विरोध करता है, लेकिन महत्वपूर्ण के रूप में मापा वर्गों में छोटी अनुकूलन के लिए वकालत करता है।

— 8bittree

Answer 2

प्रोग्रामिंग भाषा की "गति" को क्या नियंत्रित करता है?

प्रोग्रामिंग भाषा की "गति" जैसी कोई चीज नहीं है। एक विशेष वातावरण में चलने वाले विशेष निष्पादन इंजन के किसी विशेष संस्करण के एक विशेष संस्करण द्वारा निष्पादित एक विशेष प्रोग्रामर द्वारा लिखे गए एक विशेष कार्यक्रम की गति है।

विभिन्न कार्यान्वयनों का उपयोग करके एक ही मशीन पर एक ही भाषा में लिखे गए समान कोड को चलाने में भारी प्रदर्शन अंतर हो सकते हैं। या यहां तक ​​कि एक ही कार्यान्वयन के विभिन्न संस्करणों का उपयोग करना। उदाहरण के लिए, एक ही मशीन पर स्पाइडरमोंकी के 10 साल पहले के संस्करण का उपयोग करके सटीक एक ही ईसीएमएस्क्रिप्ट बेंचमार्क चलाना, इस वर्ष के एक संस्करण बनाम संभवतः 2 × -5 ×, शायद 10 × के बीच कहीं भी प्रदर्शन में वृद्धि होगी। क्या इसका मतलब यह है कि ECMAScript ECMAScript की तुलना में 2 × अधिक तेज है, क्योंकि एक ही मशीन पर एक ही प्रोग्राम चलाने से नए कार्यान्वयन के साथ 2 × अधिक तेज है? इसका कोई मतलब नहीं है।

यह स्मृति प्रबंधन के साथ कुछ भी करना है?

ज़रुरी नहीं।

ऐसा क्यों होता है?

संसाधन। पैसे। Microsoft शायद अपने कंपाइलर प्रोग्रामर के लिए पूरे PHP, Ruby, और Python समुदाय की तुलना में कॉफी बनाने वाले अधिक लोगों को नियुक्त करता है, जिसमें संयुक्त रूप से अपने VMs पर काम करने वाले लोग होते हैं।

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

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

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

लेकिन, एक और तरीका है: कैश मिस की कुल लागत एक व्यक्ति कैश मिस की लागत से कैश मिस की संख्या को गुणा करना है। मुख्यधारा के सीपीयू मिसेस की संख्या को कम करने की कोशिश करते हैं, लेकिन क्या होगा अगर आप किसी व्यक्ति की मिस की लागत को कम कर सकते हैं?

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

सीपीयू आर्किटेक्चर सिर्फ एक उदाहरण है जिसका प्रभाव किसी भाषा के उच्च निष्पादन कार्यान्वयन के लिए कितना आसान है या कितना कठिन है। C, C ++, D, Rust जैसी भाषा जो आधुनिक मुख्यधारा सीपीयू प्रोग्रामिंग मॉडल के लिए एक अच्छी फिट है, जावा, ECMAScript, पायथन, रूबी जैसी सीपीयू को "लड़ना" और उसे दरकिनार करने वाली भाषा की तुलना में तेज़ बनाना आसान होगा। , PHP।

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

व्यक्तिगत रूप से, मैं रूबी से सबसे अधिक परिचित हूं (जिसे आम तौर पर "धीमी भाषा" माना जाता है), इसलिए मैं दो उदाहरण दूंगा: रूबिनियस में Hashवर्ग (रूबी में एक केंद्रीय डेटा संरचना, एक प्रमुख मूल्य शब्दकोश) रूबी कार्यान्वयन 100% शुद्ध रूबी में लिखा गया है, और इसमें लगभग उसी तरह का प्रदर्शन हैHashYARV में कक्षा (सबसे व्यापक रूप से उपयोग किया जाने वाला कार्यान्वयन), जो C. में लिखा गया है और YARV के लिए C एक्सटेंशन के रूप में लिखा गया एक छवि हेरफेर लाइब्रेरी है, जिसमें कार्यान्वयन के लिए एक (धीमी) शुद्ध रूबी "फॉलबैक संस्करण" भी है। 'टी सपोर्ट सी' जो अत्यधिक गतिशील और चिंतनशील रूबी ट्रिक की एक टन का उपयोग करता है; JRuby की एक प्रायोगिक शाखा, Oracle लैब्स द्वारा Truffle AST इंटरप्रेटर फ्रेमवर्क और ग्रेगल JIT संकलन फ्रेमवर्क का उपयोग करते हुए, उस शुद्ध रूबी "फॉलबैक संस्करण" को निष्पादित कर सकती है, जितना कि YARV मूल उच्च-अनुकूलित C संस्करण को निष्पादित कर सकता है। यह वास्तव में गतिशील रनटाइम ऑप्टिमाइजेशन, जेआईटी संकलन, और आंशिक मूल्यांकन के साथ वास्तव में चतुर सामान बनाने वाले कुछ चतुर लोगों द्वारा प्राप्त किया गया है (ठीक है, कुछ भी लेकिन)।

Comments

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

— गमथ

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

— थोरबजोर्न रेवन एंडरसन

मैं संसाधनों के बारे में टिप्पणी से असहमत हूं। यह उस टीम के लोगों की संख्या नहीं है जो मायने रखती है, यह टीम के सर्वश्रेष्ठ लोगों का कौशल स्तर है।

— माइकल काय

"Microsoft शायद पूरे PHP, Ruby, और Python समुदाय की तुलना में अपने कंपाइलर प्रोग्रामर के लिए कॉफी बनाने वाले अधिक लोगों को नियुक्त करता है, उनके वीएम पर काम करने वाले लोगों को मिला हुआ है" मुझे लगता है कि यह इस बात पर निर्भर करता है कि आप "कंपाइलर प्रोग्रामर" शब्द को कितना लंबा खींचना चाहते हैं। आप इसके साथ कितना शामिल हैं (Microsoft बहुत सारे कंपाइलर विकसित करता है )। उदाहरण के लिए, सिर्फ VS C ++ कंपाइलर टीम अपेक्षाकृत छोटा AFAIK है।

— घन

Answer 3

सैद्धांतिक रूप से, यदि आप ऐसा कोड लिखते हैं जो दो भाषाओं में समान है और दोनों एक "संपूर्ण" संकलक का उपयोग करके संकलित करते हैं, तो दोनों का प्रदर्शन समान होना चाहिए।

व्यवहार में, कई कारण हैं कि प्रदर्शन अलग क्यों होने जा रहा है:

1. कुछ भाषाओं को अनुकूलित करना कठिन है।

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

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

2. कुछ भाषा कार्यान्वयन को रनटाइम के दौरान कुछ संकलन करना पड़ता है।

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

   इस तरह की भाषा कार्यान्वयन को रनटाइम के दौरान अधिक काम करना पड़ता है, जो प्रदर्शन को प्रभावित करता है, विशेष रूप से स्टार्टअप के बाद स्टार्टअप समय / प्रदर्शन।

3. भाषा कार्यान्वयन जानबूझकर अनुकूलन से कम समय खर्च कर सकते हैं जितना वे कर सकते थे।

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

4. विभिन्न भाषाओं में मुहावरों में अंतर।

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

   एक उदाहरण के रूप vector[i]में, C ++ में, list[i]C # में और list.get(i)जावा में विचार करें। C ++ कोड की संभावना कोई सीमा जाँच नहीं है और कोई वर्चुअल कॉल नहीं करता है, C # कोड श्रेणी जाँच करता है, लेकिन कोई वर्चुअल कॉल और जावा कोड श्रेणी जाँच नहीं करता है और यह एक आभासी कॉल है। सभी तीन भाषाएं आभासी और गैर-आभासी तरीकों का समर्थन करती हैं और सी ++ और सी # दोनों में रेंजिंग चेकिंग शामिल हो सकती है या अंतर्निहित एरे को एक्सेस करने से बच सकती है। लेकिन इन भाषाओं के मानक पुस्तकालयों ने इन समान कार्यों को अलग तरह से लिखने का फैसला किया, और, परिणामस्वरूप, उनका प्रदर्शन अलग होगा।

5. कुछ संकलक कुछ अनुकूलन गायब हो सकते हैं।

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

Comments

कुछ भाषा में कंपाइलर नहीं होता है। कुछ भाषाओं के लिए, एक संकलक ( संदर्भ ) नहीं हो सकता है ।

— राफेल

कुछ भाषाओं के लिए, एक स्थिर संकलक नहीं हो सकता है । गतिशील संकलन स्थैतिक गुणों की अनिच्छा से प्रभावित नहीं होता है।

— जोर्ज डब्ल्यू मित्तग

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

— einpoklum

@einpoklum मुझे भेद दिखाई नहीं देता। कुछ अपवादों के साथ (जैसे सिंक्रनाइज़ेशन को फैलाना), जो मुझे लगता है कि यहां दिलचस्प नहीं हैं, भाषा विनिर्देश आमतौर पर किसी भी अनुकूलन को अनुमति देते हैं जो अवलोकन योग्य व्यवहार को संरक्षित करते हैं। आपके मन में किस तरह का व्यवहार है जो उपयोगकर्ता-अवलोकन योग्य नहीं है, लेकिन इसे अनुकूलित नहीं किया जा सकता है?

— svick

सैद्धांतिक रूप से, किसी भी व्याख्या की गई भाषा एक EXE फ़ाइल को इंटरप्रेटर + प्रोग्राम के स्रोत कोड से उत्पन्न करके "संकलित" हो सकती है।

— dan04

Answer 4

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

Comments

यह बहुत सरल उत्तर है। ऐसी सेटिंग्स हैं जिनमें जावा तेज है।

— राफेल

जावा के कार्यान्वयन भी हैं जो मशीन कोड के संकलन और सी ++ के कार्यान्वयन की व्याख्या करते हैं। और वैसे भी "मशीन कोड" क्या है, अगर मेरे पास एक picoJava सीपीयू है जो जेवीएम बायटेकोड को मूल रूप से निष्पादित करता है, और मेरे पास जेपीसी एक्स 86 दुभाषिया जेवीएम पर चल रहा है, तो क्या x86 ऑब्जेक्ट कोड "मशीन कोड" और जेवीएम बायटेकोड नहीं बनाता है?

— जोर्ग डब्ल्यू मित्तग

नाइटपिक: न केवल जावा कचरा संग्रह प्रदान करता है ... और यहां तक ​​कि अगर आप केवल सी ++ और जावा पर विचार करते हैं, तो कुछ सी ++ फ्रेमवर्क / लाइब्रेरी कार्यक्रमों में जगह-जगह कचरा संग्रह की सुविधा है।

— einpoklum

देशी मशीन कोड के संकलन से आमतौर पर प्रदर्शन में सुधार होता है। हालांकि, कुछ सीमित मामलों में एक उच्च-गुणवत्ता वाला दुभाषिया एक भोले-भाले संकलक को हरा सकता है।

— डिप्रेस्डैनियल

@ JörgWMittag ट्रिक देशी मशीन कोड को संकलित करने के लिए है - मशीन कोड जिसे होस्ट प्रोसेसर समझता है - और फिर सीधे तथाकथित कोड पर कूद जाता है ताकि इसे बिना व्याख्या के निष्पादित किया जा सके। यह एक x86 चिप पर x86 और एक picoJava सीपीयू पर JVM बाईटकोड होगा।

— डिप्रेस्डैनियल

Answer 5

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

मेरी सबसे अच्छी व्याख्या के लिए, आइए C ++ और .Net प्लेटफॉर्म को देखें।

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

अब आइए .Net पर देखें। .Net विकास करने के लिए शर्त एक विशालकाय आईडीई है जिसमें न केवल एक प्रकार की प्रोग्रामिंग भाषाएं शामिल हैं। यहां तक ​​कि अगर आप बस डेवलपर को C # कहना चाहते हैं, तब भी IDE में डिफ़ॉल्ट रूप से कई प्रोग्रामिंग प्लेटफ़ॉर्म शामिल होंगे जैसे J #, VB, मोबाइल और आदि। जब तक आप कस्टम इंस्टॉल नहीं करते हैं और केवल वही स्थापित करते हैं जो आप चाहते हैं, बशर्ते कि आप आईडीई इंस्टॉलेशन के साथ खेलने के लिए पर्याप्त अनुभव हो।

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

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

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

आमतौर पर .Net विकास करने के लिए, आपको कुछ राम और प्रोसेसर के साथ एक अच्छे कंप्यूटर की आवश्यकता होती है। अन्यथा, आप बिल्कुल भी प्रोग्रामिंग नहीं कर सकते। इस पहलू में, C ++ प्लेटफॉर्म .Net की तुलना में बहुत बेहतर है। हालाँकि आपको अभी भी एक अच्छे कंप्यूटर की आवश्यकता है, लेकिन .Net की तुलना में क्षमता की बहुत अधिक चिंता नहीं होगी।

आशा है कि मेरा उत्तर आपके प्रश्न के साथ मदद कर सकता है। यदि आप अधिक जानना चाहते हैं तो मुझे बताएं।

संपादित करें:

मेरे मुख्य बिंदु के लिए एक स्पष्टीकरण, मैं मुख्य रूप से "व्हाट्सएप प्रोग्रामिंग की गति को नियंत्रित करता हूं" के सवाल का जवाब देता हूं।

आईडीई के दृष्टिकोण में, रिश्तेदार आईडीई में C ++ या .Net भाषा का उपयोग कोड लिखने की गति को प्रभावित नहीं करता है, लेकिन यह विकास की गति को प्रभावित करेगा क्योंकि Visual Studio संकलक को प्रोग्राम को निष्पादित करने में अधिक समय लगता है, लेकिन C ++ IDE बहुत हल्का है और कम कंप्यूटर संसाधनों का उपभोग करें। इसलिए लंबे समय में, आप। नेट आईडीई के साथ C ++ प्रकार की IDE की तुलना में तेजी से प्रोग्रामिंग कर सकते हैं जो पुस्तकालयों और रूपरेखा पर बहुत निर्भर करता है। यदि आप IDE को शुरू करने, संकलन करने, कार्यक्रम को निष्पादित करने और इत्यादि की प्रतीक्षा के समय लेते हैं, तो यह प्रोग्रामिंग की गति को प्रभावित करेगा। जब तक "प्रोग्रामिंग की गति" वास्तव में केवल "लेखन कोड की गति" पर केंद्रित है।

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

जैसा कि आप अनुमान लगा सकते हैं, मुझे C ++ का बहुत अधिक पता नहीं है क्योंकि मैं इसे उदाहरण के रूप में उपयोग करता हूं, मेरा मुख्य बिंदु विज़ुअल स्टूडियो प्रकार के भारी आईडीई के बारे में है जो कंप्यूटर संसाधनों का उपभोग करते हैं।

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

Comments

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

— मेटलमाइक्टर

आप निश्चित रूप से एक आईडीई के बिना .Net में विकसित कर सकते हैं। लेकिन मैं यह नहीं देखता कि IDE भाषा में लिखे कोड की गति के लिए कैसे प्रासंगिक है।

— स्विक

@MetalMikester: और निश्चित रूप से, विजुअल स्टूडियो विंडोज पर C ++ विकास के लिए IDE है।

— जॉर्ग डब्ल्यू मित्तग

और C ++ से .Net कोड को संकलित करना केवल एक संकलक स्विच है; माना जाता है कि चैस विजुअल स्टूडियो में एक माउस क्लिक द्वारा पुल है।

— MSalters

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

— बजे एक CVn