Scala को C या C ++ के साथ क्यों नहीं लागू किया गया

Question

क्या किसी को पता है कि सी या सी ++ के बजाय जावा और .NET में स्काला क्यों लागू किया गया था? अधिकांश भाषाओं को कोर C ++ [यानी एरलंग, पायथन, पीएचपी, रूबी, पर्ल] के साथ लागू किया जाता है। जावा और .NET पुस्तकालयों तक पहुँच देने के अलावा जावा और .NET में लागू स्काला के लिए क्या फायदे हैं?

अद्यतन करें

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

Comments

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

— तमसे सजेलेई

@OP: आप बोलते हैं जैसे कि JVM (या उस मामले के लिए CLR) के शीर्ष पर लागू होने वाली भाषा का बुरा होना। सी में संभव है कि ट्यूनिंग सीएलआर या जेवीएम में ट्यूनिंग की मात्रा के पास कहीं नहीं है। और अगर मंच में सुधार होता है, तो आपकी भाषा स्वचालित रूप से मुफ्त में प्राप्त करती है। पसंद को देखते हुए, किसी को भी अपनी भाषा को अच्छी तरह से लागू नहीं किया जाना चाहिए।

— Chii

@ चाही, बस यह स्वीकार करते हैं, जावा अभी भी सी की तुलना में धीमी है

— जोशुआ पर्योगी

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

— लॉजिक

स्काला का रनटाइम वातावरण C ++ प्रोग्राम है; जेवीएम।

— माइक

Answer 1

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

पूछे गए प्रश्न का उत्तर देना:

Scala को C या C ++ में लागू नहीं किया गया क्योंकि Scala, जिस भाषा में वास्तव में लागू किया गया है, वह बहुत बेहतर भाषा है।

यह बेहतर क्यों है? खैर, स्कला भाषा के लिए ओडस्की के लक्ष्यों के बारे में पढ़ें ।

उस प्रश्न का उत्तर देना जिसका उद्देश्य हो सकता है:

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

मुझे उस अंतिम बात को दोहराना चाहिए: जेवीएम उस कोड में मशीन कोड हॉट स्पॉट को संकलित करेगा जो वह चल रहा है। यह उसी तरह संकलित है जैसे C और C ++ कंपाइलर करते हैं।

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

उस प्रश्न का उत्तर देना, जो पूछा जाना चाहिए था:

मशीन कोड का संकलन JVM बायटेकोड के संकलन के लिए पर्याप्त लाभ प्रदान नहीं करता है।

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

ध्यान दें कि स्काला विशेष रूप से अच्छी स्क्रिप्टिंग भाषा नहीं है, क्योंकि शॉर्ट-रनिंग प्रोग्राम के लिए ओवरहेड बहुत बड़ा है।

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

इसलिए, कोई फर्क नहीं पड़ता कि सवाल स्काला कंपाइलर के मशीन कोड निष्पादन योग्य होने के बारे में था , या स्काला प्रोग्राम मशीन कोड होने के नाते, संभावित गति लाभ, वास्तविक गति लाभ में अनुवाद नहीं करता है ।

और जिस तरह से,

मैं आपको एक काउंटर-उदाहरण दूंगा: हास्केल। हास्केल मशीन कोड उत्पन्न करता है, और, फिर भी, हास्केल कार्यक्रम स्काला की तुलना में डेबियन की गोलीबारी पर खराब होता है। यह देखते हुए कि क्या किसी को यकीन है कि स्काला प्रोग्राम तेज होंगे अगर सीधे मशीन कोड में संकलित किया जाए?

Comments

@ mike30 स्काला किसी भी JVM पर चलेगा, भले ही वह C ++ में न लिखा गया हो, ताकि तर्क पकड़ में न आए। और, रन टाइम में, कोई C ++ कोड नहीं है, बस मशीन कोड है। मुझे यकीन नहीं है कि यह टिप्पणी किस बारे में है, हालांकि।

— डैनियल सी। सोबरल

वास्तविक बिंदु यह है: मशीन कोड जनरेट करना बाइट-कोड की तुलना में काफी अधिक जटिल है और इसके लिए हर ओएस के साथ-साथ सीपीयू और डिफरेंशियल आर्किटेक्चर (ARM, x86, x86_64) और उन्नत निर्देशों (MMX, SSE) पर एक विशिष्ट कार्यान्वयन की आवश्यकता होती है। ...)। तो इस तरह से यह पहलू जेवीएम को सौंप दिया गया है।

— राफेलो

यदि आप निष्पादन प्रदर्शन के बारे में इतना बोलते हैं, तो आप मेमोरी प्रदर्शन के बारे में क्यों नहीं बोलते हैं? क्या आप डरते हैं कि आपकी कल्पना के अनुसार चीजें बाहर नहीं आ सकती हैं?

— luke1985

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

— डैनियल सी। सोबरल

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

— डैनियल सी। सोबरल

Answer 2

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

• कई अलग-अलग तरीके हैं जो पुस्तकालयों के साथ बातचीत करना चाहते हैं जो कई उच्च-स्तरीय भाषाओं के साथ संगत नहीं हैं। उदाहरण के लिए यदि पुस्तकालय एक पॉइंटर को चाहता है struct, तो बिना पॉइंटर्स और नो structएस वाली भाषाओं का कैसे करें ?
• विभिन्न पुस्तकालयों और भाषाओं के मेमोरी मॉडल के बीच कठोर इंटरैक्शन होते हैं जो अक्सर resolvable नहीं होते हैं या, अगर resolvable होते हैं, तो अत्यधिक त्रुटि होती है- और बग-प्रवण।
• कई एफएफआई के लिए गोंद कोड गैर-तुच्छ है और यह मानता है कि वास्तव में, सार्वभौमिक नहीं हो सकता है। (मानो या ना मानो, सभी प्रोग्रामर C गुरु नहीं हैं, और न ही वे बनना चाहते हैं और न ही उन्हें होना चाहिए!)

यह C ++ के साथ और भी खराब हो जाता है। C ++ समान प्लेटफ़ॉर्म (!) पर संकलक से संकलक तक, C ++ (एक बाइनरी स्तर पर, मेरा मतलब है) के साथ भी संगत नहीं है, अन्य भाषाओं के साथ उल्लेख करने के लिए नहीं।

JVM को लक्षित करना आपको जावा-आधारित पुस्तकालयों के बिल्कुल विशाल सुइट तक पहुँच प्रदान करते हुए इनमें से कई समस्याओं को हल करता है । (कितना भारी है? बस शुरुआत के लिए अपाचे सॉफ्टवेयर फाउंडेशन के विशाल चयन की गुंजाइश है ।)

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

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

सीएलआर इसी तरह की ताकत प्रदान करता है, लेकिन यह जोड़ता है कि आईएमओ एक कमजोरी है: यह बहुत अधिक विक्रेता लॉक-इन वातावरण है। (हां, मैं मोनो के बारे में जानता हूं। मुझे अभी भी लगता है कि यह एक विक्रेता लॉक-इन वातावरण है।)

Comments

आपको पता चलता है कि C # और CLR वास्तव में एक खुला मानक है जिसका कोई भी उपयोग कर सकता है।

— एरिन

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

— बस मेरी सही जनमत

@ नेट फ्रेमवर्क के सभी नहीं है, हालांकि

— वैकल्पिक

@alternative: यदि वह बहुत अधिक लॉकिन है, तो विचार करें कि जावा अनुरूपता परीक्षण अभी भी मुफ्त नहीं हैं, और यह जावा के लिए सबसे अच्छा 6 में से एक, आधा दर्जन से अधिक है।

— डेडुप्लिकेटर

Answer 3

इस साक्षात्कार के अनुसार , मौजूदा जावा बुनियादी ढांचे और पुस्तकालयों तक पहुंच प्राथमिक कारण था।

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

इसलिए मैंने फैसला किया कि भले ही मैं एक ऐसी भाषा डिजाइन करना चाहता था जो जावा से अलग थी, यह हमेशा जावा इन्फ्रास्ट्रक्चर से जुड़ेगी - जेवीएम और इसके पुस्तकालयों से । यह विचार था ...

Answer 4

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

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

Comments

वर्णित फायदे कुछ ऐसे कारण हैं, जैसे कि जेवीएम (जाइथन) और .NET (आयरनपाइथन) दोनों के लिए अजगर को फिर से लागू किया गया है।

— डांसक

-1: यह मानते हुए कि नई भाषाएँ किसी विशिष्ट प्लेटफ़ॉर्म (.Net या JVM) पर निर्भर हो सकती हैं क्योंकि वे उपलब्ध होंगी जो मेरे लिए एक अच्छे तर्क की तरह नहीं दिखेंगी। उदाहरण के लिए, मैं न तो पायथन या एर्लैंग के लिए इस तरह के प्लेटफॉर्म पर चलने का कोई अच्छा कारण देखता हूं। हिस्टरी यह सब नहीं कहती।

— केलेम

और यहां तक ​​कि PHP कभी भी वह नहीं कर पाएगी जो वह JVM या .Net पर करती है। @ डीन हार्डिंग> मुझे नहीं लगता कि आयरनप्यटन या जेथॉन ने कुछ भी साबित नहीं किया।

— केलेम

खेद है कि मुझे स्पष्ट नहीं था, मेरा मतलब है कि यह नहीं होता कि यह "सफलता" (PHP या पायथन) है क्योंकि JVM या .Net पर काम करने से बहुत सारी चीजें प्रभावित होती हैं, जिससे बहुत सारे विकासकर्ता नाराज हो जाते। वर्तमान में वे जितना जानते हैं उससे कहीं अधिक आला भाषा। तकनीकी पक्ष पर, प्लेटफ़ॉर्म (.Net या JVM) एक समस्या होती, क्योंकि यह आपके द्वारा भाषा बनाने के तरीके को चलाता है। मशीन के साथ मंचन करने का एक तरीका है जिसे आप चाहते हैं। तो JVM के साथ या उसके बिना उपलब्ध, मुझे .Net और JVM बनाने का 0 अच्छा कारण दिखाई देता है। तेजी से कार्यान्वयन के अलावा।

— खली

छोटा सुधार: जावा PHP से पुराना है। लेकिन PHP ने CGI प्रोग्राम के रूप में शुरू किया, बाद में एक अपाचे httpd मॉड्यूल बन गया और जैसे यह बड़ा हो गया। दोनों चीजें (cgi और httpd मॉड्यूल) जावा के लिए अच्छा काम नहीं करती हैं। इसलिए चीजें इतनी आसान नहीं हैं, एक जेवीएम सब कुछ के लिए मंच नहीं है। ;-)

— जोहान्स

Answer 5

सी कोड मूल रूप से देशी कोड (मशीन कोड) के लिए संकलित है ।

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

स्काला कोड --- स्टेटिक रूप से संकलित ---> जेवीएम बाइट कोड --- डायनेमिक रूप से संकलित-जेवीएम-हॉटस्पॉट-से ---> मूल कोड

किसी भी भाषा को बनाने / चलाने के सामान्य विकल्प:

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

आपका प्रश्न: "सी इंटरमीडिएट कोड के साथ (बी) के बजाय एक जेवीएम के साथ जावा (डी) का उपयोग क्यों करता है?"

उत्तर:

सबसे पहले, यह देखिए कि स्काला बहुत हैC की तुलना में उच्च स्तरीय भाषा, प्रोग्रामिंग शक्ति प्रदान करना, प्रोग्रामिंग और सुगमता को कम करना। यह प्रथम श्रेणी और उच्च क्रम के कार्यों के कारण जावा की तुलना में '1 स्तर अधिक' है, अंतर्निहित कार्य, ऑब्जेक्ट्स, क्लोजर और करी के रूप में कार्य, तेजी से स्टैक-संरक्षण छोरों के संकलन के लिए पूंछ-पुनरावृत्ति के लिए समर्थन, ऑब्जेक्ट के रूप में सब कुछ, सभी ऑपरेटर जो पुस्तकालयों, केस कक्षाओं और कमी (पैटर्न मिलान), अंतर्निहित प्रकार व्युत्पत्ति, विस्तारित बहु-विरासत वाले लक्षणों और विस्तारित जेनरिक के माध्यम से मजबूत बहुरूपता, जोड़े और ट्यूलिप और विपक्ष (सूचियों और पेड़ों) के लिए अंतर्निहित सिंटैक्स में हो सकता है (फिर से)। ) और नक्शे, इम्यूलेटाइल डेटा संरचनाओं के लिए समर्थन, शक्तिशाली 'प्रतिक्रियाशील' समानांतर और समवर्ती कंप्यूटिंग के लिए समर्थन संदेश की नकल और अभिनेताओं के बीच गुजरने के साथ, मनमाना डोमेन-विशिष्ट DSLs, स्क्रिप्टबिलिटी और REPL के लिए उन्नत समर्थन। ऑब्जेक्ट-ओरिएंटेशन, पॉइंटर मैनेजमेंट और गारबेज कलेक्शन, स्ट्रिंग सपोर्ट, मल्टी-थ्रेडिंग सपोर्ट और कंसीडर कंट्रोल, प्लस स्टैंडर्ड API लाइब्रेरी के कारण जावा का '1 लेवल हाई' है।

1. प्रदर्शन: उच्च स्तरीय भाषा के लिए, (d) (a) की तुलना में तेज़ प्रदर्शन देता है।
   सीधे लिखा और हाथ से अनुकूलित सी कोड तेज है। हालाँकि, उच्च स्तर की भाषाएं, जो C से संकलित हैं, अपेक्षाकृत धीमी हैं। जावा डिजाइनर इसे अच्छी तरह से जानते थे। उनका वर्तमान "हॉटस्पॉट" डिजाइन परिमाण के क्रम तक प्रदर्शन को बढ़ाता है। एक ही कोर पर, जावा हॉटस्पॉट कोड मानव-अनुकूलित सी के रूप में 'सबसे तेज' के रूप में औसत '50% पर है (सबसे अच्छी बात यह '120% जितनी तेजी से', सबसे खराब स्थिति में '30% जितनी तेजी से ')। लेकिन निश्चित रूप से सेब की तुलना संतरे के साथ की जा रही है - निम्न-स्तरीय कोड v उच्च-स्तरीय कोड। और यह बहुत कुछ होगाअगर हॉटस्पॉट अनुकूलन का उपयोग नहीं किया गया था तो इससे भी बदतर। पुष्टि करने के लिए, बस जेवीएम आर्ग्स के माध्यम से हॉटस्पॉट संकलन को अक्षम करें! या जावा 1 और 2 प्रदर्शन पर विचार करें, जब हॉटस्पॉट मौजूद नहीं था या अपरिपक्व था। या C के माध्यम से किसी अन्य भाषा को संकलित करने का प्रयास करें - उदा perlcc। तो उपरोक्त एक शक्तिशाली और उत्पादक भाषा के लिए महान परिणाम हैं। आगे के विकास के साथ, यह संभव है (या यहां तक ​​कि संभावना है) कि जेवीएम जल्द ही औसतन सी-कोडेड सी-आउट कर सकता है। स्काला औसत रूप से जावा की तुलना में 70-80% धीमा है। लेकिन स्केला जोर से कई कोर (आगे चल रहे सुधारों के साथ) में तराजू करता है, जबकि जावा आंशिक रूप से करता है और सी नहीं करता है। ऐसी उच्च स्तरीय भाषाओं के लिए सिंगल कोर प्रदर्शन का मूल्यांकन किया गया है:

   व्याख्या की गई <सांख्यिकीय रूप से संकलित <गतिशील रूप से संकलित

   मल्टी-कोर प्रदर्शन / स्केलेबिलिटी का मूल्यांकन किया गया है:

   डायनामिक कोड की व्याख्या <संवैधानिक रूप से संकलित अनिवार्य कोड <स्टेटिक रूप से संकलित कार्यात्मक / घोषणात्मक कोड <गतिशील रूप से संकलित कार्यात्मक / घोषणा कोड

   यह जीतने वाली सीट पर स्केला लगाता है क्योंकि प्रोसेसर की गति ने इसकी सीमा को प्रभावित किया है और अब मूर के कानून द्वारा कोर की संख्या बढ़ रही है। मल्टी-कोर और भविष्य में स्काला का बहुत तेज, सी या जावा की तुलना में कई गुना तेज हो सकता है। सी को सांख्यिकीय रूप से संकलित करना स्पष्ट रूप से सबसे तेज विकल्प नहीं है।

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

3. पोर्टेबिलिटी: जेवीएम दर्जनों ऑपरेटिंग सिस्टम प्लेटफॉर्म / वर्जन 'आउट ऑफ द बॉक्स' पर चलता है। स्काला को स्वचालित रूप से इन तक पहुंचा दिया जाता है। उल्लेखनीय अपवाद iOS (iPad / iPhone / iPod) - Apple द्वारा 'तकनीकी रूप से' के बजाय 'व्यावसायिक रूप से अवरुद्ध' है। जेवीएम के प्रारंभिक डिजाइन के दौरान, यह 12 साल पहले अनुमानित नहीं किया जा सकता था। JVM दर्जनों अन्य सर्वरों, डेस्कटॉप, मोबाइल और एम्बेडेड उपकरणों पर ठीक-ठाक चलता है, जिनमें वे भी शामिल हैं जो C का समर्थन नहीं करते हैं - जिनमें Google अनुकूलित Dalvik VM (बेचे गए नए फोन का 50% +) शामिल है। ज़रूर, सी कोड प्लेटफ़ॉर्म की एक भीड़ पर काम करता है, इसलिए 'जावा के साथ (या विशेष रूप से, सी उद्देश्यपूर्ण-सी का एक उपसमुच्चय है) के साथ वहां' रेटेड 'हो सकता है। लेकिन C (1), (2) & (3) की लागत पर आएगा। बेशक, iOS5 पर HTML5 / जावास्क्रिप्ट / वेबकिट (या ऑब्जेक्टिव-सी) प्रेजेंटेशन लेयर एक रिमोट स्लैला ऐप के साथ इंटरोपर्ट कर सकती है - इसलिए डेवलपर को बहुत कुछ करना चाहिए। बेशक, वे कम उत्पादक होंगे।

4. उपकरण और पुस्तकालय : स्पष्ट रूप से हजारों वाणिज्यिक और ओपन-सोर्स जावा पुस्तकालय और उपकरण हैं जो स्कैला द्वारा उत्तोलन / लीवरेज किए जा सकते हैं - सी के लिए अधिक।

5. सुरक्षा: - एक नियंत्रित ऐप सर्वर या जेवीएम वातावरण पर चलने से सुरक्षा नीतियों और प्रतिबंधों के लिए मजबूत समर्थन मिलता है, जो एक कॉर्पोरेट वातावरण में अत्यधिक मूल्यवान हो सकता है।

Answer 6

जेवीएम / सीएलआर

JVM (और CLR) अनुकूलन और कोड पोर्टेबिलिटी के संदर्भ में अद्वितीय लाभ प्रदान करते हैं।

जहाँ तक मुझे पता है, स्काला के केवल JVM संस्करण को चालू रखा जा रहा है। .NET संस्करण नहीं है।

Answer 7

ऐसा लगता है कि आप दो असंबंधित चीजों को मिला रहे हैं।

पहला तरीका यह है कि स्काला को लागू करने के लिए स्काला लेखक (एस) ने किस प्रोग्रामिंग भाषा का उपयोग किया है?

जिसका उत्तर है, स्काला ही। और यह एकमात्र स्वीकार्य उत्तर है, वास्तव में, क्योंकि यदि आपने इस नई भाषा का आविष्कार किया है, लेकिन इसे लागू करने के लिए स्वयं का उपयोग न करें - यह किस लिए अच्छा है?

दूसरी बात यह है कि स्काला में लिखित कार्यक्रमों को चलाने के लिए लक्ष्य मंच क्या है ?

यहां चुनाव अधिक दिलचस्प हो जाता है, लेकिन अभी के लिए, 100% काम करने वाला एकमात्र लक्ष्य JVM है। .NET के लिए समर्थन अभी भी प्रगति पर है। इसके अलावा, कुछ लोग ज्वाला को जलकुंभी के संकलन के लिए स्कैला प्राप्त करने के लिए काम कर रहे हैं। सिद्धांत रूप में, सी, सी ++, एलएलवीएम, मूल कोड या जो कुछ भी संकलन के लिए किसी को अधिक 'बैकएंड' जोड़ने से कोई नहीं रोकता है।

जेवीएम को प्राथमिक मंच क्यों चुना गया? मेरा अनुमान है क्योंकि

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

Comments

मैं यह नहीं देखता कि C या C ++ के साथ कचरा कलेक्टर क्यों लागू नहीं किया जा सकता है? मैं इसे एक अच्छे कारण के रूप में नहीं देखता। अजगर ने किया है। रूबी ने किया है। हेक ने एरलांग को भी कर दिया है। कौन जानता है कि अगर सी या सी ++ के साथ लिखा जाता है तो स्काला एक बेहतर कचरा संग्रहकर्ता के साथ समाप्त हो सकता है?

— यहोशू भागोगी

मेरा मतलब था 'असली' कचरा संग्रह। मुझे नहीं लगता कि कचरा संग्रह जो इस तरह के सवालों को भड़काता है वह काफी अच्छा है। हेक यहां तक ​​कि जेवीएम भी पर्याप्त नहीं है - अन्यथा अज़ुलसिस्टम जैसे लोग जेवीएम की कमियों को दूर करने के लिए अन्य लोगों की मदद करके अपना जीवन यापन नहीं कर पाएंगे।

— आर्टेम

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

— आर्टेम

Answer 8

सबसे पहले - मुझे लगता है कि आप वास्तव में पूछना चाहते थे कि स्कैला भाषा को कड़े तरीके से संकलित क्यों नहीं किया गया है। मैं आपको बताऊंगा मैं नहीं जानता। लेकिन मैं आपको यह भी बताऊंगा कि जेवीएम को देशी कोड के पक्ष में करने का कोई कारण नहीं है।

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

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

यही कारण है कि मैं इसके बारे में सोच सकता हूं, लेकिन ध्यान रखें कि अन्य कारण भी हो सकते हैं - जैसे कि लाइसेंस जारी करना और वहां शामिल राजनीति (जो गंदी चीजें हैं जिन्हें मैं कभी भी प्राप्त नहीं करना चाहूंगा)।

Answer 9

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

Comments

यह एक टिप्पणी की तरह अधिक पढ़ता है, देखें कैसे जवाब दें

— gnat