एक अनुवादक से: कुछ घंटे पहले, गुइडो ने अपने ट्विटर पर अपने सहकर्मी के ब्लॉग पोस्ट का उल्लेख किया , जिसमें से एक (पूर्व) अनलाडेन स्वॉल डेवलपर्स है, जिसमें वह गूगल पर अनलाडेन स्वालो की जीवंत लेकिन अल्पायु की दुखद कहानी बताता है।

मूल: रीड क्ल्केनर - अनलडेन स्वल्ट रेट्रोस्पेक्टिव

अनलडेन स्वोलो: रेट्रोस्पेक्टिव

मैंने यह लिखना तब शुरू किया जब मैं PyCon पर था, लेकिन तब से पाठ को थोड़ा अपडेट कर रहा हूं। जैसा भी हो, यहां हो। :)

जैसा कि यह अब स्पष्ट है, किसी और ने गंभीरता से या तो सीधे अनलाडेन निगल के साथ सौदा नहीं किया है, या इसे py3k में पोर्ट कर रहा है। क्यों?

ग्राहक की रुचि का नुकसान

मुख्य कारण यह है कि Google को अनलडेन स्वॉल के लिए पर्याप्त संभावित उपयोगकर्ता नहीं मिले। इसके कई कारण हैं:

1. Google के अजगर कोड के थोक के लिए, उच्च प्रदर्शन की आवश्यकता नहीं है। पायथन मुख्य रूप से टूल और प्रोटोटाइप के लिए उपयोग किया जाता है, जबकि मुख्य अंत-उपयोगकर्ता एप्लिकेशन जावा और सी ++ में लिखे गए हैं।
2. जिन आंतरिक उपयोगकर्ताओं के लिए प्रदर्शन महत्वपूर्ण था, वे अनलडेन स्वॉल को तैनात करने के लिए बहुत जटिल आवश्यकताओं से भ्रमित थे। उनके लिए, यह सिर्फ जरूरी नहीं था कि अनलडेन स्वॉल सीपीथॉन के लिए एक प्रतिस्थापन हो - किसी भी नए पायथन कार्यान्वयन को मौजूदा "टर्नकी" को बदलना चाहिए। हमने सोचा था कि सीपीथॉन पर स्रोत कोड को आधार बनाकर, और पूर्ण शून्य से विकास शुरू नहीं करने से, हम इस समस्या से बचेंगे, क्योंकि C और SWIG आवरण के सभी एक्सटेंशन काम करना जारी रखेंगे जैसे कि कुछ भी नहीं हुआ था। हालाँकि, यहां तक ​​कि सीपीथॉन के पिछले संस्करण से पायथन 2.6 में अपग्रेड करना भी जटिल था।
3. एक या दूसरे तरीके से, हमारे संभावित उपयोगकर्ताओं ने अपनी प्रदर्शन समस्याओं को हल करने के लिए अन्य तरीके ढूंढे, जो उन्हें तैनात करने के लिए अधिक सुविधाजनक थे।

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

स्वहित की हानि

मूल रूप से, उपरोक्त सभी को 2010 की पहली तिमाही में माना गया था। हम अभी भी अपने खाली समय में अनलाडेन पर काम करने का फैसला कर सकते थे, लेकिन यह अलग होगा।

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

दूसरे, हमारी रुचि के मुख्य कारणों में से एक यह था कि हम मानते थे कि PyPy कभी भी C एक्सटेंशन या SWIG लिपटे कोड का समर्थन करने का प्रयास नहीं करेगा। हमें बहुत आश्चर्य हुआ जब हमें पता चला कि PyPy परियोजना इस दिशा में आगे बढ़ने लगी है। इसने आंशिक रूप से CPththon के लिए प्लग-इन JIT की आवश्यकता को कम कर दिया। इसके अलावा, जब परियोजना शुरू की गई थी, तो PyPy ने अभी तक 64-बिट प्लेटफॉर्म का समर्थन नहीं किया था, लेकिन समय के साथ उन्होंने इस समर्थन को जोड़ दिया।

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

इसलिए, उपरोक्त सभी कारणों को ध्यान में रखते हुए, क्यों हममें से कोई भी अब अनलडेन के साथ कोई व्यवहार नहीं करता है, हम क्या समझते हैं?

एलएलवीएम के बारे में निष्कर्ष

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

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

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

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

इसके अलावा, मैंने गर्मियों में LLVM JIT और gdb के बीच एक इंटरफ़ेस का निर्माण किया। यह आवश्यक नहीं था, लेकिन परिणाम एक उपयोगी उपकरण था। मुझे पता नहीं है कि PyPy को डिबग करने के लिए क्या उपयोग किया जा रहा है, लेकिन हम अपने अनुभव का उपयोग कर सकते हैं और इसे PyPy पर लागू कर सकते हैं।

परिणाम

व्यक्तिगत रूप से, इस परियोजना पर काम शुरू करने से पहले ही, मैंने कंपाइलर और ऑपरेटिंग सिस्टम पर एक कोर्स कर लिया, लेकिन काम करते समय मैंने जो अनुभव प्राप्त किया, उससे मुझे बड़ी मात्रा में नए कौशल प्राप्त हुए। मैं अब gdb में बहुत अच्छी तरह से वाकिफ हूँ, मैंने इसे अपने लिए शासित किया और यहाँ तक कि gdb के साथ gbb पर बहस की। अब मैं x86, कंपाइलर ऑप्टिमाइज़ेशन तकनीक, JIT सुविधाओं के बारे में बहुत कुछ जानता हूं, और मैं अपने मास्टर के काम में इसका उपयोग करता हूं।

मुझे अपने स्थूल-बेंचमार्क सेट पर असली पायथन अनुप्रयोगों पर भी बहुत गर्व है, जो अब PyPy प्रोजेक्ट द्वारा सक्रिय रूप से उपयोग किया जाता है: speed.pypy.org । मेरे सभी पायथन प्रदर्शन-संबंधी गतिविधियों में से, यह सबसे उपयोगी साबित हुआ है। प्रदर्शन में कोई भी बदलाव इसके दिखने से पहले और बाद के परिणामों में आसानी से देखा जाता है।

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

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