Steering Council’dan JIT projesi hakkında açıklama

• CPython’ın deneysel JIT derleyicisi birkaç yıldır main dalında geliştiriliyordu ve yakın zamanda gerçek performans iyileştirmeleri gösterdi, ancak desteklenen bir özellik olarak kalması için resmi PEP incelemesinden geçmesi gerekiyor
• PEP 744 ilk tasarımı ve kalıcı bir özelliğe dönüşme ölçütlerini ele aldı, ancak uzun vadeli bakım sorumluları, güvenlik incelemesi, hata ayıklama ve harici süreç araç desteği, çalışma zamanı garantileri, yeniden dağıtıcılar ve downstream paketleyicilerin yükümlülükleri konusunda hâlâ uzlaşı sağlanmadı
• Python Steering Council, JIT’yi CPython’ın desteklenen deneysel olmayan bir özelliği haline getirmek için bir Standards Track PEP yazılmasını resmen talep etti ve PEP kabul edilene kadar yeni özellik, optimizasyon ve performans çalışmalarının maine alınmasının durdurulmasını istedi
• Yeni PEP; uzun vadeli bakım, mevcut CPython özellikleri ve araçlarıyla uyumluluk, ölçülebilir başarı ölçütleri ve takvim, CinderX·Numba·PyTorch gibi üçüncü taraf JIT’lerle ilişki ve mevcut mimarinin kararlılığını ele almalı
• 6 ay içinde PEP sunulup sonuçlandırılmaz veya kabul edilmezse JIT kodu main dalından çıkarılacak ve geliştirme ana Python deposu dışında sürdürülecek

---

Arka plan ve resmi talep

• CPython’ın deneysel Just-In-Time derleyicisi, son birkaç yıldır birden fazla core developer ve katkıcı tarafından main dalında geliştirilen bir çalışma ve son performans iyileştirmeleri gerçek ve cesaret verici sonuçlar gösteriyor
• Bu adım, JIT çalışmasına ya da katılımcılarına yönelik bir eleştiri değil; projenin uzun süredir devam etmesi ve birkaç kez yeniden tasarlanmış olması nedeniyle, JIT’nin CPython projesi içindeki gayriresmî statüsünü yeniden değerlendirme zamanı geldiği düşünülüyor
• JIT, ilk kez maine birleştirildiğinde deneysel olarak eklendi ve ilgili PEP olan PEP 744 bir Informational PEP
• PEP 744 ilk tasarımı ele aldı ve JIT’nin kalıcı bir özellik haline gelebilmesi için gereken ölçütleri ana hatlarıyla sundu, ancak uzun vadeli bakım sorumluları, güvenlik incelemesi, hata ayıklama ve harici süreç araç desteği, çalışma zamanı garantileri, yeniden dağıtıcılar ve downstream paketleyicilerin yükümlülükleri gibi soruları açık bıraktı
• Python Steering Council, bu düzeyde karmaşıklık ve kapsama sahip bir değişiklik için daha sıkı bir sürecin gerekli olduğunu ve bu çözülmemiş soruların topluluğun PEP süreci üzerinden değerlendirip uzlaşması gereken taahhütler olduğunu düşünüyor
• JIT’yi CPython’ın desteklenen deneysel olmayan bir özelliği haline getirmek için; garantileri, bakım taahhütlerini ve yeniden dağıtıcılar üzerindeki etkileri de kapsayan bir Standards Track PEP gerekiyor ve bunun topluluk tartışmasının ardından Steering Council tarafından resmen kabul ya da reddedilmesi gerekiyor
• Bu PEP kabul edilene kadar main dalına yeni JIT geliştirmeleri alınmamalı; yeni özellikler, optimizasyonlar ve performans çalışmaları durdurma kapsamına giriyor
• Hata düzeltmeleri ve güvenlik düzeltmeleri devam edebilir; durdurma talebinin kapsamı, PEP kabulünden önce ek JIT özelliklerinin eklenmesiyle sınırlı

PEP’nin ele alması gereken başlıklar ve 6 aylık takvim

• Amaç rakip öneriler istemek değil, ancak şu an alternatif önerileri tartışmak için de iyi bir zaman ve bu, CPython main dalında PEP olmadan deney yapılmaması gerektiğine dair mevcut görüşle de uyumlu
• Tek bir JIT uygulamasını önermek yerine, birden fazla uygulama stratejisini destekleyebilecek JIT altyapısını açıklayan bir PEP daha uygun olabilir
• Umut vadeden çeşitli JIT tracing yaklaşımları önerilmeye devam ettiği için, altyapı tek bir stratejiye sıkı biçimde bağlı olmaktan ziyade bu tür yaklaşımların CPython içinde kolayca denenip değerlendirilebilmesini sağlamalı
• PEP, bu ölçekte ve karmaşıklıkta bir alt sistemin uzun vadede nasıl sürdürüleceği ve korunacağı ile JIT’ye doğrudan katkı yapmayan bakımcılar ve katkıcılar üzerindeki etkisi için net bir plan ortaya koymalı
• PEP, mevcut CPython özellikleri ve araçlarıyla uyumluluğu ele almalı; free-threading, profiler, debugger gibi özelliklerle JIT’nin etkileşimini ve garantilerini geniş ve ayrıntılı biçimde kapsamalı
• PEP, açık ve ölçülebilir başarı ölçütleri ile bir takvim içermeli; performans hedefleri, platform desteğinin kapsamı ve bellek ek yükü gibi hedefleri ve zaman noktalarını ele almalı
• PEP, diğer JIT derleyicileriyle ilişkiyi ele almalı; tasarımın başka girişimlerin temel alabileceği genel bir altyapı sağlayıp sağlamadığını ve CinderX, Numba, PyTorch gibi üçüncü taraf JIT’lerle uyum ya da uyumsuzluk beklenip beklenmediğini belirtmeli
• PEP, mevcut JIT mimarisinin kararlı kabul edilip edilmediğini ya da daha fazla değişme olasılığının yüksek olup olmadığını ele almalı
• Bu liste tam bir liste değil; topluluk tartışması ilerledikçe ek başlıklar gündeme gelebilir
• PEP’nin sunulması ve sonuçlandırılması için 6 aylık bir süre belirlendi; bu süre içinde ilgili PEP kabul edilmezse JIT kodu main dalından çıkarılacak ve geliştirme ana Python deposu dışında devam etmeli
• Bu talep, projenin sonlandırılması değil; CPython çalışma zamanındaki büyük değişiklikler için gereken açıklığı ve topluluğun açık taahhüdünü sağlamak amacıyla işletilen bir süreç

[GN⁺]

Lobste.rs görüşleri

• Pek sert görünmüyor ama biraz garip duruyor. JIT hâlâ deneysel bir özellikse, birleştirilmeye devam edilmesinin kendi başına sorunlu olduğunu düşünmüyorum
  Shannon gibi kişiler “PEP getireceğiz ama lütfen garip çatışmalardan kaçınalım” diyorsa, daha fazla ilerlemeyi engellemek için sert bir kilit koymaya gerek kalmayacak kadar güvenilebilir olduklarını hissediyorum. Bu kamuya açık duyuru özel görüşmelerden sonra gelmiş olabilir, ama umarım gereksiz kırgınlıklar olmadan iyi şekilde ilerler

• Farklı JIT uygulamalarına izin veren bir arayüz önerisi, yüksek performanslı bir JIT için ne gerektiğini ciddi biçimde yanlış anlıyor gibi görünüyor. JIT üzerinde çalışanların çeşitli sorunları olmuş olabilir, ama büyük sorunlardan biri çekirdek çalışma zamanı veri yapılarında büyük değişiklikler yapamamış ya da yapmak istememiş olmaları gibi görünüyor
  Elbette Python'un fiilen tüm uygulamayı bir API gibi dışarı açmış olması gibi bir sorun da var. Yine de biri kötü bir şey yaparsa onu türleri yeniden yazmak zorunda bırakabilirsiniz, ama bunun için performansı gerçekten önemseyen bir topluluk gerekir. Python tarihsel olarak performans gerektiren kütüphaneleri Python ile yazmama yaklaşımıyla ayakta kaldı ve bu da öncelikleri etkiledi. Eskiden dil performansı karşılaştırmalarında temel algoritma uygulamalarıyla, gerçekte C kütüphanelerindeki iyi parlatılmış yüksek performanslı uygulamaları saran Python uygulamalarının kıyaslandığını hatırlıyorum

  • JIT arayüzü önerisi Ruby'den esinlenmiş gibi görünüyor ve Ruby'de oldukça iyi çalışmış izlenimi veriyor. Bu yüzden Ruby'de süper yüksek performanslı bir JIT olmayabilir, ama bu kadarı yeterince iyi olabilir. Python JIT, Ruby JIT kadar bile çalışsa birçok kişi memnun olur gibi geliyor

  • “Farklı JIT uygulamalarına izin veren bir arayüz önerisi, yüksek performanslı bir JIT için gerekenleri ciddi biçimde yanlış anlıyor” ifadesinin neden böyle olduğunu tam anlayamadım
    Dediğiniz gibi Python'un uygulamayı bir API gibi dışarı açmış olması durumu var, ama aynı nedenle JIT de bu API'leri çağırıyor. Nitekim bazı işlevler, JIT'in ihtiyaç duyması nedeniyle bağlayıcıda açık semboller olarak dışarı açılmıştı. Ben şahsen izleme JIT'i değil metot JIT'i üzerinde çalışıyorum ve takılabilir JIT fikrini kamuya açık biçimde destekliyorum

• Bunun neden çekirdek JIT geliştiricilerine özel bir istek olarak gönderilmek yerine kamuya açık bir duyuru olarak yayımlandığını merak ediyorum

  • Çünkü Python topluluk güdümlü bir açık kaynak projesi. Benzer duyurular özel mülkiyetli projelerde de sızdırıldı

• Bir yerlerde bir antropologun açık kaynak yazılım projelerindeki bürokrasi hakkında bir kitap yazması gerekiyor gibi geliyor ve Python ile Debian bunun temel inceleme alanları olmalı
  Bu bir suçlama değil. Bu tür bürokrasi sonuçta dağıtık karar alma ve uzlaşma oluşturma süreci ve bunu bu ölçekte iyi işleyecek hale getirmek zor

  • Gabriella Coleman, Debian üzerine saha çalışması yapmış bir antropolog. Bunun sonucunda ortaya çıkan kitabın adı “Coding Freedom” ve şiddetle tavsiye ederim

• Açıkçası, Python 3'e giden süreçteki sendromun aynısı ama ters etki yaratmış gibi görünüyor. CPython esasen uygulayıcıların keyfi için var ve bu değişiklik, işleri şu anki şekilde kurcalamaya alışmış kişiler için epey büyük bir rahatsızlık yaratacak gibi
  Muhtemelen doğru yön, JIT sürümünü ayrı bir uygulama olarak desteklemek, değişikliklere izin vermek ve özgün CPython ile uyumluluğu en iyi çaba düzeyinde hedeflemek olurdu

  • “Python 3'e giden süreçteki sendromun aynısı ama ters etki” derken tam olarak ne kastedildiğinden emin değilim
    “CPython esasen uygulayıcıların keyfi için var” kısmına gelince, SC ve çekirdek geliştiricilerle sınırlı etkileşimlerimden edindiğim izlenim bunun tam tersiydi. Genel olarak mevcut topluluğu desteklemeyi sürdürürken aynı zamanda ilerlemek arasında makul bir denge kurmaya oldukça derinden bağlı görünüyorlardı