सी ++ प्रदर्शन बनाम जावा / सी #

Question

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

शायद यह एक भाषा के प्रश्न की तुलना में अधिक संकलित प्रश्न है, लेकिन क्या कोई स्पष्ट अंग्रेजी में बता सकता है कि इन आभासी मशीन भाषाओं में से एक के लिए एक मूल भाषा से बेहतर प्रदर्शन करना कैसे संभव है?

Comments

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

— पीटर लॉरी

इन उत्तरों में बहुत परतदार सिद्धांत को पढ़ने से पहले जाँच करने के लिए कुछ वास्तविक माप: shootout.alioth.debian.org/u32/…

— Justicle

Answer 1

आम तौर पर, C # और जावा केवल तेज या तेज हो सकते हैं क्योंकि JIT कंपाइलर - एक कंपाइलर जो आपके IL को पहली बार संकलित करता है - वह अनुकूलन कर सकता है जो C ++ संकलित प्रोग्राम नहीं कर सकता क्योंकि यह मशीन को क्वेरी कर सकता है। यह निर्धारित कर सकता है कि मशीन इंटेल या एएमडी है; पेंटियम 4, कोर सोलो, या कोर डुओ; या अगर SSE4 का समर्थन करता है, आदि।

एक C ++ प्रोग्राम को पहले से आमतौर पर मिश्रित अनुकूलन के साथ संकलित करना पड़ता है ताकि यह सभी मशीनों पर शालीनता से चलता रहे, लेकिन यह एक कॉन्फ़िगरेशन (यानी प्रोसेसर, इंस्ट्रक्शन सेट, अन्य हार्डवेयर) के लिए उतना अनुकूलित नहीं है।

इसके अतिरिक्त कुछ भाषा सुविधाएँ आपके कोड के बारे में धारणा बनाने के लिए C # और Java में संकलक को अनुमति देती हैं जो इसे कुछ भागों को दूर करने की अनुमति देता है जो अभी करने के लिए C / C ++ संकलक के लिए सुरक्षित नहीं हैं। जब आपके पास पॉइंटर्स तक पहुंच होती है तो बहुत सारे अनुकूलन होते हैं जो अभी सुरक्षित नहीं हैं।

इसके अलावा Java और C # C ++ की तुलना में अधिक कुशलतापूर्वक ढेर आवंटन कर सकते हैं क्योंकि कचरा कलेक्टर और आपके कोड के बीच अमूर्त की परत इसे एक बार में अपने सभी ढेर संपीड़न (एक काफी महंगा ऑपरेशन) करने की अनुमति देती है।

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

तो जैसा कि आप देख सकते हैं, ऐसे कुछ कारण हैं जिनकी वजह से C # या Java कार्यान्वयन तेजी से होगा।

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

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

जावा पक्ष में से, @Swati एक अच्छा लेख बताते हैं:

https://www.ibm.com/developerworks/library/j-jtp09275

Comments

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

— जस्टिक

@ जूलरी विभिन्न आर्किटेक्चर के लिए आपके c ++ कंपाइलर की पेशकश सबसे अच्छी होगी आमतौर पर x86, x64, ARM और whatnot है। अब आप इसे विशिष्ट सुविधाओं (SSE2 कहते हैं) का उपयोग करने के लिए कह सकते हैं और यदि आप भाग्यशाली हैं तो यह कुछ बैकअप कोड भी उत्पन्न करेगा यदि वह सुविधा उपलब्ध नहीं है, लेकिन यह उतना ही बढ़िया है जितना कि कोई भी प्राप्त कर सकता है। निश्चित रूप से कैश आकार और व्हाट्सएप के आधार पर कोई विशेषज्ञता नहीं है।

— वू

देखें shootout.alioth.debian.org/u32/... इस सिद्धांत के उदाहरण के लिए नहीं हो रहा।

— जस्टीक

सच कहूं तो, यह सबसे खराब उत्तरों में से एक है। यह बहुत निराधार है, मैं इसे उल्टा कर सकता हूं। बहुत अधिक सामान्यीकरण, बहुत अधिक अनजाना (खाली कार्यों को दूर करना वास्तव में सिर्फ हिमशैल का टिप है)। एक लक्जरी सी ++ संकलक के पास: समय है। एक और लक्जरी: कोई जाँच लागू नहीं है। लेकिन stackoverflow.com/questions/145110/c-performance-vs-java-c/… में अधिक खोजें ।

— सेबेस्टियन मच

@OrionAdrian ठीक हम अब कर रहे हैं चक्र पूरा ... देखें shootout.alioth.debian.org/u32/... इस सिद्धांत नहीं हो रहा उदाहरणों के लिए। दूसरे शब्दों में, हमें दिखाओ कि अस्पष्ट अनुमानों को बयान करने से पहले आपका सिद्धांत सही साबित हो सकता है ।

— जस्टिक

Answer 2

JIT बनाम स्टेटिक कंपाइलर

जैसा कि पहले ही पोस्ट में कहा जा चुका है, JIT IL / bytecode को रनटाइम में देशी कोड में संकलित कर सकता है। उस की लागत का उल्लेख किया गया था, लेकिन इसके निष्कर्ष के लिए नहीं:

JIT की एक बड़ी समस्या यह है कि यह सब कुछ संकलित नहीं कर सकता है: JIT संकलन में समय लगता है, इसलिए JIT कोड के केवल कुछ हिस्सों को संकलित करेगा, जबकि एक स्थिर संकलक एक पूर्ण देशी बाइनरी का उत्पादन करेगा: कुछ प्रकार के कार्यक्रमों के लिए, स्थैतिक कंपाइलर बस आसानी से JIT से आगे निकल जाएगा।

बेशक, C # (या जावा, या VB) आमतौर पर C ++ की तुलना में व्यवहार्य और मजबूत समाधान का उत्पादन करने के लिए तेज़ है (यदि केवल इसलिए कि C ++ में जटिल शब्दार्थ है, और C ++ मानक पुस्तकालय है, जबकि दिलचस्प और शक्तिशाली, पूर्ण की तुलना में काफी खराब है। .NET या जावा से मानक पुस्तकालय का दायरा), इसलिए आमतौर पर, C ++ और .NET या Java JIT के बीच का अंतर अधिकांश उपयोगकर्ताओं को दिखाई नहीं देगा, और उन बायनेरिज़ के लिए जो महत्वपूर्ण हैं, ठीक है, आप अभी भी C ++ प्रोसेसिंग को कॉल कर सकते हैं। C # या Java से (भले ही इस तरह के देशी कॉल अपने आप में काफी महंगे हो सकते हैं ...)

सी ++ मेटाप्रोग्रामिंग

ध्यान दें कि आमतौर पर, आप C ++ रनटाइम कोड की तुलना C # या Java में इसके समकक्ष कर रहे हैं। लेकिन C ++ में एक विशेषता है जो जावा / C # को बॉक्स से बाहर कर सकती है, वह है टेम्पलेट मेटाप्रोग्रामिंग: कोड प्रसंस्करण को संकलन समय पर किया जाएगा (इस प्रकार, बहुत अधिक संकलन समय बढ़ जाता है), जिसके परिणामस्वरूप शून्य (या लगभग शून्य) रनटाइम होता है।

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

2011-06-10 संपादित करें: C ++ में, प्रकारों के साथ खेलना संकलन समय पर किया जाता है, जिसका अर्थ है जेनेरिक कोड का उत्पादन करना जो नॉन-जेनेरिक कोड कहता है (जैसे स्ट्रिंग से टाइप टी के लिए एक जेनेरिक पार्सर, टाइप T के लिए मानक लाइब्रेरी API कॉल करना यह पहचानता है,) और पार्सर को अपने उपयोगकर्ता द्वारा आसानी से एक्स्टेंसिबल बनाना) बहुत आसान और बहुत ही कुशल है, जबकि जावा या सी # में समतुल्य लिखना सबसे अच्छा है, और हमेशा धीमी गति से हल किया जाएगा और यहां तक ​​कि जब प्रकार संकलित समय पर ज्ञात होते हैं, तब भी मतलब आपकी पूरी उम्मीद है कि JIT पूरी बात को इनलाइन कर दे।

...

2011-09-20 को संपादित करें: ब्लिट्ज ++ ( होमपेज , विकिपीडिया ) के पीछे की टीम इस तरह से चली गई, और जाहिर है, उनका लक्ष्य वैज्ञानिक गणना पर फोरट्रान के प्रदर्शन तक पहुंचने के लिए है, जितना संभव हो सके रनटाइम निष्पादन से संकलन समय तक, C ++ टेम्पलेट के माध्यम से । तो " मैं अभी तक तो एक वास्तविक जीवन प्रभाव इस पर देख चुके हैं हिस्सा मैंने ऊपर लिखा था" जाहिरा तौर पर करता है वास्तविक जीवन में मौजूद।

मूल C ++ मेमोरी उपयोग

C ++ में Java / C # से अलग एक मेमोरी उपयोग है, और इस प्रकार, इसके अलग-अलग फायदे / दोष हैं।

JIT ऑप्टिमाइज़ेशन से कोई फर्क नहीं पड़ता है, मेमोरी में डायरेक्ट पॉइंटर एक्सेस के रूप में तेजी से कुछ भी नहीं होगा (चलो एक पल प्रोसेसर कैश के लिए अनदेखा करें, आदि)। इसलिए, यदि आपके पास मेमोरी में सन्निहित डेटा है, तो इसे C ++ पॉइंटर्स (यानी C पॉइंटर्स ... लेट सीजर को इसके कारण के माध्यम से एक्सेस करना) जावा / सी # की तुलना में कई गुना तेजी से जाएगा। और C ++ में RAII है, जो C # या जावा में भी बहुत अधिक प्रसंस्करण को आसान बनाता है। C ++ usingको अपनी वस्तुओं के अस्तित्व की गुंजाइश की आवश्यकता नहीं है। और C ++ में एक finallyक्लॉज नहीं है । यह एक त्रुटि नहीं है।

:-)

और सी # आदिम-जैसी संरचनाओं के बावजूद, सी + "स्टैक पर" वस्तुओं को आवंटन और विनाश पर कुछ भी खर्च नहीं होगा, और सफाई करने के लिए एक स्वतंत्र धागे में काम करने के लिए जीसी की आवश्यकता नहीं होगी।

मेमोरी फ़्रेग्मेंटेशन के लिए, 2008 में मेमोरी एलोकेटर्स 1980 से पुराने मेमोरी एलोकेटर्स नहीं हैं, जो आमतौर पर जीसी के साथ तुलना की जाती हैं: सी ++ आवंटन को मेमोरी में स्थानांतरित नहीं किया जा सकता है, सच है, लेकिन फिर, लिनक्स फाइल सिस्टम की तरह: हार्ड डिस्क की आवश्यकता किसे है विखंडन जब विखंडन नहीं होता है? सही कार्य के लिए सही आवंटनकर्ता का उपयोग करना C ++ डेवलपर टूलकिट का हिस्सा होना चाहिए। अब, आवंटनकर्ताओं को लिखना आसान नहीं है, और फिर, हम में से अधिकांश के पास करने के लिए बेहतर चीजें हैं, और अधिकांश उपयोग के लिए, आरएआईआई या जीसी पर्याप्त से अधिक है।

2011-10-04 को संपादित करें: कुशल आवंटनकर्ताओं के बारे में उदाहरणों के लिए: विस्टा के बाद से, विंडोज प्लेटफॉर्म पर, कम फ्रैग्मेंटेशन हीप डिफ़ॉल्ट रूप से सक्षम है। पिछले संस्करणों के लिए, LFH को WinAPI फ़ंक्शन HeapSetInformation ) पर कॉल करके सक्रिय किया जा सकता है । अन्य ओएस पर, वैकल्पिक आवंटन प्रदान किए जाते हैं (देखेंएक सूची के लिए https://secure.wikimedia.org/wikipedia/en/wiki/Malloc )

अब, मेमोरी मॉडल कुछ हद तक मल्टीकोर और मल्टीथ्रेडिंग प्रौद्योगिकी के उदय के साथ जटिल होता जा रहा है। इस क्षेत्र में, मुझे लगता है कि .NET का लाभ है, और जावा, मुझे बताया गया था, ऊपरी जमीन पर कब्जा कर लिया गया है। यह कुछ "नंगे धातु" हैकर के लिए "मशीन के पास" उसकी प्रशंसा करने के लिए आसान है। लेकिन अब, संकलक को अपनी नौकरी देने की तुलना में हाथ से बेहतर विधानसभा का निर्माण करना काफी कठिन है। सी ++ के लिए, संकलक एक दशक से आमतौर पर हैकर से बेहतर हो गया। C # और Java के लिए, यह और भी आसान है।

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

C ++ / CLI बनाम C # / VB.NET

नोट: इस खंड में, मैं C ++ / CLI के बारे में बात कर रहा हूँ, अर्थात, C ++ .NET द्वारा होस्ट किया गया है, न कि मूल C ++।

पिछले हफ्ते, मेरे पास .NET ऑप्टिमाइज़ेशन पर एक प्रशिक्षण था, और पता चला कि स्थिर संकलक वैसे भी बहुत महत्वपूर्ण है। जेआईटी से ज्यादा महत्वपूर्ण।

C ++ / CLI (या इसके पूर्वज, प्रबंधित C ++) में संकलित बहुत समान कोड C # (या VB.NET, जिसका कंपाइलर C # की तुलना में समान IL) का उत्पादन करता है, उसी कोड से कई गुना तेज हो सकता है।

क्योंकि C ++ स्टेटिक कंपाइलर C # की तुलना में पहले से ही अनुकूलित कोड का उत्पादन करने के लिए बहुत बेहतर था।

उदाहरण के लिए, .NET में फ़ंक्शन इनलाइनिंग उन फ़ंक्शंस तक सीमित है, जिनकी बाइटकोड लंबाई में 32 बाइट्स से कम या बराबर है। तो, C # में कुछ कोड 40 बाइट्स एक्सेसर का उत्पादन करेगा, जो कभी भी JIT द्वारा इनबिल्ड नहीं किया जाएगा। C ++ / CLI में समान कोड 20 बाइट्स एक्सेसर का उत्पादन करेगा, जो कि JIT द्वारा इनबिल्ट किया जाएगा।

एक अन्य उदाहरण अस्थायी चर है, जो सी + कंपाइलर द्वारा अभी भी संकलित किए गए हैं जबकि अभी भी सी / कंपाइलर द्वारा निर्मित आईएल में उल्लेख किया गया है। C ++ स्टैटिक कंप्लायंस ऑप्टिमाइज़ेशन के परिणामस्वरूप कम कोड आएगा, इस प्रकार फिर से अधिक आक्रामक JIT ऑप्टिमाइज़ेशन को अधिकृत करता है।

इसका कारण सी ++ देशी कंपाइलर से विशाल अनुकूलन तकनीकों से संबंधित सी ++ / सीएलआई संकलक होने का अनुमान लगाया गया था।

निष्कर्ष

मुझे C ++ बहुत पसंद है।

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

संपादित करें (2011-06-06)

C # /। NET पर मेरा अनुभव

मेरे पास अब लगभग 5 महीने का है विशेष एक्सक्लूसिव प्रोफेशनल C # कोडिंग (जो C CV और Java से पहले ही मेरे CV में जुड़ जाता है, और C ++ / CLI का एक टच)।

मैंने WinForms (अहम ...) और WCF (कूल!), और WPF (कूल !!!! दोनों XAML और रॉ C # के माध्यम से खेला है। इतना आसान है कि मुझे विश्वास है कि स्विंग सिर्फ इसकी तुलना नहीं कर सकता), और C [4.0]।

निष्कर्ष यह है कि C ++ की तुलना में C # / Java में काम करने वाले कोड का निर्माण करना आसान / तेज है, लेकिन C ++ की तुलना में C # (और जावा में भी कठिन) में एक मजबूत, सुरक्षित और मजबूत कोड का उत्पादन करना बहुत कठिन है। कारण समाप्त हो जाते हैं, लेकिन इसे संक्षेप में प्रस्तुत किया जा सकता है:

1. जेनरिक टेम्प्लेट की तरह शक्तिशाली नहीं हैं ( एक कुशल जेनेरिक पार्स विधि लिखने की कोशिश करें (स्ट्रिंग से टी तक), या बढ़ावा देने के लिए एक कुशल समकक्ष :: समस्या को समझने के लिए C # में lexical_cast )
2. आरए II बेजोड़ बनी हुई है ( जीसी अभी भी लीक कर सकते हैं (हाँ, मुझे लगता है कि समस्या को संभालने के लिए किया था) और केवल स्मृति को संभाल लेंगे। यहां तक कि सी # के usingआसान और शक्तिशाली रूप में नहीं है, क्योंकि एक सही निपटान कार्यान्वयन लेखन मुश्किल है )
3. C # readonlyऔर Java finalC ++ के रूप में कहीं भी उपयोगी नहीं हैconst ( कोई ऐसा तरीका नहीं है कि आप जबरदस्त काम के बिना C # में आसानी से जटिल डेटा (नोड्स का एक पेड़, उदाहरण के लिए) को उजागर कर सकते हैं, जबकि यह C ++ की अंतर्निहित विशेषता है। अपरिवर्तनीय डेटा एक दिलचस्प समाधान है। , लेकिन सब कुछ अपरिवर्तनीय नहीं बनाया जा सकता है, इसलिए यह अभी तक पर्याप्त नहीं है )।

इसलिए, C # जब तक आप काम करते हैं, तब तक एक सुखद भाषा बनी रहती है, लेकिन एक निराशाजनक भाषा जिस क्षण आप कुछ चाहते हैं जो हमेशा और सुरक्षित रूप से काम करता है।

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

इसलिए मुझे लगता है कि अधिकांश कोड के लिए C # / Java का उत्पादकता लाभ दिखाई देता है ... जिस दिन तक आपको कोड की आवश्यकता होती है, जितना संभव हो उतना सही है। उस दिन, आपको दर्द का पता चल जाएगा। (आपको विश्वास नहीं होगा कि हमारे सर्वर और GUI ऐप्स से क्या पूछा गया है ...)।

सर्वर-साइड जावा और C ++ के बारे में

मैंने सर्वर टीमों के साथ संपर्क बनाए रखा (मैंने जीयूआई टीम में वापस आने से पहले उनके बीच 2 साल काम किया), इमारत के दूसरी तरफ, और मैंने कुछ दिलचस्प सीखा।

पिछले वर्षों में, प्रवृत्ति थी कि जावा सर्वर एप्स को पुराने C ++ सर्वर एप्स को बदलने के लिए नियत किया जाता है, क्योंकि जावा में बहुत सारे फ्रेमवर्क / टूल हैं, और इनका रखरखाव, तैनाती आदि करना आसान है।

... जब तक कम-विलंबता की समस्या ने पिछले महीनों में अपने बदसूरत सिर को पाला। फिर, जावा सर्वर ऐप, हमारे कुशल जावा टीम द्वारा किए गए अनुकूलन का कोई फर्क नहीं पड़ता, बस और साफ-सुथरे तरीके से पुराने के खिलाफ दौड़ हार गए, वास्तव में अनुकूलित नहीं C ++ सर्वर।

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

निष्कर्ष

उम्मीद के मुताबिक कुछ भी सरल नहीं है।

जावा, और यहां तक ​​कि अधिक सी #, शांत भाषा हैं, व्यापक मानक पुस्तकालयों और चौखटे के साथ, जहां आप तेजी से कोड कर सकते हैं, और बहुत जल्द परिणाम आ सकते हैं।

लेकिन जब आपको कच्ची शक्ति, शक्तिशाली और व्यवस्थित अनुकूलन, मजबूत संकलक समर्थन, शक्तिशाली भाषा सुविधाएँ और पूर्ण सुरक्षा की आवश्यकता होती है, तो जावा और C # आपको गुणवत्ता के अंतिम लापता लेकिन महत्वपूर्ण खतरों को जीतने के लिए कठिन बनाते हैं जो आपको प्रतियोगिता से ऊपर रहने की आवश्यकता है।

ऐसा लगता है जैसे आपको C ++ की तुलना में C # / Java में कम समय और कम अनुभवी डेवलपर्स की आवश्यकता थी, औसत गुणवत्ता कोड का उत्पादन करने के लिए, लेकिन दूसरी ओर, जिस क्षण आपको उत्तम गुणवत्ता कोड के लिए उत्कृष्ट की आवश्यकता थी, परिणाम प्राप्त करने के लिए यह अचानक आसान और तेज था। C ++ में सही है।

बेशक, यह मेरी अपनी धारणा है, शायद हमारी विशिष्ट आवश्यकताओं तक सीमित है।

लेकिन फिर भी, यह वही है जो आज जीयूआई टीमों और सर्वर-साइड टीमों में होता है।

अगर कुछ नया होता है, तो बेशक मैं इस पोस्ट को अपडेट करूंगा।

संपादित करें (2011-06-22)

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

[...] जावा संस्करण शायद लागू करने के लिए सबसे सरल था, लेकिन प्रदर्शन के लिए विश्लेषण करना सबसे कठिन था। विशेष रूप से कचरा संग्रह के आस-पास के प्रभाव जटिल थे और धुन के बहुत कठिन थे। "

सूत्रों का कहना है:

• https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
• http://www.computing.co.uk/ctg/news/2076322/-winner-google-language-tests

संपादित करें (2011-09-20)

"फेसबुक पर शब्द चल रहा है कि ' यथोचित लिखा सी ++ कोड बस तेजी से चलता है, ' जो PHP और जावा कोड को अनुकूलित करने में खर्च किए गए भारी प्रयास को रेखांकित करता है। विरोधाभासी रूप से, सी ++ कोड अन्य भाषाओं की तुलना में लिखना अधिक कठिन है, लेकिन कुशल कोड एक है। बहुत आसान [C ++ में लिखने के लिए अन्य भाषाओं की तुलना में]। "

- हर्ब Sutter पर // निर्माण / के हवाले से आंद्रेई Alexandrescu

सूत्रों का कहना है:

• http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T
• http://video.ch9.ms/build/2011/slides/TOOL-835T_Sutter.pptx

Comments

आप सी # के 5 महीने बाद संपादित करते हैं, बिल्कुल मेरे अपने अनुभव (बेहतर तरीके से, बेहतर कांस्टेबल, RAII) का वर्णन करता है। +1। वे तीन C ++ (या D, जो मेरे लिए अभी तक नहीं था) के लिए मेरे व्यक्तिगत हत्यारे की विशेषताएं बनी हुई हैं।

— सेबस्टियन मच

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

— जेडी

"प्रकारों के साथ खेलना संकलन समय पर किया जाता है ... जावा या C # में समतुल्य लिखना सबसे अच्छा होता है, और यह हमेशा धीमी गति से और हल किया जाएगा, भले ही संकलन समय पर ज्ञात हों"। C # में, यह केवल संदर्भ प्रकारों के लिए सही है और मूल्य प्रकारों के लिए सही नहीं है।

— जेडी

"कोई बात नहीं जेआईटी ऑप्टिमाइज़ेशन, मेमोरी में डायरेक्ट पॉइंटर एक्सेस के रूप में कुछ भी तेजी से नहीं चलेगा ... यदि आपके पास मेमोरी में डेटा सन्निहित है, तो इसे C ++ पॉइंटर्स (यानी C पॉइंटर्स ... के माध्यम से एक्सेस करना है। चलो सीजर को इसके कारण बताएं) जावा / C # की तुलना में अधिक तेज़ है ”। लोगों ने Java को C ++ को SOR टेस्ट में SciMark2 बेंचमार्क से सटीक रूप से देखा है क्योंकि पॉइंटर्स अलियासिंग-संबंधित अनुकूलन को बाधित करते हैं। blogs.oracle.com/dagastine/entry/sun_java_is_faster_than

— JD

यह भी ध्यान देने योग्य है कि .NET, लिंक करने के बाद गतिशील रूप से जुड़े पुस्तकालयों में जेनरिक के विशेषज्ञता को टाइप करता है जबकि C ++ नहीं कर सकता क्योंकि लिंक करने से पहले टेम्प्लेट को हल करना होगा। और जाहिर है कि बड़े लाभ वाले जेनरिक में टेम्प्लेट्स की अधिकता है, यह त्रुटिहीन त्रुटि संदेश है।

— जेडी

Answer 3

जब भी मैं बनाम अप्रबंधित प्रदर्शन को प्रबंधित करने की बात करता हूं, मैं रीको (और रेमंड) श्रृंखला की ओर इशारा करना पसंद करता हूं, चीनी / अंग्रेजी शब्दकोश के सी ++ और सी # संस्करणों की तुलना करना। यह Google खोज आपको अपने लिए पढ़ने देगा, लेकिन मुझे रिको का सारांश पसंद है।

तो क्या मुझे अपनी करारी हार से शर्म आ रही है? मुश्किल से। प्रबंधित कोड को शायद ही किसी भी प्रयास के लिए एक बहुत अच्छा परिणाम मिला। प्रबंधित रेमंड को हराने के लिए:

• उसकी अपनी फाइल I / O सामान लिखें
• अपनी खुद की स्ट्रिंग क्लास लिखें
• अपने स्वयं के आवंटनकर्ता लिखें
• उसकी खुद की इंटरनेशनल मैपिंग लिखें

बेशक उन्होंने ऐसा करने के लिए उपलब्ध निचले स्तर के पुस्तकालयों का उपयोग किया, लेकिन यह अभी भी बहुत काम है। क्या आप कॉल कर सकते हैं कि एसटीएल प्रोग्राम क्या बचा है? मुझे ऐसा नहीं लगता है, मुझे लगता है कि उन्होंने एसटीडी :: वेक्टर क्लास को रखा था, जो अंततः एक समस्या नहीं थी और उन्होंने खोज फ़ंक्शन रखा। बहुत कुछ बाकी सब चला गया है।

तो, हाँ, आप निश्चित रूप से सीएलआर को हरा सकते हैं। मुझे लगता है कि रेमंड अपने कार्यक्रम को और भी तेजी से आगे बढ़ा सकता है।

दिलचस्प है, फ़ाइल को पार्स करने का समय जैसा कि दोनों कार्यक्रमों द्वारा रिपोर्ट किया गया है आंतरिक टाइमर लगभग प्रत्येक के लिए समान - 30ms है। अंतर ओवरहेड में है।

मेरे लिए लब्बोलुआब यह है कि प्रबंधित संस्करण को हरा देने के लिए अप्रबंधित संस्करण के लिए 6 संशोधन किए गए जो कि मूल अप्रबंधित कोड का एक सरल बंदरगाह था। यदि आपको हर अंतिम प्रदर्शन की आवश्यकता है (और इसे प्राप्त करने के लिए समय और विशेषज्ञता है), तो आपको अप्रबंधित जाना होगा, लेकिन मेरे लिए, मैं 33 से अधिक पहले संस्करणों पर मेरे द्वारा दिए गए परिमाण के लाभ का आदेश लूंगा अगर मैं 6 बार कोशिश करूं तो मुझे फायदा होगा।

Comments

लिंक मर चुका है, उल्लेखित लेख यहां पाया गया: blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx

— gjvdkamp

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

— 18:27

कोशिश करता है या यहां तक ​​कि std :: नक्शा C ++ या यहां तक ​​कि एक हैश तालिका की ओर अधिक अनुकूल रूप से किराया करेगा। अंत में, एक शब्दकोश बिल्कुल कार्यक्रम का प्रकार है जो उच्च-स्तरीय पुस्तकालयों और रूपरेखाओं से सबसे अधिक लाभान्वित होता है। यह भाषा में मतभेदों को प्रदर्शित नहीं करता है, क्योंकि इसमें शामिल पुस्तकालयों (जिनमें से, मैं खुशी से कहूंगा कि C # कहीं अधिक पूर्ण है और कार्य के लिए अधिक उपयुक्त उपकरण प्रदान करता है)। एक प्रोग्राम दिखाएं जो कि बड़े पैमाने पर मैट्रिक्स / वेक्टर कोड की तरह, स्मृति के बड़े ब्लॉक को हेरफेर करता है। कि अगर इस मामले में कोडर्स को पता नहीं है, तो यह बहुत जल्दी सुलझा

— लेगा

Answer 4

विशिष्ट CPU अनुकूलन के लिए संकलन आमतौर पर ओवररेटेड हैं। बस सी ++ में एक कार्यक्रम लें और पेंटियम प्रो के लिए अनुकूलन के साथ संकलित करें और एक पेंटियम 4 पर चलाएं। फिर पेंटियम के लिए अनुकूलन के साथ फिर से मिलाएं। मैंने कई कार्यक्रमों के साथ इसे करते हुए लंबे समय तक काम किया। सामान्य परिणाम ?? आमतौर पर 2-3% से कम प्रदर्शन में वृद्धि होती है। तो सैद्धांतिक जेआईटी फायदे लगभग कोई भी नहीं हैं। प्रदर्शन के अधिकांश अंतर केवल स्केलर डेटा प्रोसेसिंग सुविधाओं का उपयोग करते समय देखे जा सकते हैं, कुछ ऐसा जो अंततः किसी भी तरह अधिकतम प्रदर्शन प्राप्त करने के लिए मैनुअल फाइन ट्यूनिंग की आवश्यकता होगी। उस तरह के अनुकूलन धीमे और महंगे हैं, जिससे उन्हें कभी-कभी जेआईटी के लिए अनुपयुक्त बना दिया जाता है।

वास्तविक दुनिया और वास्तविक एप्लिकेशन C ++ पर आमतौर पर जावा की तुलना में अधिक तेजी से होता है, मुख्यतः लाइटर मेमोरी फुटप्रिंट के कारण जो बेहतर कैश प्रदर्शन का परिणाम है।

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

Comments

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

— बिल के

तो, JITs, रनरथ का अवलोकन करने के लिए रूटीन का पुन: निर्धारण कैसे करते हैं और इससे कितना फर्क पड़ता है?

— डेविड थॉर्नले

@ क्या मैं दो चीजों का मिश्रण कर सकता हूं ... लेकिन क्या निर्देश पाइपलाइन में रन समय पर किया गया शाखा पूर्वानुमान भाषा के समान लक्ष्यों को प्राप्त नहीं करता है?

— हार्डी

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

— बिल के

Answer 5

जेआईटी (जस्ट इन टाइम कंपाइलिंग) अविश्वसनीय रूप से तेज़ हो सकता है क्योंकि यह लक्ष्य प्लेटफ़ॉर्म के लिए अनुकूलन करता है।

इसका मतलब यह है कि यह किसी भी संकलक की चाल का लाभ उठा सकता है जो आपके सीपीयू का समर्थन कर सकता है, चाहे सीपीयू डेवलपर ने कोड पर लिखा हो।

.NET JIT की मूल अवधारणा इस तरह काम करती है (भारी सरलीकृत):

पहली बार एक विधि कॉलिंग:

• आपका प्रोग्राम कोड एक विधि फू कहता है ()
• सीएलआर उस प्रकार को देखता है जो फू () को लागू करता है और इससे जुड़ा मेटाडेटा प्राप्त करता है
• मेटाडेटा से, सीएलआर जानता है कि आईएल (इंटरमीडिएट बाइट कोड) को किस मेमोरी एड्रेस में स्टोर किया गया है।
• CLR मेमोरी का एक ब्लॉक आवंटित करता है, और JIT को कॉल करता है।
• JIT IL को मूल कोड में संकलित करता है, इसे आवंटित मेमोरी में रखता है, और फिर इस मूल कोड को इंगित करने के लिए Foo () के टाइप मेटाडेटा में फ़ंक्शन पॉइंटर को बदलता है।
• देशी कोड भागा है।

दूसरी बार एक विधि को कॉल करना:

• आपका प्रोग्राम कोड एक विधि फू कहता है ()
• सीएलआर उस प्रकार को देखता है जो फू () को लागू करता है और मेटाडेटा में फ़ंक्शन पॉइंटर पाता है।
• इस स्मृति स्थान पर मूल कोड चलाया जाता है।

जैसा कि आप देख सकते हैं, दूसरी बार आसपास, वास्तविक समय अनुकूलन के लाभ को छोड़कर, C ++ जैसी लगभग एक ही प्रक्रिया है।

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

Comments

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

— ब्रायन आर बॉडी

Answer 6

मुझे ओरियन एड्रियन पसंद है का जवाब पसंद है, लेकिन इसका एक और पहलू है।

इसी सवाल को दशकों पहले विधानसभा भाषा बनाम "मानव" भाषाओं जैसे कि फोरट्रान के बारे में बताया गया था। और उत्तर का हिस्सा समान है।

हां, एक C ++ प्रोग्राम किसी भी (गैर-तुच्छ?) एल्गोरिथ्म पर C # से तेज होने में सक्षम है, लेकिन C # में प्रोग्राम अक्सर C ++ में "भोली" कार्यान्वयन की तुलना में अधिक तेज या तेज होगा, और C ++ में एक अनुकूलित संस्करण होगा। विकसित होने में अधिक समय लगेगा, और अभी भी C # संस्करण को बहुत कम अंतर से हरा सकता है। तो, क्या यह वास्तव में इसके लायक है?

आपको एक-एक करके उस प्रश्न का उत्तर देना होगा।

उस ने कहा, मैं C ++ का एक लंबे समय से प्रशंसक हूं, और मुझे लगता है कि यह एक अविश्वसनीय रूप से अभिव्यंजक और शक्तिशाली भाषा है - कभी-कभी अविकसित। लेकिन कई "वास्तविक जीवन" समस्याओं में (मेरे लिए व्यक्तिगत रूप से, इसका मतलब है कि "जिस तरह से मुझे हल करने के लिए भुगतान मिलता है"), सी # जल्दी और सुरक्षित काम करवाएगा।

सबसे बड़ा जुर्माना आप भुगतान करते हैं? कई .NET और जावा प्रोग्राम मेमोरी हॉग हैं। मैंने .NET और जावा ऐप्स को मेगाबाइट्स मेमोरी के "सैकड़ों" लेने के लिए देखा है, जब इसी तरह की जटिलता के सी ++ प्रोग्राम एमबी के "दसियों" को मुश्किल से खरोंचते हैं।

Answer 7

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

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

इसलिए, अत्यधिक दोहराव वाले कोड के लिए, मैं देख सकता था कि हॉटस्पॉट JVM के लिए जावा को C ++ की तुलना में अधिक तेज़ी से चलाना संभव होगा ... जब तक कि कचरा संग्रह खेलने में नहीं आता। :)

Comments

क्या आप दावे पर विस्तार कर सकते हैं Since hand-tuning Assembly is almost always faster than C++ compiled code? "हैंड-ट्यूनिंग असेंबली" और "C ++ संकलित कोड" से आपका क्या अभिप्राय है?

— पीरसेबल

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

— बिलजमदेव १४'११

1. हॉटस्पॉट या किसी अन्य JIT से अनुकूलन अभी भी संकलक अनुकूलन हैं। JIT को कुछ परिणाम (कोड जिसे अक्सर कहा जाता है), या यहां तक ​​कि निष्पादन प्रोसेसर के आधार पर अनुकूलन करने में सक्षम होने के लिए एक स्थिर संकलक पर लाभ होता है, लेकिन यह अभी भी एक संकलक अनुकूलन है। । । 2. मुझे लगता है कि आप एल्गोरिथ्म अनुकूलन के बारे में बात कर रहे हैं, न कि "असेंबली फाइन ट्यूनिंग"। "मानव कोडर द्वारा मैनुअल असेंबली फाइन ट्यूनिंग" एक दशक से अधिक समय से संकलक अनुकूलन से बेहतर परिणाम देने में विफल रहा। वास्तव में, असेंबली के साथ खेलने वाला एक इंसान आमतौर पर किसी भी अनुकूलन को

— खत्म कर देता है

ठीक है, मुझे लगता है कि मैं "स्थिर अनुकूलन" के बजाय गलत शब्दावली, "संकलक अनुकूलन" का उपयोग कर रहा हूं। मैं इंगित करता हूं कि, कम से कम गेमिंग उद्योग में, जैसा कि हाल ही में PS2 के लिए हम अभी भी हाथ में कोडित विधानसभा का उपयोग कर रहे थे, जो हम जानते थे कि कंसोल पर थे विशिष्ट चिप्स के लिए "अनुकूलन" करने के लिए; इन नए चिप्स के लिए क्रॉस-कंपाइलर अभी तक x86 आर्किटेक्चर के लिए परिष्कृत नहीं हैं। उपरोक्त मूल प्रश्न पर वापस जाएं: जेआईटी को अनुकूलन करने से पहले मापने में सक्षम होने का लाभ है, जो कि एक अच्छी बात है (TM)

— बिलजमदेव

ध्यान दें कि अधिकांश उत्पादन GCs हाथ से लिखे कोडांतरक का भी उपयोग करते हैं क्योंकि C / C ++ इसे काटता नहीं है।

— जेडी

Answer 8

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

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

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

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

Answer 9

मैं या तो नहीं जानता ... मेरे जावा प्रोग्राम हमेशा धीमी गति से होते हैं। :-) मैंने कभी भी C # कार्यक्रमों को विशेष रूप से धीमा नहीं देखा है, हालाँकि।

Answer 10

यहां एक और इंटरस्टिंग बेंचमार्क है, जिसे आप खुद अपने कंप्यूटर पर आजमा सकते हैं।

यह ASM, VC ++, C #, सिल्वरलाइट, जावा एप्लेट, जावास्क्रिप्ट, फ्लैश (AS3) की तुलना करता है

Roozz प्लगइन गति डेमो

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

Answer 11

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

• क्या वर्चुअल मशीन अधिक रनटाइम ओवरहेड करती हैं? हाँ!
• क्या वे अधिक काम करने वाली मेमोरी खाते हैं? हाँ!
• क्या उनके पास उच्च स्टार्टअप लागत (रनटाइम इनिशियलाइजेशन और जेआईटी कंपाइलर) है? हाँ!
• क्या उन्हें एक विशाल पुस्तकालय स्थापित करने की आवश्यकता है? हाँ!

और इसी तरह, इसके पक्षपाती, हाँ;)

सी # और जावा के साथ आप जो भी प्राप्त करते हैं उसके लिए एक मूल्य का भुगतान करते हैं (तेजी से कोडिंग, स्वचालित मेमोरी प्रबंधन, बड़ी लाइब्रेरी और इसी तरह)। लेकिन आपके पास विवरणों के बारे में परेशान करने के लिए बहुत जगह नहीं है: पूरा पैकेज लें या कुछ भी नहीं।

यहां तक ​​कि अगर वे भाषा संकलित कोड की तुलना में तेजी से निष्पादित करने के लिए कुछ कोड का अनुकूलन कर सकते हैं, तो संपूर्ण दृष्टिकोण (IMHO) अक्षम है। एक ट्रक के साथ, अपने कार्यस्थल पर हर दिन 5 मील की दूरी पर ड्राइविंग की कल्पना करें! यह आरामदायक है, यह अच्छा लगता है, आप सुरक्षित (चरम crumple ज़ोन) हैं और कुछ समय के लिए गैस पर कदम रखने के बाद, यह एक मानक कार की तरह तेज़ भी होगा! हम सभी के पास काम करने के लिए ड्राइव करने के लिए ट्रक क्यों नहीं है? ;)

C ++ में आपको वह मिलता है जो आप भुगतान करते हैं, अधिक नहीं, कम नहीं।

Bjarne Stroustrup का हवाला देते हुए: "सी ++ मेरी पसंदीदा कचरा एकत्र भाषा है क्योंकि यह इतना कम कचरा उत्पन्न करता है" लिंक पाठ

Comments

ठीक है, मुझे लगता है कि वह अपनी कमियां की एक अच्छा विचार है, उन्होंने यह भी कहा: "सी पैर में अपने आप को गोली मार करने के लिए आसान बनाता है, सी ++ यह मुश्किल है, लेकिन यह बंद अपने पूरे पैर चल रही है जब आप करते हैं";)

— Frunsi

"क्या उन्हें एक विशाल पुस्तकालय स्थापित करने की आवश्यकता है" जावा इस समस्या को परियोजना आरा के साथ संबोधित कर रहा है जो मुझे विश्वास है।

— toc777

"C ++ में आपको वह मिलता है जो आप भुगतान करते हैं, अधिक नहीं, कम नहीं"। काउंटर उदाहरण: मैंने OCaml और C ++ (GNU GCC) में एक RB ट्री कार्यान्वयन को बेंचमार्क किया, जिसने मौजूदा सेट का पुन: उपयोग करने के लिए पहले से ही एक तत्व जोड़ा गया था, तो पुनरावृत्ति से लंबी छलांग लगाने के लिए एक अपवाद का उपयोग किया। OCaml C ++ की तुलना में 6 गुना अधिक तेज था क्योंकि यह डिस्ट्रक्टर्स की जांच के लिए भुगतान नहीं करता है क्योंकि स्टैक अनवाउंड है।

— जेडी

@Jon: लेकिन कुछ (बाद में?) समय में यह किसी भी तरह से वस्तुओं को नष्ट करने के लिए है (कम से कम इसे अपनी स्मृति को जारी करना होगा)। और यह भी ध्यान दें, कि अपवाद असाधारण मामलों के लिए हैं, कम से कम C ++ में कि नियम का सम्मान किया जाना चाहिए। अपवाद होने पर C ++ अपवाद भारी हो सकता है, यह एक व्यापार-बंद है।

— फ्राँसी

@Jon: शायद अपने बेंचमार्क को timesशेल पर दोहराने की कोशिश करें । ताकि यह पूरे कार्यक्रम की जाँच करें, न कि केवल एक पहलू। क्या परिणाम फिर समान हैं?

— फ्राँसी

Answer 12

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

Answer 13

आपके द्वारा पूछे गए विशिष्ट प्रश्न के बारे में कुछ अच्छे उत्तर। मैं पीछे हटना चाहता हूं और बड़ी तस्वीर देखना चाहता हूं।

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

• मैनुअल मेमोरी प्रबंधन सही तरीके से (कोई लीक नहीं) करना मुश्किल है, और यहां तक ​​कि कुशलता से करने के लिए कठिन है (मुफ्त मेमोरी जल्द ही आपके द्वारा किए जाने के बाद)। जीसी का उपयोग करना, सामान्य रूप से, एक प्रोग्राम का उत्पादन करने की अधिक संभावना है जो स्मृति को अच्छी तरह से प्रबंधित करता है। क्या आप GC को आउट-ऑफ करने के प्रयास में, बहुत मेहनत करने और अपने सॉफ़्टवेयर को डिलीवर करने में देरी कर रहे हैं?

• मेरे C ++ की तुलना में मेरा C # पढ़ना और समझना आसान है। मेरे पास खुद को समझाने के और भी तरीके हैं कि मेरा C # कोड सही तरीके से काम कर रहा है। इसका मतलब है कि मैं बग को पेश करने के कम जोखिम के साथ अपने एल्गोरिदम को अनुकूलित कर सकता हूं (और उपयोगकर्ता सॉफ़्टवेयर को पसंद नहीं करते हैं जो दुर्घटनाग्रस्त हो जाते हैं, भले ही यह इतनी जल्दी क्यों न हो!)

• मैं C # की तुलना में C # में अपना सॉफ़्टवेयर तेज़ी से बना सकता हूं। यह प्रदर्शन पर काम करने के लिए समय को मुक्त करता है, और फिर भी समय पर मेरा सॉफ्टवेयर वितरित करता है।

• C ++ की तुलना में C # में अच्छा UI लिखना आसान है, इसलिए जब मैं प्रोग्राम को कुछ समय के लिए ब्लॉक करना चाहता हूं तो यूआई प्रतिक्रियाशील रहने या यूआई को प्रगति या दिल की धड़कन प्रदान करने के लिए पृष्ठभूमि पर काम करने में सक्षम होने की अधिक संभावना है। यह कुछ भी तेज नहीं करता है, लेकिन यह उपयोगकर्ताओं को प्रतीक्षा के बारे में अधिक खुश करता है।

मैंने C # के बारे में जो कुछ भी कहा है वह शायद जावा के लिए सच है, मेरे पास निश्चित रूप से कहने के लिए अनुभव नहीं है।

Answer 14

यदि आप एक जावा / सी # प्रोग्रामर हैं जो C ++ सीख रहे हैं, तो आपको जावा / सी # के बारे में सोचते रहने और Cb वाक्य रचना में शब्दशः अनुवाद करने के लिए लुभाया जाएगा। उस स्थिति में, आपको केवल मूल कोड बनाम व्याख्या / JIT के पहले उल्लिखित लाभ मिलते हैं। C ++ बनाम Java / C # में सबसे बड़ा प्रदर्शन हासिल करने के लिए, आपको C ++ में सोचने के लिए सीखना होगा और विशेष रूप से C ++ की शक्तियों का फायदा उठाने के लिए कोड डिजाइन करना होगा।

एप्रेजर डीजकस्ट्रा को paraphrase करने के लिए : [आपकी पहली भाषा] मन को रिकवरी से परे उत्परिवर्तित करता है। जेफ एटवुड
को पैराफेयर करने के लिए : आप [अपनी पहली भाषा] किसी भी नई भाषा में लिख सकते हैं।

Comments

मुझे संदेह है कि यह कहावत "आप किसी भी भाषा में फोरट्रान लिख सकते हैं" जेफ के करियर की भविष्यवाणी करता है।

— डेविड थॉर्नले 21

Answer 15

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

जावा / सी # में मानक मेमोरी आवंटन भी तेज है, और डीलक्लोकेशन (जीसी) बहुत धीमा नहीं है, लेकिन केवल कम निर्धारक है।

Comments

ध्यान दें कि freeऔर deleteनिर्धारक या तो नहीं हैं और जीसी को आवंटित नहीं करके निर्धारक बनाया जा सकता है।

— JD

Answer 16

वर्चुअल मशीन भाषाओं में संकलित भाषाओं के बेहतर प्रदर्शन की संभावना नहीं है, लेकिन वे पर्याप्त पास प्राप्त कर सकते हैं कि यह कोई फर्क नहीं पड़ता, कम से कम (कम से कम) निम्नलिखित कारणों से (मैं जावा के लिए बोल रहा हूं क्योंकि मैंने कभी भी C # नहीं किया है)।

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

जावा पुस्तकालयों के 2 / विशाल हिस्से को संकलित किया जाता है, ताकि जब आप किसी लाइब्रेरी फ़ंक्शन को कॉल करें, तो आप संकलित कोड निष्पादित कर रहे हैं, व्याख्या नहीं की गई है। आप OpenJDK को डाउनलोड करके कोड (C में) देख सकते हैं।

3 / जब तक आप बड़े पैमाने पर गणना नहीं कर रहे हैं, तब तक आपका कार्यक्रम चल रहा है, यह बहुत धीमे (अपेक्षाकृत बोलने वाले) मानव से इनपुट की प्रतीक्षा कर रहा है।

4 / चूंकि क्लास को लोड करने के समय जावा बाइटकोड का बहुत सत्यापन किया जाता है, रनटाइम चेक का सामान्य ओवरहेड बहुत कम हो जाता है।

5 / सबसे खराब स्थिति में, प्रदर्शन-गहन कोड को संकलित मॉड्यूल से निकाला जा सकता है और जावा से बुलाया जा सकता है (जेएनआई देखें) ताकि यह पूरी गति से चले।

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

Comments

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

— सेरो

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

— ग्वेंटे

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

— लीरन ओरवी

Answer 17

ओरियन एड्रियन , मुझे अपनी पोस्ट को देखने दें कि आपकी टिप्पणी कितनी निराधार है, क्योंकि सी ++ के बारे में बहुत कुछ कहा जा सकता है। और यह बताना कि जावा / सी # संकलक दूर के खाली कार्यों का अनुकूलन करता है वास्तव में आपको ध्वनि देता है जैसे आप नहीं हैं अनुकूलन में मेरे विशेषज्ञ , क्योंकि क) वास्तविक कार्यक्रम में खाली कार्य शामिल होने चाहिए, वास्तव में खराब विरासत कोड के अलावा, ख) जो वास्तव में नहीं है काले और खून बह रहा बढ़त अनुकूलन।

उस वाक्यांश के अलावा, आपने पॉइंटर्स के बारे में स्पष्ट रूप से मूल्यांकन किया है, लेकिन जावा और C # में ऑब्जेक्ट्स मूल रूप से C ++ पॉइंटर्स की तरह काम नहीं करते हैं? क्या वे ओवरलैप नहीं हो सकते? क्या वे अशक्त नहीं हो सकते? C (और अधिकांश C ++ कार्यान्वयन) में प्रतिबंधित कीवर्ड होता है, दोनों में मूल्य प्रकार होते हैं, C ++ में गैर-शून्य गारंटी के साथ संदर्भ-से-मूल्य होता है। Java और C # क्या ऑफर करते हैं?

>>>>>>>>>>

आम तौर पर, C और C ++ केवल तेज या तेज़ हो सकते हैं क्योंकि AOT कंपाइलर - एक कंपाइलर जो कि तैनाती से पहले आपके कोड को संकलित करता है, एक बार और सभी के लिए, आपकी उच्च मेमोरी पर कई कोर बिल्ड सर्वर - अनुकूलन कर सकते हैं कि C # संकलित प्रोग्राम ऐसा नहीं कर सकते क्योंकि ऐसा करने के लिए एक टन का समय है। कंपाइलर यह निर्धारित कर सकता है कि मशीन इंटेल या एएमडी है; पेंटियम 4, कोर सोलो, या कोर डुओ; या अगर SSE4, आदि का समर्थन करता है, और यदि आपका कंपाइलर रनटाइम प्रेषण का समर्थन नहीं करता है, तो आप मुट्ठी भर विशेष बायनेरिज़ को तैनात करके खुद के लिए हल कर सकते हैं।

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

इसके अतिरिक्त कुछ भाषा सुविधाएँ आपके कोड के बारे में धारणा बनाने के लिए C ++ या C में संकलक को अनुमति देती हैं जो इसे कुछ भागों को दूर करने की अनुमति देता है जो सिर्फ जावा / सी # संकलक के लिए सुरक्षित नहीं हैं। जब आपके पास जेनेरिक की पूर्ण प्रकार आईडी या एक गारंटीकृत प्रोग्राम फ्लो तक पहुंच नहीं है, तो बहुत सारे अनुकूलन हैं जो अभी सुरक्षित नहीं हैं।

इसके अलावा C ++ और C कई स्टैक एलोकेशन एक बार में सिर्फ एक रजिस्टर इन्क्रीप्शन के साथ करते हैं, जो निश्चित रूप से Javas और C # एलोकेशन की तुलना में अधिक कुशल है, क्योंकि कचरा कलेक्टर और आपके कोड के बीच अमूर्त की परत के लिए।

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

इसलिए जैसा कि आप देख सकते हैं, ऐसे कुछ कारण हैं जिनके कारण कुछ C ++ या C कार्यान्वयन तेजी से होंगे।

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

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

<<<<<<<<<<

आमतौर पर, कुछ सामान्यीकृत तर्क विशिष्ट पदों में अच्छे लग सकते हैं, लेकिन आम तौर पर विश्वसनीय नहीं लगते।

वैसे भी, शांति बनाने के लिए: AOT महान है, जैसा कि JIT है । एकमात्र सही उत्तर हो सकता है: यह निर्भर करता है। और असली स्मार्ट लोग जानते हैं कि आप दोनों दुनिया के सर्वश्रेष्ठ का उपयोग कर सकते हैं।

Answer 18

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

हालाँकि, वास्तव में ऐसा होने की संभावना बहुत कम है - जब तक कि जावा में बहुत अच्छी तरह से लिखित पुस्तकालय नहीं है, और आपके पास अपनी खराब लिखी सी ++ लाइब्रेरी है।

Comments

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

— ब्रायन आर बॉडी

Answer 19

वास्तव में, C # वास्तव में जावा जैसी वर्चुअल मशीन में नहीं चलता है। IL को असेंबली भाषा में संकलित किया गया है, जो पूरी तरह से देशी कोड है और देशी कोड के समान गति से चलता है। आप एक JIT .NET को प्री-JIT कर सकते हैं जो पूरी तरह से JIT कॉस्ट को हटा देता है और फिर आप पूरी तरह से देशी कोड चला रहे हैं।

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

उन्होंने कहा, प्रबंधित कोड की एक ताकत यह है कि यह पूरी तरह से सत्यापन योग्य हो सकता है, अर्थात। आप यह सत्यापित कर सकते हैं कि कोड आपके द्वारा निष्पादित होने से पहले किसी अन्य प्रक्रिया की मेमोरी तक कभी नहीं पहुंचेगा या चीजों को अनसुना नहीं करेगा। Microsoft के पास पूरी तरह से प्रबंधित ऑपरेटिंग सिस्टम का एक अनुसंधान प्रोटोटाइप है, जिसने आश्चर्यचकित रूप से दिखाया है कि 100% प्रबंधित वातावरण वास्तव में किसी भी आधुनिक ऑपरेटिंग सिस्टम की तुलना में तेजी से प्रदर्शन कर सकता है, इस सुविधा का लाभ उठाकर सुरक्षा सुविधाओं को बंद कर सकता है जिन्हें अब प्रबंधित कार्यक्रमों की आवश्यकता नहीं है। (हम कुछ मामलों में 10x की तरह बात कर रहे हैं)। एसई रेडियो के पास इस परियोजना के बारे में बात करने वाला एक शानदार प्रकरण है।

Answer 20

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

से विकिपीडिया :

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

उस ने कहा, मैंने बहुत सी # और बहुत सी ++ लिखी है, और मैंने बहुत सारे बेंचमार्क चलाए हैं। मेरे अनुभव में, C ++ दो तरह से C # की तुलना में बहुत तेज है: (1) यदि आप कुछ कोड लेते हैं जो आपने C # में लिखे हैं, तो इसे C ++ में पोर्ट करें, जो कि मूल कोड है। तेजी से किया जाना है। कितना तेज? खैर, यह पूरी तरह से भिन्न होता है, लेकिन 100% गति में सुधार देखना असामान्य नहीं है। (२) कुछ मामलों में, कचरा संग्रह बड़े पैमाने पर एक प्रबंधित अनुप्रयोग को धीमा कर सकता है । .NET सीएलआर बड़े ढेर (कहते हैं,> 2 जीबी) के साथ एक भयानक काम करता है, और जीसी में बहुत समय बिताने को समाप्त कर सकता है - यहां तक ​​कि उन अनुप्रयोगों में भी जिनके पास कुछ नहीं है - या यहां तक ​​कि मध्यवर्ती जीवन की वस्तुओं का भी नहीं।

बेशक, ज्यादातर मामलों में जो मैंने सामना किया है, प्रबंधित भाषाएं एक लंबे शॉट से काफी तेज हैं, और सी ++ के अतिरिक्त प्रदर्शन के लिए रखरखाव और कोडिंग ट्रेडऑफ बस एक अच्छा नहीं है।

Comments

समस्या यह है कि लंबे समय तक चलने वाली प्रक्रियाओं के लिए, जैसे कि एक वेब सर्वर, समय के साथ आपकी मेमोरी इतनी खंडित हो जाएगी (C ++ लिखित प्रोग्राम में), आपको कुछ ऐसा लागू करना होगा जो कचरा संग्रह जैसा हो (या हर बार पुनः आरंभ करें, IIS देखें) )।

— टोनी बेनब्राहिम

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

— डेविड थॉर्नले

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

— kyoryu

C / C ++ में आप स्टैक पर छोटी जीवित वस्तुओं को आवंटित कर सकते हैं , और जब आप उचित हो तब करते हैं। प्रबंधित कोड में आप नहीं कर सकते , आपके पास कोई विकल्प नहीं है। इसके अलावा, C / C ++ में आप सन्निहित क्षेत्रों (नई Foo [100]) में वस्तुओं की सूची आवंटित कर सकते हैं , प्रबंधित कोड में भी नहीं कर सकते हैं। तो, आपकी तुलना मान्य नहीं है। खैर, विकल्पों की यह शक्ति डेवलपर्स पर बोझ डालती है, लेकिन इस तरह से वे उस दुनिया को जानना सीखते हैं जिसमें वे रहते हैं (स्मृति ......)।

— फ्रून्सी

@frunsi: "C / C ++ में आप सन्निहित क्षेत्रों में वस्तुओं की सूची आवंटित कर सकते हैं (नया फू [100]), प्रबंधित कोड में आप नहीं कर सकते हैं"। यह गलत है। स्थानीय मान प्रकार स्टैक आबंटित हैं और आप C # में उनमें से सरणियों को भी स्टैक कर सकते हैं। यहां तक ​​कि C # में लिखी गई उत्पादन प्रणालियां भी हैं जो स्थिर अवस्था में पूरी तरह से आवंटन रहित हैं।

— JD

Answer 21

यहाँ एक दिलचस्प बेंचमार्क है http://zi.fi/shootout/

Answer 22

दरअसल सन के हॉटस्पॉट JVM "मिश्रित-मोड" निष्पादन का उपयोग करता है। यह विधि के बाइटकोड की व्याख्या करता है जब तक कि यह निर्धारित नहीं करता है (आमतौर पर किसी प्रकार के काउंटर के माध्यम से) कि कोड का एक विशेष ब्लॉक (विधि, लूप, ट्राइ-कैच ब्लॉक, आदि) को बहुत निष्पादित किया जा रहा है, तो यह JIT इसे संकलित करता है। जेआईटी के लिए आवश्यक समय एक विधि को संकलित करने में अधिक समय लेता है यदि विधि की व्याख्या की जाए तो यह शायद ही कभी चलने वाली विधि हो। प्रदर्शन आमतौर पर "मिश्रित-मोड" के लिए अधिक होता है क्योंकि JVM समय को बर्बाद नहीं करता है JITing कोड जो शायद ही कभी होता है, यदि कभी चलता है। C # और .NET ऐसा नहीं करते हैं। .NET जो कुछ भी, अक्सर, समय बर्बाद करता है, JIT करता है।

Answer 23

एचपी लैब्स के डायनामो के बारे में पढ़ें , PA-8000 के लिए एक दुभाषिया जो PA-8000 पर चलता है, और अक्सर वे जितनी तेजी से देशी करते हैं उससे कहीं ज्यादा तेजी से प्रोग्राम चलाते हैं। तब यह सब आश्चर्यजनक नहीं लगेगा!

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

यह अक्सर नीचे आता है:

• प्रोग्राम में हॉट-स्पॉट होते हैं, इसलिए भले ही आप कोड के शरीर के 95% भाग को धीमा कर रहे हों, आपको अभी भी प्रदर्शन-प्रतिस्पर्धी हो सकता है, यदि आप हॉट 5% पर तेज़ हैं

• एक HLL, C / C ++ जैसे LLL से आपके इरादे के बारे में अधिक जानता है, और इसलिए अधिक अनुकूलित कोड उत्पन्न कर सकता है (OCaml में और भी अधिक है, और व्यवहार में यह और भी तेज़ है)

• एक JIT कंपाइलर में बहुत सारी जानकारी होती है जो एक स्टैटिक कंपाइलर के पास नहीं होती है (जैसे, इस समय आपके पास होने वाला वास्तविक डेटा)

• एक जेआईटी कंपाइलर रन-टाइम पर अनुकूलन कर सकता है जो पारंपरिक लिंकर्स को वास्तव में करने की अनुमति नहीं है (जैसे शाखाओं को फिर से व्यवस्थित करना इसलिए सामान्य मामला फ्लैट है, या लाइब्रेरी कॉल को इनलाइन करना)

सभी सभी में, C / C ++ प्रदर्शन के लिए बहुत ही घटिया भाषाएं हैं: आपके डेटा प्रकारों के बारे में अपेक्षाकृत कम जानकारी, आपके डेटा के बारे में कोई जानकारी नहीं है, और रन-टाइम ऑप्टिमाइज़ेशन के रास्ते में अनुमति देने के लिए कोई गतिशील रनटाइम नहीं है।

Answer 24

जब जावा या सीएलआर C ++ की तुलना में तेज़ होता है, तो आपको कम फटने की समस्या हो सकती है, लेकिन समग्र रूप से प्रदर्शन जीवन के लिए बदतर है: इसके लिए कुछ परिणामों के लिए www.codeproject.com/KB/dotnet/RuntimePerformance.aspx देखें।

Answer 25

यहाँ क्लिफ क्लिक से उत्तर दिया गया है: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain

Answer 26

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

वह अतार्किक है। एक मध्यवर्ती प्रतिनिधित्व का उपयोग स्वाभाविक रूप से प्रदर्शन को नीचा नहीं करता है। उदाहरण के लिए, llvm-gcc देशी कोड में LLVM IR (जो एक आभासी अनंत-रजिस्टर मशीन है) के माध्यम से C और C ++ को संकलित करता है और यह उत्कृष्ट प्रदर्शन (अक्सर GCC को हराकर) प्राप्त करता है।

शायद यह एक भाषा के प्रश्न की तुलना में अधिक संकलित प्रश्न है, लेकिन क्या कोई स्पष्ट अंग्रेजी में बता सकता है कि इन आभासी मशीन भाषाओं में से एक के लिए एक मूल भाषा से बेहतर प्रदर्शन करना कैसे संभव है?

यहाँ कुछ उदाहरण हैं:

• JIT संकलन वाली वर्चुअल मशीनें रन-टाइम कोड जनरेशन (जैसे System.Reflection.Emit.NET पर) की सुविधा प्रदान करती हैं, इसलिए आप C # और F # जैसी भाषाओं में जनरेट कोड को मक्खी पर संकलित कर सकते हैं, लेकिन C या ++ में तुलनात्मक रूप से धीमा दुभाषिया लिखने का सहारा लेना चाहिए। उदाहरण के लिए, नियमित अभिव्यक्ति को लागू करने के लिए।

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

• देशी कोड के डायनेमिक लिंकिंग को एक ABI के अनुरूप होना आवश्यक है जो प्रदर्शन को बाधित कर सकता है और पूरे प्रोग्राम ऑप्टिमाइज़ेशन को कम कर सकता है, जबकि लिंकिंग को आमतौर पर वीएम पर स्थगित कर दिया जाता है और पूरे प्रोग्राम ऑप्टिमाइज़ेशन (जैसे .NET के रिवाइज्ड जेनरिक) से लाभ मिल सकता है।

मैं ऊपर पियरसेबल के अत्यधिक उत्तोलित उत्तर के साथ कुछ मुद्दों को संबोधित करना चाहूंगा (क्योंकि कोई व्यक्ति अपने उत्तर पर मेरी टिप्पणियों को हटाता रहता है) जो एक प्रति-उत्पादक ध्रुवीकृत दृश्य प्रस्तुत करता है:

संकलन समय पर कोड प्रसंस्करण किया जाएगा ...

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

... प्रकारों के साथ खेलना संकलन समय पर किया जाता है ... जावा या C # में समतुल्य लिखना सबसे अच्छा होता है, और हमेशा संकलन के समय धीमी गति से हल किया जाएगा और तब भी जब प्रकार ज्ञात हो।

C # में, यह केवल संदर्भ प्रकारों के लिए सही है और मूल्य प्रकारों के लिए सही नहीं है।

JIT ऑप्टिमाइज़ेशन से कोई फर्क नहीं पड़ता है, मेमोरी में डायरेक्ट पॉइंटर एक्सेस के रूप में कुछ भी फास्ट नहीं होगा ... यदि आपके पास मेमोरी में डेटा सन्निहित है, तो इसे C ++ पॉइंटर्स (यानी C पॉइंटर्स ... लेट से सीज़र को इसकी वजह से एक्सेस करना) कई गुना तेज हो जाएगा। जावा / सी # की तुलना में।

लोगों ने अवलोकन किया SciMark2 बेंचमार्क से SOR टेस्ट पर जावा बी + सी पिटाई सटीक रूप से देखा है क्योंकि पॉइंटर्स अलियासिंग-संबंधित अनुकूलन को बाधित करते हैं।

यह भी ध्यान देने योग्य है कि .NET, लिंक करने के बाद गतिशील रूप से जुड़े पुस्तकालयों में जेनरिक के विशेषज्ञता को टाइप करता है जबकि C ++ नहीं कर सकता क्योंकि लिंक करने से पहले टेम्प्लेट को हल करना होगा। और जाहिर तौर पर बड़े लाभ वाले जेनरिक में टेंपरेचर अधिक है, यह एक त्रुटि संदेश है।

Answer 27

कुछ अन्य लोगों ने मेरी समझ से ऊपर कहा, .NET और जावा मेमोरी आवंटन में बेहतर हैं। उदाहरण के लिए, वे मेमोरी को कॉम्पैक्ट कर सकते हैं क्योंकि यह C ++ नहीं हो सकता (मूल रूप से, लेकिन यह तब हो सकता है जब आप एक चतुर कचरा संग्राहक का उपयोग कर रहे हों)।

Comments

या यदि आप वस्तुओं के बेहतर C ++ आवंटनकर्ता और / या पूल का उपयोग कर रहे हैं। यह C ++ दृश्य बिंदु से जादू से दूर है, और यह "ढेर आवंटन" के रूप में तेजी से ढेर आवंटन हो सकता है।

— पियरसेबल

यदि आप हमेशा हीप पर सब कुछ आवंटित करते हैं, तो .NET और Java C / C ++ से बेहतर प्रदर्शन कर सकते हैं। लेकिन आप सिर्फ C / C ++ में ऐसा नहीं करेंगे।

— फ्रून्सी

Answer 28

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

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

हालांकि, C ++ का लाभ यह है कि यह आपको अपने आप को अनुकूलित करने की अनुमति देता है, अन्यथा आप संकलक / jvm के साथ फंस जाते हैं। यदि आप अपने खुद के कंटेनर बनाते हैं, तो अपने स्वयं के मेमोरी प्रबंधन को लिखें जो कि संरेखित है, SIMD का उपयोग करें, और यहां और वहां असेंबली करने के लिए ड्रॉप करें, आप कम से कम 2x-4x बार गति कर सकते हैं जो कि अधिकांश C ++ कंपाइलर अपने दम पर करेंगे। कुछ संचालन के लिए, 16x-32x। यह उसी एल्गोरिदम का उपयोग कर रहा है, यदि आप बेहतर एल्गोरिदम का उपयोग करते हैं और समानांतर करते हैं, तो नाटकीय रूप से बढ़ सकता है, कभी-कभी हजारों बार तेजी से होता है जो आमतौर पर उपयोग किए जाने वाले तरीके हैं।

Answer 29

मैं इसे कुछ अलग बिंदुओं से देखता हूं।

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

Answer 30

एक बहुत ही कम जवाब: एक निश्चित बजट को देखते हुए आप एक C ++ एप्लिकेशन (ROI विचार) की तुलना में बेहतर प्रदर्शन करने वाले जावा एप्लिकेशन को प्राप्त करेंगे। इसके अलावा जावा प्लेटफॉर्म में अधिक अच्छे प्रोफाइलर्स हैं, जो आपके हॉटस्पॉट्स को अधिक तेज़ी से पिन करने में आपकी मदद करेंगे।