Free Threaded Python के पहले 1 साल पर एक नज़र

(labs.quansight.org)

5 पॉइंट द्वारा GN⁺ 2025-05-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Free Threaded Python को मल्टीकोर हार्डवेयर का कुशल उपयोग करने के लिए डिज़ाइन किया गया है
CPython 3.14 में कोर मॉड्यूल्स की thread safety और performance में बड़े सुधार किए गए हैं
अभी भी कई प्रमुख packages ऐसे हैं जो free-threaded build को support नहीं करते
कोई भी व्यक्ति production environment की रिपोर्टिंग और community contribution के ज़रिए इसके विकास में साथ दे सकता है

अवलोकन

पिछले हफ्ते CPython 3.14.0b1 जारी किया गया, और इस हफ्ते PyCon 2025 पिट्सबर्ग में शुरू हो रहा है।
ये दोनों घटनाएँ Free Threaded Python के वितरण और स्थिरीकरण के लिहाज़ से महत्वपूर्ण मील के पत्थर हैं।
यह लेख पिछले 1 साल की यात्रा पर नज़र डालता है और बताता है कि Quansight टीम ने जटिल dependencies वाले वास्तविक production workflows में free-threaded build को प्रयोगात्मक रूप से लागू करने में कैसे केंद्रीय भूमिका निभाई।

Free Threaded Python का अर्थ और आवश्यकता

Free Threaded Python सपोर्ट आधुनिक हार्डवेयर, जहाँ मल्टीकोर CPU और GPU आम हो चुके हैं, के पूरे compute resources का उपयोग संभव बनाता है
मौजूदा GIL (Global Interpreter Lock) मॉडल में parallel algorithms का पूरा लाभ लेने के लिए workaround और अलग tuning की ज़रूरत पड़ती थी
आम तौर पर threading मॉड्यूल की जगह multiprocessing का उपयोग किया जाता था, लेकिन इसमें process creation की लागत अधिक होती है और data copying भी अक्षम होती है
जिन Python packages में native code शामिल है, वे free-threaded build के साथ तुरंत compatible नहीं होते, इसलिए thread safety सुनिश्चित करने के लिए code audit अनिवार्य है
GIL हटाने के लिए CPython interpreter में गहरे संरचनात्मक बदलाव करने पड़े, और इससे मौजूदा packages की संरचनात्मक समस्याएँ भी उजागर हुईं

प्रमुख उपलब्धियाँ

Meta की Python runtime team के साथ मिलकर, नीचे दिए गए कई packages और projects में free-threaded Python support जोड़ा गया
- meson, meson-python, setup-python GitHub Actions, packaging, pip, setuptools जैसे packaging और workflow tools
- Cython, pybind11, f2py, PyO3 जैसे binding generators
- NumPy, SciPy, PyArrow, Matplotlib, pandas, scikit-learn, scikit-image जैसे PyData ecosystem के core packages
- Pillow, PyYAML, yarl, multidict, frozenlist जैसे PyPI downloads में शीर्ष dependencies
कुछ लोकप्रिय packages (CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, grpcio आदि) और machine learning libraries (safetensors, tokenizers आदि) अभी पूरी तरह समर्थित नहीं हैं, लेकिन उन पर क्रमिक रूप से काम चल रहा है
Quansight टीम के CPython core developers ने 3.14 संस्करण में निम्न सुधार शामिल किए
- warnings module अब free-threaded build में default रूप से thread-safe तरीके से काम करता है
- asyncio में गंभीर thread-safety समस्याओं में सुधार और parallel scalability में वृद्धि
- ctypes module में thread safety का व्यापक सुधार
- free-threaded garbage collector की performance में सुधार
- deferred reference counting scheme और adaptive specializing interpreter optimization
- अनेक bug fixes और thread-safety सुधार
free-threaded Python support के लिए एक व्यापक guide1 भी तैयार की गई है, ताकि आगे और packages के लिए व्यावहारिक documentation उपलब्ध हो सके

Free Threaded Python ecosystem की वर्तमान स्थिति

1 साल पहले (जब 3.13.0b1 जारी हुआ था) free-threaded build पर ज़्यादातर Python packages की installation पूरी तरह टूट जाती थी
build failures का कारण मूलभूत समस्या कम और unsupported default options या छोटी-छोटी assumptions के टूटने से अधिक था
पिछले 1 साल में community के साथ मिलकर कई समस्याएँ हल की गईं, और खास तौर पर Cython 3.1.0 के आधिकारिक support ने बड़ा turning point दिया
अभी भी ऐसे packages मौजूद हैं जिनमें compiled code शामिल है लेकिन वे free-threaded wheels उपलब्ध नहीं कराते
इनकी प्रगति manual और automatic tracking tables2 में देखी जा सकती है

मौजूदा चुनौतियाँ

अभी free-threaded Python build उस चरण में है जहाँ वास्तविक workflows में प्रयोग और feedback की आवश्यकता है
खासकर उन workflows में, जहाँ multiprocessing के उपयोग की लागत अधिक है, performance improvement की संभावना है, लेकिन हर package के लिए विस्तृत thread-safety audit अनिवार्य है
कई libraries mutable data structures देती हैं, लेकिन उनकी thread-safety documentation या वास्तविक सुरक्षा गारंटी अपर्याप्त है
जिन packages का आकार बड़ा है और जिनमें legacy अधिक है, उनमें support धीमा पड़ जाता है क्योंकि code को पूरी तरह समझने वाले लोग कम होते हैं
community स्तर पर core package maintenance की sustainability के लिए प्रयासों की आवश्यकता है

योगदान कैसे करें

official guide के contribution guide को देखा जा सकता है
पूरे ecosystem की issues tracking और मुख्य compatibility documents free-threaded-compatibility repository5 में प्रबंधित किए जाते हैं
Quansight-Labs द्वारा संचालित community Discord6 में चर्चा और योगदान किया जा सकता है

PyCon प्रस्तुति की सूचना

इस लेख के लेखक और उनकी टीम के सदस्य Lysandros Nikolaou PyCon 2025 में प्रस्तुति देंगे
वे अनुभव-आधारित व्यावहारिक porting cases और सीख साझा करने की योजना रखते हैं, और YouTube रिकॉर्डिंग भी उपलब्ध कराई जाएगी
उनका मानना है कि free-threaded build Python भाषा का भविष्य है, और इसे वास्तविकता बनाने में योगदान दे पाना बेहद उत्साहजनक है
आशा है कि आज का यह प्रयास उन विशाल और विविध packages के भविष्य का निर्णायक मोड़ बनेगा, जिनका उपयोग हर दिन लाखों developers करते हैं

1 टिप्पणियां

GN⁺ 2025-05-17

Hacker News राय

बहुत से लोग multiprocessing का उपयोग करते हैं, और यह बात उठाई गई कि process creation की लागत महंगी होती है
- SharedMemory फीचर मौजूद है, लेकिन यह ज़्यादा बार क्यों उपयोग नहीं होता, यह समझ नहीं आता
- ShareableList के उपयोग का अनुभव अच्छा रहा, इस पर ज़ोर दिया गया
- Unix पर process creation की गति 1ms से कम स्तर की होती है
  - लेकिन PYTHON interpreter process start होने में import की संख्या के अनुसार 30ms~300ms लग सकते हैं
  - 1~2 अंकों का अंतर होता है, इसलिए सटीक संख्या महत्वपूर्ण है
  - CGI इस मामले में अपवाद है, और C·Rust·Go में यह समस्या नहीं है
  - sqlite.org भी प्रति request अलग process वाले तरीके का उपयोग करता है, ऐसा उदाहरण साझा किया गया
- ShareableList में केवल atomic scalar और bytes·strings ही share किए जा सकते हैं
  - Python के structured objects में pickle dump जैसी serialization लागत और process-वार copied memory लागत आती है
- numpy array sharing में बड़ी सफलता का अनुभव
  - explicit sharing का तरीका, threads के बीच गलती से sharing होने से पैदा होने वाली समस्याओं को debug करने की कठिनाई की तुलना में बोझ नहीं है
  - बहुत से लोग यह बढ़ा-चढ़ाकर आंकते हैं कि threads, multiprocessing की तुलना में कितने बेहतर हैं
  - चिंता है कि GIL हटने पर random segfault को debug करने के मामले बढ़ेंगे
  - यह भी कहा गया कि JavaScript में shared memory आधारित threading का support न होने पर लोगों ने बहुत शिकायत नहीं की
  - इसकी एक व्याख्या यह दी गई कि JavaScript तेज़ है, इसलिए ऐसी ज़रूरत कम पड़ती है
  - Python की base performance सुधारने पर और ज़्यादा मेहनत की इच्छा जताई गई
- processes अलग-अलग मरते हैं, इसलिए यदि shared memory data structure को lock पकड़े हुए बदल रहा process मर जाए तो recovery मुश्किल होती है
  - Postgres के shared memory structure और पूरे backend process को बंद करने की ज़रूरत का उदाहरण दिया गया
  - threads साथ मरते हैं, इसलिए इस तरह की समस्या को कम महसूस किया जाता है
- shared memory केवल dedicated hardware पर काम करती है
  - AWS Fargate जैसे environments में shared memory नहीं होती, इसलिए network या filesystem का उपयोग करना पड़ता है और latency बढ़ती है
  - fork आधारित process replication एक अलग समस्या है
  - वास्तविक अनुभव में green thread और actor model कहीं ज़्यादा प्रभावी रहे, ऐसा दावा किया गया
जिज्ञासा व्यक्त की गई कि GIL हटाने का Python multithreaded code पर parallel processing के अलावा और कोई असर है या नहीं
- समझ यह है कि GIL बना रहने का कारण यह नहीं था कि multithreading उस पर निर्भर थी, बल्कि GIL हटाने से interpreter implementation, C extensions, और single-threaded code की गति पर असर पड़ता है
- पूछा गया कि क्या free-threaded Python में भी वही पुरानी guarantee रहेगी कि bytecode boundary पर कभी भी preempt किया जा सकता है
- या फिर code लिखने का तरीका बदलेगा, जैसे और locks लगाने पड़ेंगे
- free-threaded Python में भी ज़्यादातर वही guarantees रहती हैं
  - लेकिन free-threading न होने पर लोग threading फीचर्स कम इस्तेमाल करते हैं, इसलिए boundary पर preemption वाले bugs वास्तव में कम सामने आते हैं
  - free-threading आने पर और bugs उजागर होंगे
  - multiprocessing जैसे workaround की ज़रूरत कम होगी, इसलिए user code सरल होगा; interpreter की बढ़ी हुई जटिलता इसकी काफ़ी कीमत वसूल करती है, ऐसा माना गया
  - C extensions के जटिल होने की समस्या free-threading से ज़्यादा sub-interpreter में गंभीर है; numpy टीम ने साफ़ कहा है कि वे sub-interpreter support नहीं कर सकते
  - numpy पहले से free-threading support कर रहा है, और बाकी bugs ठीक किए जा रहे हैं
  - single-thread speed में हल्की (single-digit %) कमी स्वीकार करने लायक trade-off है
- multi-core का उपयोग संभव है, लेकिन thread-प्रति performance गिरती है और libraries को फिर से काम करना होगा
  - PyTorch के साथ प्रयोग में 10x CPU उपयोग पर आधा throughput मिलने का अनुभव बताया गया
  - समय के साथ सुधार की उम्मीद है, और 20 साल से इसका इंतज़ार होने के कारण इसे स्वागतयोग्य बताया गया
- race condition ज़्यादा बार हो सकती है, इसलिए reliability बनाए रखने के लिए multithreaded Python लिखते समय ज़्यादा सावधानी चाहिए
यह खबर दी गई कि Microsoft ने Faster Python team को भंग कर दिया
- 2025 के अनुमानित प्रदर्शन लक्ष्य पूरे न होने के कारण team को जारी नहीं रखा गया
- आगे CPython में performance improvements जुड़ती हैं या नहीं, या कोई दूसरी कंपनी sponsor करती है या नहीं, यह देखा जाएगा
- Facebook (Meta) अभी भी कुछ हद तक sponsor कर रहा है, ऐसा लगता है
- यह भी कहा गया कि Microsoft के वादों की तुलना में timeline बहुत ज़्यादा खिसक गई थी
  - हाल में गंभीर political·governance समस्याओं की जानकारी होने की बात कही गई; सक्षम कर्मचारी बिना वजह योगदान देकर group की बदनामी का निशाना नहीं बनना चाहेंगे, ऐसा मत व्यक्त किया गया
  - CPython organization पर ज़रूरत से ज़्यादा वादे करने, आज्ञाकारी लोगों पर काम लादने, और सक्षम विरोधियों को बाहर करने का आरोप लगाया गया
  - कहा गया कि पहले ऐसी समस्याएँ नहीं थीं, और वर्तमान स्थिति उन्होंने खुद पैदा की है
- इस नतीजे को दुखद बताया गया, लेकिन यह भी कहा गया कि Microsoft के long-term promises पर भरोसा न करने का अपना अनुमान सही निकला
- हाल में यह अफ़वाह भी है कि Google ने पूरी Python development team को निकाल दिया
  - पूछा गया कि क्या दोनों मामलों के पीछे समय की कोई बड़ी वजह या कोई common factor है
- इसे बहुत अफ़सोसनाक बताया गया, लेकिन embrace & extend के बाद अब बस एक ही चीज़ बची है, ऐसा संकेत दिया गया
पूछा गया कि क्या Python से GIL के गायब होने को लेकर चिंतित होने वाला वह अकेला है
- किसी भी भाषा में जटिल multithreaded code पर भरोसा करना कठिन है, और Python की dynamic प्रकृति के कारण यह और भी अस्थिर लगता है
- जवाब में कहा गया कि बदलाव को लेकर डर सिर्फ उसी को नहीं है, हालांकि उसके कारण शायद तर्कसंगत न हों
  - GIL शुद्ध technical debt है, इसलिए community के हित में इसे हटाना ज़रूरी है
  - आजकल Python में ज़्यादातर लोग threads के बजाय non blocking IO और async का उपयोग करते हैं
  - यदि threads का उपयोग नहीं करते, तो GIL हटने से कोई बदलाव नहीं; C libraries भी single-thread में safe हैं
  - सावधानी केवल तब चाहिए जब वास्तव में threads उपयोग किए जाएँ
  - naïve threaded Python code अब तक GIL की वजह से लगभग single-thread की तरह चलता था, अब वह थोड़ा तेज़ हो सकता है, लेकिन bugs भी बढ़ सकते हैं
  - सलाह यह दी गई कि threads मत उपयोग करें, और यदि करें तो सही तरीके से सीखें
  - आगे बेहतर abstractions मिलने की उम्मीद है, और community में structured concurrency जैसी बातों पर चर्चा की आशा जताई गई
- उन्होंने बताया कि वे asyncio का सक्रिय उपयोग करते हैं
  - यह single-threaded होते हुए भी concurrent Python को आनंद से लिखने देता है; Node.js जैसा अनुभव
  - web·network कामों के लिए इस तरीके की सिफारिश की गई
- अनुमान जताया गया कि ML/AI क्षेत्र की तरह विशेषज्ञ पहले जटिल libraries बनाएँगे और आम उपयोगकर्ताओं तक वही पहुँचेंगी
  - Python में GIL कई मामलों में गंभीर bottleneck बन चुका है
  - इसी वजह से Go भाषा सीखी; उसमें thread support ठीक से है, abstraction के लिहाज़ से Python से नीचे और C/C++ से ऊपर माना जा सकता है
  - compiler model भी threading जितना ही महत्वपूर्ण पृष्ठभूमि कारक बताया गया
- यह भी याद दिलाया गया कि शायद यह बेवजह डर फैलाने जैसा लगे, लेकिन LLM ने पिछले कई दशकों के उस Python code पर training ली है जिसमें GIL के मौजूद होने की धारणा शामिल थी
- GIL हो या न हो, यह केवल उन लोगों के लिए मुद्दा है जो multi-core workloads चाहते हैं
  - यदि अभी तक threading·multiprocessing पर ध्यान नहीं दिया, तो व्यावहारिक रूप से कोई बदलाव नहीं
  - race condition की समस्या GIL हो या न हो, फिर भी हो सकती है
एक व्यक्ति ने कहा कि वह Python अक्सर उपयोग करता है, लेकिन expert नहीं है, और कभी-कभी concurrent.futures से कई simple functions साथ चलाता है
- उसने पूछा कि ऐसे उपयोगकर्ता को आगे क्या बदलना चाहिए
- जवाब मिला कि threads अब GIL से बंधे नहीं रहेंगे, इसलिए कुल मिलाकर तेज़ होंगे
  - यदि shared objects पर locks ठीक से संभाले हैं, तो अतिरिक्त चिंता की ज़रूरत नहीं
20 साल के Python professional development अनुभव से विचार साझा किए गए
- जब सच में threads की ज़रूरत पड़ती है, तब आमतौर पर message passing अपरिहार्य होता है
  - Python ecosystem पहले से ही ऐसी लगभग सभी परिस्थितियों के लिए workarounds देता है
  - threads handling की कई pitfalls, जैसे locks, के कारण आगे भी यह केवल कुछ libraries·domains में ही ज़रूरी हो सकता है
  - केवल pure Python से अधिकतम performance निकालनी हो तो native code आधारित libraries (जैसे Pypy, numba) का उपयोग किया जा सकता है
  - Python की performance में असली क्रांति async programming है; इसे ज़रूर सीखने की सिफारिश की गई
- एक अन्य व्यक्ति ने कहा कि उसने भी Python लगभग उतने ही समय से उपयोग किया है और वह सहमत है, लेकिन थोड़े अलग ढंग से कहेगा
  - Python threads इतने खराब रहे कि उनसे बचने के लिए तरह-तरह के workarounds विकसित हुए
  - CPU-bound काम को threads से 2x तेज़ करने की कोशिश में GIL से टकराना पड़ा, फिर multiprocessing पर जाना पड़ा; data structure serialization की लागत आई, 2x cores पर केवल 1.5x speed जैसे अल्प-प्रभावी नतीजे मिले
  - अच्छा thread support होने पर कई environments में उसका उपयोग करना चाहेंगे; अब तक वह नहीं था, इसलिए अलग-अलग alternative approaches अपनाई गईं
  - जहाँ उपयुक्त हो, async के उपयोग की मज़बूत सिफारिश की गई (glyph, आप सही थे!)
यह AI image है, लेकिन उसमें साँप की दो पूँछें बनी हुई हैं, इस पर हैरानी जताई गई
- मज़ाक में कहा गया कि इसे चुपचाप जाने देना चाहिए; Python article में साँप की तस्वीर हो तो अक्सर यह ऐसा संकेत होता है जिस पर ज़्यादा ध्यान देने की ज़रूरत नहीं
- Confusoborus नाम का मज़ाकिया सुझाव दिया गया
यह भी कहा गया कि header image में साँप की दो पूँछें दिख रही हैं
- जवाब में मज़ाक किया गया कि शायद उसी process के भीतर दूसरा thread बना दिया गया है
libraries support के अलावा, यह पूछा गया कि WSGI और Celery workers को single process में चलाने पर कोई और बाधा है क्या
- जवाब मिला कि कोई बाधा नहीं है, लेकिन यह तरीका भाषा की first-class feature नहीं है
  - GIL को technical debt का मुद्दा बताया गया
  - यह भी कहा गया कि सिर्फ parallelism ही नहीं, और कारण भी हैं जिनसे GIL हटाना ज़रूरी है
इसे आने वाले performance era के लिए बहुत बड़ा foundational work बताया गया