Interpreter Windows x86-64 Python 3.15 diperkirakan sekitar 15% lebih cepat

• Interpreter tail-calling CPython menunjukkan performa sekitar 15% lebih cepat dibanding metode sebelumnya di lingkungan Windows x86-64
• Peningkatan performa sekitar 5% juga terkonfirmasi di macOS AArch64 (XCode Clang), sementara di Windows memanfaatkan fitur eksperimental MSVC 2026
• Dalam benchmark pyperformance, sebagian besar pengujian menunjukkan peningkatan kecepatan, dan beberapa meningkat hingga 78%
• Penyebab utama peningkatan performa dianalisis berasal dari reset heuristik optimisasi compiler dan peningkatan inlining
• Saat rilis resmi Python 3.15, fitur ini dijadwalkan aktif secara default pada build berbasis Visual Studio 2026

---

Peningkatan performa interpreter tail-calling

• Interpreter tail-calling CPython diukur sekitar 15% lebih cepat daripada interpreter switch-case yang ada di Windows x86-64
  • Berdasarkan pyperformance, rata-rata geometrik meningkat 15~16%
  • Beberapa benchmark meningkat hingga 78%, sementara sedikit kasus justru 60% lebih lambat
• Di macOS AArch64 (XCode Clang), terkonfirmasi peningkatan performa sekitar 5%
• Hasil ini berlaku dengan asumsi tidak ada perubahan selama siklus pengembangan Python 3.15

Perbandingan struktur interpreter

• Metode implementasi interpreter berbasis C dibagi menjadi tiga: switch-case, computed goto, dan tail-call threaded
  • switch-case: menangani percabangan per instruksi
  • computed goto: ekstensi GCC/Clang yang melompat langsung ke alamat percabangan
  • tail-call threaded: memisahkan tiap handler bytecode menjadi fungsi, lalu melakukan tail call ke fungsi berikutnya
• Di masa lalu, compiler C tidak menjamin optimisasi tail call sehingga ada risiko stack overflow
• Atribut __attribute__((musttail)) milik Clang dan [[msvc::musttail]] milik MSVC memungkinkan forced tail call

Hasil build MSVC 2026 untuk Windows

• Pada build CPython yang menggunakan fitur eksperimental MSVC, sebagian besar benchmark menunjukkan peningkatan kecepatan
  • Contoh hasil:
    • spectralnorm: 1.48x
    • nbody: 1.35x
    • bm_django_template: 1.18x
    • xdsl: 1.14x
• Sudah dicerminkan secara resmi dalam dokumen “What’s New” Python 3.15
  • Interpreter tail-calling tersedia pada build Visual Studio 2026 (MSVC 18)
  • Library Python murni sekitar 15% lebih cepat, skrip kecil hingga 40% lebih cepat

Penyebab peningkatan performa

• Tail calling menginisialisasi ulang heuristik optimisasi compiler, sehingga mendorong pembuatan kode yang lebih efisien
• Loop interpreter CPython sebelumnya tersusun sebagai satu fungsi tunggal sekitar 12.000 baris, sehingga optimisasi inlining sering gagal
  • Banyak kasus compiler menolak inlining untuk menghindari pembesaran ukuran kode
• Pada pendekatan tail calling, fungsi dipisah sehingga fungsi sederhana bisa diproses inline
  • Sebagai contoh, fungsi sederhana seperti PyStackRef_CLOSE_SPECIALIZED dapat di-inline
• Fenomena yang sama juga dilaporkan pada build PGO (profile-guided optimization)

Cara build dan penggunaan

• Saat ini hanya build dari source yang memungkinkan
  • Di lingkungan Visual Studio 2026, build dengan perintah berikut

    $env:PlatformToolset = "v145"
    ./PCbuild/build.bat --tail-call-interp -c Release -p x64 --pgo
    

• Ke depannya, setelah pengembangan Python 3.15 stabil, distribusi binary resmi akan dirilis

[GN⁺]

Komentar Hacker News

• Membagikan potongan kode inti yang seharusnya bagus jika dimasukkan ke dalam tulisan blog
  Ini adalah contoh yang menunjukkan perbedaan definisi atribut musttail dan preserve_none di MSVC dan Clang
  Atribut ini harus ditempelkan pada deklarator fungsi, dan tidak berfungsi jika diletakkan pada posisi penentu fungsi
  Tautan kode terkait
  Memberi nuansa seolah Microsoft hanya memberi tahu fitur nonpublik seperti ini kepada proyek yang mereka anggap penting
  • Saya keliru. [[msvc::musttail]] ternyata memang atribut yang terdokumentasi resmi
    Saya akan memperbarui tulisan blog untuk mencerminkan hal itu
    Komentar HN terkait
  • Mengajukan pertanyaan, “Apakah mereka memberi tahu karena ini penting, atau karena menguntungkan bagi mereka?”
• Mengingat kasus saat Python 3.14 dulu, ketika bug LLVM 19 menyebabkan peningkatan performa yang keliru dilaporkan, dan berharap kali ini tidak ada masalah seperti itu
  Setelah membaca tulisannya, menilai pendekatan yang mengutamakan transparansi dan umpan balik cepat ini cukup baik
  Akan lebih baik lagi jika ada verifikasi lintas-kompiler atau audit independen, tetapi berkat transparansi penuh dari penulisnya, ini terasa dapat dipercaya
  • Penulis mengatakan kesalahan saat itu justru merupakan kecelakaan yang beruntung
    Karena dipublikasikan lebih awal, Nelson menemukan bug Clang 19, sehingga bisa diperbaiki sebelum rilis resmi
    Kali ini ada dua peningkatan, yaitu logika dispatch dan inlining, jadi ia lebih percaya diri
    MSVC bisa mengubah interpreter switch-case menjadi threaded code dalam kondisi tertentu, tetapi CPython terlalu kompleks sehingga optimisasi itu tidak diterapkan
    Sebaliknya, pendekatan tail call memberi penulis kode C lebih banyak kendali
    Referensi terkait: syarat threaded code di MSVC, isu terkait forceinline
  • Kelebihan desain baru ini adalah lebih sedikit bergantung pada perubahan perilaku optimisasi kompiler
    Dulu optimisasi seperti tail duplication bisa berbeda tergantung penilaian kompiler, tetapi sekarang interpreter bisa langsung mengekspresikan bentuk machine code yang diinginkan
    Tautan diskusi sebelumnya
• Menyebut ada presentasi yang membahas masalah kompiler di masa lalu, lalu membagikan video presentasi EuroPython 2025
• Sedang membuat aplikasi GUI untuk Windows dengan Python setelah sekian lama
  Memilih Python karena ekosistem VS terlalu berat dibanding C#/MAUI
  Tkinter terasa merepotkan, Qt punya beban belajar yang besar, jadi menggunakan kombinasi wxGlade + wxPython
  Hanya butuh satu dependensi yang bisa dipasang via pip, dan menyukai rasa penggunaan yang Pythonic
  Peningkatan runtime Windows ini disambut baik
  • Saya lebih suka kombinasi Python + Qt/PySide
    Membuat UI cepat dengan QtCreator lalu menempelkan logika dengan Python membuat kecepatan pengembangan sangat tinggi
  • Juga merekomendasikan pyfltk. Di GNU/Linux ini cukup bagus
  • Jika GUI penting, LINQPad juga layak dipertimbangkan. Ia berada di titik tengah antara scripting dan pekerjaan yang lebih berat
  • Merekomendasikan binding ImGui untuk Python
    Tidak seperti Tkinter atau Qt yang memakai retained mode, ini memakai pendekatan immediate mode, sehingga sangat berguna terutama untuk tooling internal
    Proyek imgui_bundle
• Mengajukan pertanyaan, “Bukankah ini seharusnya tugas optimisasi dengan tingkat kesulitan rendah?” dan heran mengapa loop interpreter masih belum sepenuhnya dioptimalkan
  Ia mengatakan sempat mengira ini pasti sudah ditulis dalam assembly untuk ISA utama
  • Justru pembaruan kali ini menunjukkan bahwa loop tersebut sudah dioptimalkan secara ekstrem
    [[msvc::musttail]] adalah atribut baru yang ditambahkan di MSVC 14.50 (dirilis bulan lalu), dan tim CPython berhasil memakainya untuk meningkatkan performa hanya dalam beberapa minggu
    Dokumentasi MSVC musttail
  • Sejak awal Python memang menargetkan kesederhanaan, bukan kecepatan
    Guido memprioritaskan kesederhanaan kode, sehingga adopsi JIT terlambat, lalu muncul upaya seperti PEP 744 (JIT Compilation)
  • Jangan menaruh harapan berlebihan pada open source
    Optimisasi assembly adalah mimpi buruk dalam pemeliharaan, dan bottleneck Python yang sebenarnya adalah sistem packaging
  • Toh orang yang sensitif terhadap performa tidak menjalankan Python di Windows
• Mengajukan pertanyaan, “Mengapa interpreter Python jauh lebih lambat daripada V8?”
  • JavaScript menggunakan kompilasi JIT, sedangkan CPython tidak
    PyPy cepat berkat JIT, tetapi tidak kompatibel dengan ekstensi C
    Model threading Python juga membuat optimisasi lebih sulit
    Sebaliknya, JS sederhana karena single-threaded
    Python bisa mengakali banyak hal lewat ekstensi C, sehingga tekanan untuk mengoptimalkan CPython sendiri lebih kecil
  • Menilai bahwa tenaga dan kualitas SDM Google membuat perbedaan besar
    Selain itu, CPython tidak bisa merusak kompatibilitas karena memiliki ekosistem ekstensi C yang sangat besar
    Sebaliknya, V8 bisa bebas mengubah struktur internalnya
  • Python jauh lebih dinamis, sampai-sampai akses properti pun melewati protokol descriptor
    Selain itu, karena harus mempertahankan ABI C yang stabil, JIT sulit menganalisis kode dengan bebas
  • Python adalah bahasa yang jauh lebih dinamis daripada JS, dan perubahan internalnya dibatasi oleh binding FFI
    Disebut juga kasus PyPy yang kesulitan menyesuaikan diri dengan batasan-batasan itu
  • JS dioptimalkan dengan sumber daya besar-besaran yang dikucurkan Google demi mendominasi web, sedangkan Python lebih banyak mengalokasikan sumber daya untuk perkembangan bahasa
    Selain itu, JS cukup mendukung JS murni, sementara Python harus mempertahankan ekosistem ekstensi eksternal sehingga optimisasinya lebih terbatas
• Menyebut grafik benchmark yang baru itu menarik dan bertanya alat apa yang dipakai untuk membuatnya
  Ia berbagi bahwa dirinya pernah mengukur performa pustaka JS dengan mitata
  PR optimisasi Immer JS
  • Grafik itu adalah violin plot
    Penjelasan Wikipedia, contoh Matplotlib
    Plot ini memvisualisasikan distribusi secara simetris, tetapi ada kritik bahwa smoothing dapat mendistorsi distribusi nyata dan juga boros ruang
    Dalam diskusi HN, ada juga pendapat bahwa half-violin plot lebih baik
    Contoh gambar
• Menyampaikan bahwa Matt Godbolt pernah menyebut interpreter berbasis tail-call lebih cocok dengan branch predictor CPU
• Ada komentar yang bertanya apakah dua typo pada kalimat pertama tulisan itu adalah kesalahan yang disengaja agar terlihat seperti tulisan AI
  • Penulis menjawab, “Terima kasih, sudah diperbaiki”
  • Pengguna lain bercanda memberi saran, “Kalau tidak ingin terlihat seperti AI, ya tulis sendiri saja”
    Ia menyindir ciri khas tulisan AI (paragraf pendek, nada terlalu positif, kurang mendalam, dan sebagainya)
• Mengajukan pertanyaan, “Jika tim Python menganggap tail call berguna, apakah bahasanya sendiri nantinya juga akan mendapat dukungan tail call?”