क्या तकनीकी सीमाएँ या भाषा सुविधाएँ हैं जो मेरी पायथन लिपि को समान C ++ प्रोग्राम के रूप में तेज़ होने से रोकती हैं?

Question

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

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

लेकिन क्या ऐसी तकनीकी सीमाएँ या भाषा सुविधाएँ हैं जो मेरी पायथन लिपि को समान C ++ प्रोग्राम के समान तेज़ होने से रोकती हैं?

Comments

हाँ यह कर सकते हैं। Python संकलक में कला की स्थिति के लिए PyPy देखें ।

— ग्रेग हेविगेल

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

— nwp

@nwp नहीं, यह आसान है, PyPy देखें। ट्रिकलियर, अभी भी खुला है, समस्याओं में शामिल हैं: जेआईटी संकलक के स्टार्ट अप विलंबता को कैसे दूर किया जाए, जटिल लंबे समय तक रहने वाले ऑब्जेक्ट ग्राफ़ के लिए आवंटन से कैसे बचा जाए, और सामान्य रूप से कैश का अच्छा उपयोग कैसे किया जाए।

Answer 1

मैंने खुद इस दीवार को तब मारा जब मैंने कुछ साल पहले एक पूर्णकालिक पायथन प्रोग्रामिंग की नौकरी ली। मैं पायथन से प्यार करता हूं, मैं वास्तव में करता हूं, लेकिन जब मैंने कुछ प्रदर्शन ट्यूनिंग करना शुरू किया, तो मुझे कुछ कठोर झटके लगे।

कड़े पाइथोनिस्टस मुझे सही कर सकते हैं, लेकिन यहां वे चीजें हैं जो मैंने पाया, बहुत व्यापक स्ट्रोक में चित्रित किया।

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

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

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

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

अब, वेब सेवा बेंचमार्क में, पायथन रूबी या पीएचपी जैसी अन्य संकलन-पर-रनटाइम भाषाओं के अनुकूल तुलना करता है। लेकिन यह संकलित अधिकांश भाषाओं के पीछे बहुत दूर है। यहां तक ​​कि वे भाषाएँ जो मध्यवर्ती भाषा को संकलित करती हैं और VM (जैसे जावा या C #) में चलती हैं, बहुत बेहतर करती हैं।

यहाँ बेंचमार्क परीक्षणों का एक बहुत ही दिलचस्प सेट है जिसे मैं कभी-कभी संदर्भित करता हूं:

http://www.techempower.com/benchmarks/

(सभी ने कहा, मैं अभी भी प्यारेन से प्यार करता हूं, और अगर मुझे उस भाषा को चुनने का मौका मिलता है जिसमें मैं काम कर रहा हूं, तो यह मेरी पहली पसंद है। ज्यादातर समय, मैं वैसे भी पागल थ्रूपुट आवश्यकताओं से विवश नहीं हूं।)

Comments

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

दूसरी समस्या जिसे आप इंगित कर रहे हैं वह केवल विशिष्ट कार्यान्वयन से संबंधित है और भाषा के लिए अंतर्निहित नहीं है। पहली समस्या के स्पष्टीकरण की आवश्यकता है: 28 "बाइट्स" का वजन क्या होता है यह चरित्र ही नहीं है, लेकिन यह तथ्य है कि यह एक स्ट्रिंग कक्षा में पैक किया गया है, इसके अपने तरीके और गुण हैं। एकल वर्ण को बाइट्स सरणी (शाब्दिक b'a) के रूप में प्रतिनिधित्व करते हुए "केवल" पायथन 3.3 पर 18 बाइट्स का वजन होता है और मुझे यकीन है कि स्मृति में वर्ण भंडारण को अनुकूलित करने के लिए और अधिक तरीके हैं यदि आपके आवेदन को वास्तव में इसकी आवश्यकता है।

— रेड

C # देशी रूप से (उदाहरण के लिए आगामी MS तकनीक, iOS के लिए Xamarin) संकलित कर सकता है।

— डेन

Answer 2

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

• शॉर्ट-रनिंग स्क्रिप्ट, उदाहरण के लिए sysadmin कार्यों के लिए उपयोग किया जाता है। कई ऑपरेटिंग सिस्टम जैसे उबंटू पायथन के शीर्ष पर अपने बुनियादी ढांचे का एक अच्छा हिस्सा बनाते हैं: सीपीथॉन नौकरी के लिए काफी तेज़ है, लेकिन लगभग कोई स्टार्ट-अप समय नहीं है। जब तक यह बैश से तेज है, यह अच्छा है।

• CPython में स्पष्ट शब्दार्थ होना चाहिए, क्योंकि यह एक संदर्भ कार्यान्वयन है। यह सरल अनुकूलन जैसे "फू ऑपरेटर के कार्यान्वयन का अनुकूलन" या "तेजी से बायटेकोड के संकलन सूची" की अनुमति देता है, लेकिन आम तौर पर ऐसी आशाओं को नष्ट कर देगा जो जानकारी को नष्ट कर देती हैं, जैसे कि इनलाइनिंग फ़ंक्शन।

बेशक, सिर्फ सीपीथॉन की तुलना में अधिक पायथन कार्यान्वयन हैं:

• Jython JVM के ऊपर बनाया गया है। JVM प्रदान किए गए बायोटेक की व्याख्या या JIT-compile कर सकता है, और इसमें प्रोफ़ाइल-निर्देशित अनुकूलन हैं। यह उच्च स्टार्ट-अप समय से ग्रस्त है, और जब तक जेआईटी अंदर नहीं जाता तब तक इसमें कुछ समय लगता है।

• PyPy कला का एक राज्य है, JITting Python VM। PyPy को RPython में लिखा गया है, जो Python का प्रतिबंधित उपसमूह है। यह सबसेट पायथन से कुछ अभिव्यंजकता को हटा देता है, लेकिन किसी भी चर के प्रकार को सांख्यिकीय रूप से अनुमान लगाने की अनुमति देता है। RPython में लिखा गया VM तब C को ट्रांसप्लान्ट किया जा सकता है, जो RPython C जैसा प्रदर्शन देता है। हालांकि, आरपीथॉन अभी भी सी से अधिक अभिव्यंजक है, जो नई अनुकूलन के तेजी से विकास की अनुमति देता है। PyPy कंपाइलर बूटस्ट्रैपिंग का एक उदाहरण है। PyPy (RPython नहीं!) ज्यादातर CPython संदर्भ कार्यान्वयन के अनुकूल है।

• साइथॉन (RPython की तरह) एक स्थिर टाइपिंग के साथ असंगत पायथन बोली है। यह सी कोड के लिए भी ट्रांसपाइल करता है, और सीपीथॉन दुभाषिया के लिए सी एक्सटेंशन आसानी से उत्पन्न करने में सक्षम है।

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

लेकिन क्या गुण या विशेषताएं वैनिला पायथन को प्रदर्शन के सी-लाइक स्तर तक पहुंचने से रोकती हैं, जो लंबे समय तक स्टार्ट-अप से अलग होती हैं?

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

• देर से बाध्यकारी और किसी भी स्थिर टाइपिंग की कमी। अजगर हमें इस तरह बकवास लिखने की अनुमति देता है:

  import random
  
  # foo is a function that returns an empty list
  def foo(): return []
  
  # foo is a function, right?
  # this ought to be equivalent to "bar = foo"
  def bar(): return foo()
  
  # ooh, we can reassign variables to a different type – randomly
  if random.randint(0, 1):
     foo = 42
  
  print bar()
  # why does this blow up (in 50% of cases)?
  # "foo" was a function while "bar" was defined!
  # ah, the joys of late binding

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

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

• कचरा इकठा करना। कई मामलों में, जीसी को पूरी तरह से टाला जा सकता है। C ++ हमें उन वस्तुओं को वैधानिक रूप से आवंटित करने की अनुमति देता है जो वर्तमान स्कोप के बचे रहने पर स्वचालित रूप से नष्ट हो जाती हैं Type instance(args);। तब तक, वस्तु जीवित है और अन्य कार्यों के लिए उधार दिया जा सकता है। यह आमतौर पर "पास-बाय-संदर्भ" के माध्यम से किया जाता है। रस्ट जैसी भाषाएं संकलक को सांख्यिकीय रूप से जांचने की अनुमति देती हैं कि ऐसी वस्तु का कोई सूचक वस्तु के जीवनकाल से अधिक नहीं है। यह स्मृति प्रबंधन योजना पूरी तरह से अनुमानित है, अत्यधिक कुशल है, और जटिल वस्तु रेखांकन के बिना अधिकांश मामलों के लिए उपयुक्त है। दुर्भाग्य से, पायथन को स्मृति प्रबंधन को ध्यान में रखकर नहीं बनाया गया था। सिद्धांत रूप में, एस्केप विश्लेषण का उपयोग उन मामलों को खोजने के लिए किया जा सकता है जहां जीसी से बचा जा सकता है। व्यवहार में, सरल विधि जंजीर जैसेfoo().bar().baz() ढेर पर अल्पकालिक वस्तुओं को आवंटित करना होगा (इस समस्या को छोटा रखने के लिए जेनेसी जीसी एक तरीका है)।

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

  • विशिष्ट आकार की सूचियाँ बनाई जा सकती हैं जैसे fixed_size = [None] * size। हालांकि, उस सूची के अंदर की वस्तुओं के लिए मेमोरी को अलग से आवंटित करना होगा। कंट्रास्ट सी ++, जहां हम कर सकते हैं std::array<Type, size> fixed_size।

  • एक विशिष्ट देशी प्रकार के पैक किए गए सरणियों को arrayअंतर्निहित मॉड्यूल के माध्यम से पायथन में बनाया जा सकता है । इसके अलावा, numpyदेशी संख्यात्मक प्रकारों के लिए विशिष्ट आकार वाले डेटा बफ़र्स का कुशल प्रतिनिधित्व प्रदान करता है।

सारांश

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

Answer 3

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

मैं यह दावा नहीं करने जा रहा हूं कि यह अस्वीकार्य व्यापार है। लेकिन यह पायथन की प्रकृति के लिए मौलिक है कि वास्तविक कार्यान्वयन कभी भी C ++ कार्यान्वयन के रूप में तेज़ नहीं होंगे।

Answer 4

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

1. व्याख्यात्मक उपरि। रनटाइम में मशीन निर्देशों के बजाय किसी प्रकार का बाइट कोड होता है और इस कोड को निष्पादित करने के लिए एक निश्चित ओवरहेड होता है।
2. ओवरहेड डिस्पैच करें। फ़ंक्शन कॉल के लिए लक्ष्य को रनटाइम तक नहीं जाना जाता है, और यह पता लगाने के लिए कि कॉल करने की कौन सी विधि लागत वहन करती है।
3. स्मृति प्रबंधन ओवरहेड। गतिशील भाषाएं उन वस्तुओं को संग्रहित करती हैं जिन्हें आवंटित किया जाना है और उनका निपटारा किया जाना है, और जो ओवरहेड प्रदर्शन करती है।

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

जेआईटी संकलन के साथ सी # / जावा के लिए पहले दो कम हैं लेकिन कचरा एकत्र स्मृति में एक लागत है। अच्छी तरह से लिखा कोड 2x C / C ++ तक पहुंच सकता है।

पायथन / रूबी / पर्ल के लिए इन तीनों कारकों की लागत अपेक्षाकृत अधिक है। C / C ++ की तुलना में 5x या इससे भी बदतर सोचें। (*)

याद रखें कि रनटाइम लाइब्रेरी कोड आपके कार्यक्रमों के समान भाषा में लिखा जा सकता है और इसमें प्रदर्शन की सीमाएँ समान हैं।

---

(*) जैसा कि जस्ट-इन_टाइम (JIT) संकलन को इन भाषाओं में विस्तारित किया जाता है, वे भी (आमतौर पर 2x) अच्छी तरह से लिखित C / C ++ कोड की गति से संपर्क करेंगे।

यह भी ध्यान दिया जाना चाहिए कि एक बार अंतर संकीर्ण है (प्रतिस्पर्धी भाषाओं के बीच), फिर एल्गोरिदम और कार्यान्वयन विवरणों में मतभेद हावी हैं। JIT कोड C / C ++ को हरा सकता है और C / C ++ असेंबली भाषा को हरा सकता है क्योंकि अच्छा कोड लिखना आसान है।

Comments

"याद रखें कि रनटाइम लाइब्रेरी कोड आपके कार्यक्रमों के समान भाषा में लिखा जा सकता है और प्रदर्शन की सीमाएं समान हैं।" और "पायथन / रूबी / पर्ल के लिए इन तीनों कारकों की लागत अपेक्षाकृत अधिक है। सी / सी ++ या बदतर की तुलना में 5x सोचो।" वास्तव में, यह सच नहीं है। उदाहरण के लिए, Hashरूबिनियस वर्ग (रूबी में कोर डेटस्ट्रक्टर्स में से एक) रूबी में लिखा गया है, और यह तुलनात्मक रूप से, कभी-कभी और भी तेजी से होता है, यारव की Hashकक्षा की तुलना में जो सी में लिखा गया है और एक कारण यह है कि रुबिनियस के रनटाइम के बड़े हिस्से। सिस्टम रूबी में लिखे गए हैं, ताकि वे कर सकें ...

— Jörg W Mittag

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

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

@ JörgWMittag: फिर भी सच है। रुबिनियस के पास JIT है, और JIT कोड अक्सर व्यक्तिगत बेंचमार्क पर C / C ++ को हराता है। मुझे कोई सबूत नहीं मिला कि जेएसी की अनुपस्थिति में यह मेटासेकुलर सामान गति के लिए बहुत कुछ करता है। [देखें JIT के बारे में स्पष्टता के लिए संपादित करें।]

— david.pfx

Answer 5

लेकिन क्या ऐसी तकनीकी सीमाएँ या भाषा सुविधाएँ हैं जो मेरी पायथन लिपि को समान C ++ प्रोग्राम के समान तेज़ होने से रोकती हैं?

नहीं, यह सिर्फ पैसे का सवाल है और संसाधनों को सी ++ रन बनाने में डाला जाता है। पैसे और संसाधनों को पायथन को तेजी से चलाने में डाला जाता है।

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

लेकिन फिर सन ने टीवी सेट टॉप बॉक्स में एनिमेटेड मेनू के लिए एक छोटी स्क्रिप्टिंग भाषा पर ध्यान केंद्रित करने के लिए सेल्फ प्रोजेक्ट (बड़े सिस्टम को विकसित करने के लिए एक परिपक्व सामान्य उद्देश्य) को रद्द कर दिया (आपने इसके बारे में सुना होगा, इसे जावा कहा जाता है), कोई नहीं था अधिक धन। वहीं, Intel, IBM, Microsoft, Sun, Metrowerks, HP et al। धन और संसाधनों की बड़ी मात्रा में सी ++ तेजी से खर्च किया। सीपीयू निर्माताओं ने सी + + तेज बनाने के लिए अपने चिप्स में सुविधाओं को जोड़ा। ऑपरेटिंग सिस्टम C ++ को तेज बनाने के लिए लिखे या संशोधित किए गए थे। तो, C ++ तेज है।

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

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

यदि आप अजगर को उपवास करने पर उतना पैसा, अनुसंधान और संसाधन खर्च करते हैं, जैसा कि C ++ के लिए किया गया था, और आप ऑपरेटिंग सिस्टम बनाने पर उतना पैसा, अनुसंधान और संसाधन खर्च करते हैं, जो कि Python प्रोग्राम को तेजी से चलाते हैं जैसा कि C ++ के लिए किया गया था और आप उसी के रूप में खर्च करते हैं सीपीयू बनाने पर बहुत पैसा, अनुसंधान और संसाधन जो पायथन प्रोग्राम बनाते हैं तेजी से चलते हैं जैसा कि C ++ के लिए किया गया था, फिर मेरे दिमाग में कोई संदेह नहीं है कि पायथन C ++ के तुलनीय प्रदर्शन तक पहुंच सकता है।

हमने ECMAScript के साथ देखा है कि यदि केवल एक खिलाड़ी प्रदर्शन को लेकर गंभीर हो जाए तो क्या हो सकता है। एक साल के भीतर, हमने सभी प्रमुख विक्रेताओं के लिए मूल रूप से पूरे बोर्ड में 10 गुना प्रदर्शन वृद्धि की है।