Python 3.15 का Windows x86-64 इंटरप्रिटर लगभग 15% तेज़ होने की उम्मीद

 (fidget-spinner.github.io)
3 पॉइंट द्वारा GN⁺ 2025-12-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CPython का tail-calling interpreter Windows x86-64 वातावरण में मौजूदा तरीके की तुलना में लगभग 15% बेहतर प्रदर्शन दिखाता है
  • macOS AArch64(XCode Clang) पर भी लगभग 5% का performance improvement देखा गया है, और Windows में MSVC 2026 की experimental functionality का उपयोग किया गया है
  • pyperformance benchmark में ज़्यादातर tests में speed improvement देखा गया, और कुछ में अधिकतम 78% तक सुधार
  • performance improvement का मुख्य कारण compiler optimization heuristics reset और inlining improvement माना गया है
  • Python 3.15 की आधिकारिक रिलीज़ पर, Visual Studio 2026 आधारित build में इसे डिफ़ॉल्ट रूप से लागू किया जाएगा

tail-calling interpreter का performance improvement

  • CPython का tail-calling interpreter, मौजूदा switch-case interpreter की तुलना में Windows x86-64 पर लगभग 15% तेज़ मापा गया
    • pyperformance के अनुसार, geometric mean में 15~16% सुधार
    • कुछ benchmarks में अधिकतम 78% speed improvement, जबकि बहुत कम मामलों में 60% धीमापन
  • macOS AArch64(XCode Clang) पर लगभग 5% performance improvement की पुष्टि हुई
  • यह परिणाम इस शर्त पर मान्य है कि Python 3.15 development cycle के दौरान इसमें कोई बदलाव न हो

interpreter संरचना की तुलना

  • C-आधारित interpreter implementation को तीन तरीकों में बाँटा जाता है: switch-case, computed goto, tail-call threaded
    • switch-case: हर instruction के लिए branch handling
    • computed goto: GCC/Clang extension, जिसमें branch address पर सीधे jump किया जाता है
    • tail-call threaded: हर bytecode handler को function में अलग करना और अगले function को tail call करना
  • पहले C compiler tail call optimization की गारंटी नहीं देते थे, इसलिए stack overflow का जोखिम था
  • Clang के __attribute__((musttail)) और MSVC के [[msvc::musttail]] attribute से forced tail call संभव हो गया

Windows के लिए MSVC 2026 build results

  • MSVC की experimental functionality का उपयोग करने वाले CPython build में ज़्यादातर benchmarks तेज़ हुए
    • उदाहरण परिणाम:
      • spectralnorm: 1.48x
      • nbody: 1.35x
      • bm_django_template: 1.18x
      • xdsl: 1.14x
  • इसे Python 3.15 के “What’s New” दस्तावेज़ में आधिकारिक रूप से शामिल किया गया
    • Visual Studio 2026(MSVC 18) build में tail-calling interpreter उपलब्ध
    • pure Python libraries में लगभग 15%, और छोटे scripts में अधिकतम 40% speed improvement

performance improvement के कारण

  • tail calling, compiler की optimization heuristics को reset करके अधिक efficient code generation को बढ़ावा देता है
  • मौजूदा CPython interpreter loop लगभग 12,000 lines के एक single function से बना है, जिससे inlining optimization failure अक्सर होती है
    • compiler code size बढ़ने से बचने के लिए कई बार inlining से इनकार करता है
  • tail-calling approach में functions अलग हो जाते हैं, जिससे simple functions inline किए जा सकते हैं
    • उदाहरण के तौर पर PyStackRef_CLOSE_SPECIALIZED जैसे simple function inline हो जाते हैं
  • PGO(profile-guided optimization) build में भी यही phenomenon रिपोर्ट किया गया

build और उपयोग का तरीका

  • फिलहाल केवल source build संभव है
    • Visual Studio 2026 वातावरण में निम्न command से build करें 
      $env:PlatformToolset = "v145"
./PCbuild/build.bat --tail-call-interp -c Release -p x64 --pgo
  • आगे Python 3.15 development स्थिर होने पर official binary distribution जारी की जाएगी

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

1 टिप्पणियां

 
GN⁺ 2025-12-26
Hacker News की टिप्पणियाँ
  • उस मुख्य code snippet को साझा किया गया है जिसे ब्लॉग पोस्ट में शामिल किया जाना चाहिए था
    यह MSVC और Clang में musttail तथा preserve_none attributes की परिभाषा के अंतर को दिखाने वाला उदाहरण है
    इन attributes को function declarator पर लगाना चाहिए, function specifier की स्थिति में यह काम नहीं करते
    संबंधित code link
    इससे ऐसा आभास मिलता है कि Microsoft ऐसी गैर-प्रकाशित सुविधाएँ केवल उन्हीं projects को बताता है जिन्हें वह महत्वपूर्ण मानता है
    • मुझसे गलती हुई थी। [[msvc::musttail]] वास्तव में एक आधिकारिक रूप से documented attribute था
      इसे दर्शाने के लिए ब्लॉग पोस्ट को अपडेट करने वाला हूँ
      संबंधित HN टिप्पणी
    • यह सवाल उठाया गया: “क्या उन्होंने इसे इसलिए बताया क्योंकि यह महत्वपूर्ण था, या इसलिए क्योंकि इससे उनका अपना फायदा था?”
  • Python 3.14 के समय की तरह LLVM 19 bug के कारण गलत performance improvement report होने वाली घटना याद करते हुए, इस बार वैसी समस्या न हो यही उम्मीद जताई गई
    पोस्ट पढ़ने पर यह ठीक लगा कि इसमें transparency और तेज feedback को प्राथमिकता दी गई है
    cross-compiler validation या independent audit होता तो और अच्छा रहता, लेकिन लेखक की पूर्ण पारदर्शिता के कारण इसे भरोसेमंद माना गया
    • लेखक ने याद किया कि उस समय की गलती दरअसल एक तरह की भाग्यशाली दुर्घटना थी
      जल्दी सार्वजनिक कर देने से Nelson ने Clang 19 bug पकड़ लिया, और उसकी वजह से आधिकारिक release से पहले उसे ठीक किया जा सका
      इस बार dispatch logic और inlining दोनों तरह के सुधार हैं, इसलिए उन्हें अधिक भरोसा है
      MSVC कुछ शर्तों में switch-case interpreter को threaded code में बदल सकता है, लेकिन CPython इतना जटिल है कि वह optimization वहाँ लागू नहीं होती
      इसके बजाय tail call approach में C code लिखने वाले के पास अधिक नियंत्रण होता है
      संबंधित संदर्भ: MSVC threaded code conditions, forceinline related issue
    • नई design का फायदा यह है कि यह compiler optimization की मनमर्जी पर कम निर्भर है
      पहले tail duplication जैसी optimizations compiler के निर्णय पर निर्भर थीं, लेकिन अब interpreter सीधे उस machine code के रूप को व्यक्त कर सकता है जो वह चाहता है
      पिछली चर्चा का link
  • compiler issues पर पुरानी एक presentation का ज़िक्र करते हुए, EuroPython 2025 presentation video साझा किया गया
  • काफ़ी समय बाद Windows के लिए Python में एक GUI app बनाया जा रहा है
    C#/MAUI की तुलना में VS ecosystem बहुत भारी होने के कारण Python चुना गया
    Tkinter असुविधाजनक लगा, Qt का learning curve बड़ा था, इसलिए wxGlade + wxPython का संयोजन इस्तेमाल किया गया
    सिर्फ़ एक dependency चाहिए जो pip से install हो सके, और इसका Pythonic अनुभव पसंद आया
    Windows runtime improvements देखकर अच्छा लगा
    • मुझे Python + Qt/PySide का संयोजन पसंद है
      QtCreator में जल्दी UI बनाकर Python से logic जोड़ दें तो development speed बहुत तेज़ हो जाती है
    • pyfltk की भी सिफारिश की गई। GNU/Linux पर यह काफ़ी अच्छा था
    • अगर GUI महत्वपूर्ण है, तो LINQPad पर भी विचार किया जा सकता है। यह scripting और भारी काम के बीच का एक मध्य बिंदु है
    • Python के लिए ImGui bindings की सिफारिश की गई
      Tkinter या Qt की तरह retained mode नहीं, बल्कि immediate mode तरीका है, इसलिए internal tooling में यह खास तौर पर उपयोगी है
      imgui_bundle project
  • यह पूछते हुए कि “क्या यह कम कठिनाई वाला optimization task नहीं है?”, सवाल उठाया गया कि interpreter loop अभी तक पूरी तरह optimize क्यों नहीं हुई
    कहा गया कि प्रमुख ISA के लिए इसे assembly में लिखा हुआ होना चाहिए था
    • इसके उलट, इस update से यही दिखता है कि loop पहले से ही बेहद optimize है
      [[msvc::musttail]] MSVC 14.50 (पिछले महीने जारी) में जोड़ा गया एक नया attribute है, और CPython टीम ने कुछ ही हफ्तों में इसका उपयोग करके performance improvement हासिल कर ली
      MSVC musttail docs
    • Python का मूल लक्ष्य speed से अधिक simplicity है
      Guido ने code simplicity को प्राथमिकता दी, इसलिए JIT अपनाने में देर हुई, और बाद में PEP 744 (JIT Compilation) जैसे प्रयास सामने आए
    • open source से अत्यधिक अपेक्षा नहीं रखनी चाहिए
      assembly optimization एक maintenance nightmare है, और Python की असली bottleneck packaging system है
    • वैसे भी performance के प्रति संवेदनशील लोग Windows पर Python नहीं चलाते, ऐसा भी कहा गया
  • “Python interpreter, V8 की तुलना में इतना धीमा क्यों है?” यह प्रश्न पूछा गया
    • JavaScript JIT compilation का उपयोग करता है, लेकिन CPython ऐसा नहीं करता
      PyPy, JIT की वजह से तेज़ है, लेकिन C extensions के साथ compatible नहीं है
      Python का threading model भी optimization को कठिन बनाता है
      दूसरी ओर JS single-threaded है, इसलिए अपेक्षाकृत सरल है
      Python में C extensions के ज़रिए रास्ता निकाला जा सकता था, इसलिए CPython को optimize करने का दबाव कम था
    • Google की मानव-शक्ति और गुणवत्ता इस अंतर का बड़ा कारण मानी गई
      साथ ही CPython विशाल C extension ecosystem के कारण compatibility नहीं तोड़ सकता
      जबकि V8 अपनी internal structure को अपेक्षाकृत स्वतंत्र रूप से बदल सकता था
    • Python में property access भी descriptor protocol से होकर जाता है, इसलिए यह कहीं अधिक dynamic है
      साथ ही stable C ABI बनाए रखना पड़ता है, इसलिए JIT के लिए code analysis को स्वतंत्र रूप से करना कठिन हो जाता है
    • Python, JS की तुलना में कहीं अधिक dynamic language है, और FFI bindings के कारण internal changes पर सीमाएँ हैं
      इस संबंध में PyPy को इन बंधनों से जूझना पड़ा, इसका भी उल्लेख किया गया
    • JS को optimize करने के लिए Google ने web पर प्रभुत्व बनाए रखने हेतु विशाल संसाधन लगाए, जबकि Python ने भाषा के विकास पर अधिक resources लगाए
      साथ ही JS को सिर्फ़ pure JS support करना होता है, लेकिन Python को external extension ecosystem भी बनाए रखना पड़ता है, इसलिए optimization पर कई सीमाएँ हैं
  • नए benchmark graph को रोचक बताते हुए पूछा गया कि इसे किस tool से बनाया गया
    साथ ही साझा किया गया कि उन्होंने mitata से JS library performance नापी है
    Immer JS optimization PR
    • वह graph एक violin plot है
      Wikipedia explanation, Matplotlib example
      यह distribution को symmetric रूप में दिखाता है, लेकिन smoothing वास्तविक distribution को विकृत कर सकती है, और इसे space waste भी कहा जाता है
      HN discussion में half-violin plot को बेहतर बताने वाली राय भी थी
      example image
  • यह बताया गया कि Matt Godbolt ने कहा था कि tail-call आधारित interpreter, CPU के branch predictor के लिए अधिक अनुकूल है
  • पोस्ट की पहली पंक्ति में दो typos हैं; इस पर पूछा गया कि क्या यह AI से बना हुआ दिखाने के लिए जानबूझकर की गई गलती है
    • लेखक ने जवाब दिया, “धन्यवाद, ठीक कर दिया”
    • एक अन्य उपयोगकर्ता ने मज़ाक में सलाह दी कि “अगर AI जैसा नहीं दिखना है, तो बस खुद लिखो”
      और AI-लिखित लेखों की सामान्य विशेषताओं (छोटे paragraphs, ज़रूरत से ज़्यादा सकारात्मक लहजा, गहराई की कमी आदि) पर व्यंग्य किया
  • यह सवाल भी पूछा गया: “अगर Python टीम को tail call उपयोगी लग रही है, तो क्या भाषा में भी tail call support जोड़ा जाएगा?”