क्या हम व्याख्या किए गए कोड बनाम संकलित कोड के प्रदर्शन के बारे में सामान्य कथन कर सकते हैं?

Question

मैं एक सिफारिश तक पहुँचने के लिए दो तकनीकों की तुलना कर रहा हूँ जिसके लिए किसी कंपनी द्वारा उपयोग किया जाना चाहिए। Technology A के कोड की व्याख्या की जाती है जबकि Technology B का कोड मशीन कोड के लिए संकलित किया जाता है। मेरी तुलना में मुझे लगता है कि टेक बी में सामान्य रूप से बेहतर प्रदर्शन होगा क्योंकि इसमें व्याख्या प्रक्रिया का अतिरिक्त ओवरहेड नहीं है। मैं यह भी कहता हूं कि चूंकि एक कार्यक्रम कई मायनों में लिखा जा सकता है, इसलिए यह अभी भी संभव है कि तकनीक ए में लिखा गया कार्यक्रम टेक बी में लिखे गए एक परिणाम को बेहतर बना सके।

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

तो मेरा सवाल यह है कि क्या हम कभी संकलित / व्याख्या की गई प्रौद्योगिकियों के प्रदर्शन के बारे में कुछ कह सकते हैं? यदि हम कह सकते हैं कि संकलित आम तौर पर तेज है तो व्याख्या की गई है, मैं अपनी बात के समीक्षक को कैसे मना सकता हूं?

Comments

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

— 5gon12eder

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

— ब्रायन ओकले

बेतरतीब ढंग से व्याख्या की गई भाषा और संकलित एक को चुनें, और एक डॉलर की शर्त लगाएं कि संकलित तेजी से हो। पर्याप्त समय दोहराएं और आप अंततः सबवे पर दोपहर का भोजन खरीदने के लिए काफी आगे निकल आएंगे। हालांकि, एक सक्षम प्रोग्रामर के लिए तेज़ और अधिक दिलचस्प तरीके हैं ताकि वह अधिक पैसा कमा सके। और सबवे महान महान किसी भी तरह नहीं है।

— एड प्लंकेट

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

— लोनबोट

ईमानदारी से, प्रदर्शन पर आधारित दो तकनीकों में से एक के लिए आप कंपनी-प्रासंगिक सिफारिश क्यों देना चाहते हैं? विशेष मामलों में (जैसे 3 डी हाई स्पीड गेम्स प्रोग्रामिंग), प्रदर्शन एक प्रासंगिक मानदंड हो सकता है, लेकिन अधिकांश वास्तविक दुनिया के व्यावसायिक कार्यक्रमों के लिए, यह आखिरी चीज होनी चाहिए जिसकी आप तुलना करते हैं, पहली नहीं।

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

Answer 1

नहीं।

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

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

वहाँ कुछ बहुत तेजी से दुभाषिए हैं, और कुछ संकलक जो बहुत धीमा कोड उत्पन्न करते हैं ।

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

Comments

जहाँ तक मैं एक लिंक्ड (संभवतः एक डुप्लिकेट) प्रश्न में अपना खुद का पूर्व उत्तर बता सकता हूं, इन मामलों को इस एक से बेहतर रूप से कवर करता है

— gnat

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

— एपिकसम

@ ईपिकसम: सही है। "एक भाषा की गति" का विचार मौलिक रूप से गैर-संवेदनात्मक है।

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

सामान्य तौर पर: विशिष्ट हो।

— इगौई

मैं "... और कुछ बहुत धीमे संकलक" के द्वारा मान लेता हूं, जिसका अर्थ था कि वे कोड उत्पन्न करते हैं, संकलन की उनकी गति नहीं।

— मार्टीन्यू

Answer 2

सामान्यीकरण और विशिष्ट परिदृश्य वस्तुतः विपरीत हैं।

आप खुद के विपरीत प्रतीत होते हैं। एक तरफ, आप व्याख्या की गई बनाम संकलित भाषाओं के बारे में एक सामान्य वक्तव्य देना चाहते हैं। लेकिन दूसरी ओर, आप उस सामान्य कथन को एक तकनीकी परिदृश्य में शामिल करना चाहते हैं जिसमें Technology A और Technology B शामिल हैं।

एक बार जब आप किसी ठोस परिदृश्य के लिए कुछ लागू करते हैं, तो यह अब सामान्यीकृत नहीं है । तो भले ही आप यह मामला बना सकें कि भाषाओं की व्याख्या सामान्य रूप से धीमी है , फिर भी आप अपनी बात नहीं बना रहे हैं। आपका समीक्षक सामान्यीकरण की परवाह नहीं करता है। आप दो बहुत विशिष्ट तकनीकों का विश्लेषण कर रहे हैं। यह वस्तुतः सामान्यीकरण के विपरीत है।

Comments

यह प्रश्न शीर्षक के विपरीत, प्रश्न पाठ का सबसे अच्छा उत्तर है।

— डेविड मोल्स

Answer 3

अंगूठे के एक नियम के रूप में, एक व्याख्यात्मक कार्यक्रम दुभाषिया की मेजबान भाषा में कार्यक्रम लिखने की तुलना में 2x-10x धीमा के बारे में है, जिसमें अधिक गतिशील भाषाओं के लिए दुभाषिया धीमा हैं। इसका कारण यह है कि व्याख्या किए गए कार्यक्रम को सभी वास्तविक कार्य करने हैं, लेकिन इसके अतिरिक्त व्याख्या ओवरहेड है।

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

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

अनुकूलन के बारे में बोलना यहाँ महत्वपूर्ण है, क्योंकि एक पॉलिश, अनुकूलित दुभाषिया यथोचित गैर-अनुकूलन नाभि संकलक से बेहतर प्रदर्शन कर सकता है। चूंकि एक अनुकूलन कंपाइलर बनाना मुश्किल है और इसके लिए बहुत अधिक प्रयास की आवश्यकता होती है, इसलिए यह संभावना नहीं है कि आपकी "प्रौद्योगिकी बी" में परिपक्वता का यह स्तर है।

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

जब एक तकनीक चुनते हैं, तो अपने आप में एक भाषा रनटाइम का प्रदर्शन पूरी तरह से अप्रासंगिक है। यह महत्वपूर्ण है कि तकनीक कुछ बेसलाइन बाधाओं को पूरा करती है (हमारा बजट $ x है, हमें yyyy-mm-dd से पहले वितरित करने में सक्षम होना चाहिए, हमें विभिन्न गैर-कार्यात्मक आवश्यकताओं को पूरा करना चाहिए), और यह एक कम है स्वामित्व की कुल लागत (डेवलपर उत्पादकता, हार्डवेयर लागत, व्यवसाय के अवसर की लागत, तकनीक और रखरखाव की लागत, प्रशिक्षण और काम पर रखने की लागत,…) में बग और अप्रत्याशित बाधाओं का जोखिम। जैसे एक उद्योग जहां समय-समय पर बाजार सबसे महत्वपूर्ण कारक है, सबसे अच्छा डेवलपर उत्पादकता के साथ तकनीक सबसे उपयुक्त होगी। एक बड़े संगठन के लिए, रखरखाव और दीर्घकालिक लागत अधिक दिलचस्प हो सकती है।

Comments

अगर आपको लगता है कि "कंप्यूटर लैंग्वेज बेंचमार्क गेम साइट में एक भ्रामक संरचना है" तो किसी विशिष्ट पृष्ठ पर एक URL दें जो आपकी बात का समर्थन करता है, बजाय इसके कि लोग शीर्ष-स्तर की खोज से ऐसी चीज़ की तलाश करें जो उन्हें कभी न मिले! प्रदर्शन; बस मत बताओ।

— इगौई

यदि आपको लगता है कि "साइट का सबसे महत्वपूर्ण हिस्सा बेंचमार्क परिणाम नहीं है, लेकिन इस बात पर चर्चा करना कि कितना सार्थक बेंचमार्क हैं" तो उन पृष्ठों को URL दें। प्रदर्शन; बस मत बताओ।

— इगौई

यह आपके उत्तर पढ़ने वालों की सुविधा के लिए होगा। (मैं सिर्फ कोई है जो बेंचमार्क गेम को स्वीकार करता हूं)।

— इगौई

उत्तर में के-न्यूक्लियोटाइड उदाहरण को जोड़ने वाला @amon इसे अधिक पठनीय और नोट को अधिक उपयोगी बना देगा, जैसा कि चर्चाओं को जोड़ रहा है (संपूर्ण साइट को पढ़े बिना, यह मेरे लिए स्पष्ट नहीं है कि आप किन चर्चाओं के बारे में बात कर रहे हैं)।

— डेविड मोल्स

पृथ्वी पर आपको 2-10X कहां से मिला? अनुपात पूरी तरह से इस बात पर निर्भर करता है कि प्रत्येक बाइटकोड के लिए हैंडलर को कितना समय लगता है और कितना समय लगता है, जबकि प्रत्येक हैंडलर निष्पादित करने में कितना समय लेता है, और 10x केवल तभी संभव होगा जब भ्रूण का चक्र हैंडलर से 9x लंबा समय ले, जो बेतहाशा होता है असंभवत। आमतौर पर निष्पादन को हैंडलर द्वारा हावी किया जाता है। और भ्रूण चक्र गायब हो सकता है।

— user207421

Answer 4

आप संकलित / व्याख्या की गई प्रौद्योगिकियों के प्रदर्शन के बारे में कुछ कह सकते हैं। लेकिन पहले, आपको "प्रदर्शन" को परिभाषित करना होगा। यदि आप एक कम्प्यूटेशनल सरल एम्बेडेड सिस्टम का निर्माण कर रहे हैं, तो "प्रदर्शन" चीजों के मेमोरी उपयोग पक्ष की ओर झुकाव होगा। जबकि बड़े डेटा सेटों पर काम करने वाला एक कम्प्यूटेशनल रूप से जटिल सिस्टम JVM या .NET से मेमोरी ओवरहेड होने के बाद प्रति यूनिट समय पर गणना की संख्या में "प्रदर्शन" को परिभाषित करता है, यह नगण्य होगा।

एक बार जब आप तय कर लेते हैं कि "प्रदर्शन" क्या है, तो आप कुछ ऐसा कह सकते हैं जैसे "हमारे पास किसी भी समय मेमोरी में 50 बिलियन ऑब्जेक्ट होंगे और व्याख्या की गई टेकए आंतरिक प्रबंधन के लिए प्रत्येक ऑब्जेक्ट में एक अतिरिक्त 8 बाइट्स जोड़ता है जो 400GB मेमोरी ओवरहेड के बराबर होता है टेकबी की तुलना में जो इस डेटा को नहीं जोड़ता है "

Answer 5

यह एक तकनीकी प्रश्न है और आपको पहले से ही कई अच्छे तकनीकी उत्तर मिल गए हैं, लेकिन मैं आपकी स्थिति से थोड़ा अलग पहलू बताना चाहूंगा: इस तथ्य को कि आप "प्रौद्योगिकी ए या प्रौद्योगिकी बी" जैसे निर्णय को पूरी तरह से आधार नहीं बना सकते। तकनीकी और / या प्रदर्शन कारणों पर।

कुछ इस तरह के तकनीकी पहलू ए और बी के बीच निर्णय का सिर्फ एक छोटा सा हिस्सा है। ध्यान में रखने के लिए दर्जनों अन्य कारक हैं:

• क्या इसमें कोई लाइसेंसिंग लागत शामिल है? उदाहरण के लिए: आपको PostgreSQL मशीनों के क्लस्टर का उपयोग करके SQL सर्वर मशीनों के क्लस्टर का उपयोग करने के लिए (एक पर्याप्त राशि) का भुगतान करना होगा।
• क्या मेरे पास ऐसे कर्मचारी हैं जो उस तकनीक (स्टैक) और उसके पारिस्थितिकी तंत्र से परिचित हैं? यदि हाँ, तो क्या वे उपलब्ध हैं? यदि नहीं, तो क्या मैं कुछ किराए पर ले सकता हूं? इसकी कितनी लागत आएगी? या क्या मैं मौजूदा लोगों को प्रशिक्षित करता हूं? मेरी लागत कितनी होगी?
• ग्राहक क्या चाहता है? यह समय का एक मुद्दा हो सकता है।
• क्या मैं उत्पादन उपयोग के लिए तैयार तकनीक की सलाह देता हूं? या यह सिर्फ एक मौजूदा प्रचार है कि शायद बाहर मर जाएगा? (उदाहरण के लिए Node.js के बारे में सोचें जब यह पहली बार सामने आया था)
• जिस तकनीक की मैं सलाह देता हूं, वह मौजूदा आर्किटेक्चर या मेरे पास मौजूद आर्किटेक्चर के साथ अच्छी तरह फिट है? या मुझे एक साथ काम करने के लिए बहुत सारे पैसे खर्च करने होंगे?
• और कई और अधिक पहलू जो आपकी विशिष्ट स्थिति पर निर्भर करते हैं।

जैसा कि आप देख सकते हैं, इस तरह का निर्णय लेते समय विचार करने के लिए ए टन है।

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

Answer 6

आंशिक मूल्यांकन दुभाषियों और संकलक से संबंधित प्रासंगिक वैचारिक ढांचा है।

क्या हम व्याख्या किए गए कोड बनाम संकलित कोड के प्रदर्शन के बारे में सामान्य कथन कर सकते हैं?

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

यहां तक ​​कि पारंपरिक रूप से संकलित भाषाओं में (अर्थात, ऐसी भाषाएं जिनका कार्यान्वयन अक्सर संकलक होता है) सी की तरह, कुछ हिस्सों की अक्सर व्याख्या की जाती है। उदाहरण के लिए, के प्रारूप नियंत्रण स्ट्रिंग printf (सी मानक में परिभाषित) है अक्सर "व्याख्या" (द्वारा सी मानक पुस्तकालय , एक है जो printf समारोह लेकिन कुछ चर तर्क तकनीक का उपयोग) compilers (सहित जीसीसी ) कर रहे हैं -इन सक्षम सीमित विशिष्ट मामलों- इसे अनुकूलित करने के लिए और इसे "निचले स्तर की कॉल में" संकलित करें।

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

SBCL एक सामान्य लिस्प "कंपाइलर" है जो गतिशील रूप से प्रत्येक REPL इंटरैक्शन (और कॉल evalआदि ...) को मशीन कोड में अनुवादित करता है । तो आपको लगता है कि यह एक दुभाषिया है। ब्राउज़रों में अधिकांश जावास्क्रिप्ट कार्यान्वयन (जैसे v8 ) JIT संकलन तकनीकों का उपयोग करते हैं।

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

एक कार्यान्वयन तकनीक की तरह "संकलक" या "दुभाषिया" का उपयोग करके स्वतंत्र रूप से तेज या धीमा हो सकता है।

कुछ भाषा लक्षण एक व्याख्यात्मक दृष्टिकोण के पक्ष में हैं (और केवल पूरे कार्यक्रम विश्लेषण के माध्यम से कुशलता से संकलित किया जा सकता है )।

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

पायथन के बारे में यह संबंधित प्रश्न भी देखें , और वह भी

Answer 7

जैसे कोड के लिए A = A + B, जो एक या दो मशीन निर्देशों को संकलित कर सकता है, प्रत्येक एक निश्चित संख्या में चक्र ले सकता है। कोई भी दुभाषिया एक साधारण कारण के लिए चक्रों की संख्या में एक ही काम नहीं कर सकता है।

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

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

दूसरी ओर...

जैसे कोड के लिए callSomeFunction( ... some args ...), उस कोड को दर्ज करने और छोड़ने के बीच कितने चक्र खर्च होते हैं? यह सब इस बात पर निर्भर करता है कि अंदर क्या होता है callSomeFunction। यह कुछ ही हो सकता है, और यह अरबों हो सकता है, भले callSomeFunctionही खुद को संकलित किया जाए। यदि यह बहुत है, तो उस कोड की व्याख्या लागत पर बहस करने का कोई मतलब नहीं है - पैसा कहीं और है।

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

इसके अलावा, प्रोग्रामिंग के बुद्धिमान स्तरों के लिए आवश्यक लचीलापन है। Minsky's Society of Mind , Chapter 6.4 B -Brains में, ए प्रोग्राम हैं जो दुनिया से निपटते हैं, और बी प्रोग्राम हैं जो ए प्रोग्राम से निपटते हैं, और आगे के स्तर हो सकते हैं। अन्य कार्यक्रमों को लिखने और प्रबंधित करने वाले प्रोग्राम व्याख्यात्मक प्रणालियों में अधिक आसानी से किए जा सकते हैं।

लिस्प में, आप (+ A B)ए और बी को जोड़ने के लिए लिख सकते हैं , लेकिन एक बार यह लिखे जाने के बाद आपके पास इसे चलाने का विकल्प है या नहीं। आप यह भी लिख सकते हैं (eval (list '+ 'A 'B))जो प्रोग्राम का निर्माण करता है और फिर उसे निष्पादित करता है। यह कुछ अलग निर्माण कर सकता है।

कार्यक्रम का विषय एक और कार्यक्रम है । व्याख्यात्मक भाषा में लिखना आसान है (हालांकि, जैसा कि जार्ग बताते हैं, लिस्प के नए संस्करण, जबकि उनके पास evalसंकलन-ऑन-द-फ्लाई है, इसलिए उन्हें व्याख्या करने की गति का दंड नहीं है)।

Comments

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

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

@ JörgWMittag: ज़रूर, लेकिन उनके पास सभी कार्य evalऔर applyकार्य हैं, जो व्याख्याकार हैं।

— माइक डनलैवी

मुझे पूरा यकीन है कि कम से कम SBCL पर, evalव्याख्या नहीं की गई है। और है भी नहीं apply। निश्चित रूप से ऐसे कार्यान्वयन हैं जिनमें दुभाषिया होते हैं, लेकिन एसबीसीएल नहीं करता है।

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

दुभाषिया रनटाइम में लूप की स्थिति को अनुकूलित कर सकता है और शेष पुनरावृत्तियों को स्क्वैश कर सकता है। संकलित कार्यक्रमों में यह शायद ही कभी होता है। विशेष रूप से, ओरेकल का हॉटस्पॉट बिल्कुल यही करता है।

— बसिलेव

@ JörgWMittag: निश्चित evalरूप से एड की व्याख्या नहीं है । यह एक व्याख्या एर है ।

— माइक डनलैवी

Answer 8

इसका प्रकार, यह निर्भर करता है, लेकिन यह सामान्य नियम के रूप में संकलित है - यह जेआईटी के माध्यम से हो या सांख्यिकीय रूप से संकलित हो - कई कम्प्यूट-गहन कार्यों के लिए पर्यावरण तेज होगा - सादगी समान भाषा के लिए।

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

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

टीएल; डीआर - संकलित कार्यक्रमों में व्याख्या किए गए लोगों के लिए विशाल प्रदर्शन लाभ हैं (सेब-से-सेब की तुलना में PyP स्पीड देखें )। हालाँकि निष्पादन योग्य गति केवल समस्या का हिस्सा है और यह समग्र गति में बहुत योगदान नहीं दे सकती है (यदि समय अधिकतर पुस्तकालयों में बिताया जाता है)। साथ ही कार्यान्वयन मायने रखता है।

Answer 9

आपकी धारणा अच्छी तरह से स्थापित है, हालांकि यह एक धारणा है।

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

हालांकि उनके पास एक बिंदु हो सकता है, चाहे वह अंतर आपके द्वारा विकसित किए जा रहे अनुप्रयोग के प्रकार में महत्वपूर्ण हो। यदि यह ज्यादातर I / O है या ज्यादातर संकलित पुस्तकालयों को बुला रहा है और इसमें बहुत अधिक संगणना नहीं है, तो व्याख्या प्रक्रिया का ओवरहेड वास्तव में महत्वहीन हो सकता है।

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

लेकिन समय-समय पर आप पकड़े जाते हैं। यह मेरे साथ हुआ है। आप एक अच्छी धारणा बनाते हैं और फिर आप पाते हैं कि आप दुनिया की मूर्खता पर ध्यान देने में असफल रहे।

लेकिन मैं सभी समय के अपने पसंदीदा दिलबर्ट कार्टून के रूप में अच्छी तरह से समझा नहीं सकता। स्मार्ट-गधा होने के खतरों से बेहतर कुछ भी नहीं दिखा।

टीएल; डीआर: आपको सही होना चाहिए, लेकिन वास्तविक दुनिया को सिर्फ मामले में जांचें।

Answer 10

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

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

यहाँ विभिन्न भाषाओं में रेगेक्स के बारे में एक लिंक है; आप देखेंगे कि रेगेक्स को किसी भाषा में बेहतर तरीके से संकलित किया गया है, भले ही संकलित किया गया हो या नहीं: http://benchmarkgame.alioth.debian.org/u64q/performance.php?test=regexdna

Comments

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

— एपिकसम

@EpicSam तब उनकी पिछली परियोजनाओं के बारे में क्या?

— वॉलफ्रैट

A और B दोनों का उपयोग किया गया है। हालाँकि वे सभी परियोजनाओं के लिए 1 तकनीक का उपयोग करना चाहते हैं। वर्तमान परियोजनाओं के लिए दोनों प्रौद्योगिकियों का प्रदर्शन काफी अच्छा है। हालांकि संभावित भविष्य की परियोजनाओं को देखते समय उनमें से एक के उच्चतर प्रदर्शन को माना जाना चाहिए।

— इपिकसम

@EpicSam आपकी परियोजनाओं में आपकी सहायता के लिए भाषा और लाइब्रेरी / फ्रेमवर्क के आसपास के समुदाय के लिए बेहतर रूप से उपलब्ध है।

— वॉलफ्रैट

मैं @Walfrat से सहमत हूं। मैं शर्त लगाता हूं कि "उच्चतम क्षमता" वाली भाषा सीधे-सीधे असेंबली या कुछ कच्चे सीपीयू अनुदेश सेट है। लेकिन हम उन भाषाओं के बारे में बात नहीं कर रहे हैं क्योंकि इसके "स्पष्ट" कि संकलक, दुभाषिया और पूर्व-लिखित पुस्तकालय जैसे उपकरण अति महत्वपूर्ण हैं। मुझे लगता है कि व्याख्या / संकलित के बीच विकल्प की तुलना में उपकरण / सामुदायिक ज्ञान की उपलब्धता अधिक महत्वपूर्ण है

— इवान

Answer 11

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

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

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

Answer 12

एक बार मुझे एक बड़े फैसले को सही ठहराने के लिए इसी तरह का व्यापक बयान देना पड़ा।

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

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

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

Comments

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

— एपिकसम

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

— RedSonja

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

— मआर्टिनियस

Answer 13

मेरा तर्क है कि किसी भी गतिशील भाषा का सांख्यिकीय रूप से संकलित लोगों पर एक फायदा है: "रनटाइम अनुकूलन"

यही कारण है कि जावा C ++ की तुलना में तेज हो सकता है

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

नोट: खैर, जावा एक व्याख्या की गई भाषा है, न कि एक गतिशील। लेकिन यह एक महान उदाहरण है कि आप रनटाइम जानकारी के साथ क्या गति दे सकते हैं

Answer 14

... मैं यह भी कहता हूं कि चूंकि एक कार्यक्रम कई मायनों में लिखा जा सकता है इसलिए यह अभी भी संभव है कि तकनीकी ए में लिखा गया कार्यक्रम बी में किसी एक को बेहतर बना सके।

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

यह मेरा दृष्टिकोण होगा:

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

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

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

Comments

पूरा गलत। आपको समझ में नहीं आता है कि व्याख्याकार कैसे काम करते हैं बनाम कंपाइलर कैसे काम करते हैं।

— रागोम