"पायथन धीमा है" और मरने वाले युग के अन्य मिथक

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

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

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

और बेसिक और असेंबली में, वे आमतौर पर थे। बेसिक एक अनिवार्य भाषा है, यहां तक कि संरचनात्मक प्रोग्रामिंग के लिए भी अनुकूल नहीं है। यहां तक कि एक "फ़ंक्शन" के रूप में प्रधान के रूप में एक अंतर्निहित भाषा निर्माण नहीं है, लेकिन एक पैटर्न: "GOSUB ... RETURN", विधानसभा में "कॉल ... रिट" की तरह बहुत अधिक है।

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

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

फिर भी यह पूरा कारोबार अब एक घोटाले की तरह नजर आ रहा है। हम इसे C++ में फिर से लिखकर कोड को धीमा कर रहे हैं ताकि हम कोड को फिर से इंजीनियरिंग करके इसे और तेज़ बना सकें। हम इसे सीधे पायथन में फिर से इंजीनियर क्यों नहीं करते? आह! बात यह है कि हम पायथन को नहीं जानते हैं। हम थोड़ा सा पायथन जानते हैं, पढ़ने और समझने के लिए पर्याप्त है, लेकिन इसमें अल्ट्रा-फास्ट प्रोग्राम बनाने के लिए पर्याप्त नहीं है।

तो क्या जानना है?

पुस्तकालयों

अधिकांश पायथन पुस्तकालय सी या फोरट्रान में लिखे गए हैं। NumPy core को C में लिखा गया है; पांडा - साइथन और सी में; SciPy - फोरट्रान, सी और आंशिक रूप से सी ++ में। सी ++, जंग, या जूलिया में जो कुछ भी लिखा गया था उससे धीमा होने का उनके पास कोई कारण नहीं है। हालांकि वे तेज हो सकते हैं।

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

बेशक, एक उचित लक्ष्य के लिए निर्मित कम्प्यूटेशनल लाइब्रेरी आम तौर पर सीमित सुपरस्क्लेयर क्षमताओं वाले 15 वर्षीय सामान्य कंप्यूटर के लिए बनाए गए समकक्ष पुस्तकालय की तुलना में तेज़ होगी।

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

संकलनकर्ता

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

व्याख्या और संकलन के बीच का अंतर ही पिछली सदी का कुछ है। आजकल, IGCC , PicoC , या CCons जैसे C इंटरप्रेटर हैं, और Python कंपाइलर हैं। JIT कंपाइलर जैसे [PyPy] और क्लासिक कंपाइल-बिफोर-यू-रन कंपाइलर जैसे कोडन (जिसमें JIT क्षमता भी है यदि आप केवल अपने कोड का हिस्सा संकलित करना चाहते हैं)।

कोडन एलएलवीएम पर बनाया गया है, वही बुनियादी ढांचा रस्ट, जूलिया या क्लैंग पर बनाया गया है। कोडन के साथ बनाया गया कोड समान प्रदर्शन स्तरों पर चलता है, देता है या लेता है, जैसा कि उनमें से किसी के साथ बनाया गया है। पायथन के कचरा संग्रह या बड़े देशी डेटा प्रकारों के कारण प्रदर्शन में कमी हो सकती है लेकिन हम अब 100x या 10x के बारे में बात नहीं कर रहे हैं। एलएलवीएम अपना जादू करता है। यह आपके लिए पायथन कोड को मशीन कोड में बदल देता है।

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

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

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

नुम्बा और इसका कर्नेल मॉडल

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

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

इसलिए लाइटमैटर अभी तक नहीं है। लेकिन एनवीडिया है। उन्होंने Numba के लिए अपना CUDA बैकएंड प्रदान किया और अब आप Python में गुठली लिख सकते हैं, और उन्हें अधिकतम दक्षता के साथ NVidia हार्डवेयर पर चला सकते हैं। सी ++ में वह नहीं है। हालाँकि, NVidia से आने वाली एक CU बोली है, जो निश्चित रूप से इस मामले के लिए C ++ का विस्तार करती है। पायथन में, आपको स्वयं भाषा का विस्तार करने की आवश्यकता नहीं है। चूंकि Numba JIT कर्नेल कंपाइलर के रूप में काम करता है, इसलिए बैकएंड जोड़ना केवल लाइब्रेरी को पैच करने का मामला है।

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

यह कुछ ऐसा है जो पारंपरिक संकलक के साथ हासिल करना कठिन है जहां आप अनुवाद इकाई के बीच में संकलन विकल्प नहीं बदल सकते। ठीक है, कर्नेल मॉडल के साथ, प्रत्येक कर्नेल की अपनी अनुवाद इकाई होती है।

निष्कर्ष

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

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

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

यह देखने के लिए तैयार रहें कि कुछ वर्षों में पायथन कंपाइलर: PyPy, Numba, या कुछ पूरी तरह से नया, कोड को अधिक प्रभावी ढंग से उत्पन्न करने के लिए स्पाइरल या हर्बी से तकनीक उधार लेगा कि कोई भी पारंपरिक कंपाइलर संभवतः पास नहीं आ सकता है। आखिरकार, पायथन में एक नया JIT बैकएंड लिखना पूरे LLVM इन्फ्रास्ट्रक्चर को फिर से तैयार करने की तुलना में आसान है।