CPython'ın deneysel JIT'i ana daldan çıkıyor: PEP 836 geri çekildi

JIT ne işe yarıyordu?

Python kodun normalde bir yorumlayıcı (interpreter) tarafından adım adım çalıştırılır. JIT (just-in-time) derleyici ise sık çalışan kod parçalarını program çalışırken makine koduna çevirir, böylece aynı döngü her seferinde baştan yorumlanmaz. JavaScript motorları ve PyPy bu yüzden hızlıdır.

CPython’ın JIT’i Python 3.13’te deneysel olarak geldi. Copy-and-patch denen bir yöntem kullanıyor: Yorumlayıcının küçük adımları için hazır makine kodu kalıpları (“stencil”) derleme sırasında LLVM ile üretiliyor, çalışma anında bu kalıplar kopyalanıp boşlukları dolduruluyor. Bu yaklaşımı anlatan PEP 744 yalnızca bilgilendirme amaçlı (Informational) bir belgeydi. Yani JIT’in kalıcı ve desteklenen bir özellik olup olmayacağı hiçbir zaman resmî olarak karara bağlanmadı.

Steering Council’ın şartı

Python’un yönetim kurulu sayılan Steering Council, 5 Haziran 2026’da JIT için ana dalda yeni geliştirmeyi durdurdu. Hata ve güvenlik düzeltmelerine izin vardı. Kurul, bu ölçekte bir değişiklik için süreci yeterince sıkı uygulamadığını kendisi de kabul etti ve ekibin kasıtlı olarak süreci atladığını düşünmediğini söyledi. Ama soru açıktı: JIT’in bakımını uzun vadede kim yapacak, hata ayıklayıcı ve profiler’larla nasıl çalışacak, Python’u paketleyen dağıtımlara ne yük getirecek, başarı neyle ölçülecek?

İstenen şey bir Standards Track PEP’ti, yani topluluğun tartışıp kurulun kabul ya da reddedebileceği bağlayıcı bir öneri. Süre yaklaşık altı ay. Kabul edilen bir PEP çıkmazsa JIT kodu ana daldan çıkarılacak, çalışma Python deposunun dışında sürecekti.

PEP 836 ne öneriyordu?

Savannah Ostrowski, Ken Jin ve Brandt Bucher Temmuz’da PEP 836’yı (“JIT Go Brrr”) yazdı. JIT’i hemen “desteklenen” ilan etmiyor, iki buçuk yıllık bir yol haritası öneriyordu:

• 3.16 betaya kadar: İz kaydeden (tracing) ön ucu fonksiyon tabanlı derlemeye çevirmek, JIT’i GIL’siz (free-threaded) Python’la uyumlu yapmak, tek bir LLVM sürümüne bağımlılığı azaltmak.
• 3.17 betaya kadar: Free-threaded yapıda pyperformance testlerinde en az %20 hızlanma.
• 3.17 RC’ye kadar: Popüler PyPI paketleriyle uyumluluk testleri.

PEP’e göre 3.15’te JIT, platforma bağlı olarak yorumlayıcıdan yaklaşık %4 ile %12 daha hızlı. Ölçülebilir ama büyük bir fark değil.

Neden geri çekildi?

InfoWorld’ün aktardığına göre kurul, PEP’te JIT’in nasıl destekleneceği, performansın nasıl değerlendirileceği ve hata ayıklama/profil araçlarıyla nasıl bütünleşeceği konusunda yeterli ayrıntı görmedi, hız beklentilerini de fazla iyimser buldu. Ostrowski 19 Ekim’de PEP’i geri çektiklerini duyurdu: Kurulun haklı olarak yüksek bir çıta koyduğunu, ama mevcut hâliyle bu öneriyi taşıyacak kişisel zamanlarının olmadığını yazdı. Teknik yöne hâlâ inandıklarını, referans uygulamayı da başkaları üzerine kurabilsin diye paylaşacaklarını ekledi.

Şimdi ne olacak?

LWN’e göre JIT büyük olasılıkla yakında ana daldan çıkarılacak, böylece kaldırmanın doğuracağı sorunlar 3.16 geliştirme döneminin başında çözülebilecek. Kurul 3.15 için mevcut durumla sorun olmadığını daha Haziran’da söylemişti. Yani 3.13, 3.14 ve 3.15’teki deneysel JIT olduğu yerde kalıyor. JIT fikri de ölmüş değil: Çalışma ayrı bir derlemede ya da çatallanmış bir depoda sürebilir, ama geri dönmek için aynı çıtayı aşması gerekecek.

Python’un yeni özellikleri hep bu PEP sürecinden geçiyor. Python 3.15’teki tembel import yazımızda aynı sürecin kabulle biten bir örneğini anlattık.

Düşün

• Bir özelliğin kodu çalışıyor ve hız kazandırıyorsa, neden yine de yazılı bir bakım planı ve başarı ölçütü istenir?
• %5-10’luk bir hız kazancı, hata ayıklayıcılarla uyumsuzluk ve paketlemeyi zorlaştıran bir derleme bağımlılığı karşısında ne kadar değerli?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.