CPython 3.15’in JIT’i yeniden rayına oturdu

(blog.python.org)

15 puan yazan darjeeling 2026-03-29 | Henüz yorum yok. | WhatsApp'ta paylaş

Temel sonuçlar

Platform	JIT performans artışı (tail-calling interpreter’a kıyasla)
macOS AArch64	+11~12%
x86_64 Linux	+5~6%

Benchmark aralığı: %20 daha yavaş olan durumlardan %100’den fazla daha hızlı olan durumlara kadar değişiyor (unpack_sequence mikrobenchmark’ı hariç)

Hedefe ulaşıldı: 3.15 hedefi (%5 iyileşme), 1 yıldan daha erken gerçekleştirildi
Free-threading desteği: Henüz tamamlanmadı; 3.15/3.16 için çalışmalar sürüyor

Ana dersler

Sponsorun ayrılması = kriz → topluluk öncülüğünde dönüşüm
Faster CPython ekibinin ana sponsoru 2025’te çekilmiş olsa da, topluluğun gönüllü katkıları sayesinde katkı verenlerin sayısı arttı ve sonuç alındı.
Karmaşık problemleri küçük parçalara bölün
JIT gibi giriş bariyeri yüksek bir projede bile, işi küçük görevlere ayırmak ve net rehberler sunmak sayesinde C programcılığı geçmişi olan ama uzman olmayan kişiler de katkı verebildi.
Bus factor’ı azaltmak sağlıklı bir projenin göstergesidir
Orta katmandaki (optimizer) katkı verenlerin sayısı 2’den 4’e çıktı ve core olmayan geliştiriciler de temel katkı sahiplerine dönüştü.
Ölçüm altyapısı geliştirme hızını değiştirir
Her gün JIT performansını raporlayan sistem (doesjitgobrrr.com), regression’ları erken tespit etmekte ve motivasyon sağlamada belirleyici oldu.
Topluluklar arası etkileşim teknik yetkinliği artırır
PyPy ekibiyle etkileşim ve derleyici geliştiricileriyle yapılan gayriresmî sohbetler, somut teknik ilerlemelere dönüştü.

Arka plan ve sonuçlar

[IMG] JIT performans grafiği (17 Mart 2026 itibarıyla, daha düşük değer yorumlayıcıdan daha hızlı anlamına gelir)
(17 Mart 2026 itibarıyla JIT performansı. Daha düşük değer, yorumlayıcıya kıyasla daha hızlı anlamına gelir. Görsel kaynağı: doesjitgobrrr.com)

İyi haberler var. macOS AArch64 üzerinde hedeflenen tarihten 1 yıldan fazla önce, x86_64 Linux üzerinde ise birkaç ay önce CPython JIT’in (oldukça mütevazı) performans hedeflerine ulaşıldı. 3.15 alpha JIT, macOS AArch64 üzerinde tail-calling interpreter’dan yaklaşık %11~12 daha hızlı, x86_64 Linux üzerinde ise standart yorumlayıcıdan %5~6 daha hızlı. Bu rakamlar geometrik ortalamadır ve geçicidir. Gerçek aralık, %20 daha yavaş olan durumlardan %100’den fazla daha hızlı olan durumlara kadar değişiyor (unpack_sequence mikrobenchmark’ı hariç). Henüz düzgün bir free-threading desteği yok, ancak bunun 3.15/3.16’da hedeflenmesi planlanıyor. JIT artık yeniden rayına oturdu.

Bunun ne kadar zor olduğunu abartmak mümkün değil. Bir noktada JIT projesinin gerçekten anlamlı bir hız artışı sağlayıp sağlayamayacağı ciddi biçimde sorgulanıyordu. Geriye dönüp bakınca, CPython JIT’in ilk hali fiilen hiç hız kazancı sağlamıyordu. 8 ay önce, 3.13 ve 3.14’teki ilk CPython JIT’in çoğu zaman yorumlayıcıdan daha yavaş olduğunu anlatan bir JIT değerlendirme yazısı yayımlamıştım. O sırada Faster CPython ekibi de ana sponsorunun desteğini kaybetmişti. Ben gönüllü olduğum için doğrudan etkilenmedim, ancak orada çalışan ekip arkadaşlarım etkilendi ve bir süre JIT’in geleceği belirsiz görünüyordu.

Peki 3.13 ve 3.14’e kıyasla ne değişti? Kendi zekâmızla JIT’i başarısızlık eşiğinden kurtardığımıza dair kahramanlık hikâyeleri anlatmayacağım. Dürüst olmak gerekirse, bugünkü başarının büyük kısmının şans sayesinde olduğunu düşünüyorum. Doğru zaman, doğru yer, doğru insanlar, doğru seçimler. Savannah Ostrowski, Mark Shannon, Diego Russo, Brandt Bucher ve benim aramızdan tek bir kişi bile eksik olsaydı bunun mümkün olmayacağını ciddiyetle düşünüyorum. Diğer aktif JIT katkı sahiplerini de atlamamak için birkaç kişiyi daha anmak isterim: Hai Zhu, Zheaoli, Tomas Roun, Reiden Ong, Donghee Na ve muhtemelen unuttuklarım da vardır.

Burada JIT hakkında pek konuşulmayan bir unsurdan, yani insanlardan ve biraz da şanstan söz etmek istiyorum. Teknik ayrıntılarla ilgileniyorsanız buraya bakabilirsiniz.

Bölüm 1: Topluluk öncülüğünde JIT

Faster CPython ekibi 2025’te ana sponsorunu kaybetti. Ben de hemen topluluk öncülüğünde yönetim fikrini önerdim. O sırada bunun işe yarayıp yaramayacağı oldukça belirsizdi. JIT projesi, yeni katkı verenler için pek uygun olmayan bir proje olarak biliniyor. Tarihsel olarak çok fazla ön bilgi gerektiriyordu.

Cambridge’de düzenlenen CPython core sprint sırasında JIT core ekibi bir araya gelip, 3.15’e kadar %5 daha hızlı JIT, 3.16’ya kadar %10 daha hızlı JIT ve free-threading desteği için bir plan hazırladı. Daha az dikkat çekse de proje sağlığı açısından kritik başka bir hedef daha vardı: bus factor’ı azaltmak. JIT’in üç aşamasının her birinde (frontend’de region selector, middle-end’de optimizer, backend’de code generator) 2’den fazla aktif bakımcı istiyorduk.

Daha önce JIT middle-end’de yalnızca 2 aktif düzenli katkı sahibi vardı. Bugün JIT middle-end’de 4 aktif düzenli katkı sahibi bulunuyor ve core olmayan 2 geliştirici (Hai Zhu ve Reiden) yetkin ve değerli üyelere dönüştü.

İnsanları projeye çekmede etkili olan şey, genel yazılım mühendisliği pratiğiydi: karmaşık problemleri yönetilebilir parçalara ayırmak. Brandt, buna ilk olarak 3.14’te başladı ve JIT optimizasyonlarını basit görevlere bölen çeşitli mega issue’lar açtı. Örneğin “JIT içinde tek bir komutu optimize edin” gibi işler vardı. Ben de Brandt’ın fikrini devralıp 3.15’te uyguladım. Neyse ki bana daha kolay işler düştü; yorumlayıcı komutlarını kolay optimize edilebilir biçimlere dönüştürmeye yönelik issue’lar gibi. Yeni katkı verenleri teşvik etmek için, çok ayrıntılı talimatları hemen uygulanabilecek şekilde düzenledim. Ayrıca iş birimlerini net biçimde ayırdım. Bunun faydalı olduğu anlaşılıyor. Benim de dahil olduğum 11 katkı sahibi bu issue üzerinde çalışarak neredeyse tüm yorumlayıcıyı JIT optimizer dostu bir forma dönüştürdü. Temel nokta, JIT’i opak bir yığından çıkarıp JIT deneyimi olmayan C programcılarının da katkı verebileceği bir şeye dönüştürmekti.

Etkili olan diğer yöntemler de şunlardı: insanları teşvik etmek ve büyük küçük tüm başarıları kutlamak. Her JIT PR’ının net bir çıktısı vardı ve bunun insanlara yön hissi verdiğini düşünüyorum.

Topluluk optimizasyon çabası sonuç verdi. JIT, x86_64 Linux üzerinde %1 daha hızlı olmaktan %3~4 daha hızlı olmaya ilerledi (aşağıdaki mavi çizgiye bakın):

[IMG] Topluluk optimizasyon dönemi boyunca JIT performansı vs yorumlayıcı
(Görsel kaynağı: doesjitgobrrr.com)

Bölüm 2: Şanslı seçimler

Trace Recording

Tekrar söylemek gerekirse, bunun büyük kısmının şans sayesinde olduğunu düşünüyorum. Cambridge’deki CPython core sprint sırasında Brandt beni JIT frontend’ini tracing yaklaşımıyla yeniden yazmaya ikna etti. İlk başta bundan hoşlanmamıştım, ama bir tür inatla “işe yaramadığını kanıtlamak için” yeniden yazmayı denemeye karar verdim.

İlk prototip 3 gün içinde çalıştı, ancak test paketini geçecek ve düzgün JIT yapacak hâle gelmesi bir ay sürdü. İlk sonuçlar berbattı. x86_64 Linux’ta yaklaşık %6 daha yavaştı. Tam vazgeçmek üzereyken şanslı bir kaza oldu: Mark’ın önerisini yanlış anlamıştım.

Mark, yorumlayıcıya dispatch table’ları thread ederek iki ayrı dispatch table’a sahip olmayı önermişti; biri normal yorumlayıcı için, diğeri tracing için. Ama ben bunu yanlış anlayıp daha uç bir sürümünü yaptım: normal komutların tracing sürümleri yerine, tracing’i yapan tek bir komut bıraktım ve ikinci tablodaki tüm komutların onu göstermesini sağladım. Bunun gerçekten çok iyi bir seçim olduğu ortaya çıktı. İlk çift tablo yaklaşımı yorumlayıcının boyutunu iki katına çıkarıyor, code bloat yaratıyor ve doğal olarak performansı düşürüyordu. Sadece tek bir komut ve iki tablo kullanarak yorumlayıcının boyutunu yalnızca bir komut kadar artırabildik ve temel yorumlayıcıyı çok hızlı tutabildik. Bu mekanizmaya sevgiyle dual dispatch diyorum.

Trace recording’in ne kadar önemli olduğunu gösteren rakam şu: JIT code coverage %50 arttı. Bu, gelecekteki tüm optimizasyonların (basitleştirerek söylersek) %50 daha az etkili olacağı anlamına gelirdi.

Brandt ve Mark’a, bu harika çözümü tesadüfen bulmamı sağlayacak şekilde yönlendirdikleri için teşekkürler.

Reference Count Elimination

Bir diğer şanslı seçim de reference count elimination’ı denemek oldu. Bu, aslında Matt Page’in CPython bytecode optimizer’ında yaptığı çalışmadan geliyordu. Bytecode optimizer üzerinde yapılan çalışmaya rağmen, her reference count decrement için JIT’lenmiş kodda hâlâ bir branch kaldığını fark ettim. “Bu branch’ı kaldırsak ne olur?” diye düşündüm ve bunun ne kadar faydalı olacağına dair hiçbir fikrim yoktu. Tek bir branch bile aslında oldukça maliyetliydi ve her Python komutunda 1 veya daha fazla branch varsa bunlar birikiyordu.

Bir başka şanslı nokta da bunun paralelleştirmesinin ne kadar kolay olduğu ve insanlara hem yorumlayıcıyı hem de JIT’i öğretmek için iyi bir araç hâline gelmesiydi. Python 3.15 JIT’te insanlara iş dağıtırken ana optimizasyon olarak bunu kullandık. Çoğu kısım elle yapılan refactoring süreciydi, ancak insanlara JIT’in temel bileşenlerini bunaltmadan öğrenme fırsatı verdi.

Bölüm 3: Harika bir ekip

Harika bir altyapı ekibimiz var. Aslında bu tek bir kişi. Daha doğrusu bizim “ekibimiz” şu anda Savannah’nın dolabında çalışan 4 makineden ibaret. Yine de Savannah, JIT için adeta tam bir altyapı ekibinin yapacağı işi yaptı. Performans sayılarını raporlamanın bir yolu olmasaydı JIT bu kadar hızlı ilerleyemezdi. Her gün alınan JIT çalıştırma sonuçları, geri bildirim döngüsünde oyunun kurallarını değiştirdi. JIT performansındaki regression’ları yakalamaya yardımcı oldu ve yaptığımız optimizasyonların gerçekten işe yaradığını doğrulamamızı sağladı.

Mark teknik açıdan olağanüstü biri. İnternetin zaten ona fazlasıyla övgü verdiğini düşündüğüm için daha fazla bir şey söylemeyeceğim :).

Diego da harika. ARM donanımı üzerindeki JIT’ten sorumlu ve son dönemde JIT’i profiler dostu hâle getirme işine başladı. Bunun ne kadar zor bir problem olduğunu abartmak mümkün değil.

Brandt, machine code backend’inin ilk temelini attı. Bu olmasaydı yeni katkı verenlerin assembler yazması gerekecekti ve bu da muhtemelen daha fazla kişiyi uzaklaştıracaktı.

Bölüm 4: İnsanlarla konuşmak

İnsanlarla konuşmanın ve fikir paylaşmanın değerini vurgulamak istiyorum.

PyPy hakkında bana çok şey öğreten CF Bolz-Tereick’e teşekkürler. Aylar boyunca PyPy kaynak koduna baktım ve bunun beni genel olarak daha iyi bir JIT geliştiricisi yaptığını düşünüyorum. Yardıma ihtiyaç duyduğumda CF son derece nazik davrandı.

Max Bernstein ile samimi compiler sohbetleri yapıyorum; bu olmasaydı muhtemelen motivasyonumu çok daha önce kaybederdim. Max üretken bir yazar ve yaklaşılması kolay bir derleyici uzmanı.

Fikirler yalıtılmış alanlarda var olmaz. Bir süredir derleyici geliştiricileriyle takılmanın JIT yazma becerimi artırdığını düşünüyorum. En azından PyPy’ye bakmak ufkumu genişletti!

Sonuç

İnsanlar önemlidir. Ve biraz da şans eklenince, JIT go brrr.