Free-threaded CPython प्रयोग के लिए तैयारी पूरी

 (labs.quansight.org)
3 पॉइंट द्वारा GN⁺ 2024-07-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Free-threaded CPython एक बड़ा बदलाव है, जो एक ही interpreter के भीतर कई threads को parallel में चलाने की अनुमति देता है
  • यह CPython 3.13 में एक experimental feature के रूप में उपलब्ध है
  • PEP 703 की बदौलत अब इसे GIL को disable करके चलाया जा सकता है
  • यह performance सुधार, खासकर multi-thread performance के लिए महत्वपूर्ण है
  • यह कई CPU cores का प्रभावी उपयोग संभव बनाता है

शानदार है, लेकिन समस्याएँ क्या हैं?

  • CPython में free-threading को लागू करना अपने आप में एक बड़ा प्रयास है
  • दो मुख्य समस्याएँ हैं: thread safety और ABI compatibility
    • Thread safety: शुद्ध Python code बिना बदलाव के काम करता है, लेकिन दूसरी भाषाओं में लिखा गया code या CPython C API का उपयोग करने वाला code ऐसा न भी करे
    • ABI compatibility: free-threaded interpreter का ABI अलग होता है, इसलिए extension modules वाले हर package को अतिरिक्त wheels बनानी होंगी
  • Thread safety समस्याओं को समझना, सुधारना और test करना कठिन है
  • उदाहरण: numpy#26690, pywavelets#758 आदि में intermittent failures हुए

आगे की योजना और टीम का काम

  • free-threaded CPython के default बनने में अभी कुछ साल लगेंगे
  • उम्मीद है कि Python 3.13 में कई projects compatibility पर काम करेंगे और cp313t wheels को PyPI पर release करेंगे
  • टीम ने कई महीनों से PyData stack के निचले हिस्से से काम शुरू किया है
  • हर package के लिए मिलती-जुलती approach अपनाई गई है:
    1. पहला CI job जोड़ना
    2. thread safety और shared/global state की समस्याएँ ठीक करना
    3. wheel build CI jobs में free-threaded support जोड़ना
    4. local में stress test करना और CI jobs की निगरानी करना
    5. extension modules को GIL के बिना चल सकने योग्य के रूप में चिह्नित करना
    6. अगले package पर बढ़ना

GN⁺ का सारांश

  • Free-threaded CPython एक महत्वपूर्ण बदलाव है, जो multi-thread performance को काफी बेहतर बना सकता है
  • thread safety और ABI compatibility समस्याओं को हल करना सबसे बड़ी चुनौती है
  • उम्मीद है कि Python 3.13 में कई projects compatibility पर काम कर पाएँगे और प्रयोग कर सकेंगे
  • PyTorch जैसे बड़े packages और कई छोटे packages को भी इस बदलाव को अपनाना होगा
  • संबंधित projects में PyO3 और PyTorch शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-13
Hacker News राय

  • Python के GIL हटने से कई संगठनों और प्रोजेक्ट्स को लगभग बिना अतिरिक्त मेहनत के performance में बड़ा सुधार करने का अवसर मिलेगा

    • अगर पुराने libraries इस बदलाव को समय पर नहीं अपनाते, तो नए projects के market share हासिल करने की संभावना है
    • multiprocessing की जटिलता और bugs से बचते हुए simple threads का उपयोग करके बड़े machines के सभी cores का इस्तेमाल किया जा सकेगा

  • macOS पर GIL-हटाया गया Python install करके चलाने का अनुभव साझा किया गया

    • install process और differences समझाने के लिए एक छोटा script लिखा गया
    • लिंक

  • Python की आसान writing और logic को पसंद करने वाला उपयोगकर्ता उम्मीद करता है कि GIL-हटाया गया approach, Python लिखने के मौजूदा तरीके जैसा ही रहे

    • यह भी कहा कि multithreading मुश्किल होने के कारण उसने इसमें गहराई से काम नहीं किया

  • Python 3 की प्रगति का सारांश दिया गया

    • [x] Async
    • [x] Optional static typing
    • [x] Threading
    • [ ] JIT
    • [ ] Efficient dependency management

  • याद किया गया कि 2007 के आसपास parallel processing अनिवार्य हो गई थी

    • यह भी कहा गया कि Rust, speed और parallel processing में बढ़त रखता है

  • PEP703 में बताया गया कि GIL हटने के बाद भी list का append operation thread safety कैसे बनाए रखता है

    • हर list के लिए lock जोड़ा गया है
    • यह भी कहा गया कि simple integer increment operation अभी GIL की वजह से thread-safe है

  • GIL हटने से ML training और inference की प्रकृति कैसे बदलेगी, इसे लेकर उत्साह जताया गया

    • memory passing और process coordination की जटिलता कम हो सकती है
    • PyTorch जैसी libraries के optimize होने की संभावना की उम्मीद की गई

  • चिंता जताई गई कि जिन programmers ने असली multithreading कभी नहीं संभाली, वे नए subtle bugs ला सकते हैं

  • सवाल उठाया गया कि क्या single-thread performance में गिरावट गंभीर है

    • benchmarks नहीं मिल पाए, और सिर्फ सामान्य आश्वासन ही दिए गए

  • async के साथ यह कैसे काम करेगा, इसे लेकर जिज्ञासा व्यक्त की गई

    • I/O और CPU-bound code के बीच एक स्वाभाविक दीवार है
    • अधिक flexible model देखने की इच्छा जताई गई
    • यह भी पूछा गया कि CPU-bound coroutines पर "gather" करते समय JIT संभव होगा या नहीं
    • ऐसा flexible programming model अच्छा लगेगा जिसमें मिलते-जुलते interface के साथ जल्दी switch किया जा सके