क्या रूबी / पायथन जैसी गतिशील भाषा प्रदर्शन की तरह C / C ++ तक पहुँच सकती है?


64

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

क्या ऐसा कंपाइलर बनाना संभव है जो रूबी या किसी अन्य गतिशील भाषा को बाइनरी में संकलित कर सकता है जो C / C ++ के बहुत करीब करता है? क्या एक मौलिक कारण है कि जेआईटी संकलक, जैसे कि PyPy / रुबिनियस अंततः प्रदर्शन में C / C ++ से मेल नहीं खाएगा?

नोट: मैं समझता हूं कि "प्रदर्शन" अस्पष्ट हो सकता है, इसलिए यह स्पष्ट करने के लिए कि मेरा मतलब है, यदि आप प्रदर्शन Y के साथ C / C ++ में X कर सकते हैं, तो क्या आप Y के करीब प्रदर्शन के साथ Ruby / Python में X कर सकते हैं? जहां एक्स डिवाइस चालकों और ओएस कोड से वेब अनुप्रयोगों तक सब कुछ है।


1
क्या आप इस प्रश्न को फिर से समझ सकते हैं ताकि यह दूसरों के ऊपर उचित साक्ष्य द्वारा समर्थित उत्तरों को प्रोत्साहित करे?
राफेल

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

1
विशेष रूप से, मुझे लगता है कि आपको एक (या कुछ) ठोस प्रदर्शन उपायों को ठीक करने की आवश्यकता है। रनटाइम? अंतरिक्ष उपयोग? ऊर्जा के उपयोग? डेवलपर समय? निवेश की वापसी? हमारे मेटा पर इस प्रश्न पर भी ध्यान दें जो इस प्रश्न (या इसके उत्तर) की चिंता करता है।
राफेल

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

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

जवाबों:


68

उन सभी लोगों के लिए जिन्होंने "हाँ" कहा, मैं एक काउंटर-पॉइंट पेश करूंगा कि जवाब "नहीं" है, डिजाइन द्वारा । वे भाषाएं कभी भी संकलित भाषाओं के प्रदर्शन से मेल नहीं खाएंगी।

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

हालांकि, सिक्के का एक और पक्ष है: इस अतिरिक्त जानकारी को ट्रैक करने की आवश्यकता है। आधुनिक आर्किटेक्चर पर, यह एक प्रदर्शन हत्यारा है।

विलियम एडवर्ड्स तर्क का एक अच्छा अवलोकन प्रदान करता है

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

विलियम कुछ दिलचस्प आईबीएम स्लाइड्स का हवाला देते हैं :

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

विश्लेषण के बाद उन चेकों में से कुछ को समाप्त किया जा सकता है (एनबी: यह विश्लेषण समय भी लेता है - रनटाइम पर)।

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

लेकिन C ++ कंपाइलर ही ऐसा कर सकता है! आधुनिक संकलक तथाकथित प्रोफाइल-निर्देशित अनुकूलन की पेशकश करते हैं, जो यदि उन्हें उपयुक्त इनपुट दिया जाता है, तो प्रोग्राम रनटाइम व्यवहार को मॉडल कर सकता है और एक ही ऑप्टिमाइज़ेशन लागू कर सकता है जो एक JIT लागू होगा।

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

सारांश में, मुझे विश्वास नहीं है कि स्थैतिक विश्लेषण और अनुकूलन की तुलना में लंबे समय में रनटाइम जानकारी पर नज़र रखने के लिए रन-टाइम हॉट-स्पॉट ऑप्टिमाइज़ेशन ओवरहेड होता है


2
@ राफेल यह तब कंपाइलर की "कमी" है। विशेष रूप से, क्या javacकभी प्रोफ़ाइल-निर्देशित अनुकूलन किया गया था? जहां तक ​​मेरी जानकारी नहीं है। सामान्य तौर पर JITted भाषा के संकलक को अच्छी तरह से अनुकूलित करने का कोई मतलब नहीं है क्योंकि JIT इसे संभाल सकता है (और बहुत कम से कम, इस तरह से अधिक भाषाओं के प्रयास से लाभ होता है)। इसलिए (समझ में आता है) javacआशावादी में बहुत प्रयास नहीं किया गया था , जहां तक ​​मुझे पता है (.NET भाषाओं के लिए यह निश्चित रूप से सच है)।
कोनराड रुडोल्फ

1
@ राफेल प्रमुख शब्द है: हो सकता है। यह इसे किसी भी तरह से नहीं दिखाता है। यही सब मैं कहना चाहता था। मैंने पूर्ववर्ती पैराग्राफ में अपनी धारणा के लिए कारण (लेकिन कोई सबूत नहीं) दिए हैं।
कोनराड रुडोल्फ

1
@ मैं इनकार नहीं करता कि यह जटिल है। यह केवल एक अंतर्ज्ञान है। रनटाइम पर वह सभी जानकारी ट्रैक करना, एक लागत पर आता है, सब के बाद। मैं IO के बारे में आपकी बात से सहमत नहीं हूँ। यदि यह अनुमानित (= विशिष्ट उपयोग-मामला) है, तो पीजीओ इसकी भविष्यवाणी कर सकता है। यदि यह सहज है, तो मुझे यकीन नहीं है कि JIT इसे या तो अनुकूलित कर सकता है। शायद एक बार एक समय में, सरासर भाग्य से बाहर। लेकिन मज़बूती से? …
कोनराड रुडोल्फ

2
@ कोनराड: आपका अंतर्ज्ञान झूठा है। यह रनटाइम में भिन्नता के बारे में नहीं है, यह संकलन समय पर अप्रत्याशितता के बारे में है । JITs बनाम स्टेटिक ऑप्टिमाइज़ेशन के लिए मधुर स्थान तब नहीं होता जब प्रोग्राम का व्यवहार प्रोफाइलिंग के लिए "बहुत तेज़" गति से बदलता है, यह तब होता है जब प्रोग्राम के प्रत्येक व्यक्तिगत रन में प्रोग्राम के व्यवहार को अनुकूलित करना आसान होता है, लेकिन बीच में अलग-अलग होता है रन। एक स्टेटिक ऑप्टिमाइज़र को आमतौर पर केवल एक सेट के लिए ऑप्टिमाइज़ करना होगा, जबकि एक JIT उस रन में होने वाली परिस्थितियों के लिए प्रत्येक रन को अलग से ऑप्टिमाइज़ करता है।
बेन

3
सूचना: यह टिप्पणी-धागा एक मिनी चैट रूम के रूप में विकसित हो रहा है। यदि आप इस चर्चा को जारी रखना चाहते हैं, तो कृपया इसे चैट पर लाएँ। मूल पोस्ट को बेहतर बनाने के लिए टिप्पणियों का उपयोग किया जाना चाहिए। कृपया इस वार्तालाप को यहाँ बंद करें। धन्यवाद।
रॉबर्ट Cartaino

20

यदि आप प्रदर्शन C के साथ X को C / C ++ में कर सकते हैं, तो क्या आप Y के करीब प्रदर्शन के साथ Ruby / Python में X कर सकते हैं?

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

पाठ्यक्रम का व्यापार यह है कि केवल पायथन कोड का एक सबसेट RPython द्वारा स्वीकार किया जाता है, और सामान्य तौर पर, भले ही उस प्रतिबंध को हटा दिया जाता है, केवल पायथन कोड का एक सबसेट अच्छा कर सकता है: सबसेट जो विश्लेषण किया जा सकता है और स्थिर प्रकार दिया जा सकता है।

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

इसके अतिरिक्त, क्या जेआईटी कंपाइलर्स, जैसे कि PyPy / Rubinius कभी भी प्रदर्शन में C / C ++ से मेल खाएंगे?

नाह।

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

जावा के लिए मौजूदा प्रदर्शन डेटा, जिसमें पायथन या रूबी की तुलना में अधिक प्रकार की जानकारी है, और पायथन या रूबी की तुलना में एक बेहतर विकसित जेआईटी संकलक है, अभी भी C / C ++ से मेल नहीं खाता है। हालांकि, यह एक ही बॉलपार्क में है।


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

1
JIT के बारे में: मैंने एक से अधिक बेंचमार्क देखे हैं जहां जावा ने C (++) के कई फ्लेवरों को देखा। केवल C ++ को बढ़ावा देने के साथ मज़बूती से आगे रहने के लिए लगता है। उस मामले में, मैं प्रति डेवलपर समय प्रदर्शन के बारे में आश्चर्य करता हूं, लेकिन यह एक और विषय है।
राफेल

@ पता: एक बार जब आप RPython है, यह एक संकलक / दुभाषिया बनाने के लिए तुच्छ है जो CPython दुभाषिया का उपयोग करने के लिए वापस आता है जब RPython संकलक विफल हो जाता है, इसलिए "केवल पायस कोड का एक सबसेट अच्छा कर सकता है: ..." पूरी तरह से सही है।
रेयान

9
@ राफेल यह कई बार दिखाया गया है कि अच्छी तरह से लिखा सी ++ कोड आउटपरफॉर्म जावा। यह "अच्छी तरह से लिखा गया" हिस्सा है, जो C ++ में प्राप्त करने के लिए काफी कठिन है, इसलिए कई बेंचों में आप परिणाम देखते हैं कि जावा C ++ से बेहतर प्रदर्शन करता है। C ++, इसलिए, अधिक महंगा है, लेकिन जब तंग मेम नियंत्रण और धातु धैर्य की आवश्यकता होती है, तो C / C ++ वही होता है जिसे आप चालू करते हैं। सी विशेष रूप से सिर्फ एसी / पी कोडांतरक है।
टीसी 1

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

18

संक्षिप्त उत्तर है: हम नहीं जानते , 100 वर्षों में फिर से पूछें। (हम तब भी नहीं जान सकते हैं; संभवतः हम कभी नहीं जान पाएंगे।)

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

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

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

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

क्या सैद्धांतिक रूप से यह संभव है कि पायथन सी के मुकाबले इष्टतम प्रदर्शन के करीब, या शायद करीब भी मिलेगा? जैसा कि ऊपर देखा गया है, हाँ, लेकिन हम आज उससे बहुत दूर हैं। फिर, पिछले दशकों में कंपाइलरों ने बहुत प्रगति की है, और यह प्रगति धीमी नहीं हो रही है।

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

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

सर्वर और डेस्कटॉप प्लेटफार्मों पर, सीपीयू लगभग एक पठार पर पहुंच गए हैं, जहां उन्हें कोई तेज़ नहीं मिलता है (मोबाइल प्लेटफ़ॉर्म वहां भी मिल रहे हैं); यह उन भाषाओं का पक्षधर है जहाँ समानता का फायदा उठाना आसान है। बहुत सारे प्रोसेसर I / O प्रतिक्रिया के इंतजार में अपना अधिकांश समय बिताते हैं; अभिकलन में बिताया गया समय I / O की मात्रा की तुलना में बहुत कम है, और एक ऐसी भाषा जो प्रोग्रामर को संचार को कम करने की अनुमति देती है।

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

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


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

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

ठीक है, मुझे लगता है कि सवाल सिर्फ "कितना अच्छा हो सकता है जेआईटी, और अगर वे स्थैतिक संकलन से आगे निकल जाते हैं, तो क्या सांख्यिकीय रूप से संकलित भाषाएं भी उनसे लाभ कमा सकती हैं?" और हां, मैं आपके आकलन से सहमत हूं लेकिन निश्चित रूप से हम कुछ सूचित अनुमान प्राप्त कर सकते हैं जो "यह निर्भर करता है" से परे है। ;-)
कोनराड रुडोल्फ

@KonradRudolph अगर मुझे अनुमान था, मैं सॉफ्टवेयर इंजीनियरिंग पर पूछना चाहता हूँ ।
गाइल्स

1
भाषा शूटआउट दुर्भाग्य से मात्रात्मक मानदंड के लिए एक संदिग्ध स्रोत है: वे केवल उन सभी कार्यक्रमों को स्वीकार नहीं करते हैं जो केवल भाषा के विशिष्ट समझा जाता है। यह एक मुश्किल और बहुत व्यक्तिपरक आवश्यकता है; इसका मतलब है कि आप यह नहीं मान सकते हैं कि शूटआउट कार्यान्वयन वास्तव में कोई अच्छा है (और व्यवहार में, कुछ कार्यान्वयन स्पष्ट रूप से बेहतर विकल्प अस्वीकार कर दिए गए हैं)। दूसरे पहलू पर; ये माइक्रोबैनमार्क हैं और कुछ कार्यान्वयन असामान्य तकनीकों का उपयोग करते हैं जिन्हें आप केवल प्रदर्शन जीतने के लिए अधिक सामान्य परिदृश्य में नहीं मानते हैं। तो: यह एक खेल है, बहुत विश्वसनीय डेटा स्रोत नहीं है।
Eamon Nerbonne

10

C ++ स्टेटमेंट x = a + bऔर पायथन स्टेटमेंट के बीच मूल अंतर x = a + bयह है कि C / C ++ कंपाइलर इस स्टेटमेंट (और थोड़ी अतिरिक्त जानकारी के बारे में बता सकता है कि यह किस प्रकार के , और ) के बारे में आसानी से उपलब्ध है x, ठीक उसी तरह जिसे मशीन कोड को निष्पादित करने की आवश्यकता है । जबकि पायथन स्टेटमेंट क्या संचालन करने जा रहा है, यह बताने के लिए, आपको हॉल्टिंग समस्या को हल करने की आवश्यकता है।ab

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

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

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

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

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

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


1
यह अब बिना किसी टिप्पणी के दो डाउन वोट है। मैं इस उत्तर को बेहतर बनाने के लिए सुझावों का स्वागत करूंगा!
बेन

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

@ मिकेरा मुझे क्षमा करें, लेकिन नहीं, आप गलत हैं। पूरी तरह से सामान्य पायथन, या अन्य गतिशील भाषाओं के लिए किसी ने कभी भी एक कंपाइलर (इस अर्थ में नहीं कि हम समझते हैं कि जीसीसी एक कंपाइलर है) को लागू किया है । ऐसी प्रत्येक प्रणाली केवल भाषा के सबसेट के लिए काम करती है, या केवल कुछ कार्यक्रमों के लिए, या कभी-कभी कोड का उत्सर्जन करती है जो मूल रूप से एक दुभाषिया है जिसमें हार्ड-कोडेड प्रोग्राम होता है। यदि आप चाहें, तो मैं आपको एक पायथन कार्यक्रम लिखूंगा, जिसमें foo = x + yसंकलन समय पर अतिरिक्त ऑपरेटर के व्यवहार की भविष्यवाणी करना, रुकने की समस्या को हल करने पर निर्भर करता है।
बेन

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

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

9

बस एक त्वरित सूचक जो गतिशील भाषाओं के लिए सबसे खराब स्थिति को रेखांकित करता है:

पर्ल पार्सिंग गणना योग्य नहीं है

परिणामस्वरूप, (पूर्ण) पर्ल को कभी भी संकलित नहीं किया जा सकता है।


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

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


5

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

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

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

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

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

व्यवहार में, एक स्थिर भाषा के साथ एक गतिशील भाषा के प्रदर्शन का मिलान एक स्थिर भाषा में दुभाषिया / रनटाइम को फिर से लागू करने की आवश्यकता हो सकती है; हालाँकि, आप यह कर सकते हैं कि इस तर्क का क्रूरतम और बिंदु है। यह एक मुर्गी और अंडे का सवाल है और, बशर्ते आप ऊपर दी गई अप्रमाणित (हालांकि, मेरी राय में, ज्यादातर आत्म-स्पष्ट) मान्यताओं से सहमत हों, हम वास्तव में इसका जवाब दे सकते हैं; हमें स्टेटिक को गति देनी है, न कि गतिशील, भाषाओं को।

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


इसे फिर से पढ़ना, मुझे नहीं लगता कि यह सच है। JIT संकलन आपके तर्क को तोड़ देता है। यहां तक ​​कि सबसे सरल कोड, उदाहरण के लिए एक बार मूल्य ज्ञात होने पर महत्वपूर्ण रूप से फैलाया main(args) { for ( i=0; i<1000000; i++ ) { if ( args[0] == "1" ) {...} else {...} }जा सकता है (यह मानते हुए कि यह कभी नहीं बदलता है, जिसे हम मुखर करने में सक्षम हो सकते हैं)। एक स्थिर संकलक ऐसा कोड नहीं बना सकता है जो तुलना को कभी कम कर दे। (बेशक, उस उदाहरण में आप सिर्फ लूप को बाहर निकालते हैं। लेकिन बात और भी जटिल हो सकती है।)argsif
राफेल

@ राफेल मुझे लगता है कि जेआईटी शायद अपना तर्क देता है। जेआईटी संकलन (जैसे, जेवीएम) आमतौर पर संकलित कार्यक्रम हैं। यदि एक संकलित JIT कार्यक्रम स्क्रिप्ट को तेजी से चला सकता है तो कुछ अन्य स्थैतिक कार्यक्रम समान कार्य कर सकते हैं, JIT संकलक के साथ स्क्रिप्ट को "बंडल" करें, और बंडल को एक संकलित प्रोग्राम कहें। यह कम से कम और साथ ही जेआईटी को एक अलग गतिशील कार्यक्रम पर काम करना चाहिए, जो किसी भी तर्क का खंडन करता है कि जेआईटी को बेहतर करना चाहिए।
पैट्रिक87

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

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

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

4

क्या आप रूबी जैसी गतिशील भाषाओं के लिए कंपाइलर का निर्माण कर सकते हैं जो C / C ++ के समान और तुलनीय प्रदर्शन है?

मुझे लगता है कि जवाब "हाँ" । मेरा यह भी मानना ​​है कि वे दक्षता के मामले में वर्तमान C / C ++ आर्किटेक्चर को भी पार कर सकते हैं (भले ही धीरे-धीरे)।

वजह साफ है: संकलन-समय की तुलना में रन-टाइम में अधिक जानकारी है।

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

देखें डायनामिक लैंग्वेज स्ट्राइक बैक , Google के स्टीव येजेज का एक भाषण (इसमें एक वीडियो संस्करण भी है जो मुझे विश्वास है)। उन्होंने V8 से कुछ ठोस JIT अनुकूलन तकनीकों का उल्लेख किया है। प्रेरणादायक!

मैं आगे देख रहा हूँ कि हम अगले 5 वर्षों में क्या करने जा रहे हैं!


2
मुझे आशावाद पसंद है।
डेव क्लार्क

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

1
@DaveClarke मुझे वही चलता रहता है :)
कोस

2

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

  • प्रतीक (var, या id = <-> सभी प्रकार के डेटाम बाइंडिंग) अप्रकाशित हैं।
  • संरचनाएं (डेटा, सभी जो रनटाइम में रहती हैं) उनके तत्वों के प्रकारों के साथ-साथ अप्रयुक्त हैं।

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

एल

  • Elementएलएल
  • सभी प्रतीक उस प्रकार के हैं Element, वे किसी भी तत्वों को पकड़ सकते हैंएल
  • सभी संरचनाएं (फिर, मॉडल रूटीन सहित) केवल तत्व प्राप्त करती हैं

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


+1 बहुत दिलचस्प। क्या आपने मेरा जवाब पढ़ा है? आपकी और मेरी सोच समान है, हालाँकि आपका उत्तर अधिक विस्तार और एक दिलचस्प परिप्रेक्ष्य प्रदान करता है।
पैट्रिक87

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

@ पैट्रिक87: आप सही कह रहे हैं, हमारे विचार की रेखाएं बहुत समान हैं (पहले नहीं पढ़ी थी, क्षमा करें, मेरा पलटा वर्तमान में सी में एक डायन लैंग को लागू करने से आता है)।
सर्प

@ गिल्स: मैं इसके बारे में सहमत हूं कि "... अप्राप्य होने की जरूरत नहीं है", अगर आपका मतलब सांख्यिकीय रूप से टाइप नहीं है । लेकिन यह ऐसा नहीं है जो लोग सामान्य रूप से dyn langs के बारे में सोचते हैं, मुझे लगता है। मैं व्यक्तिगत रूप से सामान्यता (ऊपर दिए गए उत्तर में दिए गए सामान्य अर्थों) पर विचार करता हूं, एक ऐसी सुविधा जो बिना जीने के लिए कहीं अधिक शक्तिशाली और कठिन है। हम अपनी सोच को चौड़ा करके स्थैतिक प्रकारों के साथ आसानी से कर सकते हैं कि किसी दिए गए (प्रतीत होता है बहुरूपिक) प्रकार को कैसे परिभाषित किया जा सकता है, या सीधे उदाहरणों को अधिक लचीलापन देकर।
सर्प

1

मेरे पास सभी उत्तरों को विस्तार से पढ़ने का समय नहीं था ... लेकिन मुझे बहुत आश्चर्य हुआ।

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

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

वैसे कुछ अफवाहें थीं कि किसी ने एक संकलक का उत्पादन किया था जो कभी-कभी 1 का विस्तार अनुपात प्राप्त कर सकता था ... जब तक कि यह केवल नियम नहीं बन गया कि संकलित कोड हाथ से लिखे गए कोड (और अधिक विश्वसनीय भी) से बहुत बेहतर था। लोग उन समय (छोटी यादों) में कोड आकार के बारे में चिंतित थे, लेकिन वही गति, या ऊर्जा की खपत के लिए जाता है। मैं कारणों में नहीं जाऊंगा।

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

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

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

और इस कथन पर आगे टिप्पणी करने के लिए कि Perl parsing is not computable, जो भी उस वाक्य से अभिप्राय है, एमएल के साथ एक समान समस्या है, जो एक उल्लेखनीय रूप से औपचारिक भाषा है।Type checking complexity in ML is a double exponential in the lenght of the program.यह सबसे खराब स्थिति में सबसे सटीक और औपचारिक परिणाम है ... जो बिल्कुल भी मायने नहीं रखता है। Afaik, ML उपयोगकर्ता अभी भी एक व्यावहारिक कार्यक्रम की प्रतीक्षा कर रहे हैं जो टाइप चेकर में विस्फोट करेगा।

कई मामलों में, जैसा कि पहले था, कंप्यूटिंग शक्ति की तुलना में मानव समय और क्षमता दुर्लभ है।

भविष्य की वास्तविक समस्या हमारी नई विरासत, नए प्रोग्रामिंग रूपों को एकीकृत करने के लिए हमारी भाषाओं को विकसित करने के लिए होगी, जो अभी भी उपयोग की जाने वाली सभी विरासत सॉफ़्टवेयर को फिर से लिखने के बिना है।

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

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


0

नोटों की एक जोड़ी:

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

  • गतिशील भाषाओं के लिए समय-समय पर संकलक के अत्यधिक ऑप्टोमाइज़िंग मौजूद हैं। अच्छा लिस्प कार्यान्वयन समान सी की आधी गति तक पहुंचता है।

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

  • Deoptimization भी महत्वपूर्ण है। JIT- संकलित कोड के बजाय एक बंदर को पकड़ने वाले वर्ग की जांच करने की आवश्यकता है, बंदरपंचिंग का कार्य रनटाइम सिस्टम में एक हुक को चलाता है जो मशीन कोड को पुरानी परिभाषा पर निर्भर करता है।


यह कैसा उत्तर है? यदि आप संदर्भ जोड़ते हैं तो, शायद तीन गोली।
राफेल

मुझे इस दावे पर बहुत संदेह है कि PGO विशिष्ट कार्यभार के तहत वेब एप्लिकेशन कोड के लिए LuaJIT के प्रदर्शन से मेल नहीं खा सकता है।
कोनराड रुडोल्फ

@KonradRudolph एक JIT का मुख्य लाभ यह है कि JIT कोड को अलग-अलग रास्तों के गर्म होते ही स्वीकार कर लेता है।
डेमी

@ डेमेट्री मैं यह जानता हूं। लेकिन यह निर्धारित करना बहुत कठिन है कि क्या यह एक फायदा है - मेरा उत्तर और टिप्पणी चर्चा वहां देखें। संक्षेप में: जब जेआईटी उपयोग में परिवर्तन के लिए अनुकूल हो सकता है, तो उसे रनटाइम पर सामान को ट्रैक करने की भी आवश्यकता होती है, जो एक ओवरहेड को लगाता है। इसके लिए ब्रेक-इवन सहज रूप से केवल जहाँ व्यवहार में लगातार परिवर्तन होते हैं। वेब ऐप्स के लिए, संभवतः एक एकल (या बहुत कम) उपयोग पैटर्न है जिसके लिए अनुकूलन भुगतान करता है, इसलिए अनुकूलन क्षमता के कारण न्यूनतम प्रदर्शन में वृद्धि लगातार रूपरेखा के ओवरहेड को ऑफसेट नहीं करती है।
कोनराड रुडोल्फ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.