Free-threaded CPython deneyi için hazırlık tamam

• Free-threaded CPython, aynı yorumlayıcı içinde birden fazla iş parçacığının paralel çalışmasını mümkün kılan büyük bir değişim
• CPython 3.13'te deneysel bir özellik olarak sunuluyor
• PEP 703 sayesinde GIL devre dışı bırakılmış durumda çalıştırılabiliyor
• Performans artışı, özellikle çok iş parçacıklı performans için önemli
• Birden fazla CPU çekirdeğinin etkili şekilde kullanılmasını sağlıyor

Heyecan verici ama sorunlar ne?

• CPython'ın kendisinde free-threading uygulaması büyük bir çaba gerektiriyor
• İki ana sorun var: iş parçacığı güvenliği ve ABI uyumluluğu
  • İş parçacığı güvenliği: Saf Python kodu değişiklik olmadan çalışıyor, ancak başka dillerde yazılmış kodlar veya CPython C API kullanan kodlar için aynı şey geçerli olmayabilir
  • ABI uyumluluğu: free-threaded yorumlayıcı farklı bir ABI'ye sahip olduğundan, uzantı modülü içeren her paket için ek wheel derlenmesi gerekiyor
• İş parçacığı güvenliği sorunlarını anlamak, iyileştirmek ve test etmek zor
• Örnekler: numpy#26690, pywavelets#758 gibi yerlerde görülen aralıklı hatalar

Bundan sonraki plan ve ekibin çalışmaları

• free-threaded CPython'ın varsayılan hale gelmesi birkaç yıl alacak
• Python 3.13 ile birçok projenin uyumluluk üzerinde çalışması ve cp313t wheel'lerini PyPI'da yayımlaması umuluyor
• Ekip birkaç aydır PyData yığınının alt katmanlarından başlayarak çalışıyor
• Her paket için benzer bir yaklaşım izleniyor:
  1. İlk CI işi eklenir
  2. İş parçacığı güvenliği ile paylaşılan/genel durum sorunları düzeltilir
  3. Wheel derleme CI işlerine free-threaded desteği eklenir
  4. Yerelde stres testi yapılır ve CI işleri izlenir
  5. Uzantı modülleri, GIL olmadan çalışabilecek şekilde işaretlenir
  6. Sonraki pakete geçilir

GN⁺ özeti

• Free-threaded CPython, çok iş parçacıklı performansı büyük ölçüde artırabilecek önemli bir değişim
• İş parçacığı güvenliği ve ABI uyumluluğu sorunlarını çözmek başlıca görevler
• Python 3.13 ile birçok projenin uyumluluk üzerinde çalışması ve deneyler yapabilmesi umuluyor
• PyTorch gibi büyük paketlerin ve çok sayıda küçük paketin bu değişimi benimsemesi gerekiyor
• İlgili projeler arasında PyO3 ve PyTorch bulunuyor

[GN⁺]

Hacker News görüşleri

• Python'da GIL'in kaldırılmasıyla birçok kuruluş ve proje için neredeyse ek çaba gerektirmeden performansı büyük ölçüde artırma fırsatı doğuyor

  • Eski kütüphaneler bu değişime zamanında uyum sağlamazsa yeni projelerin pazar payı kazanma ihtimali var
  • Multiprocessing'in karmaşıklığı ve hatalarından kaçınılıp basit thread'ler kullanılarak büyük makinelerdeki tüm çekirdeklerden yararlanılabilecek

• macOS'ta GIL'siz Python'ı kurup çalıştırma deneyimi paylaşılıyor

  • Kurulum sürecini ve farkları anlatan kısa bir script yazılmış
  • bağlantı

• Python'un kolay yazılabilirliğini ve mantığını seven bir kullanıcı, GIL'siz yaklaşımın mevcut Python yazım tarzına benzer kalmasını umuyor

  • Multithreading zor geldiği için konuya derinlemesine girmediğini belirtiyor

• Python 3'ün ilerleyişi özetleniyor

  • [x] Async
  • [x] İsteğe bağlı statik tipleme
  • [x] Threading
  • [ ] JIT
  • [ ] Verimli bağımlılık yönetimi

• 2007 civarında paralel işlemenin zorunlu hale geldiği hatırlatılıyor

  • Rust'ın hız ve paralel işlem konusunda avantajlı durumda olduğu belirtiliyor

• PEP703'te GIL kaldırıldıktan sonra liste üzerindeki append işleminin thread safety'yi nasıl koruduğu açıklanıyor

  • Liste başına kilit ekleniyor
  • Basit tamsayı artırma işlemlerinin şu anda GIL sayesinde thread-safe olduğu belirtiliyor

• GIL'in kaldırılmasının ML eğitimi ve çıkarımın doğasını nasıl değiştireceği merakla bekleniyor

  • Bellek aktarımı ve süreç koordinasyonu karmaşıklığını azaltabilir
  • PyTorch gibi kütüphanelerin optimize edilmesi bekleniyor

• Gerçek multithreading deneyimi olmayan programcıların yeni ve ince hatalar ortaya çıkarabileceği konusunda endişe duyuluyor

• Tek thread performansındaki düşüşün ciddi olup olmadığı soruluyor

  • Benchmark bulunamadığı, yalnızca genel güvence verildiği belirtiliyor

• Async ile nasıl çalışacağına dair merak dile getiriliyor

  • I/O ile CPU-bound kod arasında doğal bir sınır var
  • Daha esnek bir model görmek isteniyor
  • CPU-bound coroutine'lerde gather yapılırken JIT'in mümkün olup olmayacağı sorgulanıyor
  • Benzer bir arayüzle hızlı geçiş yapılabilen esnek bir programlama modelinin harika olacağı düşünülüyor