· kaynak dev.to (home feed)
Python 3.15 sürüm adayı, CPython'un deneysel JIT'ini tracing ve register allocation ile yükseltiyor
Python 3.15.0rc1, CPython'un deneysel JIT derleyicisini yeni tracing, register allocation ve daha yalın referans sayımıyla birlikte önemli ölçüde geliştirmiş halde sunuyor; bir yandan da PEP 836 projenin uzun vadeli yolunu tartışıyor.

Sürüm adayı daha yetenekli bir JIT ile geliyor
4 Ağustos 2026'da yayımlanan Python 3.15.0rc1, deneysel tam zamanında (JIT) derleyicisinin gözle görülür bir ilerleme kaydettiği bir CPython sürümünün ilk sürüm adayı. dev.to'da aktarıldığına göre JIT, Python 3.13'ten beri deneysel biçimde CPython'un parçası; ancak 3.15'in önemi yalnızca bir JIT'in var olmasında değil, çalışan kodu gözlemleme ve optimize etme mekanizmasının önemli ölçüde gelişmiş olmasında yatıyor. Nihai sürümün Ekim'de çıkması bekleniyor.
Yeni bir tracing ön ucu
Öne çıkan iç değişiklik, baştan yazılmış bir tracing ön ucu. dev.to'nun açıkladığı gibi yeni ön uç, bir programın gerçekte izlediği yürütme yollarını kaydediyor ve derleyiciye hangi işlemlerin ve dallanmaların önemli olduğu konusunda somut kanıt sunuyor. Önceki sürümler, çalıştırılan kod hakkında çok daha az bilgiyle işleyordu. Tracing çalışmasının kendisi başlı başına bir performans kazancı değil; üzerinde inşa edilen optimizasyonları daha etkili kılan bir zemin niteliğinde.
Daha sıkı üretilmiş kod
Bu temelin üzerinde üç optimizasyon yer alıyor:
- Register allocation. JIT tarafından üretilen kod daha önce birçok ara değeri işlemler arasında bellek üzerinden taşıyordu. Python 3.15 artık seçili değerleri birkaç işlem boyunca CPU register'larında tutabiliyor ve bellek trafiğini azaltıyor — bu değişiklik en çok tekrarlayan aritmetik ve benzeri sıkı döngüler içeren kodda işe yarıyor.
- Daha yalın referans sayımı. Referans sayımı CPython'un bellek yönetiminin merkezinde, ancak ciddi bir CPU yükü getiriyor. Yeni JIT, gereksiz olduklarını kanıtlayabildiği referans sayımı işlemlerini ortadan kaldırabiliyor; böylece derlenen kod, nesne ömrü muhasebesini sürdürmeye daha az, asıl işe daha fazla zaman harcıyor.
- Yerinde sayısal işlemler. Bazı int ve float işlemlerinde, derleyici bir nesnenin başka hiçbir yerde referanslanmadığını belirleyebildiğinde, her sonuç için yeni bir nesne ayırmak yerine o nesneyi yeniden kullanabiliyor. Bu doğrudan aynı değerleri tekrar tekrar güncelleyen sayısal döngülere yönelik.
Benchmark'lar ne gösteriyor
dev.to'daki yazıya göre güncel pyperformance sonuçları, x86-64 Linux'ta yaklaşık %8-9, AArch64 macOS'ta ise yaklaşık %12-13 geometrik ortalama iyileşmeye işaret ediyor; her iki durumda da karşılaştırma, ilgili JIT'siz interpreter yapılandırmasıyla yapılıyor. Yazar bu rakamları bir ilerleme göstergesi olarak sunmakta özen gösteriyor; her Python programının yaklaşık onda bir daha hızlı hale geleceği şeklinde bir taahhüt değil bunlar — gerçek etki büyük ölçüde iş yüküne bağlı.
Deneysel durum ve PEP 836 sorusu
JIT, 3.15'te hâlâ varsayılan olarak devre dışı. Üretim sistemlerinin test etmeden açması gereken bir şey olarak değil, deneme ve benchmark amaçlı konumlandırılmış durumda ve arayüzlerinin bir kısmı açıkça kararsız (unstable) olarak işaretlenmiş; hâlâ evrilmekte olan bir uygulamanın yansıması bu.
Yönetişim tarafı da aynı belirsizlik içinde. 8 Haziran 2026'da Python Steering Council, CPython'un ana dalındaki yeni JIT geliştirmesini duraklattı ve geliştiricilerden projenin geleceğine dair resmî bir plan istedi. Bu plan PEP 836 oldu: "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython" — ölçülebilir performans hedefleri içeren, çok sürümlük bir yol haritası ortaya koyuyor; bunlar arasında Python 3.17'ye kadar JIT ile free-threading birleşiminin pyperformance setinde önerilen %20 geometrik ortalama iyileşme de var. Ağustos 2026 itibarıyla PEP 836 hâlâ kesinleşmiş bir politika değil tartışma aşamasındaydı; bu da CPython'u alışılmadık bir konuma sokuyor: uygulama ilk sürümlerinden çok daha yetenekli, ancak interpreter'daki uzun vadeli yeri hâlâ karara bağlanmamış durumda.
Neden önemli
CPython'un önümüzdeki birkaç yıldaki performans seyri bu deneyimin nasıl sonuçlanacağına bağlı olabilir. 3.15 sürüm adayı, JIT'in geleneksel derleyici teknikleri — tracing, register allocation, ölü referans sayımı elemesi ve nesne yeniden kullanımı — yoluyla ölçülebilir, benchmark'lanabilir kazanımlar sunabildiğini gösteriyor; ancak bu kazanımlar hâlа opsiyonel ve ortalama olarak mütevazı. PEP 836, topluluğu başarının neye benzediğini, belirli sürümlere bağlı somut hedeflerle tanımlamaya zorluyor; ana dalda açık uçlu geliştirmeyi sürdürmek yerine. Kütüphane yazarları ve performansa duyarlı kullanıcılar için Python 3.15, Python'ın bir JIT edindiği an olarak değil, bir JIT'in CPython'un yürütme modelinin güvenilir ve desteklenen bir parçası olup olamayacağının canlı bir testi olarak izlenmeye değer.
- #python
- #cpython
- #jit-compiler
- #performance
- #programming-languages