GIL हटाने और तेज़ CPython प्रोजेक्ट
(lwn.net)- Python Steering Council ने PEP 703 को स्वीकार करने की मंशा जताई है, जिससे CPython में GIL हटाने की प्रक्रिया experimental build से default mode में बदलाव तक लंबी और चरणबद्ध प्रक्रिया में प्रवेश कर गई है
- GIL हटाने से multi-threaded performance के अवसर खुल सकते हैं, लेकिन मौजूदा ecosystem के बड़े हिस्से वाली single-threaded performance और C extension compatibility पर इसकी लागत पड़ सकती है
- Faster CPython टीम मानती है कि PEP 659 आधारित specializing adaptive interpreter GIL पर निर्भर करता है, इसलिए no-GIL environment में optimization strategy और maintenance burden का फिर से हिसाब लगाना होगा
- Meta ने कहा है कि PEP 703 स्वीकार होने पर वह 2025 के अंत तक 3 engineer-years लगाएगा, और Anaconda ने pip, cibuildwheel, conda-forge जैसे packaging कामों में support का वादा किया है
- transition का लक्ष्य Python 2→3 जैसी टूट-फूट से बचना है, और अगर no-GIL से होने वाली अव्यवस्था उसके फायदे से ज़्यादा मानी गई तो default mode घोषित होने से पहले इसे वापस लिया जा सकता है
Python में GIL हटाने की चर्चा फिर गंभीरता से शुरू हुई
- Python का Global Interpreter Lock(GIL) interpreter virtual machine तक access को serialize करता है ताकि एक समय में केवल एक thread ही Python code चला सके
- कई threads का उपयोग कर performance बढ़ाने में बाधा बनने वाले GIL को Python की पुरानी कमजोरी के रूप में अक्सर उठाया जाता रहा है
- Sam Gross ने अक्टूबर 2021 में no-GIL Python proof-of-concept version जारी किया था, और शुरुआती रुचि के बाद एक साल से अधिक समय तक प्रगति सीमित रही
- इसके बाद Python Steering Council ने no-GIL feature स्वीकार करने की मंशा घोषित की
- वास्तविक release version में आने में समय लगेगा
- भविष्य में किसी समय काम वापस लिए जाने की संभावना भी बनी हुई है
- कई कंपनियों के support से सफलता की संभावना बढ़ी है
Faster CPython और single-threaded performance के बीच तनाव
- 2022 Python Language Summit में Gross ने no-GIL fork प्रस्तुत करते हुए काम आगे बढ़ाने पर tacit approval लेने की कोशिश की, लेकिन विस्तृत प्रभाव पर्याप्त रूप से स्पष्ट न होने के कारण सहमति नहीं बन पाई
- इसी समय Faster CPython project interpreter की single-threaded performance सुधारने पर केंद्रित था
- Mark Shannon ने PEP 659 “Specialized Adaptive Interpreter” लिखा, और इनमें से कुछ बदलाव Python 3.10 और 3.11 में शामिल हुए
- PyCon में Faster CPython टीम के Brandt Bucher ने adaptive instructions पर, और Shannon ने memory layout सुधारों और अन्य optimization techniques पर presentation दी
- मौजूदा Python programs GIL के कारण लगभग पूरी तरह single-threaded लिखे गए हैं, इसलिए single-threaded performance improvement Python ecosystem के समग्र perceived performance पर सीधा असर डालता है
PEP 703 proposal और शुरुआती चिंताएं
- Łukasz Langa ने जनवरी 2023 में Gross द्वारा लिखे गए PEP 703 “Making the Global Interpreter Lock Optional in CPython” का पहला version पोस्ट किया
- no-GIL को लेकर उम्मीदों के साथ, C में लिखे Python extension modules एक प्रमुख चिंता बनकर उभरे
- GIL C extension code में कई concurrency problems रोकने की भूमिका निभाता रहा है
- GIL हटाने से उस code में नए bugs बन सकते हैं
- Python 2 से 3 में जाते समय जैसी flag day transition से बचना चाहिए, इस पर सहमति थी
- GIL हटाने का transition ऐसे code के साथ भी smooth तरीके से काम करना चाहिए जो अभी तैयार नहीं है
- Shannon ने पूछा कि single-threaded code में स्वीकार्य performance degradation कितना हो सकता है; उनका अपना estimate 15~20% range में था, और PEP 659 पर असर के आधार पर यह और बड़ा हो सकता है
- Eric Snow ने PEP 684 “Per-Interpreter GIL” और PEP 683 “Immortal Objects” लिखने वाले व्यक्ति के रूप में लंबा analysis पोस्ट किया, और माना कि no-GIL और subinterpreter approach जरूरी नहीं कि एक-दूसरे से टकराएं
C extensions पर लागत और फायदे
- Gross ने जवाब दिया कि C extensions पर प्रभाव पूरी तरह नकारात्मक ही नहीं होगा
- PEP में widely used C API extensions के maintainers द्वारा GIL bypass work में झेली जाने वाली complexity के quotes शामिल हैं
- PyTorch core developer Zachary DeVito ने बताया कि हाल के महीनों में तीन बार उन्होंने वास्तविक समस्या हल करने की तुलना में GIL limitations को bypass करने का तरीका समझने में एक order of magnitude ज़्यादा समय लगाया
- no-GIL extension module maintainers के लिए नए concurrency problems बना सकता है, लेकिन साथ ही GIL से बचने के लिए जरूरी complexity भी घटा सकता है
updated PEP और performance debate
- Gross ने मई 2023 की शुरुआत में Python 3.12 development version पर आधारित PEP 703 implementation और updated PEP पोस्ट किया
- 12 मई को उन्होंने Steering Council से PEP पर decision मांगा, लेकिन decision से पहले और चर्चा जारी रही
- 2 जून को Shannon ने PEP के performance impact का आकलन करते हुए 11~30% range का impact बताया, और इस संख्या ने debate छेड़ दी
- Shannon का मानना था कि adaptive specializing interpreter GIL पर निर्भर करता है, इसलिए no-GIL स्वीकार होने पर optimization strategy को फिर से design करना होगा
- redesign और implementation में लगने वाला effort वास्तविक optimization work में नहीं लग पाएगा
- Langa ने ऐसे benchmark numbers पोस्ट किए जिनमें impact Shannon के estimate से काफी कम दिखा, और additional results Gross द्वारा PEP में रिपोर्ट की गई बातों के करीब थे
Python 2→3 transition से मिली सीख
- Guido van Rossum का मानना था कि अगर Python 2 और 3 code एक ही interpreter में साथ रह सकते, तो transition में मदद मिलती
- उन्होंने जोर दिया कि अगर no-GIL आगे बढ़ता है, तो GIL की मांग करने वाले extension modules भी no-GIL interpreter में बिना अतिरिक्त काम के import हो सकने चाहिए
- application code में भी बदलाव की जरूरत नहीं होनी चाहिए
- extension modules में भी बदलाव की जरूरत नहीं होनी चाहिए
- Steering Council के Gregory P. Smith ने कहा कि PEP 703 का impact scope बहुत बड़ा है, इसलिए तुरंत निर्णय लेने के लिए वे तैयार नहीं थे
- Smith ने मांग होने की बात स्वीकार की, लेकिन माना कि पूरे ecosystem को ध्यान में रखते हुए और दुनिया को न तोड़ते हुए transition का तरीका खोजना होगा
- Gross ने प्रतिक्रिया दी कि स्पष्ट acceptance criteria और schedule के बिना निर्णय टालना व्यवहार में “no” जैसा काम करता है
Faster CPython टीम की नज़र में तीन विकल्प
- Shannon ने “A fast, free threading Python” चर्चा में आगे के विकल्पों को तीन में समेटा
- मौजूदा योजना के अनुसार fast single-threaded interpreter पर काम जारी रखना
- no-GIL free-threading interpreter पर काम करना, जिसका single-threaded performance पर अज्ञात लेकिन non-zero प्रभाव होगा
- दोनों को साथ-साथ आगे बढ़ाना
- Shannon का मानना था कि performance, parallelism और mutability में से किसे सीमित करना है, यह चुनना होगा
- उन्होंने इसे “Performance, parallelism, mutability: pick two” नहीं, बल्कि “pick one to restrict” के करीब बताया
- उन्होंने चेतावनी दी कि free-threading environment में Python को तेज़ बनाने के लिए original research की जरूरत होगी, और लागत व जोखिम ज़्यादा होंगे
- पसंदीदा विकल्प तीसरा था, लेकिन उन्होंने माना कि केवल no-GIL चुनकर यह उम्मीद नहीं करनी चाहिए कि “कोई performance problem हल कर देगा”
- van Rossum ने भी माना कि free threading और fast per-thread performance को साथ हासिल करना सबसे अच्छा होगा, लेकिन इसके लिए अतिरिक्त resources की जरूरत पर जोर दिया
corporate support और core developers की राय
- van Rossum ने कहा कि Microsoft Faster CPython टीम को support जारी रखेगा, और इस टीम की भूमिका केवल single-threaded performance work तक सीमित नहीं है
- no-GIL दुनिया के अनुरूप specialization और optimization work को adjust करके, अंततः single-threaded performance में गिरावट के बिना no-GIL को अकेला build mode बनाने का लक्ष्य बताया गया
- Meta के Carl Meyer ने कहा कि अगर PEP 703 स्वीकार होता है तो Meta 2025 के अंत तक 3 engineer-years लगाएगा
- CPython internals का अनुभव रखने वाले engineers core dev team के साथ सहयोग करेंगे
- PEP 703 implementation को CPython में smooth तरीके से शामिल करेंगे
- no-GIL CPython की compatibility और performance सुधारना जारी रखेंगे
- Anaconda के Stan Seibert ने कहा कि वे PEP 703 adoption से जुड़ी packaging समस्याओं में support देंगे
- pip, cibuildwheel, conda-forge से जुड़े काम शामिल
- no-GIL compatible packages को Python community तक पहुंचाने के लिए जरूरी काम शामिल
- core developer survey में 46 लोगों में से 87% ने कहा कि free-threaded Python को सक्रिय रूप से आगे बढ़ाना चाहिए, और 38 लोगों में से 63% ने कहा कि वे PEP 703 आधारित no-GIL Python के support और maintenance में योगदान देने को तैयार हैं
Steering Council का निर्णय और चरणबद्ध transition
- 28 जुलाई को Thomas Wouters ने घोषणा की कि Steering Council ने PEP 703 स्वीकार करने का फैसला किया है, लेकिन acceptance details पर अभी काम चल रहा है
- तरीका यह है कि पहले no-GIL interpreter पेश किया जाए, कमियों की पहचान की जाए, और no-GIL के default और अंततः एकमात्र version बनने से पहले जरूरी काम पूरा किया जाए
- transition period लगभग 5 साल अनुमानित है
- Council Python 3 जैसी स्थिति नहीं चाहता, और मानता है कि no-GIL build के अनुरूप होने के लिए third-party code में किए जाने वाले जरूरी बदलाव with-GIL build में भी वैसे ही काम करने चाहिए
- short term में experimental no-GIL build का प्रस्ताव है, जो Python 3.13 के समय हो सकता है
- Python 3.13 अक्टूबर 2024 के लिए तय है
- core developers और अन्य लोगों के experiment करने के लिए build
- medium term में no-GIL default नहीं, बल्कि supported option बनेगा
- timing बहुत हद तक इस पर निर्भर करेगी कि community no-GIL build को कितनी तेजी से adopt और support करती है
- long term में no-GIL default build बनेगा और GIL पूरी तरह हट जाएगा
- यह ऐसा होना चाहिए कि अनावश्यक रूप से backward compatibility न टूटे
काम अभी खत्म नहीं हुआ
- Wouters का मानना है कि GIL हटाना एक PEP स्वीकार करने से कहीं बड़ा काम है
- core developers को no-GIL Python का experience जुटाना होगा, और उसके आधार पर बाकी community का नेतृत्व करना होगा
- मौजूदा code की thread safety व्यवस्थित करने की प्रक्रिया में नए C API और Python API की जरूरत पड़ सकती है
- पूरी प्रक्रिया में progress और schedule का नियमित रूप से पुनर्मूल्यांकन करना होगा
- यह backward compatibility की एक और 10 साल की लड़ाई में नहीं बदलना चाहिए
- अगर PEP 703 problematic दिखता है, तो इसे रोककर दूसरा solution खोजने में सक्षम होना चाहिए
- no-GIL-only Python तक पहुंचने के लिए अभी बहुत research, coding, testing, experimentation और documentation बाकी है, और उदाहरण के तौर पर अक्टूबर 2028 का जिक्र है, जब Python 3.17 आ सकता है
1 टिप्पणियां
Hacker News की रायें
लेख अच्छी तरह लिखा गया है और पूरी प्रक्रिया को अच्छे से समेटता है, लेकिन यह GIL हटाने के विरोध और असफलता की संभावना को ज़्यादा वजन देता दिखता है
विरोधी पक्ष को भी पर्याप्त रूप से रेखांकित करने की ज़रूरत है। Sam Gross के काम की गुणवत्ता बहुत ऊँची है, और उन्होंने no-GIL से सीधे जुड़े बिना भी performance improvements जोड़े, जिससे performance loss कम हुआ। वे open source तरीके से भी बहुत अच्छे से आगे बढ़े, और community pressure न होता तो steering committee में यह लंबे समय तक अटका रहता—इतनी धीमी प्रतिक्रिया के बावजूद उन्होंने धैर्य दिखाया। Subinterpreters ने अभी तक Python में, खासकर गंभीर metrics के साथ, अपनी उपयोगिता लगभग कभी नहीं दिखाई है, और यह अच्छी तरह परिभाषित व मापा गया पहला प्रयास जैसा है। Community की प्रतिक्रिया ने भी इस project में बड़ी दिलचस्पी दिखाई, और steering committee ने भी निष्कर्ष निकाला कि “हम PEP 703 को स्वीकार करने के इच्छुक हैं और acceptance की विस्तृत शर्तों पर तालमेल कर रहे हैं।” मैं no-GIL का कट्टर समर्थक नहीं हूँ, और अगर अंत में इसे न हटाया जाए तो भी मुझे ठीक है; मेरा मानना है कि subinterpreters को पहले आज़माना चाहिए, लेकिन निष्पक्ष रूप से देखना ज़रूरी है
नतीजे भी काफ़ी प्रभावशाली हैं: https://lwn.net/SubscriberLink/941090/8bcb029dbf548f26/. जितनी उम्मीद की जा सकती थी, उतना अच्छा लगता है। Subinterpreter का काम शायद free-threading के काम के समानांतर चलेगा, और दोनों के use cases अलग हैं
मेरी जानकारी में PDM अब भी इसे support करता है। मुझे build और deployment के लिए virtualenv इस्तेमाल करना पसंद नहीं, और अच्छा होगा अगर Python भी JavaScript की तरह व्यवहार कर सके। यह संभव है, यह पहले ही साबित हो चुका है। Discussion thread https://discuss.python.org/t/pep-582-python-local-packages-d... पर है। “बिल्कुल एक ही सही तरीका” को rejection reason की तरह इस्तेमाल किया जाना भी निराशाजनक है, क्योंकि Python में मुझे कभी नहीं लगा कि यह बात सच है
LWN का शानदार लेख है और पढ़ने लायक था। Sam Gross का NoGIL पहली बार आने पर मैं उत्साहित था, लेकिन लेख पढ़ने और अपने अनुभव पर लौटकर देखने के बाद मेरी सोच बदलने लगी
मैंने कई भाषाओं में backend systems बनाए हैं, और वे कुल मिलाकर दो ही प्रकार के रहे। एक वे systems जो network endpoints खोलते हैं, requests लेते हैं, computation और दूसरे network requests के बाद response देते हैं; दूसरा वे systems जो queue या database, दूसरे API polling आदि से messages पढ़ते हैं, computation और network calls करते हैं, फिर उन्हें दूसरी queue में भेजते हैं। पहले में latency अहम होती है, दूसरे में throughput। पहले प्रकार में request के अनुसार thread शुरू करना, किसी computation-heavy endpoint का दूसरे requests को block न करना, और database connection pool share करना—इन सबके लिए NoGIL उपयोगी है। दूसरे प्रकार में, GIL न रखने वाली भाषाओं में भी, मुझे shared resources वाले process के अंदर parallelism या concurrency इस्तेमाल करने की याद बहुत कम है; इसे समझना बहुत मुश्किल हो जाता है। Optimization आम तौर पर intelligent batching होता था, और parallelism कई independent processes को कई machines पर चलाने के रूप में होता था। अगर NoGIL की वजह से दूसरे प्रकार के systems की quality compromise होती है तो यह काफ़ी निराशाजनक होगा, और सच कहूँ तो अभी मेरी ज़्यादातर मानसिक ऊर्जा दूसरे प्रकार को सुधारने में लग रही है
अभी QThread से JournalParser implement करता हूँ; यह parser Elite: Dangerous और Odyssey द्वारा बनाए गए player journal files से game events लगातार पढ़ता है, और हर event के लिए custom QSignal emit करता है, जिसे उस Signal को सुनने वाले slots handle करते हैं। Application के दूसरे हिस्सों में भी GIL न होना काफ़ी उपयोगी हो सकता है। https://captainslog.scarygliders.net/captains-log-2/
तब सबका code बेहतर हो सकता है
बेशक कहा जा सकता है कि CPU-heavy programs शुरुआत से ही Python में नहीं लिखने चाहिए, लेकिन वह अलग बात है
अगर shared resource read-only है, तो यह क्यों उलझन भरा होगा, मुझे ठीक से समझ नहीं आता
जुड़े हुए थ्रेड में यह वाक्य कि “GIL हटाने से केवल Python में लिखे codebase के टूटने की संभावना बहुत कम है” सच में सही है या नहीं, इस पर शक है
कुछ multi-threaded Python code, GIL की वजह से यह उम्मीद कर सकते हैं कि कुछ operations implicit रूप से thread-safe हैं। उदाहरण के लिए, दो threads अगर एक ही list में items जोड़ें तो list खराब नहीं होती, क्योंकि GIL के कारण दोनों threads उस operation को parallel में execute नहीं करते। GIL हटाने पर, C++ में
std::vectorको simultaneously modify करने जैसी स्थिति में, ऐसा code अचानक सजा भुगत सकता है। पक्का नहीं कह सकता, लेकिन यह वाक्य थोड़ा संदिग्ध लगता है। https://discuss.python.org/t/pep-703-making-the-global-inter...mapको simultaneously बदलने पर panic हो जाता हैPEP 703 का container thread safety वाला हिस्सा इस issue को address करता है। इसमें हर list, dictionary, set के लिए हल्का per-object lock रखने, object को modify करने वाले हर operation को वह lock लेना जरूरी करने, और ज्यादातर read operations को भी lock लेने का प्रस्ताव है। details https://peps.python.org/pep-0703/#container-thread-safety पर हैं
हालांकि फिर यह सवाल बचता है कि जब unsynchronized
[]चाहिए हो तो क्या किया जाएopen source में इससे कठिन testbed की कल्पना करना मुश्किल है
फैसला अपने-आप में reasonable है। test mode में आगे बढ़ना, multi-interpreter को बीच के experiment की तरह treat करना, लेकिन लक्ष्य concurrent execution वाली Python रखना। हालांकि existing code और नए code को उसी virtual machine पर चलाने की constraint बहुत बड़ी है। यह surprising है कि LWN summary ने testing को लगभग छुआ नहीं, क्योंकि testing अभी भी काफी अनसुलझी है और इससे ऐसी release आ सकती है जिसमें अज्ञात लेकिन गंभीर bugs हों। Microsoft, Facebook/Meta, Conda resources दे रहे हैं और core contributors का भारी बहुमत आगे बढ़ना चाहता है, लेकिन काम कठिन होने और और लोगों की जरूरत पड़ने पर क्या होगा, यह unclear है। साथ ही websites से लेकर big data और AI तक academia और industry के विशाल projects Python पर निर्भर हैं, और Python developers पर डाली जाने वाली cost GDP के percentage में मापी जा सकती है। अभी तो लगता भी नहीं कि समस्याएं पूरी तरह ज्ञात हैं, इसलिए अगले 3+ सालों तक predictable improvements करने वाले Faster CPython approach पर focus करना चाहिए, और concurrent execution Python के supporters को simple prototype से आगे जाकर analyze करना चाहिए कि कौन-सी समस्याएं आ सकती हैं, उन्हें कैसे detect किया जाएगा, और क्या किया जा सकता है। concurrency guarantees साबित करने की background वाले लोग review करें, और unknowns कम से कम identify हो जाने के बाद steering council के सामने सवाल रखना ज्यादा fair होगा। open source में program management scale के decisions बहुत ज्यादा नहीं रहे हैं, और Apache, Eclipse, Linux जैसे market direction drive करने वाले comparatively simple decisions ज्यादा रहे हैं, लेकिन इस बार असली technical unknowns हैं। साथ ही लगता है कि cross-language ABI को भी handle करना होगा। बड़ा issue C द्वारा expect किए जाने वाले execution model से match करना है, और Java की foreign function और memory interface कई सालों से incubation में है, Swift भी C और C++ wrapping में बेहतर हो रहा है, लेकिन FFI बदनाम रूप से कठिन है और शायद अनावश्यक रूप से भी कठिन है
निजी तौर पर मुझे लगता है कि GIL हटाना एक गलती है। ऐसे applications ज्यादा नहीं हैं जिन्हें इससे मजबूत फायदा होगा, और ज्यादातर को performance penalty मिलेगी
यह काम कई सालों का ध्यान और मेहनत खा जाएगा, जिसे शायद ज्यादा समझदारी से लगाया जा सकता था। Python ऐसा लगता है जैसे GIL को लेकर उसमें anxiety या inferiority complex हो। बेहतर होगा कि JavaScript की तरह single-threaded model को पूरी तरह अपना लिया जाए। कुछ applications आगे भी कठिन या असंभव रहेंगे, लेकिन मुझे नहीं लगता कि high-performance या high-scalability की जरूरत वाली apps के लिए Python अच्छा विकल्प है। कुछ हद तक specialized होना और सभी use cases support न करना जरूरी नहीं कि बुरी बात हो
लोगों को उन कामों में performance चाहिए जो वे अभी Python से पहले ही कर रहे हैं। उस दौर में वापस नहीं जा सकते जब यह सच नहीं था। अब यह Python के सबसे आम use cases में से एक है, और लोग इस पर अपना career लगा रहे हैं
लोग पहले से ही Python से parallel काम करने की कोशिश कर रहे हैं। उन्हें दूसरी भाषा इस्तेमाल करने के लिए मजबूर करना ज्यादा मददगार नहीं है
data-intensive कामों का काफी हिस्सा Python में parallel processes के रूप में आसानी से चलाया जा सकता है, इसलिए समझ नहीं आता कि GIL हटाने से इतना बड़ा फायदा होगा या नहीं
सिंगल-थ्रेड performance को ज़्यादा पैसा लगाकर सुधारना कहीं अधिक मुश्किल है, इसलिए उसे ज़्यादा प्राथमिकता मिलनी चाहिए
मल्टी-थ्रेड performance में एक और core जोड़कर process-based parallelization के overhead की भरपाई की जा सकती है। मुझे लगता है कि GIL बनाम no-GIL वाली यह binary सोच ही गलत है। multiprocessing में सबसे बड़ी समस्या यह है कि memory share नहीं की जा सकती। इसलिए explicit memory sharing mechanism वाले virtual processes जोड़ दिए जाएँ। तब objects एक ही thread में रहेंगे, इसलिए barrier-less reference counting जैसी single-thread optimizations बनाए रखी जा सकती हैं
GIL के बिना भी single-thread performance अच्छी बनाई जा सकती है। Rust में zero-cost abstractions की अवधारणा है और वह threads को भी अच्छे से handle करता है। Java भी single-threaded काम अच्छी तरह करता है। और भी कई भाषाएँ हैं; यह कोई science fiction नहीं है। locks optimization से गायब हो सकते हैं, lock-free code चुना जा सकता है, और fine-grained या structured concurrency भी संभव है। कौन-सी चीज thread-safe है, यह मूल रूप से API contract का मामला है। optimistic locking भी मौजूद है। कोई अच्छा कारण नहीं कि Python वैसा कुछ न कर सके, लेकिन पहले GIL हटाना होगा। GIL-less Python की performance regression का बड़ा हिस्सा unresolved technical debt जैसा है, जिसे समय के साथ ठीक किया जा सकता है। बहुत सारे locks लगाना एक workaround है, इसलिए वह धीमा होता है; लेकिन सही समाधान शायद internals पर फिर से विचार करना या thread-safety को document करने वाले API contracts बनाना होगा। तेज़ Python runtime और compiler कई ऐसी चीजों को भी Python में फिर से implement करने की क्षमता देंगे जो अभी native libraries पर निर्भर हैं। native code के साथ interaction ही वह जगह है जहाँ अक्सर locks की जरूरत पड़ती है, और अगर उस तरीके को नहीं बदला गया तो समस्या बनी रहेगी। GIL हटाने का मूल उद्देश्य इन्हीं चीजों को व्यवस्थित तरीके से ढूँढकर ठीक करना है, और समय के साथ यह बेहतर होगा
Python/multiprocessing की अकेली समस्या यह है कि कभी-कभी queue नहीं, बल्कि shared mutable state चाहिए होता है। अभी Python objects को shared memory में रखने का तरीका जटिल, सीमित और inefficient है। ठीक करने का लक्ष्य वही हिस्सा होना चाहिए, और Python को native instances को shared memory में रखने के लिए बेहतर support चाहिए
“single-threaded code में कितनी performance गिरावट स्वीकार्य है” वाले सवाल पर Shannon ने लगभग 15–20% का अनुमान लगाया, लेकिन उस सवाल का कुल मिलाकर जवाब नहीं मिला
यानी “CPython को तेज़” बनाने वाले project के कुछ लोग यह स्वीकार्य मानते हैं कि मौजूदा Python code का अधिकांश हिस्सा रातों-रात 15–20% धीमा हो जाए? मुझे लगता है सीमा लगभग 5% होनी चाहिए। वह भी तभी, जब GIL हटाना आगे की अन्य optimizations में मदद करे। लेकिन कहा जा रहा है कि उलटे यह बदलाव दूसरी optimizations को जटिल बनाता और टालता है। दूसरी ओर Shannon ने 2020 में व्यक्तिगत रूप से CPython को 5x तेज़ करने के लिए funding proposal दिया था, और अब बहुत बड़े corporate support वाली पूरी team CPython को तेज़ कर रही है, मगर लक्ष्य काफी छोटा दिखता है
जब performance सचमुच महत्वपूर्ण हो, तो किसी दूसरी भाषा में rewrite किए बिना लगभग 20x speedup मिल सके तो वह बड़ी बात है
अगर दूसरी optimizations रुकती नहीं हैं, बस थोड़ा ज़्यादा समय लेती हैं, तो यह स्वीकार्य हो सकता है
network या disk access के बिना numeric/string operations वाले वास्तविक code की तुलना करें, तो 3.12 beta 3.8 की तुलना में सिर्फ लगभग 20–25% कम समय लेता है। वह 2.7 के स्तर जैसा है। पुराने core लोग ऐसे लगते हैं मानो अगले release में corporate sponsors को दिखाने के लिए bullet point features की desperately तलाश कर रहे हों। इसलिए वे Sam Gross का काम इस्तेमाल करते हैं, लेकिन समय के साथ credit धीरे-धीरे वे खुद ले लेंगे
LWN के मुताबिक, यह शानदार summary है
मुझे Python community पसंद है। यह open source software का leading example है, और दिखाती है कि transparency और good governance क्या हासिल कर सकते हैं। Meta, Microsoft वगैरह जो engineering time लगा रहे हैं उसके लिए आभार है, लेकिन tech industry और data science समेत व्यापक क्षेत्रों को Python और open source software से जो value मिलती है, उसके मुकाबले यह अब भी बहुत छोटा है
8 साल पहले JPMorgan में मैंने technical leadership team को PyCon UK sponsorship, recruiting booth, और पूरे UK से JPMorgan के junior developers की attendance support करने के लिए मनाया था। 5 साल पहले मैंने JPM छोड़ दिया, लेकिन वे आज भी PyCon UK के headline sponsor हैं। Python और open source ecosystem से मिले भारी लाभ की तुलना में यह खर्च पूरी तरह negligible था
mailing lists censor की जाती हैं, और inner circle की आलोचना नहीं की जा सकती। असली contributors का शोषण उन लोगों द्वारा होता है जो सही companies में होते हैं और बहुत कम करते हुए भी bureaucratic authority वाली positions पर काबिज रहते हैं। LWN का लेख बहुत favorable है और decision-makers के नाम हमेशा अच्छी तरह mention करता है, इसलिए धोखा नहीं खाना चाहिए। मुझे यह selective reporting जैसा लगता है
Sam Gross ने जिस तरह push किया, वह काफी impressive है। steering council से सकारात्मक लेकिन non-committal प्रतिक्रिया मिलने के बाद वे बस बैठकर progress का इंतज़ार कर सकते थे, लेकिन विरोध कर दबाव बनाने वाली बात बहुत सराहनीय है
बेहद दिलचस्प। Sam Gross का यह कहना कि “हमें अभी तुरंत yes/no की ज़रूरत नहीं है, लेकिन हमें यह जानना होगा कि स्वीकार किए जाने की शक्ल क्या होगी, और यह issue बहुत लंबे समय से पड़ा हुआ है” काफी bold कदम था: https://github.com/python/steering-council/issues/188#issuec...
वह बातचीत कई दिशाओं में जा सकती थी, लेकिन लगता है कि steering council को ठीक वही धक्का चाहिए था। no-GIL Python तक का रास्ता अब भी लंबा और घुमावदार है, और इसके लिए double-digit engineer-years के पैमाने का प्रयास चाहिए होगा, लेकिन कम-से-कम अब एक सही रास्ता बनता दिख रहा है। सबसे मुश्किल हिस्सा मौजूदा codebase की correctness सुनिश्चित करना है। Python 2 से 3 पर जाने वाली स्थिति दोहराना नहीं चाहते, यह कहना एक बात है; और यह बिल्कुल अलग बात है कि breaking changes नहीं हैं ऐसा दावा करने के बावजूद लोग bugs के डर से सच में upgrade करने से बचें। GIL/no-GIL को सिर्फ compile-time switch रखने पर भी maintenance cost निश्चित रूप से बढ़ेगी। फिर भी, लंबे समय में मुझे लगता है कि यह प्रयास worthwhile होगा। GIL Python की आलोचनाओं के लिए lightning rod जैसा है, और Python व parallelism पर HN threads देखकर यह समझ आता है। शायद इसलिए कि लोग दशकों का context समझे बिना भी सीधे “यही वजह है कि Python तेज़ नहीं हो सकता” कहकर इसे दिखा सकते हैं। उस मायने में यह Chesterton’s fence का final boss जैसा है
नई guidelines के तहत भी GIL हटाने के कई सालों के प्रयास को अंततः reject किए जाने की संभावना अब भी बनी हुई है