Python 3.15'in Windows x86-64 yorumlayıcısının yaklaşık %15 daha hızlı olması bekleniyor

• CPython'ın tail-calling yorumlayıcısı, Windows x86-64 ortamında mevcut yönteme göre yaklaşık %15 daha hızlı performans gösteriyor
• macOS AArch64 (XCode Clang) üzerinde de yaklaşık %5'lik bir performans artışı doğrulandı; Windows tarafında ise MSVC 2026'nın deneysel özelliği kullanılıyor
• pyperformance benchmark'larında testlerin çoğunda hız artışı görüldü ve bazıları en fazla %78'e kadar iyileşti
• Performans artışının ana nedeninin derleyici optimizasyon sezgisellerinin sıfırlanması ve inlining iyileştirmeleri olduğu düşünülüyor
• Python 3.15'in resmi sürümünde, Visual Studio 2026 tabanlı derlemelerde varsayılan olarak uygulanması planlanıyor

---

Tail-calling yorumlayıcısında performans iyileşmesi

• CPython'ın tail-calling yorumlayıcısının, mevcut switch-case yorumlayıcısından Windows x86-64 üzerinde yaklaşık %15 daha hızlı olduğu ölçüldü
  • pyperformance'a göre geometrik ortalamada %15~16 iyileşme
  • Bazı benchmark'larda en fazla %78 hız artışı görülürken, az sayıda durumda %60 yavaşlama görüldü
• macOS AArch64 (XCode Clang) üzerinde yaklaşık %5'lik performans artışı doğrulandı
• Bu sonuçlar, Python 3.15 geliştirme döngüsü sırasında değişiklik yapılmaması varsayımıyla geçerli

Yorumlayıcı yapılarının karşılaştırılması

• C tabanlı yorumlayıcı uygulama yöntemleri üçe ayrılıyor: switch-case, computed goto, tail-call threaded
  • switch-case: komut bazında dallanma işlemi
  • computed goto: GCC/Clang genişletmesiyle, dallanma adresine doğrudan atlama
  • tail-call threaded: her bytecode işleyicisini ayrı bir fonksiyona bölüp bir sonrakine tail call yapmak
• Geçmişte C derleyicileri tail call optimizasyonunu garanti etmediği için stack overflow riski vardı
• Clang'ın __attribute__((musttail)) ve MSVC'nin [[msvc::musttail]] niteliği sayesinde zorunlu tail call mümkün hale geldi

Windows için MSVC 2026 derleme sonuçları

• MSVC'nin deneysel özelliğiyle derlenen CPython'da benchmark'ların çoğunda hız artışı görüldü
  • Örnek sonuçlar:
    • spectralnorm: 1.48 kat
    • nbody: 1.35 kat
    • bm_django_template: 1.18 kat
    • xdsl: 1.14 kat
• Python 3.15'in “What’s New” belgesine resmi olarak yansıdı
  • Visual Studio 2026 (MSVC 18) derlemelerinde tail-calling yorumlayıcısı kullanılabilecek
  • Saf Python kütüphanelerinde yaklaşık %15, küçük script'lerde ise en fazla %40 hız artışı

Performans artışının nedenleri

• Tail calling, derleyicinin optimizasyon sezgisellerini sıfırlayarak daha verimli kod üretimini teşvik ediyor
• Mevcut CPython yorumlayıcı döngüsü yaklaşık 12.000 satırlık tek bir fonksiyondan oluşuyor ve bu da inlining optimizasyonunun sık sık başarısız olmasına yol açıyor
  • Derleyici, kod boyutunun büyümesini önlemek için birçok durumda inlining'i reddediyor
• Tail-calling yaklaşımında fonksiyonlar ayrıldığı için basit fonksiyonlar inline işlenebiliyor
  • Örneğin PyStackRef_CLOSE_SPECIALIZED gibi basit bir fonksiyon inline edilebiliyor
• PGO (profil tabanlı optimizasyon) derlemelerinde de aynı durum raporlandı

Derleme ve kullanım yöntemi

• Şu anda yalnızca kaynak koddan derleme mümkün
  • Visual Studio 2026 ortamında şu komutla derlenebiliyor

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

• Python 3.15 geliştirmesi istikrara kavuştuğunda resmi ikili dağıtım yapılması planlanıyor

[GN⁺]

Hacker News yorumları

• Blog yazısında yer alması iyi olurdu denilen temel kod parçasını paylaşıyor
  MSVC ile Clang’ın musttail ve preserve_none öznitelik tanımlarındaki farkı gösteren bir örnek
  Bu özniteliklerin fonksiyon bildirimine eklenmesi gerekiyor; fonksiyon belirteci konumunda çalışmıyorlar
  İlgili kod bağlantısı
  Microsoft’un bu tür resmî olmayan özellikleri yalnızca önemli gördüğü projelere bildirdiği izlenimini veriyor
  • Benim hatamış. [[msvc::musttail]] aslında resmî olarak belgelenmiş bir öznitelikmiş
    Blog yazısını buna göre düzelteceğim
    İlgili HN yorumu
  • “Bunu önemli olduğu için mi söylediler, yoksa işlerine geldiği için mi söylediler?” diye soruyor
• Python 3.14 döneminde LLVM 19 hatası yüzünden yanlış performans artışı raporlanan olayı hatırlatıp, bu kez öyle bir sorun olmamasını umuyor
  Yazıyı okuyunca, şeffaflık ve hızlı geri bildirimi önceleyen yaklaşımın makul olduğuna karar vermiş
  Çapraz derleyici doğrulaması ya da bağımsız denetim olsa daha da iyi olurdu ama yazarın tam şeffaflığı sayesinde buna güvenebildiğini söylüyor
  • Yazının yazarı, o zamanki hatanın aslında şanslı bir kaza olduğunu hatırlatıyor
    Erken paylaşıldığı için Nelson Clang 19 hatasını bulabildi ve böylece resmî sürümden önce düzeltilebildi
    Bu kez hem dispatch mantığı hem de inlining tarafında iki iyileştirme olduğu için daha emin
    MSVC bazı koşullarda switch-case yorumlayıcısını threaded code’a dönüştürebiliyor ama CPython fazla karmaşık olduğu için bu optimizasyon uygulanmıyor
    Bunun yerine tail call yaklaşımı, C kodunu yazan kişiye daha fazla denetim sağlıyor
    İlgili başvurular: MSVC threaded code koşulları, forceinline ile ilgili sorun
  • Yeni tasarımın avantajı, derleyici optimizasyonlarının keyfiliğine daha az bağımlı olması
    Geçmişte tail duplication gibi optimizasyonlar derleyicinin kararına göre değişirdi; artık yorumlayıcı istediği makine kodu biçimini doğrudan ifade edebiliyor
    Önceki tartışma bağlantısı
• Geçmiş derleyici sorunlarını ele alan bir sunum olduğunu söyleyip EuroPython 2025 sunum videosunu paylaşıyor
• Uzun bir aradan sonra Windows için Python’la GUI uygulaması yaptığını söylüyor
  C#/MAUI yerine VS ekosistemi fazla ağır olduğu için Python’u seçmiş
  Tkinter’ı kullanışsız bulmuş, Qt’nin de öğrenme yükü yüksek geldiğini söyleyerek wxGlade + wxPython ikilisini kullandığını belirtiyor
  Yalnızca pip ile kurulabilen tek bir bağımlılık gerektiğini ve Pythonic kullanım hissini sevdiğini ekliyor
  Windows çalışma zamanı iyileştirmesini memnuniyetle karşılıyor
  • Ben Python + Qt/PySide ikilisini tercih ediyorum
    QtCreator ile arayüzü hızlıca hazırlayıp Python’la mantığı ekleyince geliştirme çok hızlanıyor
  • pyfltk de öneriliyor. GNU/Linux üzerinde oldukça iyiymiş
  • GUI önemliyse LINQPad de düşünülebilir. Betik yazımı ile ağır işler arasında bir orta nokta gibi
  • Python için ImGui binding’leri öneriliyor
    Tkinter veya Qt gibi retained mode değil, immediate mode yaklaşımı kullandığı için özellikle iç araçlarda çok faydalı
    imgui_bundle projesi
• “Bu artık düşük zorluklu bir optimizasyon işi sayılmaz mı?” diyerek, yorumlayıcı döngüsünün neden hâlâ tamamen optimize edilmediğini sorguluyor
  Başlıca ISA’lar için assembly ile yazılmış olmasını beklediğini söylüyor
  • Tam tersine, bu güncellemenin döngünün zaten aşırı derecede optimize edilmiş olduğunu gösterdiğini düşünüyor
    [[msvc::musttail]], MSVC 14.50’ye geçen ay eklenmiş yeni bir öznitelik ve CPython ekibi bunu birkaç hafta içinde kullanarak performans artışı sağlamış
    MSVC musttail belgesi
  • Python’un baştan beri hızdan çok sadeliği hedeflediği söyleniyor
    Guido kod sadeliğini öncelediği için JIT’in gelişi gecikti; daha sonra PEP 744 (JIT Compilation) gibi girişimler ortaya çıktı
  • Açık kaynaktan aşırı beklentiye girilmemesi gerektiği söyleniyor
    Assembly optimizasyonu bakım kabusudur ve Python’daki asıl darboğazın paketleme sistemi olduğu ekleniyor
  • Zaten performansa duyarlı kişilerin Windows üzerinde Python çalıştırmadığı söyleniyor
• “Python yorumlayıcısı neden V8’den çok daha yavaş?” sorusu soruluyor
  • JavaScript JIT derleme kullanıyor ama CPython kullanmıyor
    PyPy JIT sayesinde hızlı fakat C eklentileriyle uyumlu değil
    Python’un threading modeli de optimizasyonu zorlaştırıyor
    Buna karşılık JS tek iş parçacıklı olduğu için daha basit
    Python, C eklentileriyle darboğazları aşabildiğinden CPython’un kendisini optimize etme baskısı daha düşük kalmış
  • Google’ın insan kaynağı ve kalite seviyesinin büyük fark yarattığı düşünülüyor
    Ayrıca CPython, devasa C eklenti ekosistemi yüzünden uyumluluğu bozamıyor
    V8 ise iç yapısını daha serbest biçimde değiştirebildi
  • Python’da özellik erişimi bile descriptor protokolünden geçtiği için çok daha dinamik
    Ayrıca kararlı bir C ABI korunmak zorunda olduğundan, JIT’in kodu özgürce analiz etmesi zorlaşıyor
  • Python’un JS’den çok daha dinamik bir dil olduğu ve FFI binding’leri nedeniyle iç değişikliklerin kısıtlandığı söyleniyor
    PyPy’nin bu kısıtlarla başa çıkarken yaşadığı zorluk örnek gösteriliyor
  • JS’nin, Google’ın web’e hâkim olmak için muazzam kaynak ayırmasıyla optimize edildiği; Python’un ise daha çok dilin gelişimine kaynak ayırdığı söyleniyor
    Ayrıca JS yalnızca saf JS’yi desteklese yeterliyken, Python dış eklenti ekosistemini de korumak zorunda olduğundan optimizasyon alanı daha dar
• Yeni benchmark grafiğinin ilginç olduğunu söyleyip hangi araçla üretildiğini soruyor
  Kendisinin mitata ile JS kütüphane performansı ölçtüğünü de paylaşıyor
  Immer JS optimizasyon PR’ı
  • O grafik bir violin plot
    Wikipedia açıklaması, Matplotlib örneği
    Dağılımı simetrik biçimde görselleştiriyor ama yumuşatma gerçek dağılımı çarpıtabilir; ayrıca alan israfı olduğu yönünde eleştiriler de var
    HN tartışmasında half-violin plot’un daha iyi olduğu da savunulmuş
    Örnek görsel
• Matt Godbolt’ın, tail-call tabanlı yorumlayıcının CPU’nun branch predictor’ına daha iyi uyduğunu söylediği aktarılıyor
• Yazının ilk cümlesinde iki yazım hatası olduğu ve bunun acaba AI üretimi gibi görünmesi için bilinçli bırakılmış hatalar olup olmadığı soruluyor
  • Yazar “Teşekkürler, düzelttim” diye yanıt veriyor
  • Başka bir kullanıcı da, “AI gibi görünmemek için sadece kendin yazman yeterli” diye şaka yollu bir tavsiye veriyor
    AI yazılarının tipik özellikleriyle (kısa paragraflar, aşırı olumlu ton, derinlik eksikliği vb.) dalga geçiyor
• “Python ekibi tail call’ı faydalı buluyorsa, acaba dilin kendisinde de tail call desteği gelir mi?” diye soruyor