Python 3.14 जारी हो गया है। यह कितना तेज़ हुआ है?

 (blog.miguelgrinberg.com)
3 पॉइंट द्वारा GN⁺ 2025-10-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • इस बार जारी किया गया Python 3.14 अब तक के CPython वर्ज़नों में सबसे तेज़ प्रदर्शन दिखाता है
  • सिंगल थ्रेड में 3.14 ने 3.13 की तुलना में लगभग 27% सुधार दिखाया, JIT का प्रदर्शन सुधार मामूली रहा, और Free-threading इंटरप्रेटर सिंगल थ्रेड में थोड़ा धीमा रहा
  • मल्टीथ्रेड में FT इंटरप्रेटर ने GIL हटने के प्रभाव से Fibonacci में 3.1 गुना, Bubble Sort में 2 गुना तक की तेजी दिखाई, इसलिए यह CPU-गहन मल्टीथ्रेड कार्यों में उपयोगी है
  • निष्कर्षतः 3.14, CPython में सबसे तेज़ है, 3.11 या उससे ऊपर की सिफारिश की गई है, Pypy अब भी बहुत तेज़ है, और JIT को परिपक्वता में और सुधार की ज़रूरत है

बेंचमार्क की पूर्वधारणाएँ और सीमाएँ

  • Python 3.14 के आधिकारिक रिलीज़ के तुरंत बाद, Python के कई वर्ज़नों और अन्य भाषाओं के साथ परफॉर्मेंस बेंचमार्क के नतीजे साझा किए गए
  • यह टेस्ट केवल शुद्ध Python कोड से लिखे गए सरल recursive (Fibonacci) और iterative (Bubble Sort) फ़ंक्शनों पर किया गया
  • वास्तविक विकास वातावरण में अक्सर C/C++/Rust जैसी native code के साथ मिश्रित उपयोग होता है, इसलिए ये परिणाम वास्तविक परिस्थितियों से 1:1 मेल नहीं खाते

टेस्ट मैट्रिक्स

  • टेस्ट वातावरण
    • Python के 6 वर्ज़न(3.9~3.14), Pypy, Node.js, Rust शामिल
    • Python इंटरप्रेटर: Standard, JIT, Free-threading (प्रत्येक 3.13 या उससे ऊपर)
    • टेस्ट स्क्रिप्ट: Fibonacci (fibo.py), Bubble Sort (bubble.py)
    • थ्रेड मोड: सिंगल थ्रेड, 4 थ्रेड
    • टेस्ट मशीन: Linux (Framework i5), macOS (M2)
  • Node.js और Rust वर्ज़नों की भी संदर्भ के तौर पर तुलना की गई

टेस्ट स्क्रिप्ट

  • Fibonacci (fibo.py): recursive संरचना का उपयोग, हर वातावरण में fibo(40) चलाया गया
  • Bubble Sort (bubble.py): 10,000 रैंडम संख्याओं को sort किया गया
  • हर टेस्ट को 3 बार दोहराकर औसत निकाला गया
  • टेस्ट कोड GitHub रिपॉज़िटरी में सार्वजनिक है

Benchmark #1: Fibonacci (सिंगल थ्रेड)

  • Python 3.14 ने 3.13 की तुलना में लगभग 27% तेज़ गति दर्ज की (6.59 सेकंड vs 8.26 सेकंड)
  • 3.11 वर्ज़न से यह "बहुत धीमा" से "कुछ कम धीमा" की स्थिति में पहुँचा
  • Pypy, 3.14 से लगभग 5 गुना तेज़ है, Node.js के बराबर है, और Rust बहुत बड़े अंतर से सबसे तेज़ है
  • Free-threading सिंगल थ्रेड में अब भी Standard वर्ज़न से धीमा है, लेकिन 3.14 में आते-आते गति का अंतर कम हुआ है (लगभग 91% स्तर)

JIT, Free-threading इंटरप्रेटर

  • इस recursive फ़ंक्शन संरचना में JIT से कोई महसूस होने योग्य प्रदर्शन सुधार नहीं मिला
  • Free-threading ने सिंगल थ्रेड में उल्टा थोड़ा धीमा परिणाम दिया
  • JIT के प्रदर्शन सुधार की सीमा फ़ंक्शन संरचना के अनुसार बदल सकती है

Benchmark #2: Bubble Sort (सिंगल थ्रेड)

  • Python 3.14, 3.11 से थोड़ा तेज़ है, लेकिन अंतर Fibonacci की तुलना में कम है (3.14: 2.18 सेकंड, 3.11: 2.48 सेकंड)
  • Pypy, 3.14 से लगभग 18 गुना तेज़ है
  • Linux वातावरण में JIT थोड़ा तेज़ दिखा, जबकि macOS में लगभग कोई अंतर नहीं था

Benchmark #3: Fibonacci (मल्टीथ्रेड)

  • Standard इंटरप्रेटर में GIL (Global Interpreter Lock) के कारण थ्रेड बढ़ाने पर भी अपेक्षित गति नहीं मिली
  • Free-threading इंटरप्रेटर (3.14) ने Standard की तुलना में 3.1 गुना तेज़ी दिखाई
  • JIT का प्रभाव लगभग नहीं दिखा
  • केवल Pypy के परिणाम मापे गए; Node.js/Rust की तुलना इस टेस्ट में नहीं की गई

Benchmark #4: Bubble Sort (मल्टीथ्रेड)

  • Free-threading (3.14 FT) ने Standard (3.14) की तुलना में 2 गुना तेज़ परिणाम दिया, खासकर CPU-गहन कार्यों में इसका लाभ स्पष्ट रहा
  • JIT की कोई स्पष्ट प्रदर्शन बढ़त नहीं दिखी
  • Mac पर Free-threading का प्रदर्शन उल्लेखनीय रहा

निष्कर्ष

  • CPython 3.14 मौजूदा CPython वर्ज़नों में सबसे तेज़ प्रदर्शन देता है
  • अगर अपग्रेड कठिन हो, तो 3.11 या उससे ऊपर का वर्ज़न इस्तेमाल करने की सिफारिश है
  • JIT इंटरप्रेटर से वास्तविक उपयोग में महसूस होने वाली गति वृद्धि मामूली रही
  • Free-threading इंटरप्रेटर मल्टीथ्रेड CPU-गहन स्थितियों में स्पष्ट लाभ देता है
  • Pypy बेहद तेज़ है और आगे परीक्षण के लिए बहुत मूल्यवान है

अन्य

  • परिणाम विभिन्न वातावरणीय कारकों के अनुसार बदल सकते हैं, इसलिए खुद बेंचमार्क करके पुष्टि करने की सिफारिश है
  • विस्तृत जानकारी और कोड के लिए GitHub रिपॉज़िटरी देखी जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2025-10-10
Hacker News राय

  • मैं उस व्यक्ति के बारे में बात करना चाहता हूँ जिसने मेरी ज़िंदगी बदल दी। मैंने Flask mega tutorial के ज़रिए अपनी पहली वेबसाइट बनाई, और लॉन्च से ठीक पहले Flask में broken files को handle करने वाले एक अहम हिस्से पर अटक गया था। मैंने सवाल पूछा, और Stack Overflow के जवाब से समस्या हल हो गई, जिसे मैंने तुरंत साइट पर लागू कर दिया। उसके बाद साइट बहुत तेज़ी से फैल गई। संदर्भ के लिए जवाब का लिंक छोड़ रहा हूँ stackoverflow link

    • इसका Flask से कोई लेना-देना नहीं है, लेकिन नया Flask लोगो मुझे बिल्कुल पसंद नहीं है। पुराने लोगो में vintage और hand-crafted जैसा एहसास था, जबकि नया लोगो ऐसा लगता है जैसे किसी हाई-स्कूल छात्र ने WordArt से मज़ाक-मज़ाक में बना दिया हो। पुराना लोगो, नया लोगो

    • पूछना चाहता हूँ कि क्या तुम्हारी बनाई साइट yout.com है। और यह भी जानना चाहता हूँ कि क्या अब भी Flask इस्तेमाल हो रहा है

    • काश कभी फिर vibe coding के साथ microphonetest.com साइट दोबारा जीवित हो जाए

  • benchmark लिखते समय loop के अंदर time measure करके उन्हें जोड़ने का तरीका न अपनाने की सलाह दूँगा। बेहतर है पूरे loop का execution time मापा जाए और फिर उसे iteration count से divide किया जाए। time measurement से पैदा होने वाला jitter नतीजों को बिगाड़ सकता है

    • standard library के timeit की सिफारिश करता हूँ timeit docs

  • डर है कि कहीं Python 3.14 पर पहुँचकर TeX की तरह स्थिर न हो जाए Reddit लिंक

    • "रुकना नहीं चाहिए" वाली राय पढ़कर Donald Knuth के उस नज़रिए का हिस्सा ताज़ा लगा, जिसमें वे बदलाव से ज़्यादा लगातार एक जैसे परिणाम देने वाली प्रणाली को महत्व देते हैं। ऐसी दुनिया में जहाँ कुछ साल बाद सब कुछ पुराना लगने लगता है, यह मजबूरी कि OOO आया है तो अब उसे अपनाना ही होगा, किसी बीमारी जैसी लगती है। ऐसा कोई कारण नहीं कि हम 100 साल चलने वाला code न लिख सकें। code आख़िरकार गणित ही है। जैसे हज़ारों साल पहले ईजाद किए गए polynomial इस्तेमाल करने पर कोई आपको पुराना नहीं कहता, वैसे ही परखे हुए तरीकों पर टिके रहने का रवैया भी ज़रूरी है। हर बार नए version और नए tool के पीछे भागना ज़रूरी नहीं है। जो लोग बिना वजह बदलने की ज़रूरत न रखने वाला code लिखते हैं, वही सच में योगदान दे रहे हैं

    • πthon से जुड़ा मज़ाक इस स्थिति पर हैरान करने वाले ढंग से फिट बैठता है

  • जब भी Python की खबर आती है, यह खलता है कि 2025 में भी PyPy अब तक अलग धारा पर है। सोचता हूँ कि क्या कभी GIL-less Python, GIL-less C FFI तक भी पहुँच पाएगा। मुझे लगता है कि उससे Python को सच में बहुत बड़ा फायदा होगा

    • C FFI में तो पहले से ही GIL को manually release किया जा सकता था, इसलिए इसका सटीक मतलब क्या है, यह जानना चाहता हूँ

    • मेरा मानना है कि C language से शुरू होकर अलग-अलग compiler implementations से कई dialects का बनना एक स्वस्थ ecosystem है। यह प्रयोग और प्रगति को बढ़ावा देता है। PyPy और CPython के बीच फर्क भी मुझे बहुत बड़ा नहीं लगता, और compatibility भी काफ़ी अच्छी है pypy compatibility guide

    • freethreading का मकसद यही है। मेरी जानकारी में अभी कई C FFI libraries को GIL के बिना काम करने लायक नहीं बदला गया है, इसलिए freethreading को default के रूप में अभी इस्तेमाल नहीं किया जा सकता

    • Python ने experimental JIT जोड़कर PyPy की ओर एक कदम और बढ़ाया है। आगे वे नया JIT खुद बनाएँगे या PyPy को merge करेंगे, यह नहीं पता, लेकिन मुझे यक़ीन है कि उन्होंने PyPy से बहुत कुछ सीखा है

    • पूछना चाहता हूँ कि क्या आपको लगता है कि इस तरह की समस्या, यानी अलग implementation systems को मिलाना, बदल सकती है। अगर Python गलती से performance को नुकसान पहुँचाने वाला कोई और breaking change ले आए, तो उसका नुकसान बहुत बड़े user base को होगा। क्या Python संगठन सच में ऐसा चाहेगा, इस पर संदेह है

  • यह दिलचस्प है कि PyPy multithreaded code में भी free threaded CPython से ज़्यादा तेज़ है

  • non-GIL में बदलाव का बहुत smooth तरीके से आगे बढ़ना खास तौर पर दिखता है। 2→3 version के समय से तुलना करें तो यह transition सच में शानदार है। standard speed तक इतनी जल्दी पहुँच जाना भी उम्मीद जगाता है, और आशा है कि incompatibilities भी जल्द गायब हो जाएँगी

  • अगर आप benchmark जल्दी खुद चलाकर देखना चाहते हैं, तो fast_langton_ant repo की सिफारिश है। इसे python3 server.py -s 10000000 -n जैसे command से चला सकते हैं

  • सोच रहा हूँ कि fold comment फीचर karma या किसी और option के आधार पर लागू होता है या नहीं। Miguel वाली मदद की कहानी सबसे लोकप्रिय पोस्ट थी, यह प्रभावशाली लगा, लेकिन जब सिर्फ़ मुख्य विषय से जुड़ी बातें पढ़नी हों, तब fold फीचर न होना पहली बार खला

  • मेरा मानना है कि केवल simple loops और integer arithmetic वाले benchmark से Python के वास्तविक उपयोग को आँकना ठीक नहीं है। hashmap या string processing असली code के ज़्यादा करीब हैं। बहुत से Python users numeric computation बाहरी libraries को सौंप देते हैं

    • benchmark हमेशा किसी न किसी खास मानदंड के लिए डिज़ाइन किए जाते हैं। लेखक ने पोस्ट में अपना उद्देश्य समझाया है, इसलिए दिलचस्पी हो तो उसे देखना चाहिए

    • काश यह और गहराई से विश्लेषण करने वाला लेख होता, लेकिन फिर भी मेरे वास्तविक उपयोग के लिए इस तरह के benchmark ज़्यादा मेल खाते हैं। मेरे मामले में मैं ज़्यादातर Monte Carlo simulations या simple scientific computations अलग-अलग समस्याओं पर बार-बार बनाता हूँ। one-off simulations के लिए मैं जानबूझकर तेज़ algorithms या अपरिचित libraries नहीं लाता। कभी-कभी 10 मिनट लग जाएँ तो भी ठीक है (हाँ, scipy, numpy मुख्य रूप से इस्तेमाल करता हूँ)। क्योंकि मैं assumptions बार-बार बदलता रहता हूँ, इसलिए संभव हो तो चीज़ों को simple रखना पसंद करता हूँ। readability और तत्काल लिखा गया code मेरे लिए अहम हैं, भले optimization अच्छा न हो (जैसे fibonacci, bubble sort, nested for loops)। अगर सच में performance चाहिए हो, तो मैं cpp/zmp/pybind/numba में चीज़ें खुद implement कर लेता हूँ

    • FastAPI endpoint calls या numpy computations जैसे लोकप्रिय उदाहरण benchmark में शामिल करना, Python के वास्तविक उपयोग के ज़्यादा करीब होगा। हो सकता है यह pure Python code न हो, लेकिन व्यवहार में बहुत से लोग Python को इसी तरह इस्तेमाल करते हैं

  • सिर्फ tight loop और int arithmetic से benchmark करना कितना वास्तविक है, इस पर संदेह है

  • जानना चाहता हूँ कि क्या नया experimental tail call interpreter (option --with-tail-call-interp) benchmark में शामिल था tail-call-interp official docs। टेस्ट नतीजों में इसका ज़िक्र नहीं था, इसलिए अनुमान है कि शायद शामिल नहीं था। देखना चाहूँगा कि tail call interpreter मौजूदा दूसरे implementations की तुलना में कितना अलग है

    • मेरे द्वारा इस्तेमाल किया गया Python build tail call फीचर enabled (--with-tail-call-interp) के साथ था। यह पक्का नहीं कि optimization recursive tail call पर भी लागू होती है या नहीं, लेकिन अगर होती, तो Fibonacci टेस्ट में performance improvement दिखना चाहिए था