ए। आज जावा की गति C ++ की तुलना कैसे करती है?
नापना मुश्किल। यह ध्यान देने योग्य है कि कार्यान्वयन की गति का एक प्रमुख हिस्सा, यह मेमोरी एलोकेटर है, जावा और सी ++ में बहुत अलग एल्गोरिदम हैं। कलेक्टर की गैर-नियतात्मक प्रकृति, C ++ की निर्धारक स्मृति प्रबंधन की तुलना में सार्थक प्रदर्शन डेटा प्राप्त करना बहुत कठिन बना देती है, क्योंकि आप कभी भी निश्चित नहीं हो सकते हैं कि कलेक्टर किस राज्य में है। इसका मतलब है कि बेंचमार्क लिखना बहुत कठिन है। जो सार्थक रूप से उनकी तुलना कर सकता है। कुछ मेमोरी एलोकेशन पैटर्न जीसी के साथ बहुत तेजी से चलते हैं, कुछ देशी एलोकेटर के साथ बहुत तेजी से चलते हैं।
हालाँकि, मैं यह कहूंगा कि जावा जीसी को हर हाल में तेजी से चलना है। हालाँकि, एक देशी आवंटनकर्ता को एक उपयुक्त वस्तु की अदला-बदली की जा सकती है। मैंने हाल ही में SO पर एक सवाल रखा है कि क्यों एक C # Dictionaryएक बराबर की तुलना में (मेरी मशीन पर 0.45 ms) निष्पादित कर सकता हैstd::unordered_mapजो (मेरी मशीन पर 10ms) पर निष्पादित किया गया। हालाँकि, अधिक उपयुक्त लोगों के लिए बस आबंटक और हैशर की अदला-बदली करके, मैंने उस निष्पादन समय को अपनी मशीन पर 0.34ms कर दिया- मूल रन-टाइम का तीसवां भाग। आप कभी भी जावा के साथ उस तरह के कस्टम अनुकूलन करने की उम्मीद नहीं कर सकते हैं। एक उत्कृष्ट उदाहरण जहां यह वास्तविक अंतर पैदा कर सकता है, वह है थ्रेडिंग। टीबीबी जैसे मूल धागा पुस्तकालय थ्रेड-कैशिंग आवंटन प्रदान करते हैं जो पारंपरिक आवंटनकर्ताओं की तुलना में बड़े पैमाने पर तेजी से होते हैं जब कई थ्रेड्स पर कई आवंटन से निपटते हैं।
अब, कई लोग जेआईटी सुधार के बारे में बात करेंगे और जेआईटी के पास अधिक जानकारी कैसे होगी। यकीन है, यह सच है। लेकिन यह अभी भी दूर नहीं है कि एक C ++ कंपाइलर क्या खींच सकता है- क्योंकि कंपाइलर में, अंतिम प्रोग्राम के रन-टाइम के परिप्रेक्ष्य से, तुलनात्मक रूप से, अनंत समय और स्थान होता है। हर चक्र और हर बाइट जो कि JIT यह सोचकर खर्च करता है कि आपके प्रोग्राम को कैसे ऑप्टिमाइज़ किया जाए, एक चक्र है कि आपका प्रोग्राम एक्जीक्यूटिंग खर्च नहीं कर रहा है और इसका उपयोग खुद की मेमोरी की जरूरत के लिए नहीं कर सकता है।
इसके अलावा, हमेशा ऐसे समय होंगे जहां कंपाइलर और जेआईटी ऑप्टिमाइज़ेशन कुछ ऑप्टिमाइज़ेशन साबित नहीं कर सकते हैं- विशेष रूप से भागने के विश्लेषण जैसी चीजों के मामले में। C ++ में, जैसा कि मूल्य वैसे भी स्टैक पर है , कंपाइलर को इसे प्रदर्शन करने की आवश्यकता नहीं है। इसके अलावा, साधारण चीजें हैं, जैसे सन्निहित स्मृति। यदि आप C ++ में एक सरणी आवंटित करते हैं, तो आप एक एकल, सन्निहित सरणी आवंटित करते हैं। यदि आप जावा में एक सरणी आवंटित करते हैं, तो यह बिल्कुल भी सन्निहित नहीं है, क्योंकि सरणी केवल पॉइंटर्स से भरी हुई है जो कहीं भी इंगित कर सकती है। यह न केवल दोहरे अप्रत्यक्ष के लिए एक मेमोरी और टाइम ओवरहेड है, बल्कि कैश ओवरहेड्स भी है। इस तरह की बात यह है कि जावा का भाषा शब्दार्थ केवल इतना ही लागू करता है कि इसे बराबर C ++ कोड से धीमा होना चाहिए।
अंततः, मेरा व्यक्तिगत अनुभव यह है कि जावा औसतन C ++ की आधी गति हो सकती है। हालाँकि, मौलिक रूप से भिन्न एल्गोरिदम में शामिल होने के कारण, अत्यंत व्यापक बेंचमार्क सूट के बिना किसी भी प्रदर्शन विवरण को वापस लेने का कोई तरीका नहीं है।
ख। क्या जावा का उपयोग करके आधुनिक AAA शीर्षक बनाना संभव होगा?
मुझे लगता है कि आप "खेल" का मतलब है, यहाँ, और एक मौका नहीं है। सबसे पहले, आपको लगभग सभी मौजूदा पुस्तकालयों और बुनियादी ढांचे के लक्ष्य C ++ के रूप में अपने आप को खरोंच से सब कुछ लिखना होगा। जब तक कि इसे प्रति से असंभव नहीं बनाया जा सकता, यह निश्चित रूप से अक्षम्य के प्रति ठोस योगदान दे सकता है। दूसरे, यहां तक कि सी ++ इंजन भी मौजूदा कंसोल की छोटी मेमोरी बाधाओं में शायद ही फिट हो सकते हैं- अगर जेवीएम उन कंसोलों के लिए भी मौजूद हैं- और पीसी गेमर्स उनकी मेमोरी के लिए थोड़ी अधिक उम्मीद करते हैं। कलाकार एएए गेम बनाना सी ++ में काफी कठिन है, मैं नहीं देखता कि यह जावा में कैसे हासिल किया जा सकता है। किसी ने कभी गैर-संकलित भाषा में बिताए महत्वपूर्ण समय के साथ एएए खेल नहीं लिखा है। इससे अधिक, यह केवल अत्यंत त्रुटिपूर्ण होगा। उदाहरण के लिए, GPU संसाधनों- और जावा में, आपके साथ काम करते समय नियतात्मक विनाश आवश्यक है
सी। किन क्षेत्रों में विशेष रूप से जावा ++ की तुलना में धीमा है, यदि सभी पर? (यानी नंबर-क्रंचिंग, ग्राफिक्स या चारों ओर)
मैं निश्चित रूप से सभी के लिए जाना होगा। सभी जावा ऑब्जेक्ट्स के लागू-संदर्भ प्रकृति का मतलब है कि जावा में C ++ करता है की तुलना में कहीं अधिक अप्रत्यक्ष और संदर्भ हैं- उदाहरण मैंने पहले सरणियों के साथ दिया था, लेकिन सभी सदस्य वस्तुओं पर भी लागू होता है, उदाहरण के लिए। जहां C ++ कंपाइलर निरंतर समय में एक सदस्य चर को देख सकता है, जावा रन-टाइम को किसी अन्य पॉइंटर का पालन करना पड़ता है। जितना अधिक आप करते हैं, उतना ही धीमे होने वाला है, और इसके बारे में JIT कुछ भी नहीं कर सकता है।
जहाँ C ++ लगभग तुरंत मेमोरी के टुकड़े को फ्री और री-यूज़ कर सकती है, जावा में आपको कलेक्शन का इंतज़ार करना होगा, और मुझे उम्मीद है कि टुकड़ा कैश से बाहर नहीं गया, और स्वाभाविक रूप से अधिक मेमोरी की आवश्यकता होती है जिसका मतलब है कम कैश और पेजिंग प्रदर्शन। फिर मुक्केबाजी और अनबॉक्सिंग जैसी चीजों के लिए शब्दार्थ को देखें। जावा में, यदि आप एक इंट का संदर्भ लेना चाहते हैं, तो आपको इसे गतिशील रूप से आवंटित करना होगा। यह C ++ शब्दार्थ की तुलना में एक अंतर्निहित अपशिष्ट है।
फिर आपको जेनेरिक समस्या है। जावा में, आप केवल रन-टाइम वंशानुक्रम के माध्यम से सामान्य वस्तुओं पर काम कर सकते हैं। C ++ में, टेम्प्लेट का शाब्दिक रूप से शून्य ओवरहेड है - कुछ जावा मेल नहीं खा सकता है। इसका मतलब है कि जावा में सभी सामान्य कोड स्वाभाविक रूप से C ++ में एक सामान्य समकक्ष की तुलना में धीमी हैं।
और फिर आप अपरिभाषित व्यवहार पर आते हैं। जब उनका कार्यक्रम यूबी प्रदर्शित करता है, तो हर कोई इससे नफरत करता है, और हर कोई चाहता है कि यह मौजूद नहीं था। हालांकि, यूबी मौलिक रूप से उन अनुकूलन को सक्षम करता है जो जावा में कभी मौजूद नहीं हो सकते। पर एक नजर डालें इस पद यूबी के आधार पर अनुकूलन का वर्णन। व्यवहार को परिभाषित नहीं करने का अर्थ है कि कार्यान्वयन अधिक अनुकूलन कर सकते हैं और उन परिस्थितियों की जांच के लिए आवश्यक कोड को कम कर सकते हैं जो C ++ में अपरिभाषित होंगे लेकिन जावा में परिभाषित किए गए हैं।
मौलिक रूप से, जावा का शब्दार्थ यह बताता है कि यह C ++ की तुलना में धीमी भाषा है।
क्या जावा अब एक संकलित भाषा या व्याख्या की गई भाषा मानी जाती है?
यह वास्तव में उन समूहों में से किसी में फिट नहीं है। मैं कहूंगा कि प्रबंधित वास्तव में अपने आप में एक अलग श्रेणी है, हालांकि मैं कहूंगा कि यह निश्चित रूप से संकलित भाषा की तुलना में एक व्याख्या की गई भाषा की तरह है। इससे भी महत्वपूर्ण बात यह है कि बहुत अधिक केवल दो प्रमुख प्रबंधित सिस्टम, JVM और CLR हैं, और जब आप "प्रबंधित" कहते हैं तो यह पर्याप्त स्पष्ट है।
जावा की कुछ प्रमुख कमियां हैं जो शुरुआती दिनों से संबोधित की गई हैं?
स्वचालित बॉक्सिंग और अनबॉक्सिंग केवल एक चीज है जिसके बारे में मुझे पता है। जेनरिक कुछ मुद्दों को हल करता है, लेकिन कई से बहुत दूर।
जावा की कुछ प्रमुख कमियाँ हैं जिन्हें अभी तक संबोधित नहीं किया जा सका है।
उनके जेनेरिक बहुत, बहुत कमजोर हैं। C # की जेनरिक काफी मजबूत हैं- हालांकि, न तो काफी टेम्प्लेट हैं। नियतात्मक विनाश एक और बड़ी कमी है। लैम्ब्डा / क्लोजर का कोई भी रूप भी एक बड़ी समस्या है- आप जावा में एक कार्यात्मक एपीआई भूल सकते हैं। और, ज़ाहिर है, हमेशा उन क्षेत्रों के लिए प्रदर्शन का मुद्दा होता है, जिनकी उन्हें आवश्यकता होती है।