अगर CPPy 6.3 गुना तेज है तो मुझे CPython पर PyPy का उपयोग क्यों नहीं करना चाहिए?

685

मैं PyPy प्रोजेक्ट के बारे में बहुत कुछ सुन रहा हूं । वे दावा करते हैं कि यह उनकी साइट पर सीपीथॉन दुभाषिया की तुलना में 6.3 गुना तेज है ।

जब भी हम पायथन जैसी गतिशील भाषाओं के बारे में बात करते हैं, तो गति शीर्ष मुद्दों में से एक है। इसे हल करने के लिए, वे कहते हैं कि PyPy 6.3 गुना तेज है।

दूसरा मुद्दा समानांतरवाद, कुख्यात ग्लोबल इंटरप्रेटर लॉक (GIL) है। इसके लिए, PyPy का कहना है कि यह GIL- कम पायथन दे सकता है ।

अगर PyPy इन महान चुनौतियों को हल कर सकता है, तो इसकी कमजोरियां क्या हैं जो व्यापक अपनाने को रोक रही हैं? यही कारण है कि कहने के लिए है, क्या मेरे जैसे किसी को, एक ठेठ अजगर डेवलपर, PyPy पर स्विच करने से रोकने अभी ?

— chhantyal
स्रोत

30

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

— शोग

3

मैं Pypy का बहुत उपयोग कर रहा हूं। यह बहुत अच्छी तरह से काम करता है। हालाँकि, जबकि Pypy कई CPU-भारी वर्कलोड के लिए काफी तेज है, यह वास्तव में I / O-भारी वर्कलोड के लिए धीमा है जिसे मैंने इसे फेंक दिया है। उदाहरण के लिए, मैंने एक बैकअप बैकअप प्रोग्राम लिखा, जिसे बैकशिफ्ट कहा जाता है। एक प्रारंभिक बैकअप के लिए, जो बहुत सारी फ़ाइल चंकिंग करता है, pypy बढ़िया है। लेकिन बाद के बैकअप के लिए जो ज्यादातर टाइमस्टैम्प को अपडेट कर रहे हैं, CPython तेज है।

— dstromberg

657

नोट: PyPy 2013 की तुलना में अधिक परिपक्व और बेहतर समर्थित है, जब यह प्रश्न पूछा गया था। आउट-ऑफ़-डेट जानकारी से निष्कर्ष निकालने से बचें।

PyPy, जैसा कि अन्य लोगों ने उल्लेख किया है, C एक्सटेंशन के लिए दस समर्थन है । यह है समर्थन, लेकिन आम तौर पर धीमी-से-अजगर गति पर है और यह सबसे अच्छे रूप में iffy है। इसलिए बहुत सारे मॉड्यूलों को बस सीपीथॉन की आवश्यकता होती है । ~~PyPy सुन्न का समर्थन नहीं करता है~~ PyPy अब numpy का समर्थन करता है । कुछ एक्सटेंशन अभी भी समर्थित नहीं हैं (पंडों, SciPy, आदि), परिवर्तन करने से पहले समर्थित पैकेजों की सूची पर एक नज़र डालें ।
~~फिलहाल~~ पायथन 3 सपोर्ट ~~प्रायोगिक है।~~ अभी-अभी स्थिर हुआ है! 20 जून 2014 तक, PyPy3 2.3.1 - फुलक्रम बाहर है !
PyPy कभी-कभी "स्क्रिप्ट" के लिए वास्तव में तेज़ नहीं होता है , जिसके लिए बहुत से लोग पायथन का उपयोग करते हैं। ये कम चलने वाले कार्यक्रम हैं जो कुछ सरल और छोटा करते हैं। क्योंकि PyPy एक JIT कंपाइलर है, जिसके मुख्य लाभ लंबे समय और सरल प्रकार (जैसे संख्या) से आते हैं। स्पष्ट रूप से, PyPy की पूर्व JIT गति CPython की तुलना में बहुत खराब है ।
जड़ता । PyPy में जाने के लिए अक्सर रिटोलिंग की आवश्यकता होती है, जो कुछ लोगों और संगठनों के लिए बस बहुत अधिक काम है।

वे मुख्य कारण हैं जो मुझे प्रभावित करते हैं, मैं कहूंगा।

— Veedrac
स्रोत

14

अच्छा है कि आप रिटोलिंग का उल्लेख करते हैं। मेरे वेब होस्ट, उदाहरण के लिए, पायथन 2.4 और 2.5 के बीच एक विकल्प है; और मेरे पास "मनोरंजन सॉफ्टवेयर का एक प्रमुख उत्पादक" जल्द ही अपग्रेड करने की कोई योजना नहीं के साथ 2.6 का उपयोग कर रहा है। कभी-कभी यह एक रूपांतरण की लागत का पता लगाने के लिए एक प्रमुख, महंगा प्रयास भी हो सकता है।

— माइक हाउसकी

19

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

— cjordan1

12

@ cjordan1: मुझे वह नहीं मिला, जो आप कह रहे हैं। np.sum(M[1:2*n**2:2, :2*n**2] * M[:2*n**2:2, :2*n**2].conjugate(), axis=1)पायथन में उच्च स्तरीय सुन्न निर्माण बेहद स्पष्ट ( ?) हैं और यह वैज्ञानिक समुदाय के लिए पायथन को बहुत उपयुक्त बनाता है। इसके अतिरिक्त, पायथन में गैर-गहन भागों को करना और छोटे गहन छोरों के लिए C से बाहर की ओर झुकना एक सामान्य और प्रयोग करने योग्य रणनीति है।

— विड्राक

26

@Veedrac यही मेरा मतलब है। के रूप में "जाओ cblas और lapacke में हस्ताक्षर पर हस्ताक्षर देखो" क्योंकि वे इतने लंबे और उपयोग करने में मुश्किल हैं कि आप तुरंत समझ जाएंगे कि हम पॉइंटर्स और मेटाडाटा के चारों ओर फेरी करने के लिए पायथन का उपयोग क्यों करते हैं।

— cjordan1

5

@ tommy.carstensen यह वास्तव में गहराई में जाने के लिए एक अच्छी जगह नहीं है, लेकिन मैं कोशिश करूँगा। 1. यह तब बहुत अधिक सच था जब मैंने इसे लिखा था अब की तुलना में। 2. "लिपियाँ" अक्सर IO-भारी होती हैं। PyPy का IO अभी भी अक्सर CPython की तुलना में धीमा है - यह काफी धीमा हुआ करता था। 3. PyPy स्ट्रिंग्स को संभालने में CPython की तुलना में धीमा हुआ करता था - अब यह अक्सर बेहतर होता है और शायद ही कभी खराब होता है। 4. कई स्क्रिप्ट "सिर्फ गोंद कोड हैं - दुभाषिया को तेज बनाने से उस मामले में समग्र रनटाइम में सुधार नहीं होगा। 5. PyPy का वार्मअप समय बड़ा होता था - बहुत कम चलने वाली स्क्रिप्ट बहुत कम हॉट कोड का निर्माण करने में कामयाब होती थी।

— विड्राक

104

उस साइट का दावा नहीं है कि PyPy CPython की तुलना में 6.3 गुना तेज है। उद्धरण के लिए:

सभी बेंचमार्क का ज्यामितीय औसत CPython की तुलना में 0.16 या 6.3 गुना तेज है

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

उसको तोड़ने के लिए:

वे जो बयान करते हैं, वे केवल उन बेंचमार्क पर लागू होते हैं, जिनका उन्होंने उपयोग किया है। यह आपके कार्यक्रम के बारे में बिल्कुल कुछ नहीं कहता है (जब तक कि आपका कार्यक्रम बिल्कुल उनके बेंचमार्क के समान नहीं है)।
बयान बेंचमार्क के एक समूह के औसत के बारे में है । इस बात का कोई दावा नहीं है कि PyPy को चलाने से उनके द्वारा परीक्षण किए गए कार्यक्रमों के लिए भी 6.3 गुना सुधार मिलेगा।
इस बात का कोई दावा नहीं है कि PyPy उन सभी कार्यक्रमों को भी चलाएगी, जो CPython सभी पर चलते हैं, अकेले और अधिक तेज़ी से चलते हैं।

— spookylukey
स्रोत

15

बेशक, इस बात का कोई दावा नहीं है कि PyPy सभी पायथन कोड को तेज़ी से चलाएगा। लेकिन अगर आप सभी शुद्ध पायथन आवेदन लेते हैं, तो मैं शर्त लगा सकता हूं कि उनमें से अधिकांश बहुमत PyPy पर CPython पर बहुत तेज़ी से (> 3x बार) चलेगा।

— रॉबर्ट ज़रेम्बा

18

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

— शॉन जेफ्री पीटज़

6

@SeanGeoffreyPietz - मैं दावा नहीं कर रहा था कि PyPy की साइट किसी भी तरह से भ्रामक है - उन्होंने अपने परिणामों को सटीक रूप से प्रस्तुत किया है। लेकिन मूल प्रश्न ने उन्हें गलत समझा, और यह प्रदर्शित किया कि लेखक ने 'औसत' शब्द के महत्व को नहीं समझा। कई व्यक्तिगत बेंचमार्क 6.3 गुना तेज नहीं हैं। और यदि आप एक अलग प्रकार के औसत का उपयोग करते हैं, तो आपको एक अलग मूल्य मिलता है, इसलिए "6.3 x तेज़" "ज्यामितीय औसत 6.3 x तेज़" का पर्याप्त सारांश नहीं है। "ग्रुप ए, ग्रुप बी की तुलना में Z गुना तेज है" सार्थक होने के लिए बहुत अस्पष्ट है।

— spookylukey

6

-1: @spookylukey आपको लगता है कि बेंचमार्क सुइट पक्षपाती है, जो दावे का समर्थन करने के लिए सबूत प्रदान किए बिना पक्षपाती है। आलोचना को हमेशा सबूतों के साथ समर्थन किया जाना चाहिए!

— एवगेनी सर्गेव

5

@EvgeniSergeev - नहीं, मैं यह मान रहा हूं कि सभी बेंचमार्क पक्षपाती हैं! जरूरी नहीं कि जानबूझकर, बिल्कुल। संभावित उपयोगी कार्यक्रमों का स्थान अनंत और अविश्वसनीय रूप से विविध है, और बेंचमार्क का एक सेट केवल उन बेंचमार्क पर प्रदर्शन को मापता है। यह पूछने पर कि "CPPthon की तुलना में PyPy कितना तेज़ है?" यह पूछने की तरह है कि "फ्रेड जोए की तुलना में कितना तेज है?", जिसे ओपी जानना चाहता है।

— spookylukey

74

चूँकि pypy 100% संगत नहीं है, इसलिए संकलन करने के लिए 8 ggs का RAM लेता है, एक गतिशील लक्ष्य है, और अत्यधिक प्रायोगिक है, जहाँ cpython स्थिर है, 2 दशकों के लिए मॉड्यूल बिल्डरों के लिए डिफ़ॉल्ट लक्ष्य (c एक्सटेंशन सहित, जो pyy पर काम नहीं करता है) ), और पहले से ही व्यापक रूप से तैनात है।

Pypy संभवतः संदर्भ कार्यान्वयन नहीं होगा, लेकिन यह एक अच्छा उपकरण है।

— Tritium21
स्रोत

2

Pypy.org/download.html के अनुसार , PyPy को संकलन करने के लिए 4 GB RAM की आवश्यकता है (64-बिट सिस्टम पर), 8. नहीं और यदि आवश्यक हो तो 3 जीबी के नीचे करने के लिए उस पृष्ठ पर एक विकल्प है।

— नाइट

4

@ एकइटी 1: यह 2015 की तरह नया है, दस्तावेज ने ऐतिहासिक रूप से 8 जीबी पढ़ा है। २: २०१५ में आपको अभी भी कम से कम 2015 की जरूरत है, ६-। मुक्त।

— ट्रिटियम

4

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

— smci

@smci यह प्राचीन आंकड़ों पर आधारित एक प्राचीन प्रश्न है, जिसमें प्राचीन उत्तर हैं। इस सवाल पर विचार करें और 4 साल पहले राज्य के लिए ऐतिहासिक होने के लिए हर उत्तर।

— Tritium21

1

@ Tritium21: मुझे केवल वर्तमान उत्तर में दिलचस्पी है। यह क्या है? आप अपने उत्तर को "2013 के अनुसार, पेप्सी बनाम संस्करण 2.x पायथन की तुलना करते हैं " कहने के लिए अपने उत्तर को संपादित करना पसंद कर सकते हैं ... " यदि प्रश्न में" 6.3x ज्यामितीय-औसत "दावा आउट-ऑफ़-डेट है ( जैसा कि 4/2017 के अनुसार वे 7.5x का दावा करते हैं, लेकिन फिर भी बेंचमार्क पर निर्भर करता है ... ), फिर उस संपादन की भी आवश्यकता है (संस्करण संख्या, नवीनतम डेटा, आदि) मुझे लगता है कि बेंचमार्क सूट बहुत प्रासंगिक नहीं है, शायद ही कोई चलाएगा। एक सीपीयू पर इन दिनों एक स्क्रिप्टिंग भाषा में पुनर्लेखन। मुझे pybenchmark.org

— smci

37

दूसरा प्रश्न उत्तर देना आसान है: आप मूल रूप से कर सकते हैं रूप से PyPy को ड्रॉप-इन रिप्लेसमेंट के रूप में उपयोग हैं यदि आपका सभी कोड प्योर पायथन है। हालांकि, कई व्यापक रूप से उपयोग किए जाने वाले पुस्तकालय (कुछ मानक पुस्तकालय सहित) सी में लिखे गए हैं और पायथन एक्सटेंशन के रूप में संकलित किए गए हैं। इनमें से कुछ PyPy के साथ काम करने के लिए बनाए जा सकते हैं, कुछ नहीं। PyPy Python के रूप में एक ही "फॉरवर्ड-फेसिंग" टूल प्रदान करता है --- अर्थात, यह Python --- है, लेकिन इसके अंतर अलग-अलग हैं, इसलिए उन innards के साथ इंटरफ़ेस वाले टूल काम नहीं करेंगे।

पहले सवाल के रूप में, मुझे लगता है कि यह पहले के साथ एक कैच -22 की तरह है: PyPy तेजी से सुधार और अन्य कोड के साथ अंतर को बढ़ाने के प्रयास में तेजी से विकसित हो रहा है। इसने इसे आधिकारिक से अधिक प्रयोगात्मक बना दिया है।

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

— BrenBarn
स्रोत

17

मुझे नहीं लगता कि सी एक ऐसी भाषा है जो जल्द ही कहीं भी जा रही है (मैं कहना चाहूंगा, यह हमारे जीवनकाल में गायब नहीं होगा)। जब तक एक और भाषा है जो कहीं भी चलेगी, हमारे पास C. (नोट होगा, JVM, C. Even जावा में लिखा गया है, वह भाषा जो "हर जगह" चलती है) को इसके हर काम के लिए C की आवश्यकता होती है।) अन्यथा मैं इस पोस्ट से सबसे अधिक सहमत हूँ इसके बिंदुओं के।

— ट्रिटियम

7

@ Tritium21: हाँ, मैं सिर्फ वहाँ संपादकीय कर रहा हूँ। मैं C के साथ ठीक हूं, लेकिन मुझे लगता है कि C पर पायथन की निर्भरता बेहद हानिकारक है, और PyPy इस बात का एक बड़ा उदाहरण है कि: अब हमारे पास तेजी से पायथन प्राप्त करने का मौका है, लेकिन हम C पर भरोसा करने के वर्षों में फंस गए हैं यह पायथन के लिए अपने दो पैरों पर खड़ा होना बेहतर होगा। यह ठीक भी है यदि पायथन स्वयं सी में लिखा गया है, लेकिन समस्या एक विस्तार तंत्र का अस्तित्व है जो लोगों को उन तरीकों से अजगर को विस्तार करने के लिए प्रोत्साहित करता है जो सी पर निर्भर हैं

— ब्रेनबर्न

4

उस पर दोहरी धार वाली तलवार - जो कि अजगर को इतना लोकप्रिय बनाती है, वह अन्य अनुप्रयोगों को विस्तारित करने और अन्य अनुप्रयोगों द्वारा विस्तारित करने की क्षमता है। यदि आप इसे दूर ले जाते हैं, तो मुझे नहीं लगता कि हम अजगर के बारे में बात करेंगे।

— Tritium21

10

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

— पीटर वैंग

4

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

— विकी

14

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

BDFL और CPython Developers लोगों के एक उल्लेखनीय बुद्धिमान समूह हैं और CPython को ऐसे परिदृश्य में उत्कृष्ट प्रदर्शन करने में मदद करने में कामयाब रहे हैं। यहाँ एक बेशर्म ब्लॉग प्लग है: http://www.hydrogen18.com/blog/unpickling-buffers.html । मैं स्टैकलेस का उपयोग कर रहा हूं, जो कि सीपीथॉन से लिया गया है और पूर्ण सी मॉड्यूल इंटरफ़ेस को बरकरार रखता है। मुझे उस मामले में PyPy का उपयोग करने का कोई फायदा नहीं मिला।

— एरिक अर्बन
स्रोत

1

PyPy के पास कई हैं, सावधानी से बेंचमार्क चलाते हैं (दुर्भाग्य से CPython के विपरीत, जिसके पास वास्तव में उपयोगकर्ता के सामने वाला बेंचमार्क सूट नहीं है)। निश्चित रूप से नेटवर्क ट्रैफ़िक के लिए PyPy जादुई रूप से कुछ भी तेज़ नहीं कर सकता है।

— जुलियन

1

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

— एलेक्स रुबिनस्टीन

9

@AlexRubinsteyn लेकिन PyPy पर काम करने वालों का दृष्टिकोण हमेशा से यही रहा है कि अगर आपको ऐसा मामला मिल जाए जहाँ PyPy CPython की तुलना में धीमा हो, और आप इसे एक उचित बेंचमार्क में बदल सकते हैं, तो इसमें सुइट में जोड़े जाने का अच्छा मौका है।

— gsnedders

1

मैंने आपका ब्लॉग चेक किया। आपके परिणामों में, सादा-पायथन जोड़ी (अचार, स्ट्रिंगियो) से पता चलता है कि खसखस से अधिक ~ pypy ~ 6.8x तेज है। मुझे लगता है कि यह एक उपयोगी परिणाम है। अपने निष्कर्ष में, आप इंगित करते हैं (सही ढंग से) कि pypy कोड (जो सादा अजगर है!) C कोड (cPickle, cStringIO) की तुलना में धीमा है, न कि cpython कोड।

— कालेब हतींग

1

@gsnedders मैं के आधार पर एक बेंचमार्क की पेशकश की है rinohtype पर कई अवसरों । उन्होंने इसे अभी तक सुइट में नहीं जोड़ा है।

— ब्रेख्त मचिएल्स

12

प्रश्न: यदि PyPy, CPython की तुलना में इन महान चुनौतियों (गति, स्मृति की खपत, समानता) को हल कर सकता है, तो इसकी कमजोरियां क्या हैं जो व्यापक अपनाने को रोक रही हैं?

A: सबसे पहले, इस बात के बहुत कम सबूत हैं कि PyPy टीम सामान्य रूप से गति की समस्या को हल कर सकती है । दीर्घकालिक सबूत दिखा रहे हैं कि PyPy CPython की तुलना में कुछ Python कोड को धीमा चलाता है और यह खामी PyPy में बहुत गहराई से निहित लगती है।

दूसरे, PyPy का वर्तमान संस्करण मामलों के एक बड़े समूह में CPython की तुलना में बहुत अधिक मेमोरी का उपभोग करता है। इसलिए PyPy ने अभी तक मेमोरी खपत की समस्या को हल नहीं किया है।

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

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

प्रश्न: मैं अब PyPy के साथ CPython के प्रतिस्थापन में ड्रॉप क्यों नहीं कर सकता?

A: PyPy CPython के साथ 100% संगत नहीं है क्योंकि यह हुड के नीचे CPython का अनुकरण नहीं कर रहा है। कुछ कार्यक्रम अभी भी CPython की अनूठी विशेषताओं पर निर्भर हो सकते हैं जो PyPy में अनुपस्थित हैं जैसे C बाइंडिंग, C, पायथन ऑब्जेक्ट और विधियों के कार्यान्वयन, या CPython के कचरा संग्राहक की वृद्धिशील प्रकृति।

यह उत्तर किसी भी बेंचमार्क का उल्लेख नहीं करता है या संदर्भ प्रदान नहीं करता है।

— qwr

7

CPython में संदर्भ गिनती और कचरा संग्रह है, PyPy में केवल कचरा संग्रह है।

इसलिए वस्तुओं को पहले हटा दिया __del__जाता है और CPython में अधिक पूर्वानुमानित तरीके से बुलाया जाता है। कुछ सॉफ्टवेयर इस व्यवहार पर निर्भर करते हैं, इस प्रकार वे PyPy के लिए प्रवास के लिए तैयार नहीं हैं।

कुछ अन्य सॉफ़्टवेयर दोनों के साथ काम करते हैं, लेकिन सीपीथॉन के साथ कम मेमोरी का उपयोग करते हैं, क्योंकि अप्रयुक्त ऑब्जेक्ट पहले मुक्त हो जाते हैं। (मेरे पास यह बताने के लिए कोई माप नहीं है कि यह कितना महत्वपूर्ण है और अन्य कार्यान्वयन विवरण मेमोरी उपयोग को कैसे प्रभावित करते हैं।)

— अंक
स्रोत

17

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

3

CPython में प्रति ऑब्जेक्ट ओवरहेड अधिक होता है, जो बहुत सारी वस्तुएं बनाने से पहले एक बहुत मायने रखता है। मेरा मानना है कि PyPy डिफ़ॉल्ट रूप से एक चीज़ के लिए स्लॉट के बराबर काम करता है।

4

बहुत सी परियोजनाओं के लिए, गति के संदर्भ में विभिन्न अजगर के बीच वास्तव में 0% अंतर है। यह वह है जो इंजीनियरिंग के समय में हावी है और जहां सभी अजगर पुस्तकालय की राशि का समर्थन करते हैं।

— Stephan Eggermont
स्रोत

1

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

1

इसका सरल से कोई लेना-देना नहीं है। इंजीनियरिंग के समय में फीडबैक लूप महत्वपूर्ण है। कभी-कभी रन टाइम से ज्यादा महत्वपूर्ण होता है।

— Stephan Eggermont

1

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

यहां कुछ भी अस्पष्ट नहीं है। OODA लूप, या PDCA पर एक नज़र डालें।

— स्टीफन एगरमोंट

3

@user खैर, किसी भी परियोजना को एक बार चलाने के लिए लिखने में एक महीने का समय लगता है, और एक मिनट चलने के लिए, PyPy का उपयोग करने से कुल 0.0% गति (1month + 1min बनाम 1month) होगी, भले ही PyPy एक हज़ार से अधिक तेज़ हो। Stephan दावा नहीं कर रहा था कि सभी परियोजनाओं में 0% की गति होगी।

— gmatht

4

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

— यिशेन चेन
स्रोत

16

"बैटरी-शामिल" का अर्थ है बड़े मानक पुस्तकालय , AFAIK

— tshepang

4

मुझे ऐसे उदाहरण मिले हैं, जहां PyPy, Python की तुलना में धीमा है। लेकिन: केवल विंडोज पर।

C:\Users\User>python -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 294 msec per loop

C:\Users\User>pypy -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 1.33 sec per loop

इसलिए, यदि आप PyPy के बारे में सोचते हैं, तो विंडोज को भूल जाएं। लिनक्स पर, आप भयानक त्वरण प्राप्त कर सकते हैं। उदाहरण (1 और 1,000,000 के बीच सभी सूची को सूचीबद्ध करें):

from sympy import sieve
primes = list(sieve.primerange(1, 10**6))

यह अजगर की तुलना में PyPy पर 10 (!) गुना अधिक तेज चलता है। लेकिन खिड़कियों पर नहीं। वहां यह केवल 3x तेज है।

— lifolofi
स्रोत

दिलचस्प! कुछ और तुलनाएं और संख्या बहुत अच्छी रही होगी।

— 2226 में ben26941

1

PyPy को कुछ समय के लिए Python 3 का समर्थन मिला है, लेकिन 2 अप्रैल, 2018 से एंथनी शॉ द्वारा इस HackerNoon पोस्ट के अनुसार , PyPy3 PyPy (Python 2) की तुलना में कई गुना धीमा है।

कई वैज्ञानिक गणनाओं के लिए, विशेष रूप से मैट्रिक्स गणना, सुन्न एक बेहतर विकल्प है ( FAQ देखें : क्या मुझे सुन्न या पिप्पली स्थापित करना चाहिए? )।

Pypy gmpy2 का समर्थन नहीं करता है। इसके बजाय आप gmpy_cffi का उपयोग कर सकते हैं, हालांकि मैंने इसकी गति का परीक्षण नहीं किया है और परियोजना की 2014 में एक रिलीज हुई थी।

प्रोजेक्ट यूलर समस्याओं के लिए, मैं PyPy का लगातार उपयोग करता हूं, और साधारण संख्यात्मक गणना के लिए अक्सर from __future__ import divisionमेरे उद्देश्यों के लिए पर्याप्त होता है, लेकिन पायथन 3 समर्थन अभी भी 2018 के अनुसार काम कर रहा है, जिसमें आपका सबसे अच्छा दांव 64-बिट लिनक्स पर है। Windows PyPy3.5 v6.0, दिसंबर 2018 तक नवीनतम, बीटा में है।

— qwr
स्रोत

0

समर्थित पायथन संस्करण

पायथन के ज़ेन का हवाला देने के लिए :

पठनीयता मायने रखती है।

उदाहरण के लिए, पायथॉन 3.7 ने डेटासलैस और पायथन 3.8 ने फस्ट्रिंग = पेश किया ।

पायथन 3.7 और पायथन 3.8 में अन्य विशेषताएं हो सकती हैं जो आपके लिए अधिक महत्वपूर्ण हैं। मुद्दा यह है कि फिलहाल PyPy Python 3.7 या Python 3.8 का समर्थन नहीं करता है।

— मार्टिन थोमा
स्रोत