Free-Threaded Python'un İlk 1 Yılına Bakış

 (labs.quansight.org)
5 puan yazan GN⁺ 2025-05-17 | 1 yorum | WhatsApp'ta paylaş
  • Free-threaded Python, çok çekirdekli donanımı verimli kullanabilmek için tasarlanmıştır
  • CPython 3.14 ile çekirdek modüllerde thread safety ve performans önemli ölçüde iyileştirildi
  • Hâlâ free-threaded build'i desteklemeyen birçok önemli paket bulunuyor
  • Herkes, gerçek kullanım ortamlarından gelen raporlar ve topluluk katkıları ile gelişime katılabilir

Genel Bakış

Geçen hafta CPython 3.14.0b1 yayımlandı ve bu hafta PyCon 2025 Pittsburgh'da başlıyor.
Bu iki etkinlik, free-threaded Python'ın dağıtımı ve kararlılığa kavuşması açısından önemli dönüm noktalarıdır.
Bu yazı, son bir yıldaki süreci geriye dönük inceliyor ve Quansight ekibinin karmaşık bağımlılıklara sahip gerçek üretim iş akışlarında free-threaded build'i deneysel olarak uygulamada nasıl kilit bir rol oynadığını açıklıyor.

Free-Threaded Python Ne Anlama Geliyor ve Neden Gerekli?

  • Free-threaded Python desteği, çok çekirdekli CPU ve GPU'ların yaygınlaştığı modern donanımın toplam hesaplama kaynaklarının tamamını kullanmayı mümkün kılar
  • Mevcut GIL (Global Interpreter Lock) yaklaşımında, paralel algoritmaları tam olarak kullanabilmek için dolambaçlı yöntemler ve ek ayarlamalar gerekiyordu
  • Genellikle threading modülü yerine multiprocessing kullanılıyordu; ancak bunun süreç oluşturma maliyeti yüksektir ve veri kopyalama da verimsizdir
  • Python paketleri arasında native kod içerenlerde, free-threaded build doğrudan uyumlu olmadığından thread safety garantisi için kod denetimi mutlaka yapılmalıdır
  • GIL'in kaldırılması, CPython yorumlayıcısında derin yapısal değişiklikler gerektirdi ve mevcut paketlerdeki yapısal sorunları da görünür hâle getirdi

Başlıca Kazanımlar

  • Meta'nın Python runtime ekibi ile birlikte, aşağıdaki gibi çeşitli paket ve projelere free-threaded Python desteği kazandırıldı
    • meson, meson-python, setup-python GitHub Actions, packaging, pip, setuptools gibi paketleme ve iş akışı araçları
    • Cython, pybind11, f2py, PyO3 gibi binding üreticileri
    • NumPy, SciPy, PyArrow, Matplotlib, pandas, scikit-learn, scikit-image gibi PyData ekosisteminin temel paketleri
    • Pillow, PyYAML, yarl, multidict, frozenlist gibi PyPI'de en çok indirilen başlıca bağımlılıklar
  • Henüz desteklenmeyen popüler paketler (CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, grpcio vb.) ile makine öğrenimi kütüphaneleri (safetensors, tokenizers vb.) üzerinde de kademeli olarak çalışılıyor
  • Quansight ekibindeki CPython çekirdek geliştiricileri, 3.14 sürümüne şu iyileştirmeleri dahil etti
    • warnings modülü, free-threaded build'de varsayılan olarak thread-safe çalışıyor
    • asyncio içindeki ciddi thread safety sorunları iyileştirildi ve paralel ölçeklenebilirlik artırıldı
    • ctypes modülünde thread safety baştan sona iyileştirildi
    • Free-threaded garbage collector performansı artırıldı
    • deferred reference counting şeması ve adaptive specializing interpreter için optimizasyonlar yapıldı
    • Çok sayıda bug fix ve thread safety iyileştirmesi gerçekleştirildi
  • Free-threaded Python desteği için kapsamlı bir rehber1 de hazırlanarak, bundan sonra daha fazla paketin pratikte yararlanabileceği dokümantasyon sağlandı

Free-Threaded Python Ekosisteminin Durumu

  • Bir yıl önce (3.13.0b1 yayımlandığında), free-threaded build'de çoğu Python paketinin kurulumu tam anlamıyla bozulmuş durumdaydı
  • Build hatalarının nedeni temel tasarım sorunlarından çok, desteklenmeyen varsayılan seçenekler ya da küçük varsayımların geçersiz hâle gelmesiydi
  • Son bir yılda toplulukla birlikte birçok sorun çözüldü; özellikle Cython 3.1.0'ın resmî destek kazanması büyük bir dönüm noktası oldu
  • Hâlâ derlenmiş kod içermesine rağmen free-threaded wheel sunmayan paketler bulunuyor
    Bunların ilerleme durumu manuel ve otomatik takip tablolarında2 görülebilir

Önümüzdeki Zorluklar

  • Şu anda free-threaded Python build'i, gerçek iş akışlarında deney ve geri bildirim gerektiren bir aşamadadır
  • Özellikle multiprocessing kullanım maliyetinin yüksek olduğu iş akışlarında performans iyileştirmesi potansiyeli var; ancak her paket için ayrıntılı thread safety denetimi zorunludur
  • Pek çok kütüphane mutable veri yapıları sunmasına rağmen thread safety dokümantasyonu veya gerçek güvence açısından yetersiz kalıyor
  • Paket büyükse ve çok fazla legacy barındırıyorsa, kodu bütünüyle anlayabilen kişi sayısının azlığı nedeniyle destek gecikebiliyor
  • Topluluk düzeyinde, temel paket bakımının sürdürülebilirliği için çaba gösterilmesi gerekiyor

Nasıl Katkı Sağlanır?

  • Resmî rehberdeki katkı kılavuzuna başvurabilirsiniz
  • Ekosistem genelindeki sorunları izleme ve başlıca uyumluluk belgeleri free-threaded-compatibility deposunda5 yönetiliyor
  • Quansight-Labs tarafından yürütülen topluluk Discord6 üzerinden tartışmalara katılabilir ve katkı sunabilirsiniz

PyCon Sunumu Duyurusu

  • Yazının yazarı ve ekip üyesi Lysandros Nikolaou, PyCon 2025'te bir sunum yapacak
  • Deneyimlerden çıkan pratik port etme örnekleri ve ipuçları paylaşılacak; ayrıca YouTube kayıt videosu da sunulacak
  • Free-threaded build'in Python dilinin geleceği olduğuna inanılıyor ve bunu gerçeğe dönüştürmeye katkı sunabilmek büyük heyecan yaratıyor
  • Bugün yapılan çalışmaların, her gün milyonlarca geliştiricinin kullandığı geniş ve çeşitli paketlerin geleceğini açan bir dönüm noktası olması umuluyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-17
Hacker News yorumları

  • Birçok kişi multiprocessing kullanıyor ve süreç oluşturma maliyetinin pahalı olduğuna dikkat çekiyor

    • SharedMemory özelliği varken bunun neden daha sık kullanılmadığını anlamadığını söylüyor

    • ShareableList ile deneyiminin iyi olduğunu özellikle vurguluyor

    • Unix'te süreç oluşturma hızı 1 ms'nin altında

      • Ancak PYTHON yorumlayıcı sürecini başlatmak, import sayısına göre 30 ms ile 300 ms sürebiliyor
      • 1 ila 2 basamaklık farklar olduğu için doğru sayılar önemli
      • CGI bu konuda istisna; C·Rust·Go tarafında sorun yok
      • sqlite.org'un da istek başına ayrı süreç yaklaşımını kullandığı örneği paylaşılıyor

    • ShareableList yalnızca atomik skalerleri ve bytes·string değerlerini paylaşabiliyor

      • Python'ın yapılandırılmış nesnelerinde pickle dump gibi serileştirme maliyeti ve süreç başına kopyalanan bellek maliyeti ortaya çıkıyor

    • numpy dizilerini paylaşmada büyük başarı yaşadığını anlatıyor

      • Açık paylaşım modeli, thread'ler arasında yanlışlıkla paylaşım yüzünden çıkan sorunları debug etmenin zorluğuyla kıyaslandığında büyük bir yük değil
      • Birçok kişinin thread'lerin multiprocessing'e göre ne kadar iyi olduğunu abarttığını düşünüyor
      • GIL kalkarsa rastgele görünen segfault'ları debug etmenin artmasından endişe ediyor
      • JavaScript'in paylaşımlı bellek tabanlı threading'i desteklememesi konusunda insanların çok da şikayet etmediğini belirtiyor
      • Bunun, JavaScript'in yeterince hızlı olması nedeniyle böyle bir ihtiyacın daha az hissedilmesi şeklinde yorumluyor
      • Python'ın temel performansını iyileştirmeye daha fazla emek verilmesini diliyor

    • Süreçler bağımsız biçimde öldüğü için, lock tutarken paylaşımlı bellek veri yapısını değiştiren bir süreç ölürse toparlamanın zor olduğuna dikkat çekiyor

      • Postgres'in paylaşımlı bellek yapıları ve tüm backend süreçlerini sonlandırma gereği buna örnek veriliyor
      • Thread'ler birlikte öldüğü için bu tür bir problemin daha az fark edildiğini söylüyor

    • Paylaşımlı bellek yalnızca özel donanım üzerinde çalışıyor

      • AWS Fargate gibi ortamlarda paylaşımlı bellek yok; ağ veya dosya sistemi kullanma ihtiyacı gecikmeyi artırıyor
      • fork tabanlı süreç kopyalama da ayrı bir sorun
      • Gerçek deneyiminde green thread ve actor modelinin çok daha etkili olduğunu savunuyor

  • GIL'in kaldırılmasının Python çoklu thread kodu üzerinde paralel işlem dışında başka etkileri olup olmadığını merak ediyor

    • GIL'in korunma nedeninin çoklu thread'lerin GIL'e bağımlı olması değil; GIL'i kaldırmanın yorumlayıcı uygulamasını ve C eklentilerini zorlaştırması ve tek thread kodunu yavaşlatması olduğunu anladığını söylüyor

    • Free-threaded Python'ın, bytecode sınırlarında her an kesilebilme yönündeki mevcut garantiyle aynı olup olmadığını soruyor

    • Yoksa daha fazla lock kullanmak gibi yazım biçimlerinin değişip değişmeyeceğini merak ediyor

    • Free-threaded Python da büyük ölçüde aynı garantileri sunuyor

      • Ancak free-threading yokken insanlar threading'i daha az kullandığı için, sınırlar arasında kesilmeden kaynaklanan bug'lar pratikte çok sık ortaya çıkmıyor
      • Free-threading gelince daha fazla bug görünür hale gelecek
      • Multiprocess dolambaçlarına gerek kalmayacağı için kullanıcı kodu sadeleşecek; yorumlayıcı karmaşıklığındaki artışın buna değdiğini düşünüyor
      • C eklentilerinin karmaşıklaşması sorununun free-threading'den çok sub-interpreter tarafında daha ağır olduğunu; numpy ekibinin sub-interpreter desteği veremeyeceklerini açıkça söylediğini belirtiyor
      • numpy zaten free-threading desteğine sahip, kalan bug'lar düzeltiliyor
      • Tek thread hızında küçük (tek haneli %) bir düşüşün kabul edilebilir bir takas olduğunu düşünüyor

    • Çok çekirdek kullanımı mümkün, ancak thread başına performans düşüşü ve kütüphanelerin yeniden elden geçirilmesi gerekiyor

      • PyTorch ile deney yaparken, 10 kat CPU kullanımına karşılık iş hacminin yarısına indiğini gördüğünü söylüyor
      • Zamanla düzelmesini bekliyor; bunu 20 yıldır beklediği için yine de memnun

    • Race condition'lar daha sık yaşanabileceği için, güvenilirlik sağlamak adına çoklu thread Python yazarken daha dikkatli olunması gerekiyor

  • Microsoft'un Faster Python ekibini dağıttığı haberi paylaşılıyor

    • Bunun, 2025 için beklenen performans hedeflerinin tutmaması nedeniyle ekibin korunamamasıyla ilgili olduğu söyleniyor

    • Bundan sonra CPython'a performans iyileştirmeleri gelip gelmeyeceğini ya da başka şirketlerin destek verip vermeyeceğini izleyeceğini belirtiyor

    • Facebook'un (Meta) hâlâ kısmi destek sağlıyor gibi göründüğünü ekliyor

    • Microsoft'un taahhütlerine kıyasla takvimin büyük ölçüde geciktiğine değiniliyor

      • Son dönemde ciddi siyasi ve yönetişim sorunlarının farkında olduklarını; yetenekli çalışanların, boş yere katkı verip grubun kötülenmesine maruz kalmak istemeyeceğini savunuyor
      • CPython organizasyonunun fazla söz verdiğini, uyumlu kişilere iş yığdığını ve güçlü muhalifleri dışladığını eleştiriyor
      • Eskiden böyle sorunlar olmadığını, mevcut durumun kendi yarattıkları bir problem olduğunu söylüyor

    • Sonucun üzücü olduğunu ama Microsoft'un uzun vadeli taahhütlerine güvenmemesinin doğru çıktığını belirtiyor

    • Son dönemde Google'ın da tüm Python geliştirme ekibini işten çıkarmış gibi göründüğüne dair bir söylenti var

      • Her ikisinde de döneme özgü bir neden ya da ortak bir payda olup olmadığını merak ediyor

    • Çok üzücü olduğunu, ancak embrace & extend sonrasında geriye tek bir şey kaldığı imasında bulunuyor

  • Python'da GIL'in ortadan kalkmasından endişe eden tek kişinin kendisi olup olmadığını soruyor

    • Hangi dilde olursa olsun karmaşık çoklu thread koduna güvenmenin zor olduğunu, Python'da bunun dinamik yapı nedeniyle özellikle daha da tedirgin edici olduğunu düşünüyor

    • Değişimden korkan tek kişi olmadığını, fakat bu gerekçenin irrasyonel olabileceğini söylüyor

      • GIL'in tam anlamıyla teknik borç olduğunu, bu yüzden topluluğun yararı için kaldırılması gerektiğini savunuyor
      • Günümüzde Python'da çoğu kişinin thread yerine non-blocking I/O ve async kullandığını belirtiyor
      • Thread kullanılmıyorsa GIL'in kaldırılmasının bir etkisi olmayacağını; C kütüphanelerinin de tek thread'de güvenli kalacağını söylüyor
      • Yalnızca gerçekten thread kullanılıyorsa dikkat gerektiğini vurguluyor
      • Naif thread tabanlı Python kodunun şimdiye kadar GIL yüzünden tek thread gibi davrandığını; artık biraz hızlanabileceğini ama bug'ların da artabileceğini belirtiyor
      • Çözüm olarak thread kullanmamak ya da kullanılacaksa bunu düzgün öğrenmek gerektiğini tavsiye ediyor
      • İleride daha iyi soyutlamalar geleceğini, toplulukta structured concurrency gibi konuların tartışılmasını beklediğini söylüyor

    • Kendisi asyncioyu aktif biçimde kullandığını söylüyor

      • Tek thread olmasına rağmen concurrent Python kodunu keyifle yazabildiğini; bunu Node.js benzeri bir kullanım olarak gördüğünü belirtiyor
      • Web ve ağ işleri için bu yaklaşımı öneriyor

    • ML/AI alanında olduğu gibi, uzmanların önce karmaşık kütüphaneleri geliştirip genel kullanıcılara bunları sunduğu bir yapı bekliyor

      • Python'da GIL'in ciddi bir darboğaz olduğu durumların giderek arttığını söylüyor
      • Bu yüzden Go öğrenmeye başladığını; thread desteği sağlam, Python'dan daha alt seviyede ama C/C++'dan daha yüksek soyutlama sunan bir dil olarak gördüğünü belirtiyor
      • Derleyici yaklaşımının da threading kadar önemli bir arka plan unsuru olduğunu ekliyor

    • Gereksiz bir korku yaymak olabilir ama LLM'lerin son on yıllardaki, GIL'in var olduğu varsayımıyla yazılmış Python kodlarıyla eğitildiğini hatırlatıyor

    • GIL'in olup olmaması yalnızca çok çekirdekli çalışma isteyenleri ilgilendiriyor

      • Bugüne kadar threading ya da multiprocessing konusunda özellikle düşünmediyseniz pratikte değişen bir şey olmayacağını söylüyor
      • Race condition sorunlarının GIL'den bağımsız olarak da ortaya çıkabildiğini ekliyor

  • Python'ı sık kullandığını ama uzman olmadığını, bazen concurrent.futures ile birkaç basit fonksiyonu aynı anda çalıştırdığını söylüyor

    • Böyle kullanıcıların ileride neyi değiştirmesi gerekeceğini merak ediyor

    • Thread'ler artık GIL'e bağlı kalmayacağı için genel olarak daha hızlı olacak

      • Paylaşılan nesnelerdeki lock'lar doğru yönetildiyse ek bir endişeye gerek olmadığını söylüyor

  • Python ile 20 yıllık profesyonel geliştirme deneyiminden çıkardıklarını paylaşıyor

    • Thread'lere gerçekten ihtiyaç duyulan durumların, message passing'in kaçınılmaz olduğu senaryolarla sınırlı olduğunu düşünüyor

      • Python ekosisteminin bu tür durumların hepsi için zaten dolaylı çözümler sunduğunu belirtiyor
      • Çoklu thread kullanımındaki çeşitli tuzaklar (lock vb.) nedeniyle, bunun ileride yalnızca belirli kütüphane ve alanlarda gerekli olabileceğini düşünüyor
      • Mümkün olan en yüksek performansı saf Python'dan çıkarmak için native code tabanlı kütüphanelerin (ör. Pypy, numba) kullanılabileceğini söylüyor
      • Python'daki asıl performans devriminin async programlama olduğunu ve mutlaka öğrenilmesini tavsiye ediyor

    • Python'ı benzer süre kullandığını ve buna katıldığını, ama biraz farklı ifade edeceğini söylüyor

      • Python thread'leri o kadar kötüydü ki, bunlardan kaçınmak için çeşitli dolambaçlı çözümler geliştiğini belirtiyor
      • CPU-bound işi thread ile 2 kat hızlandırmaya çalışırken GIL sorununa çarptığını; sonra multiprocessing'e geçtiğini, veri yapısı serileştirme maliyeti yüzünden 2 kat çekirdeğe karşılık yalnızca 1,5 kat hız gördüğünü anlatıyor
      • İyi thread desteği olsaydı bunu kullanmak isteyeceği çok ortam bulunduğunu; şimdiye kadar olmadığı için çeşitli alternatif yaklaşımlara yöneldiklerini söylüyor
      • Uygun durumlarda async kullanımını güçlü biçimde öneriyor (glif, haklıydın!)

  • Görsel yapay zekayla üretilmiş olabilir ama yılanın iki kuyruğu olması garip bulunuyor

    • Bunu sessizce geçiştirme yönünde esprili bir destek geliyor; Python haberinde yılan görseli varsa bunun genelde pek önemsenmeye değer bir işaret olmadığı söyleniyor

    • Şaka yollu olarak Confusoborus adı öneriliyor

  • Başlık görselindeki yılanın iki kuyruğu var gibi göründüğü belirtiliyor

    • Aynı süreç içinde ikinci thread'in oluşturulmuş olması gibi esprili bir yorum yapılıyor

  • Kütüphane desteğinin dışında, WSGI ve Celery worker'larını tek süreçte çalıştırmanın başka kısıtları olup olmadığını soruyor

    • Bir kısıt olmadığını, ancak bu yaklaşımın dilin birinci sınıf bir özelliği olmadığını söylüyor
      • GIL'in teknik borç meselesi olduğunu açıklıyor
      • Yalnızca paralellik değil, GIL'in kaldırılmasını gerektiren başka unsurların da bulunduğunu ekliyor

  • Bunun, önümüzdeki performans çağı için muazzam bir temel çalışması olduğunu düşünüyor