No-GIL CPython geliştirmenin mevcut durumu

 (lwn.net)
1 puan yazan GN⁺ 2023-10-22 | 1 yorum | WhatsApp'ta paylaş
  • Python steering council, GIL'in isteğe bağlı hale getirilmesini amaçlayan PEP 703'ü birkaç sürüme yayılan bir geçişle onaylama niyetini açıkladı; nihai koşullar ise hâlâ netleştiriliyor
  • CPython 3.13 için --disable-gil derlemesi deneysel olarak hazırlanıyor ve en büyük teknik başlıklar stable ABI ile eklenti modülü wheel uyumluluğu olarak öne çıkıyor
  • Mevcut abi3 wheel'leri no-GIL CPython 3.13 ile olduğu gibi uyumlu olmayabilir; bu nedenle abi4 eklenmesi, sınırlı C API değişiklikleri ve referans sayımı makrolarının fonksiyon çağrılarına dönüştürülmesi tartışılıyor
  • pip'in GIL derlemesi ile no-GIL derlemesi için wheel'leri yanlış seçebileceği endişesi var ve sessiz yanlış kurulum, basit bir kurulum hatasından daha tehlikeli görülüyor
  • no-GIL derleme adı için nogil yerine free-threading önerildi, ancak yürütülebilir dosya adı, shebang, paralel kurulum ve dağıtım paketlemesi konularının da birlikte çözülmesi gerekiyor

PEP 703 ve no-GIL CPython'ın bugünkü konumu

  • Python steering council, temmuz sonunda PEP 703'ü onaylama niyetini açıkladı; bu PEP, CPython'da global interpreter lock (GIL) mekanizmasını isteğe bağlı hale getirmeyi hedefliyor
  • Onayın ayrıntılı koşulları henüz kesinleşmemiş olsa da, ilgili uygulama tartışmaları ve ekosistem hazırlıkları şimdiden sürüyor
  • Uzun vadede GIL'siz tek bir CPython sürümüne giden bir yol öngörülüyor, ancak şu anda no-GIL davranışı --disable-gil seçeneğiyle derlenen yorumlayıcıda test ediliyor
  • CPython 3.13'ün 2024 Ekim ayında çıkması planlanıyor ve bu sürümdeki no-GIL derlemesi deneysel nitelik taşıyor

stable ABI ve eklenti modülü uyumluluğu

  • Sam Gross, PEP 703 ile CPython stable ABI'nin nasıl kesiştiğini Python tartışma forumunda ele aldı
  • stable ABI, eklenti modüllerinin birden fazla CPython sürümünde aynı ikili wheel ile çalışmasını sağlayarak her yeni CPython sürümünde yeniden derleme gereksinimini azaltıyor
  • stable ABI için derlenmiş eklentiler, CPython 3.13 no-GIL derlemesinde doğrudan çalışmayabilir
  • Bunu çözmek için sınırlı C API'ye bazı eklemeler ve değişiklikler öneriliyor
    • Yalnızca sınırlı C API kullanan eklentiler, stable ABI kullanan ikili dosyalar üretebilir
    • Önerilen değişiklikler arasında, nesne referans sayısını artırıp azaltan bazı makroların fonksiyon çağrılarına dönüştürülmesine yönelik mevcut plan da bulunuyor
  • Amaç, hem GIL derlemesinde hem de no-GIL derlemesinde çalışabilen eklenti ikili dosyalarını mümkün kılmak

abi3, abi4 ve wheel seçimi sorunu

  • Victor Stinner, no-GIL denemesinin başarılı olabilmesi için her iki yorumlayıcı türünde de çalışan eklentilere yönelik basit bir çözüme ihtiyaç olduğunu düşünüyor
  • CPython 3.12 ve öncesinde stable ABI için derlenmiş eklentiler, 3.13 ve sonrasındaki no-GIL derlemeleriyle uyumlu olmayacağından yeni bir ABI sürümü olan abi4 fikri gündeme geldi
    • Mevcut stable ABI, abi3
    • ABI numarasının CPython majör sürüm numarasıyla birebir bağlı olması gerekmiyor
  • Gross, no-GIL desteği sunmak isteyen eklentilerin iki ayrı ikili wheel üretme yükünü belli ölçüde kabul edebileceğini düşünüyor
    • Onu daha çok endişelendiren şey, no-GIL projesinin C API ve stable ABI iyileştirmelerine aşırı bağımlı hale gelmesi
  • Alex Gaynor da birçok abi3 wheel paketi yönetse de, tek seferlik iki wheel üretmenin aşırı büyük bir yük olmadığını düşünüyor
    • Ancak mevcut ve gelecekteki pip sürümlerinin doğru wheel'i seçip seçemeyeceği kritik görülüyor
  • Brett Cannon, mevcut pip mantığının bu iki sürümü ayırt edemediğini, bu yüzden abi4 benzeri bir değişiklik olmadan mevcut ve eski pip sürümlerinin doğru çalışmayacağını düşünüyor

pipin sessiz yanlış çalışma riski

  • Gross, CPython 3.13'ün deneysel --disable-gil derlemesinde eski pip desteği konusunda çok büyük endişe taşımıyor
    • Gerekçesi, yeni Python sürümlerinde eski pip sürümlerinin bozulmasının sık görülmesi
    • Örnek olarak, pip==23.1.1 ve öncesinin CPython 3.13'te pkgutil.ImpImporter bulunmadığı için bozulabildiğini belirtti
  • pip bakımcısı Paul Moore ise açıkça bozulma ile sessizce yanlış paketin kurulması arasında önemli bir fark olduğunu düşünüyor
    • Eski pip kullanan kullanıcılar var
    • Açık hata ile sessiz hata, kullanıcı üzerindeki etki açısından farklı sonuçlar doğuruyor
  • Moore, no-GIL veya free-threaded derlemeyi denemek isteyen kullanıcıların ABI uyumluluğu sorunlarını ayıklamak zorunda kalması halinde motivasyonlarının kırılabileceğinden endişe ediyor
  • Gaynor da etkilenen paketlerde pip sessizce yanlış davranırsa çok sayıda issue açılabileceğini düşünüyor

Paralel kurulum ve yürütülebilir dosya adları

  • Barry Warsaw, aynı sistemde GIL derlemesi ile no-GIL derlemesinin birlikte kurulmasının planlanıp planlanmadığını sordu
  • Gross, bunun farklı Python sürümlerini kurmaktan farksız olduğunu söyledi
  • Cannon, tek bir “fat” wheel içine iki ikili dosya koymanın da mümkün olabileceğini düşünüyor
    • Ancak wheel içindeki ikili dosya adlarının birbirinden farklı olması gerekir
  • Yürütülebilir dosya adı tartışması ayrı bir başlıkta devam etti
  • Paul Moore, kullanıcıların no-GIL modunu kolayca test edebilmesi ve GIL/no-GIL arasında kolayca seçim yapabilmesi gerektiğini düşünüyor
    • Bu süreç Windows, macOS ve Linux'ta zorsa, no-GIL projesi üzerinde olumsuz etki yaratabilir
    • Kullanıcıların kolayca deneyebilmesi, no-GIL derlemesine talep oluşması ve paket bakımcıları üzerinde no-GIL uyumlu wheel sağlama baskısı yaratması açısından önemli

nogil ve free-threading adlandırma tartışması

  • Barry Scott, shebang satırında hangi yorumlayıcının çağrılacağını belirtmek gerektiği için yürütülebilir dosya adının önemli olduğunu düşünüyor
    • Örnek olarak python-nogil3, python-nogil3.13 gibi adlar önerdi
  • Gregory P. Smith, CPython 3.13'teki no-GIL derlemesinin deneysel bir özellik olduğu için dağıtımlar tarafından varsayılan $PATH içine konulmaması gerektiği yönünde kişisel görüş bildirdi
    • Uzun yürütülebilir dosya adlarının shebang içinde kalıcı hale gelmesi de ona göre arzu edilen bir durum değil
    • Kurulum adının belirlenmesinin 3.14 sonrasına bırakılmasını önerdi
  • Fedora geliştiricisi Petr Viktorin, dağıtımların kullanıcı deneyleri için no-GIL yorumlayıcısını paketlemeye büyük ihtimalle yöneleceğini belirtti
  • Moore, #!/usr/bin/env python3.13-nogil gibi bir biçimle free-threaded derlemeyi belirtmek istediğini söyledi
    • Amaç, uzun ve sezgisel olmayan yolları sabit olarak yazmak zorunda kalmamak
  • Steve Dower'ın başlattığı Windows yükleyicisi tartışma başlığında Smith, steering council'in nogil adından kaçınmak istediğini aktardı
    • Bunun nedeni, kavramın çoğu çekirdek dışı geliştirici için açıklayıcı olmaması, GIL'in ne olduğunun bilinmesini gerektirmesi ve olumsuz bir ifade içermesi
    • Alternatif olarak free-threading terimi önerildi
  • Gross ise free-threading ifadesinin de dışarıdan bakanlar için kolay anlaşılır olmadığını ve yaygın kullanılan bir terim sayılmadığını düşünüyor
  • Pratik tartışmalarda kısa adlara güçlü bir eğilim vardı ve bu açıdan nogil en güçlü adaydı
  • Somut olarak yansıtılan değişiklik ise no-GIL derlemesinin ABI etiketinin n yerine t olarak değiştirilmesi oldu
    • t, threading anlamına geliyor

abi4 önerisi ve kalan işler

  • Gross ve Viktorin, API değişikliği önerilerindeki sorunlu noktaları tartıştı ve bu geri bildirimler yeni ABI olan abi4 önerisine dönüştü
  • Gross, yeni ABI için bir prototip oluşturdu
  • Viktorin, genel yaklaşımı desteklese de ayrıntıların daha fazla netleştirilmesi gerektiğini düşünüyor
  • Stinner, abi4 için bir PEP gerektiğini savundu; Viktorin ise bunu bir pre-PEP tartışması olarak değerlendirdi
  • Sınırlı C API sürümü ile abi3 birleşiminin hangi uyumluluk güvencelerini sağladığı konusunda kafa karışıklığı var ve bu durum abi4 yönünü de etkiliyor
  • İlgili incelemeler sürüyor ve ekim ortasındaki core developer sprint sırasında yüz yüze tartışma yapılması mümkün görünüyor

Nihai onay metni ve uzun vadeli etkiler

  • no-GIL veya free-threaded CPython çalışmaları devam ediyor, ancak PEP 703'ün nihai onayı hâlâ beklemede
  • Gecikme bir miktar uzamış olsa da, PEP 703 ve etkilerinin önümüzdeki 5 yıl ve sonrasında CPython geliştirmesi ile ekosistemi üzerinde büyük etkisi olabilir
  • steering council, onay kriterlerini daha açık hale getirmek istiyor
  • Thomas Wouters, kesin onay metnini şekillendirdiğini ve çeşitli kararları netleştirmeye çalıştığını belirtti
  • Bazı çalışmalar core developer sprint sırasında da ilerleyebilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-10-22
Hacker News görüşleri

  • Modern bilgisayarlara bakınca, açık paralellik bilgisayar biliminin ders kitaplarında moda olandan daha temel bir unsuru olabilir diye düşünüyorum.
    Artık her zaman açıkça paralel kod yazmamız gereken bir aşamada olabiliriz

    • İnsanlar aynı anda birden fazla thread hakkında akıl yürütmekte zayıf olduğundan, daha pratik değişim muhtemelen hâlihazırda gördüğümüz bildirimsel sözdizimi yönünde olacak.
      Örneğin for döngüleri foreach, map, filter gibi işlemlerle değiştiriliyor. Bu tür ifadeler, derleyiciye/yorumlayıcıya veri yapısındaki tüm öğelere bir işlem uygulamak istediğinizi bildirir; paralelleştirmenin yapılıp yapılmayacağını ve nasıl yapılacağını derleyiciye/çalışma zamanına bırakır
    • Paralellik birkaç yöne ayrıldı.
      Web servislerinin çalıştırılmasında her bir istek yeterince hızlıdır ve paralelliğin asıl faydası çok sayıda isteği yan yana işlemektedir. No-GIL buna uyuyor.
      Tek bir isteğin içinde çok sayıda alt istek varsa bu genelde asenkron kodla ele alınır; ancak bu çoğu zaman asenkronun performans kazancından çok thread oluşturmanın pahalı olması ya da thread pool yönetiminin zahmetli olmasındandır. Asenkron, throughput için iyidir ama gecikme süresi için kötüdür; servis isteklerini paralelleştiriyorsanız genelde gecikme süresi daha büyük kaygıdır. Asenkron daha çok kullanılabilirlik nedeniyle kazandı.
      Bir başka paralellik türü büyük ölçekli çevrimdışı işlerde görülür. MapReduce ya da Presto gibi şeylerdir ve genel olarak böl ve fethet problemlerine benzerler. GPU model eğitimi de buna yakındır.
      Gerçekleşmeyen şey ise yerelde, yüksek derecede paralel algoritmalar oldu. Web servislerinde veri boyutu küçük olduğu için gecikme süresi kazancı azdır, uygulama karmaşıktır ve thread’ler arası koordinasyon maliyeti büyür. Küçük bir istisna vektörleştirilmiş algoritmalardır; ancak bunlar tek bir çekirdekte çalıştığı için koordinasyon overhead’i yoktur ve çevrimiçi çıkarım da yine çok güçlü biçimde vektörleştirilmiştir
    • Bilgisayar biliminde paralellik biraz güvenliğe benzer. Soyut düzeyde önemli olduğunu bilirsiniz ama düzgün öğrenmek için ayrıca eğitim aramanız gerekir.
      Zamanla ikisi de iyileşiyor. Daha fazla dil ve kütüphanenin varsayılan olarak güvenli hâle gelmesi gibi, artık daha fazla şey varsayılan olarak paralel. Hâlâ gidilecek yol var, ama bunu çok erken yapmamış olmamızın iyi olduğunu düşünüyorum; çünkü son 10 yılda teknoloji çok gelişti.
      Örneğin Rust’ın Rayon’u ile güvenli şekilde yapılabilenler ile C++’ın OpenMP’siyle güvenli olmayan şekilde yapılanları karşılaştırabilirsiniz.
      Daha dış halkada benim üzerinde çalıştığım şu şeyler de var: https://legion.stanford.edu/, https://regent-lang.org/, https://github.com/nv-legate/cunumeric
    • Paralelliği bellek yönetimiyle aynı sınıfta görüyorum. Yazdığımız programların çoğu bir şekilde otomatik yönetim kullanabilir ve kullanmalıdır; manuel yönetim ise performans açısından gerekli alanlara bırakılabilir.
      Bu bir uygulama ayrıntısı olduğundan, daha kolay yararlanılabilecek şekilde soyutlanabiliyorsa öyle yapılmalıdır
    • LMAX Disruptor wiki’sinde, bir thread’den başka bir thread’e mesaj göndermenin ortalama gecikme süresinin 53 nanosaniye olduğu yazıyor.
      Karşılaştırma için, mutex yaklaşık 25 nanosaniyedir ve contention varsa daha da artar; ancak mutex noktadan noktaya senkronizasyondur.
      Disruptor’ın iyi yanı, birden fazla thread’in aynı mesajı büyük bir ek çaba olmadan alabilmesidir.
      https://github.com/LMAX-Exchange/disruptor/wiki/Performance-...
      https://gist.github.com/rmacy/2879257
      Smalltalk’a benzeyen ama paralelleştirme anlamlı olana kadar tek thread’de kalan bir dil hayal ediyorum.
      Büyük veri olmayan paralellik problemleri arıyorum. Paralellik, bir arabanın hızını artırmaktan çok yola daha fazla araba koymaya benziyor. Ama masaüstü ya da mobil kullanıcıların yerelde bilgisayarın matematiksel gücünden yararlanarak yapması gereken şeyin ne olduğunu hâlâ arıyorum.
      Paralellik fikri olarak Itanium ve VLIW mimarilerini de düşünüyorum

  • -ng kullanılabilir. no-gil ya da next-generation anlamında

    • Unix thread desteğinin büyük dalgasını hatırlatıyor. Geliştiricinin yapması gerekenler platformdan platforma muazzam farklılık gösteriyordu.
      Yeni derleyici flag’i, yeni linker flag’i, farklı kütüphane linkleme, tamamen farklı derleyici komutu kullanma bile vardı. AIX özellikle böyleydi

  • Shebang sorunu için mevcut Python teamüllerine yaslanmak daha iyi olabilir: from __future__ import nogil
    O noktada yorumlayıcıyı hot-swap etmek yeterli olur

    • from __future__ import bir çalışma zamanı ifadesi değil, flag’i belirten özel bir ifadedir.
      https://docs.python.org/3/reference/simple_stmts.html#future...
    • “future ifadesi, belirli bir modülün, söz konusu özelliğin standart hâle geleceği gelecekteki Python sürümlerinde kullanılacak sözdizimi veya semantik ile derlenmesi için derleyiciye verilen bir direktiftir.”
      future ifadesi modül bazındadır ve GIL/no-GIL bu modele kolayca uymaz
    • İlk modül ve ilk import olarak çalıştırılmazsa uygulaması kâbusa dönüşebilir

  • Bu öneriyi her gördüğümde, programların hâlâ doğru çalışmasının nasıl garanti edileceğini merak ediyorum. Mevcut çok iş parçacıklı Python kodlarının önemli bir kısmı güvenli olmayan şekilde yazılmış durumda
    Özellikle çeşitli şirket kod tabanlarında ve açık kaynak projelerde tekrar tekrar gördüğüm veri yarışı sorun oluşturuyor. Bu programlar yalnızca GIL’in aynı anda yalnızca tek bir iş parçacığının çalışmasına izin vermesine örtük olarak dayandıkları için bozulmuyor
    GIL ortadan kalkarsa bu programlar bozulacak. Python dinamik tipli bir dil olduğundan, mevcut Python programlarında bu sorunları bulabilecek bir statik analiz aracının var olabileceğinden ciddi biçimde kuşkuluyum
    Daha olası olan, çalışma zamanında belirlenimci olmayan şekilde ortaya çıkan sinsi hatalar. Keşke en azından çökme olsa; ama bu tür hataların yanlış davranışlarla sonuçlanması daha muhtemel
    Belki de bu GIL’siz öneri çoğu programda kullanılmak için değildir. Programcının GIL olmadığını bilip buna göre yazabileceği çok az sayıdaki durum için aşırı özelleşmiş bir araç olabilir

    • Veri yarışı olan çok iş parçacıklı bir programsa zaten sorunludur. GIL veri yarışlarını imkânsız hâle getirmez
      GIL yalnızca aynı anda tek bir iş parçacığının Python bayt kodu çalıştırabileceği anlamına gelir. GIL bulunan yorumlayıcı da bayt kodları arasında iş parçacığı değiştirebilir ve birçok Python işlemi birden fazla bayt kodu gerektirir. Buna birçok kişinin “atomik” sandığı yerleşik tiplerin yerleşik metotları da dâhil
      Bu yüzden Python, bugün GIL olmasına rağmen kilit, mutex, semafor gibi şeyler sunuyor
    • Küçük ve ilginç bir gerçek olarak, GIL tüm yarış koşulu hatalarını kesinlikle engellemez
      GIL için yarışan iş parçacıkları zaten kötü zamanlarda GIL’i birbirinden kaparak karmaşa yaratabilir
    • Ana fikri, kütüphanelerin nogil modu desteğini beyan etmesi, yani opt-in olması olarak anladım
      Program ancak tüm bağımlılıklar izin verdiğinde GIL olmadan çalışacaksa, bu tür hataları düzeltmek için yeterince zaman olacaktır
    • no-GIL Python’un en az 3-4 sürüm döngüsünden sonra geleceğini düşünüyorum. 3.11 çıkalı 1 yıl oldu ve prodüksiyondaki Python kodlarının hâlâ çoğunlukla 3.8 civarında olduğunu sanıyorum
      O zaman bu sorunun geniş ölçekte ele alınması muhtemelen 2030’a yaklaşırken olur. Mevcut runtime’ını en yeni sürüme hemen yükselten prodüksiyon ortamlarını da pek görmüyorum
      Sert konuşmak istemem ama Steering Council, 2’den 3’e geçiş gibi bir başka migrasyon istemediklerini söyledi; bu yüzden insanlar hafifçe güncelleme yapmayacak. Şu anda internetteki içeriğin çoğu kopyala-yapıştır için riskli olabilir
    • GIL yalnızca yorumlayıcıyı korur. Yapabileceği şey, sorunların ortaya çıkma sıklığını azaltmaktan ibarettir
      Gerçek Python kodlarında çok fazla threading hatası var

  • OCaml de benzer bir evrim geçirmedi mi? İki proje arasında karşılaştırılabilecek noktalar olup olmadığını merak ediyorum

    • Bence öyle değil. OCaml 5, mevcut kodu bozacak şekilde küresel kilidi kaldırmak yerine, paylaşımlı kilide sahip bir veya daha fazla iş parçacığını yöneten domain adlı yeni bir ilkel özellik getirdi
      Bu yüzden mevcut thread API’si geçerli domain içinde thread oluşturuyor ve kilidin var olduğunu varsayan kodu izole edebiliyor. Yeni kod ise bunun yerine tek bir thread ile başlayan yeni bir domain oluşturabiliyor. İkisi kasıtlı olarak birlikte kullanılıp bir zamanlama biçimi olarak da değerlendirilebilir
      Python ise kilidi, kütüphane yazarının kontrolü dışında küresel olarak tamamen isteğe bağlı hâle getirmeye çalışıyor. Ancak Python’daki kilidin yalnızca runtime’ın kendisini koruduğu garanti ediliyor gibi göründüğünden, bu kilide dayanan çoğu kodun zaten hatalı olma ihtimali yüksek; bu nedenle Python’un planı da uygulanabilir görünüyor
      Ortak nokta varsa, tüm runtime kod tabanında beklenmedik paylaşımlı durumu bulup düzeltmek ve C ABI’sini gözden geçirmek zorunda olmak gibi şeylerdir

  • Python’un artık çok iş parçacıklı performansta Tcl’i yakalama şansı var: https://www.hammerdb.com/blog/uncategorized/why-tcl-is-700-f...

  • Python kodunu Mojo’ya port edip çok iş parçacıklılık, SIMD ve başka hız kazanımları elde etmeyi tercih ederim

    • Keşke Mojo daha tamamlanmış bir dünya olsaydı, ama şu anda o seviyeye hiç yakın değil
    • Katılıyorum. Ben olsam Rust, Nim, .NET ile baştan yazardım
    • -3’e kadar inen downvote’lar, HN downvote’larının mantıktan çok alan kavgası ve ego meselesi olduğunu iyi gösteriyor
      Python kodunu nogil Python’a taşımak istemiyor musun? O zaman downvote ederim gibi

  • Adlandırmak gerekirse python4, python3-gilfoil, python3-gilfree gibi şeyler olabilir

  • Şu anda GIL’siz Python’a odaklanılan yönelim bana epey tuhaf geliyor. Faster CPython ekibi, her sürümde CPython performansını %50 artırmak gibi iddialı bir hedef koymuştu.
    3.11’de gerçekten iyileşme vardı ama %50’nin çok gerisindeydi; testlerimizin önemli bir kısmında 3.12 benzer ya da daha yavaştı. Gerçek çok iş parçacıklılık harika olurdu, ama önce tek iş parçacığı performansının iyileşmesini çok daha fazla isterim.
    Elbette bizim ihtiyaçlarımızın herkesi temsil etmeyebileceğini kabul ediyorum ve Python’u harika bir dil yapmak için yapılan tüm çalışmalara minnettarım. Yine de neyi kaçırdığımı merak ediyorum.

    • Python’un birden fazla çekirdek kullanımı konusunda acil bir yanıtı olması gerektiğini düşünüyorum. AMD daha yeni 96 çekirdekli CPU çıkardı.
      Şu anda birden fazla çekirdek kullanımı multiprocessing üzerinden yapılıyor ve bunun çok fazla sınırı var. Birden fazla yorumlayıcının coroutine benzeri şeylerle birlikte gelebileceğini anlıyorum, ama yine de gerçek çok iş parçacıklı bir seçeneği daha çok tercih ederim.
    • Bunlar tamamen farklı iki hedef. Teoride çok iş parçacıklı Python belirli programları hızlandırabilir, ama bunun nasıl yapıldığı önemli.
      nogil Python’da örneğin Python nesneleri olarak erişilebilen paylaşılan durum varken birden fazla iş parçacığı C kodu çağırabilir. Bu makine öğrenimi için oldukça kritik ve aslında bu PEP’in mevcut biçimi PyTorch ekibinden çıktı.
      Tek iş parçacığı performansı da önemli, ama kritik bölümler için zaten numba, Cython ve Mojo gibi oldukça iyi geçici çözümler vardı.
      Sıralama da önemli. nogil devreye girerse faster CPython çalışmalarının önemli bir kısmı tamamen çöpe gidebilir; bu yüzden ekiplerin koordinasyon kurması gerekiyordu.
      İdeal dünyada hem nogil modu hem de tek iş parçacığı performans iyileştirmeleri olurdu. Guido da gelişmiş bir JIT’i düşündüğünü ima etti.
    • “Python”daki hesaplama maliyeti yüksek kısımlar numpy, tensorflow gibi kütüphanelerde işleniyor.
      Python, düşük seviyeli soyutlamaları daha yüksek seviyeli bir dilden ele almayı çok kolaylaştırıyor. Bu yüzden uzun süredir Python geliştiren biri olarak GIL konusunda çok stres yaşamadım.
    • PEP 703’te alıntılanan kişilerin ihtiyaçlarıyla sizin ihtiyaçlarınızın farklı olduğunu kaçırmış gibisiniz: <https://peps.python.org/pep-0703/#motivation>
    • Anladığım kadarıyla bunlar CPython içindeki ayrı projeler ve üzerinde mutlaka aynı kişiler çalışmıyor.
      İkisinden yalnızca birini seçmek gerekse, çoğu kullanım senaryosu için sadece daha hızlı tek iş parçacıklı kodun daha uygun olduğuna katılıyorum. Ama ikisine birden sahip olmamak için de bir neden yok.

  • Geriye dönüp bakınca açık görünüyor, ama Python tarafı 2’den 3’e geçişin ne kadar uzun ve sancılı olacağını bilseydi, yorumlayıcının içini de çok daha kapsamlı biçimde elden geçirirdi diye düşünüyorum.
    12 yıllık bir geçiş yaşandı, ama tek iş parçacığı performansı hâlâ berbat ve gerçek çok iş parçacıklılığa ulaşmak için hâlâ birkaç sancılı geçiş daha var.
    Açık kaynak geliştirmeye karşı anlayışlı olmak gerektiğini biliyorum, ama bir noktadan sonra buna çok kötü yönetilen bir dil diyebilir miyiz diye merak ediyorum.

    • Kötü yönetiliyor değil. Python’un çok sorunu var, ama hepsi Python’un başarısından kaynaklanan sorunlar.
      Python’un en kötü yanları, Python’un çok popüler ve ekosisteminin çok büyük olması nedeniyle değiştirilmesi zor olan kısımlar. Bu yüzden her tür değişiklik geriye dönük uyumluluk nedeniyle daha zorlaşıyor.
    • Doğru. Aradan bu kadar uzun zaman geçmiş olmasına rağmen multiprocessing hâlâ berbat.
      Python’u fazla hızlı savunma eğilimi var. Önyargısız ve objektif bakmak önemli.
    • Bir noktada Python ile aynı sözdizimine sahip, ama baştan daha iyi performans ve iş parçacığı desteği için tasarlanmış bir dil yapmak gerekmez mi diye düşünüyorum.
      Performans ve Python sözdizimi isteyen projeler oraya gidebilir. Mevcut Python, birden fazla hedef arasında debeleniyor ve hiçbirini düzgün gerçekleştiremiyor gibi görünüyor.
    • 2’den 3’e geçişin uzun ve kötü olacağı öngörülebilirdi; o dönemde de insanlar bunu söylüyordu.
      Perl 5/6 örnek gösterilmişti. Kimsenin geçiş yapmadığı netleştiğinde bile, bunu kolaylaştırma girişimlerine kadar yaklaşık 5 yıl daha geçti.