JIT प्रोजेक्ट के बारे में Steering Council की घोषणा

• CPython का प्रायोगिक JIT compiler कई वर्षों से main branch में विकसित किया जा रहा था और हाल में इसने वास्तविक performance improvements दिखाए हैं, लेकिन इसे supported feature बनाए रखने के लिए अब औपचारिक PEP review की आवश्यकता है
• PEP 744 ने शुरुआती design और इसे permanent feature में बदलने के मानदंडों को कवर किया था, लेकिन long-term maintainers, security review, debugging और external process tools support, runtime guarantees, तथा redistributors और downstream packagers की जिम्मेदारियों पर अभी सहमति नहीं बनी है
• Python Steering Council ने JIT को CPython की supported non-experimental feature बनाने के लिए एक Standards Track PEP लिखने का औपचारिक अनुरोध किया है, और PEP स्वीकार होने तक main में नई features, optimizations और performance work को merge न करने को कहा है
• नए PEP में long-term maintenance, मौजूदा CPython features और tools के साथ compatibility, measurable success metrics और timeline, CinderX·Numba·PyTorch जैसे third-party JIT के साथ संबंध, और वर्तमान architecture की stability को कवर करना होगा
• अगर 6 महीनों के भीतर PEP जमा, resolve या स्वीकार नहीं होता, तो JIT code को main branch से हटा दिया जाएगा और development को मुख्य Python repository के बाहर जारी रखना होगा

---

पृष्ठभूमि और औपचारिक अनुरोध

• CPython का प्रायोगिक Just-In-Time compiler पिछले कुछ वर्षों से कई core developers और contributors द्वारा main branch में विकसित किया जा रहा था, और हाल की performance improvements वास्तविक और उत्साहजनक परिणाम हैं
• यह कदम JIT पर हो रहे काम या उसमें शामिल लोगों की आलोचना नहीं है; बल्कि यह मान्यता है कि प्रोजेक्ट लंबे समय से चल रहा है और कई बार redesign हो चुका है, इसलिए CPython project के भीतर JIT की अनौपचारिक स्थिति का फिर से मूल्यांकन करने का समय आ गया है
• JIT जब पहली बार main में merge किया गया था, तब उसे एक experiment के रूप में शामिल किया गया था, और संबंधित PEP, यानी PEP 744, एक Informational PEP है
• PEP 744 शुरुआती design को कवर करता था और मोटे तौर पर उन मानदंडों को बताता था जिनके आधार पर JIT एक permanent feature बन सकता है, लेकिन इसने long-term maintainers, security review, debugging और external process tools support, runtime guarantees, तथा redistributors और downstream packagers की जिम्मेदारियों जैसे सवाल खुले छोड़े थे
• Python Steering Council का मानना है कि इस स्तर की complexity और scope वाले बदलाव के लिए अधिक सख्त प्रक्रिया की आवश्यकता थी, और ये unresolved questions ऐसे commitments हैं जिन्हें community को PEP process के माध्यम से जांचना और उन पर सहमति बनानी चाहिए
• JIT को CPython की supported non-experimental feature बनाने के लिए एक Standards Track PEP आवश्यक है, जो guarantees, maintenance commitments, और redistributors पर पड़ने वाले प्रभाव को कवर करे; इसके बाद community discussion और Steering Council द्वारा औपचारिक acceptance या rejection की प्रक्रिया होनी चाहिए
• जब तक यह PEP स्वीकार नहीं हो जाता, तब तक main branch में नया JIT development नहीं जोड़ा जाना चाहिए; नई features, optimizations, और performance work इस रोक के दायरे में आते हैं
• bug fixes और security fixes जारी रह सकते हैं, और यह रोक केवल PEP स्वीकार होने से पहले अतिरिक्त JIT features को जोड़ने तक सीमित है

PEP को किन मुद्दों को कवर करना चाहिए और 6 महीने की समयसीमा

• इसका उद्देश्य competing proposals मांगना नहीं है, लेकिन अभी alternative proposals पर चर्चा करने का भी अच्छा समय है, और यह उस पुराने दृष्टिकोण के अनुरूप है कि CPython main branch में PEP के बिना experiments नहीं होने चाहिए
• किसी एक JIT implementation का प्रस्ताव देने के बजाय, ऐसा PEP अधिक उपयुक्त हो सकता है जो कई implementation strategies को support करने वाली JIT infrastructure का वर्णन करे
• क्योंकि कई promising JIT tracing approaches लगातार प्रस्तावित हो रही हैं, infrastructure को किसी एक strategy से बहुत मजबूती से जुड़ा होने के बजाय CPython के भीतर ऐसी approaches का आसानी से experiment और evaluation संभव करना चाहिए
• PEP में यह स्पष्ट योजना होनी चाहिए कि इस पैमाने और complexity वाले subsystem को long term में कैसे जारी रखा और maintain किया जाएगा, और इसका उन maintainers और contributors पर क्या प्रभाव होगा जो सीधे JIT में योगदान नहीं देते
• PEP को मौजूदा CPython features और tools के साथ compatibility को कवर करना चाहिए, और free-threading, profiler, debugger जैसी features तथा JIT के बीच interactions और guarantees को व्यापक और सूक्ष्म दोनों स्तरों पर संबोधित करना चाहिए
• PEP में स्पष्ट और measurable success metrics तथा timeline शामिल होनी चाहिए, जिसमें performance goals, platform support की सीमा, और memory overhead जैसे लक्ष्य और समयबद्ध मील के पत्थर शामिल हों
• PEP को अन्य JIT compilers के साथ संबंध को कवर करना चाहिए, और यह स्पष्ट करना चाहिए कि क्या design ऐसा general infrastructure प्रदान करता है जिस पर अन्य प्रयास निर्माण कर सकें, तथा क्या यह CinderX, Numba, PyTorch आदि जैसे third-party JIT के साथ compatibility या incompatibility की अपेक्षा करता है
• PEP को यह भी कवर करना चाहिए कि क्या वर्तमान JIT architecture को stable माना जा रहा है, या उसमें आगे भी बड़े बदलाव की संभावना है
• यह सूची पूर्ण नहीं है, और community discussion आगे बढ़ने पर इसमें अतिरिक्त मुद्दे जोड़े जा सकते हैं
• PEP submission और resolution के लिए 6 महीने की अवधि तय की गई है; यदि इस अवधि के भीतर संबंधित PEP स्वीकार नहीं होता, तो JIT code को main branch से हटा दिया जाएगा और development को मुख्य Python repository के बाहर जारी रखना होगा
• यह मांग प्रोजेक्ट को बंद करने के लिए नहीं है, बल्कि CPython runtime में बड़े बदलाव के लिए आवश्यक स्पष्टता और community की स्पष्ट प्रतिबद्धता सुनिश्चित करने की प्रक्रिया है

[GN⁺]

Lobste.rs टिप्पणियाँ

• यह बहुत डरावना तो नहीं लगता, लेकिन थोड़ा अटपटा ज़रूर है। अगर JIT अभी भी एक experimental feature है, तो इसका merge होता रहना अपने-आप में समस्या नहीं लगता।
  अगर Shannon जैसे लोग कहते हैं, “हम PEP लेकर आएँगे, लेकिन अजीब टकरावों से बचने दिया जाए,” तो वे इतने भरोसेमंद लगते हैं कि आगे बढ़ने से रोकने के लिए सख्त लॉक लगाने की ज़रूरत न पड़े। हो सकता है यह सार्वजनिक घोषणा निजी बातचीत के बाद आई हो, लेकिन उम्मीद है कि यह बिना अनावश्यक ठेस पहुँचाए ठीक से आगे बढ़े

• अलग-अलग JIT implementation की अनुमति देने वाले interface का प्रस्ताव ऐसा लगता है जैसे high-performance JIT को क्या चाहिए, इसे काफ़ी गलत समझा गया हो। JIT पर काम करने वालों के सामने कई समस्याएँ रही होंगी, लेकिन बड़ी समस्याओं में से एक यह लगती है कि वे core runtime data structures को बड़े स्तर पर बदल नहीं पाए, या बदलना नहीं चाहते थे।
  बेशक Python में यह समस्या भी है कि उसने लगभग पूरी implementation को API की तरह उजागर कर दिया है। फिर भी, अगर कोई गलत काम करे तो उसे types फिर से लिखने पर मजबूर किया जा सकता है, लेकिन उसके लिए ऐसा community चाहिए जो performance को सच में बहुत महत्व देता हो। Python ने ऐतिहासिक रूप से performance की ज़रूरत वाले libraries को Python में न लिखकर काम चलाया है, और उसका असर प्राथमिकताओं पर पड़ा है। मुझे पुरानी language performance comparisons याद हैं, जहाँ बुनियादी algorithms के implementation की तुलना उन Python implementations से की जाती थी जो वास्तव में C libraries के अच्छी तरह तराशे गए high-performance implementation को wrap करते थे

  • JIT interface का प्रस्ताव Ruby से प्रेरित लगता है, और Ruby में यह काफ़ी अच्छा काम करता हुआ दिखा है। इसलिए हो सकता है Ruby के पास ultra-high-performance JIT न हो, लेकिन शायद उतना काफ़ी भी हो। अगर Python JIT, Ruby JIT जितना भी काम करे, तो बहुत से लोग संतुष्ट होंगे

  • मुझे यह स्पष्ट नहीं है कि “अलग-अलग JIT implementation की अनुमति देने वाला interface प्रस्ताव high-performance JIT के लिए ज़रूरी चीज़ों को काफ़ी गलत समझता है” — ऐसा क्यों कहा जा रहा है।
    जैसा आपने कहा, Python ने implementation को API की तरह उजागर कर दिया है, लेकिन उसी वजह से JIT भी उन्हीं APIs को call कर रहा है। वास्तव में कुछ functions तो JIT की ज़रूरत के कारण linker में public symbols के रूप में expose भी किए गए थे। व्यक्तिगत रूप से मैं tracing JIT नहीं बल्कि method JIT पर काम कर रहा हूँ, और plug-in JIT के विचार का मैंने सार्वजनिक रूप से समर्थन किया है

• मुझे समझ नहीं आता कि इसे core JIT developers को private request के रूप में भेजने के बजाय सार्वजनिक घोषणा के रूप में क्यों पोस्ट किया गया

  • क्योंकि Python एक community-driven open source project है। इसी तरह की घोषणाएँ proprietary projects में भी leak हुई हैं

• लगता है किसी anthropologist को open source software projects की bureaucracy पर एक किताब लिखनी चाहिए, और Python तथा Debian उसके मुख्य अध्ययन-विषय होने चाहिए।
  यह आलोचना नहीं है। ऐसी bureaucracy आख़िरकार distributed decision-making और consensus-building की प्रक्रिया ही है, और इस पैमाने पर उसे अच्छी तरह काम करने लायक बनाना मुश्किल होता है

  • Gabriella Coleman एक anthropologist हैं जिन्होंने Debian पर fieldwork किया था। उससे निकली किताब “Coding Freedom” है, और मैं उसे ज़ोरदार सिफ़ारिश करता हूँ

• ईमानदारी से कहूँ तो यह उसी syndrome जैसा लगता है जिसने Python 3 को जन्म दिया था, बस इसका असर उल्टा पड़ रहा है। CPython मुख्यतः implementers की खुशी के लिए मौजूद है, और यह बदलाव उन लोगों के लिए काफ़ी बड़ी असुविधा पैदा करेगा जो मौजूदा तरीके से hack करने के आदी हैं।
  शायद सही दिशा यह होगी कि JIT version को एक अलग implementation के रूप में support किया जाए, उसे बदलाव की छूट दी जाए, और मूल CPython के साथ compatibility को best-effort आधार पर रखा जाए

  • मुझे ठीक-ठीक समझ नहीं आ रहा कि “यह उसी syndrome जैसा है जिसने Python 3 को जन्म दिया था, बस इसका असर उल्टा है” से आपका क्या मतलब है।
    और जहाँ तक “CPython मुख्यतः implementers की खुशी के लिए मौजूद है” वाली बात है, SC और core developers के साथ सीमित बातचीत से मुझे तो लगभग उल्टा प्रभाव मिला है। कुल मिलाकर वे मौजूदा community को support करते हुए भी आगे बढ़ने के बीच संतुलन बनाने के लिए काफ़ी गंभीर रूप से प्रतिबद्ध लगे हैं