क्या पायथन में प्रोग्रामिंग C, C ++ या Java की तुलना में तेज है? [बन्द है]


27

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

सिंथेटिक रूप से, पायथन कोड निष्पादन योग्य छद्म कोड जैसा दिखता है। पायथन का उपयोग करते हुए कार्यक्रम विकास सी / सी ++ का उपयोग करने की तुलना में 5-10 गुना तेज है, और जावा का उपयोग करने की तुलना में 3-5 गुना तेज है। कई मामलों में, किसी भी C / C ++ / Java कोड को लिखे बिना किसी एप्लिकेशन के प्रोटोटाइप को पायथन में लिखा जा सकता है। अक्सर, प्रोटोटाइप पर्याप्त रूप से कार्यात्मक होता है और अंतिम उत्पाद के रूप में वितरित होने के लिए पर्याप्त रूप से अच्छा प्रदर्शन करता है, जिससे काफी विकास समय की बचत होती है। दूसरी बार, प्रोटोटाइप का अनुवाद भाग में या पूरे C ++ या Java में किया जा सकता है - पायथन का ऑब्जेक्ट-ओरिएंटेड नेचर अनुवाद को एक सरल प्रक्रिया बनाता है।

क्या इस मुद्दे का सही ढंग से वैज्ञानिक मूल्यांकन किया गया है? अगर लिए नहीं तो शायद , या जैसी भाषाओं की स्क्रिप्टिंग के लिए ?

जब तक कि शोधकर्ताओं या विशेषज्ञों की राय नहीं है कि इस मुद्दे पर गौर करने का समय आ गया है, तब तक मैं तर्कशक्ति, उपमा या स्पष्टीकरण की तलाश में नहीं हूं, क्योंकि इसका उत्तर देना कठिन हो सकता है।

मैंने शुरू में skeptics.SE पर यह सवाल पूछा था , और किसी ने सुझाव दिया कि मुझे इसे यहाँ भी पूछना चाहिए।


25
खैर, चूंकि आपने संभावित उत्तरों के सेट को प्रतिबंधित कर दिया है, मैं सिर्फ एक प्रश्न पूछकर एक अन्य प्रश्न पूछ रहा हूं, जिसका उत्तर पहले (imho) दिया जाना चाहिए: क्या "प्रोग्रामर की उत्पादकता" को मापने के लिए एक विश्वसनीय और विश्वसनीय मैट्रिक्स है?
पॉल मिशैलिक

1
@Paul Michalik - मुझे लगता है कि किसी भी शोध पत्र जो उत्पादकता को देखता है, उसमें एक परिभाषा शामिल होगी (अन्यथा इसे मापना वास्तव में कठिन होगा)। इसलिए यदि कोई शोध संदर्भित करता है तो यह उत्तर में परिभाषा को शामिल करने पर मददगार होगा। उत्पादकता को मापने के लिए कई अलग-अलग पूरी तरह से स्वीकार्य तरीके हैं शायद (मैं अनुमान लगा रहा हूं), "कई बार एकतरफा होने में समय लगता है" उनमें से एक होगा।
किट सुंडे

1
@Paul Michalik - ज़रूर लेकिन प्रोग्रामर से किताबों, ब्लॉगों, वार्ताओं और लेखों में पढ़े जाने वाले बयानों में से कितने वास्तव में अनुभवजन्य हैं? मुझे यकीन है कि उत्पादकता को मापने के बेहतर या बदतर तरीके हैं। उदाहरण के लिए। "कॉफी की खपत / समय" शायद शास्त्रीय "कोड / समय की रेखाएं" की तुलना में भी बदतर होगा। मैं विशिष्ट उत्पादकता दावों पर वापस निर्णय ले सकता हूं जिन्हें हमने देखा है और उस पर आधारित गुणों का तर्क दे सकते हैं। उत्पादकता का दावा सिर्फ सादा गलत नहीं है, मुझे यकीन है कि "कोड / समय की रेखाएं" कुछ मापती हैं जब लोग मीट्रिक को नष्ट करने की कोशिश नहीं कर रहे हैं।
किट सुंडे

1
आप इस लेख में दिलचस्पी ले सकते हैं: citeseerx.ist.psu.edu/viewdoc/…
दूरंतो

1
@ क्रिस - क्या आप कह रहे हैं कि यह क्वासिटॉन प्रोग्रामर्स के लिए लागू नहीं है। यह निश्चित रूप से संदेह करने के लिए है, और यह भी यहाँ फिट करने के लिए लग रहा था। मैं इस धारणा के अधीन था कि जब तक आप इस सवाल पर रॉबर्ट कार्टेनो की एक हालिया टिप्पणी नहीं पढ़ लेते, तब तक: skeptics.stackexchange.com/q/1963/631 जो अनिवार्य रूप से कहता है कि यह पूरी तरह से ठीक है अगर यह दोनों समुदायों के लिए ब्याज की है, और ऐसा करने के लिए किसी अन्य उपयोगकर्ता द्वारा प्रेरित किए जाने के बाद मैंने केवल यह किया। यह देखते हुए कि यह सवाल बढ़ रहा है, ऐसा लगता है कि यह इस समुदाय के लिए भी एक रुचि है।
किट सुंडे

जवाबों:


17

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

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

[१]: जेके ऑस्टरहॉट, स्क्रिप्टिंग: २१ वीं सदी के लिए उच्च स्तरीय प्रोग्रामिंग , कंप्यूटर (IEEE), १ ९९ K
[२]: बी। बोहम, सॉफ्टवेयर इंजीनियरिंग अर्थशास्त्र , अप्रेंटिस हॉल, १ ९ K१


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

@romkyns, किसी भी गैर-तुच्छ परियोजना के लिए आपको बहुत सारे कोड लिखने होंगे। यहां तक ​​कि अगर आपके पास बहुत से लेगो ईंटें हैं, तो बीओनिकल्स जादुई रूप से एक साथ नहीं आते हैं।

2
@ लेकिन यह वास्तव में उन लेगो ईंटों को आगे बढ़ाने में मदद करता है, पहले एक तेल ड्रिल, एक प्लास्टिक फैक्टरी और एक लेगो ब्लॉक एक्सट्रूडर बनाने के बजाय।
रोमन स्टार्कोव

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

7

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

मेरा मानना ​​है कि समयबद्ध प्रतियोगिता में यह संकेत मिलता है कि भाषा वास्तव में उन प्रकार के कार्यों के लिए मायने नहीं रखती है। ऐसी कोई भी भाषा नहीं है जो ऐसी चुनौतियों को दूसरों की तुलना में आसान जीतती हो (कम से कम यदि आप भाषाओं की सापेक्ष लोकप्रियता की अनुमति देते हैं तो नहीं)।

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

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


7
"आप वास्तव में प्रोग्रामर का मूल्यांकन कर रहे हैं, भाषा का नहीं" - ऐसा नहीं है यदि यह वास्तव में वैज्ञानिक रूप से किया गया है। 100 प्रोग्रामर ले लो। एक सामान्य परियोजना का चयन करें जैसे "इन विशिष्ट आवश्यकताओं के साथ एक कैलेंडर ऐप लिखें"। आवश्यकताओं को स्वचालित इकाई परीक्षण से बंधा हुआ है। 50 प्रोग्रामर C ++ में ऐप लिखते हैं, 50 Python में, रैंडम में चुने जाते हैं ताकि क्वालिटी डेवलपर्स समान रूप से बाधित हो जाएं। परिणाम यूनिट स्कोर की संख्या के साथ औसत समय पूरा करने के लिए एक स्कोर होगा। C ++ परिणाम और ... SCIENCE के औसत के साथ पायथन परिणामों के औसत की तुलना करें!
मॉर्गन हेरलॉकर

2
@Prof हो सकता है अगर आपको प्रत्येक का एक हज़ार मिलता है ... लेकिन फिर भी, आप इस तथ्य के लिए कैसे नियंत्रण रखते हैं कि केवल एक निश्चित मानसिकता और एक निश्चित स्तर की क्षमता वाले लोग C ++ को जानते हैं?
रोमन स्टार्कोव

आप अपना नमूना केवल उन लोगों से खींच सकते हैं जो C ++ और पायथन में दक्षता परीक्षा पास कर सकते हैं। मेरे बहुत सारे पुराने प्रोफेसर बहुत ही समान अध्ययन कर रहे थे। इसके अलावा, आप कुछ धारणाएँ बनाते हैं, जो अन्य लोगों ने यहाँ चर्चा की हैं: प्रोग्रामर.स्टैकएक्सचेंज
com/q/73715/3792

6

http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf उन कुछ अध्ययनों में से एक है, जिनके बारे में मुझे जानकारी है कि उन्होंने विभिन्न भाषाओं में उत्पादकता के बीच वास्तविक प्रत्यक्ष तुलना की। यह पुराना है, लेकिन पढ़ने के लायक है यदि आप विषय को दिलचस्प पाते हैं। तुलना में कई प्रमुख कमियां हैं जिनके बारे में लेख बहुत ईमानदार है।

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

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


1

आमतौर पर इसे लगाने के लिए, पायथन में एक प्रोग्राम लिखना आमतौर पर सी, सी ++, जावा में एक ही प्रोग्राम लिखने से अधिक तेज होगा।

इसके धीमे चलने की भी संभावना है।

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

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

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

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

http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Expressiveness


-5

पिछली बार मैंने जावा (थोड़ी देर पहले स्वीकार किया था) ने एक फाइल को खोलने और लिखने के लिए कोड से भरा स्क्रीन लिया था। इसकी तुलना पाइथन या पर्ल की कुछ पंक्तियों से करें, और आप अनुमान लगा सकते हैं कि कौन सा तेज है।

जाहिर है कि सभी भाषाओं की अपनी ताकत और कमजोरियां होती हैं, लेकिन अधिकांश कार्यों के लिए पाइथन लिखना अधिक तेज होगा।


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

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

यह मानता है कि किसी फ़ाइल को खोलने और लिखने के लिए जावा को कोड की 50 - 60 लाइनों की आवश्यकता होती है। यह केवल सही नहीं है।
15:22 पर h22
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.