- Python Steering Council, PEP 703’ü kabul etme niyetini açıklayınca CPython’da GIL’in kaldırılması, deneysel derlemeden varsayılan moda geçişe uzanan uzun ve aşamalı bir sürece girdi
- GIL’in kaldırılması çok iş parçacıklı performansın önünü açabilir; ancak mevcut ekosistemin büyük kısmını oluşturan tek iş parçacıklı performans ve C eklentileriyle uyumluluk açısından maliyet yaratabilir
- Faster CPython ekibi, PEP 659 tabanlı özelleştirmeli uyarlanabilir yorumlayıcının GIL’e dayandığını; bu yüzden no-GIL ortamında optimizasyon stratejilerinin ve bakım yükünün yeniden hesaplanması gerektiğini düşünüyor
- Meta, PEP 703 kabul edilirse 2025 sonuna kadar 3 mühendis-yılı kaynak ayıracağını söyledi; Anaconda ise pip, cibuildwheel, conda-forge gibi paketleme çalışmalarını destekleme sözü verdi
- Geçiş, Python 2→3 dönemindeki kopuşu önlemeyi hedefliyor; no-GIL’in yaratacağı karmaşanın faydadan büyük olduğu düşünülürse varsayılan mod ilan edilmeden önce geri çekilebilir
Python’da GIL’in kaldırılması tartışması yeniden hız kazanıyor
- Python’un Global Interpreter Lock (GIL) mekanizması, aynı anda yalnızca tek bir iş parçacığının Python kodu çalıştırabilmesi için yorumlayıcı sanal makinesine erişimi seri hale getirir
- Birden çok iş parçacığıyla performans artışının önünü kesen GIL, uzun süredir Python’un eski zayıf noktalarından biri olarak sıkça anılıyor
- Sam Gross, Ekim 2021’de no-GIL Python kavram kanıtı sürümünü yayımladı; ilk ilginin ardından bir yıldan uzun süre boyunca ilerleme sınırlı kaldı
- Daha sonra Python Steering Council, no-GIL özelliğini kabul etme niyetini duyurdu
- Gerçek bir sürümün içine girmesi zaman alacak
- Gelecekte bir noktada çalışmanın geri alınması ihtimali de hâlâ var
- Birden fazla şirketin desteğiyle başarı olasılığı arttı
Faster CPython ile tek iş parçacıklı performans arasındaki gerilim
- 2022 Python Language Summit’te Gross, no-GIL fork’unu sunarak çalışmayı ilerletmek için zımni onay almaya çalıştı; ancak ayrıntılı etkiler yeterince bilinmediğinden bu bir mutabakata dönüşmedi
- Aynı dönemde Faster CPython projesi, yorumlayıcının tek iş parçacıklı performansını artırmaya odaklanıyordu
- Mark Shannon, PEP 659 “Specialized Adaptive Interpreter”ı yazdı; bu değişikliklerin bir kısmı Python 3.10 ve 3.11’e girdi
- PyCon’da Faster CPython ekibinden Brandt Bucher uyarlanabilir komutları, Shannon ise bellek yerleşimi iyileştirmelerini ve diğer optimizasyon tekniklerini sundu
- Mevcut Python programları GIL nedeniyle neredeyse tamamen tek iş parçacıklı yazıldığı için tek iş parçacıklı performans artışı, Python ekosisteminin genelinde hissedilen performansı doğrudan etkiler
PEP 703 önerisi ve ilk kaygılar
- Łukasz Langa, Ocak 2023’te Gross’un yazdığı PEP 703 “Making the Global Interpreter Lock Optional in CPython”ın ilk sürümünü yayımladı
- no-GIL’e yönelik beklentilerin yanında, C ile yazılmış Python eklenti modülleri başlıca kaygı olarak öne çıktı
- GIL, C eklenti kodunda birçok eşzamanlılık sorununu engelleyen bir rol oynuyordu
- GIL’in kaldırılması bu kodlarda yeni hatalar oluşturabilir
- Python 2’den 3’e geçişteki gibi bir flag day geçişinden kaçınılması gerektiği konusunda ortak görüş vardı
- GIL kaldırma geçişi, henüz hazır olmayan kodlarla da sorunsuz çalışmalı
- Shannon, tek iş parçacıklı kodda kabul edilebilir performans düşüşünün ne kadar olduğunu sordu; kendi tahmini %15~20 aralığındaydı ve PEP 659 üzerindeki etkisine bağlı olarak bunun daha da büyüyebileceğini düşündü
- Eric Snow, PEP 684 “Per-Interpreter GIL” ve PEP 683 “Immortal Objects” yazarlarından biri olarak uzun bir analiz paylaştı; no-GIL ile alt yorumlayıcı yaklaşımının mutlaka çatışmak zorunda olmadığını düşündü
C eklentileri için ortaya çıkan maliyetler ve faydalar
- Gross, C eklentileri üzerindeki etkinin tamamen olumsuz olmadığını söyledi
- PEP’te, yaygın kullanılan C API eklentilerinin bakımcılarının GIL’i atlatma çalışmalarında yaşadığı karmaşıklığa dair alıntılar yer aldı
- PyTorch çekirdek geliştiricisi Zachary DeVito, son birkaç ay içinde üç kez, gerçek sorunu çözmekten bir basamak daha fazla zamanı GIL sınırlamasını atlatmayı anlamaya harcadığını belirtti
- no-GIL, eklenti modülü bakımcıları için yeni eşzamanlılık sorunları yaratabilir; ancak aynı zamanda GIL’den kaçınmak için gereken karmaşıklığı da azaltabilir
Güncellenen PEP ve performans tartışması
- Gross, Mayıs 2023 başında Python 3.12 geliştirme sürümüne dayanan PEP 703 uygulamasını ve güncellenmiş PEP’i yayımladı
- 12 Mayıs’ta Steering Council’den PEP hakkında karar istedi; ancak karar öncesinde daha fazla tartışma sürdü
- 2 Haziran’da Shannon, PEP’in performans etkisini değerlendirerek %11~30 aralığında bir etki sundu ve bu sayı tartışma yarattı
- Shannon, uyarlanabilir özelleştirme yorumlayıcısının GIL’e bağımlı olduğunu; bu yüzden no-GIL kabul edilirse optimizasyon stratejisinin yeniden tasarlanması gerektiğini düşündü
- Yeniden tasarım ve uygulamaya harcanan emek, fiili optimizasyon çalışmalarına aktarılamayacak
- Langa, Shannon’ın tahmininden çok daha küçük etki gösteren benchmark sonuçları yayımladı; ek sonuçlar Gross’un PEP’te raporladıklarına yakındı
Python 2→3 geçişinden alınan dersler
- Guido van Rossum, Python 2 ve 3 kodları aynı yorumlayıcıda birlikte var olabilseydi geçişe yardımcı olacağını düşündü
- no-GIL ilerleyecekse, GIL gerektiren eklenti modüllerinin de no-GIL yorumlayıcıda ek çalışma olmadan import edilebilmesi gerektiğini vurguladı
- Uygulama kodunun da değiştirilmesine gerek olmamalı
- Eklenti modüllerinin de değiştirilmesine gerek olmamalı
- Steering Council üyesi Gregory P. Smith, PEP 703’ün etki alanının çok geniş olduğunu ve hemen karar vermeye hazır olmadıklarını belirtti
- Smith, talep olduğunu kabul etmekle birlikte tüm ekosistemi göz önünde bulundurmak ve dünyayı bozmayan bir geçiş yolu bulmak gerektiğini düşündü
- Gross, net kabul kriterleri ve takvim olmadan kararı ertelemenin pratikte “hayır” gibi işlediğini söyledi
Faster CPython ekibinin gördüğü üç seçenek
- Shannon, “A fast, free threading Python” tartışmasında gelecekteki seçenekleri üç başlıkta özetledi
- Mevcut plan doğrultusunda hızlı tek iş parçacıklı yorumlayıcı hedeflemek
- Tek iş parçacıklı performansa etkisi bilinmeyen ama sıfır olmayan no-GIL free-threading yorumlayıcı hedeflemek
- İkisini aynı anda hedeflemek
- Shannon, performans, paralellik ve değiştirilebilirlik arasında hangisinin sınırlandırılacağının seçilmesi gerektiğini düşündü
- Bunun “Performance, parallelism, mutability: pick two”dan ziyade “kısıtlamak için birini seç”e yakın olduğunu ifade etti
- free-threading ortamında Python’u hızlı hale getirmek için özgün araştırma gerektiğini, maliyet ve riskin daha yüksek olduğunu uyardı
- Tercih ettiği seçenek üçüncüsüydü; ancak yalnızca no-GIL’i seçip “birileri performans sorununu çözer” diye beklenmemesi gerektiğini düşündü
- van Rossum da free threading ile hızlı thread başına performansı birlikte elde etmenin en iyisi olduğunu düşündü; ancak bunun ek kaynak gerektirdiğini vurguladı
Şirket desteği ve çekirdek geliştiricilerin görüşü
- van Rossum, Microsoft’un Faster CPython ekibini desteklemeye devam ettiğini ve bu ekibin rolünün yalnızca tek iş parçacıklı performans çalışmalarıyla sınırlı olmadığını söyledi
- no-GIL dünyasına uygun şekilde özelleştirme ve optimizasyon çalışmalarını ayarlayıp, nihayetinde tek iş parçacıklı performans düşüşü olmadan no-GIL’i tek derleme modu yapmayı hedef olarak sundu
- Meta’dan Carl Meyer, PEP 703 kabul edilirse Meta’nın 2025 sonuna kadar 3 mühendis-yılı kaynak ayıracağını belirtti
- CPython iç yapısı konusunda deneyimli mühendisler core dev ekibiyle çalışacak
- PEP 703 uygulamasını CPython’a sorunsuz biçimde yansıtacak
- no-GIL CPython’un uyumluluğunu ve performansını geliştirmeyi sürdürecek
- Anaconda’dan Stan Seibert, PEP 703’ün benimsenmesiyle doğacak paketleme sorunlarını destekleyeceğini belirtti
- pip, cibuildwheel, conda-forge ile ilgili çalışmalar dahil
- no-GIL uyumlu paketleri Python topluluğuna ulaştırmak için gereken işler dahil
- core developer anketinde 46 kişiden %87’si free-threaded Python’ın aktif biçimde ilerletilmesi gerektiğini söyledi; 38 kişiden %63’ü PEP 703 tabanlı no-GIL Python’un destek ve bakımına katkı vermeye istekli olduğunu belirtti
Steering Council kararı ve aşamalı geçiş
- 28 Temmuz’da Thomas Wouters, Steering Council’ın PEP 703’ü kabul etmeye karar verdiğini; ancak kabul ayrıntılarının hâlâ üzerinde çalışıldığını duyurdu
- Yaklaşım, önce no-GIL yorumlayıcıyı devreye alıp eksikleri görmek; no-GIL varsayılan ve sonunda tek sürüm haline gelmeden önce gereken çalışmaları tamamlamak
- Geçiş süresinin yaklaşık 5 yıl olacağı tahmin ediliyor
- Council, Python 3 benzeri bir durum istemiyor; no-GIL derlemesine uyum için gerekli üçüncü taraf kod değişikliklerinin with-GIL derlemesinde de aynen çalışması gerektiğini düşünüyor
- Kısa vadede, Python 3.13 zamanına denk gelebilecek deneysel no-GIL derlemesi öneriliyor
- Python 3.13’ün Ekim 2024’te çıkması planlanıyor
- core developer’ların ve başkalarının deneyebileceği bir derleme
- Orta vadede no-GIL, varsayılan olmayan desteklenen bir seçenek olacak
- Zamanlama büyük ölçüde topluluğun no-GIL derlemeyi ne kadar hızlı benimsediğine ve desteklediğine bağlı
- Uzun vadede no-GIL varsayılan derleme olacak ve GIL tamamen kaldırılacak
- Gereksiz yere geriye dönük uyumluluğu bozmayan bir yöntem olmalı
Hâlâ tamamlanmamış işler
- Wouters, GIL’in kaldırılmasının tek bir PEP’i kabul etmekten çok daha büyük bir iş olduğunu düşünüyor
- core developer’lar no-GIL Python deneyimi kazanmalı ve buna dayanarak topluluğun geri kalanına öncülük etmeli
- Mevcut kodun thread-safe hale getirilmesi sürecinde yeni C API ve Python API gerekebilir
- Tüm süreç boyunca ilerleme ve takvim düzenli olarak yeniden değerlendirilmeli
- Bu, geriye dönük uyumluluk için yeni bir 10 yıllık mücadeleye dönüşmemeli
- PEP 703 sorun yaratacak gibi görünürse durdurulup başka çözümler aranabilmeli
- no-GIL-only Python’a ulaşmak için hâlâ çok sayıda araştırma, kodlama, test, deney ve dokümantasyon işi var; örnek olarak Python 3.17’nin çıkabileceği Ekim 2028 gündeme geliyor
1 yorum
Hacker News yorumları
Yazı iyi yazılmış ve tüm süreci iyi özetlemiş, ancak ağırlığı GIL’in kaldırılmasına karşı çıkan tarafa ve başarısızlık olasılığına vermiş gibi
Karşı tarafı da yeterince vurgulamak gerekiyor. Sam Gross’un yaptığı işin kalitesi çok yüksek; no-GIL ile doğrudan ilgili olmayan performans iyileştirmeleri de ekleyerek performans kaybını azalttı. Açık kaynak yöntemiyle de çok iyi ilerledi ve topluluk baskısı olmasaydı yönlendirme kurulunda sürekli bekletilecek kadar yavaş tepki verilmesine rağmen sabır gösterdi. Alt yorumlayıcılar Python’da, özellikle de ciddi metriklerle, kullanışlılıklarını şimdiye kadar neredeyse hiç göstermedi; bu da iyi tanımlanmış ve ölçülmüş ilk denemeye yakın. Topluluğun tepkisi de bu projeye büyük ilgi olduğunu gösterdi ve yönlendirme kurulu da “PEP 703’ü kabul etmeye niyetliyiz ve ayrıntılı kabul koşullarını netleştiriyoruz” sonucuna vardı. no-GIL’in ateşli bir destekçisi değilim; sonunda kaldırılmasa da sorun etmem ve önce alt yorumlayıcıların denenmesi gerektiğini düşünüyorum, ama adil bakmak gerek
Sonuçlar da epey etkileyici: https://lwn.net/SubscriberLink/941090/8bcb029dbf548f26/. Beklenebileceği kadar iyi görünüyor. Alt yorumlayıcı çalışmaları muhtemelen free-threading çalışmalarıyla paralel yürüyecek ve ikisinin kullanım alanları farklı
Bildiğim kadarıyla PDM hâlâ destekliyor. Derleme ve dağıtımda virtualenv kullanmaktan hoşlanmıyorum; Python’ın da JavaScript gibi davranabilmesini isterdim. Bunun mümkün olduğu zaten kanıtlandı. Tartışma başlığı https://discuss.python.org/t/pep-582-python-local-packages-d... adresinde. “Tam olarak tek bir doğru yol” ifadesinin ret gerekçesi gibi kullanılmasına da sinir oluyorum; Python’da bunun doğru olduğunu hiç hissetmedim
LWN’nin harika bir yazısıydı ve okumaya fazlasıyla değdi. Sam Gross’un NoGIL’i ilk ortaya çıktığında umutlanmıştım, ama yazıyı okuyup kişisel deneyimlerimi düşününce fikrim değişmeye başladı
Birkaç dilde arka uç sistemleri geliştirdim ve bunlar genel olarak sadece iki türdü. Biri ağ uç noktaları açıp istek alan, hesaplama ve başka ağ isteklerinden sonra yanıt dönen sistemler; diğeri ise kuyruklardan, veritabanlarından, başka API’leri yoklamaktan vb. mesaj okuyup hesaplama ve ağ çağrıları yaptıktan sonra başka bir kuyruğa gönderen sistemler. İlkinde gecikme süresi önemli, ikincisinde işlem hacmi önemli. İlk türde, isteğe göre thread başlatmak, hesaplaması ağır bir endpoint’in diğer istekleri engellememesi ve veritabanı bağlantı havuzunu paylaşmak istediğiniz için NoGIL yararlı. İkinci türde ise GIL olmayan dillerde bile paylaşılan kaynakları olan süreç içi paralellik ya da eşzamanlılık kullandığımı neredeyse hatırlamıyorum; anlaması çok zorlaşıyor. Optimizasyon genellikle akıllı batch işleme oluyordu; paralellik ise birden çok bağımsız süreci birden çok makinede çalıştırmak şeklindeydi. NoGIL yüzünden ikinci tür sistemlerin kalitesi taviz verirse oldukça hayal kırıklığı yaratır; gerçekten de şu anda zihinsel enerjimin çoğunu ikinci türü iyileştirmeye harcıyorum
Şu anda JournalParser’ı QThread ile uyguluyorum; bu parser, Elite: Dangerous ve Odyssey’nin ürettiği oyuncu günlük dosyalarından oyun olaylarını sürekli okuyor ve olay başına özel QSignal yayımlayarak ilgili Signal’ı dinleyen slot’un işlemesini sağlıyor. Uygulamanın başka kısımlarında da GIL’in olmaması oldukça yararlı olabilir. https://captainslog.scarygliders.net/captains-log-2/
Böylece herkesin kodu iyileşebilir
Elbette CPU odaklı programların baştan Python ile yazılmaması gerektiği de söylenebilir, ama o başka bir mesele
Paylaşılan kaynak salt okunursa bunun neden kafa karıştırıcı olacağını pek bilmiyorum
Bağlantılı başlıktaki “GIL’in kaldırılmasının yalnızca Python’dan oluşan kod tabanlarını bozma olasılığı çok düşük” cümlesinin gerçekten doğru olup olmadığı şüpheli görünüyor
Bazı çok iş parçacıklı Python kodları, GIL sayesinde belirli işlemlerin örtük olarak thread-safe olduğunu bekleyebilir. Örneğin iki thread aynı listeye öğe eklediğinde listenin bozulmaması, GIL nedeniyle iki thread’in bu işlemi paralel yürütmemesinden kaynaklanır. GIL kaldırılırsa, C++’ta
std::vector’ı aynı anda değiştirirken olduğu gibi, bu tür kodlar bir anda cezalandırılabilir. Emin değilim ama bu cümle biraz kuşkulu. https://discuss.python.org/t/pep-703-making-the-global-inter...map’i eşzamanlı değiştirdiğinizde panic oluşan benzer bir durum varPEP 703’ün container thread safety bölümü bu sorunu ele alıyor. Her
list,dictionary,setiçin hafif, nesne başına bir kilit koymayı; nesneyi değiştiren tüm işlemlerin bu kilidi almasını ve çoğu okuma işleminin de kilidi almasını öneriyor. Ayrıntılar https://peps.python.org/pep-0703/#container-thread-safety adresindeHashtable,Vectorgibi mutex ile korumak dışında pek parlak bir yol görünmüyorAncak bunu yapınca, senkronize edilmemiş
[]gerektiğinde ne yapılacağı sorusu kalıyorappendişlemi muhtemelen örnek başına kilit ile korunacak. En azından bazı nogil kavram kanıtı kodlarında böyleAçık kaynakta bundan daha zor bir sınav hayal etmek güç
Kararın kendisi makul. Test modu olarak ilerlemek, çoklu yorumlayıcıları ara bir deney olarak ele almak, ama hedefi eşzamanlı çalışabilen Python olarak belirlemek. Ancak mevcut kodla yeni kodu aynı sanal makinede çalıştırma kısıtı çok büyük. LWN özetinin test konusuna neredeyse hiç değinmemesi şaşırtıcı; test hâlâ oldukça çözülmemiş durumda ve bilinmeyen ama ciddi hatalar içeren sürümlere yol açabilir. Microsoft, Facebook/Meta ve Conda kaynak sağlıyor; çekirdek katkıcıların ezici çoğunluğu ilerlemek istiyor. Ama işler zorlaştığında ve daha fazla insana ihtiyaç duyulduğunda ne olacağı belirsiz. Aynı zamanda web sitelerinden büyük veriye ve yapay zekaya kadar akademi ve endüstrideki devasa projeler Python’a dayanıyor; Python geliştiricilerine yüklenecek maliyet GSYH oranı ile ölçülebilir bile. Sorunlar henüz biliniyor gibi de görünmüyor; bu yüzden önümüzdeki 3+ yıl boyunca öngörülebilir iyileştirmeler yapan Faster CPython yaklaşımına odaklanmak, eşzamanlı çalışabilen Python destekçilerinin ise basit prototiplerin ötesine geçip hangi sorunların çıkabileceğini, bunların nasıl tespit edileceğini ve ne yapılabileceğini analiz etmesi gerekiyor. Eşzamanlılık garantilerini kanıtlamış arka plana sahip kişilerin incelemesi ve bilinmeyenler en azından belirlendikten sonra soruların yönlendirme kuruluna götürülmesi daha adil olur. Açık kaynakta program yönetimi ölçeğinde karar çok olmadı; Apache, Eclipse, Linux gibi örneklerde piyasa yönünü belirleyen nispeten basit kararlar daha fazlaydı. Ama burada gerçek teknik bilinmezler var. Aynı zamanda diller arası ABI konusunun da ele alınması gerektiğini düşünüyorum. Büyük sorun, C’nin beklediği yürütme modeliyle uyum sağlamak; Java’nın Foreign Function & Memory API’si yıllardır incubation aşamasında, Swift de C ve C++ sarmalama konusunda gelişiyor, ama FFI kötü şöhretli ve muhtemelen gereksiz yere zor
Kişisel olarak GIL’in kaldırılmasının bir hata olduğunu düşünüyorum. Bundan güçlü biçimde fayda görecek uygulama sayısı çok fazla değil; çoğu ise performans cezası alacak
Bu çalışma yıllarca ilgi ve emek tüketecek; bence bunlar daha akıllıca kullanılabilirdi. Python, GIL konusunda sanki bir kaygı ya da aşağılık kompleksi taşıyor gibi görünüyor. Bence JavaScript gibi tek thread’li modeli tamamen benimsemek daha iyi olurdu. Bazı uygulamalar yine zor ya da imkânsız kalırdı, ama yüksek performans veya yüksek ölçeklenebilirlik gereken uygulamalar için Python’ın iyi bir tercih olduğunu düşünmüyorum. Bir ölçüde uzmanlaşmış olmak ve tüm kullanım senaryolarını desteklememek illa kötü bir şey değil
İnsanların şu anda Python ile zaten yaptığı işler için performansa ihtiyacı var. Bunun doğru olmadığı zamana geri dönemeyiz. Artık bu, Python’ın en yaygın kullanım alanlarından biri ve insanlar kariyerlerini buna bağlıyor
İnsanlar zaten Python ile paralel işler yapmaya çalışıyor. Onları başka dil kullanmaya zorlamak pek yardımcı olmaz
Veri yoğun işlerin önemli bir kısmı Python’da paralel süreçler olarak kolayca çalıştırılabildiği için, GIL’in kaldırılmasının gerçekten o kadar büyük bir kazanç olup olmadığından emin değilim
Tek iş parçacıklı performansı, daha fazla para harcayarak iyileştirmek çok daha zor olduğundan daha öncelikli olmalı
Çok iş parçacıklı performansta ise bir çekirdek daha ekleyerek süreç tabanlı paralelleştirmenin ek yükü telafi edilebilir. GIL ile no-GIL ikiliğinin kendisinin yanlış olduğunu düşünüyorum. multiprocessing’deki en büyük sorun belleğin paylaşılamaması. Dolayısıyla açık bir bellek paylaşım mekanizmasına sahip sanal süreçler eklemek yeterli olur. Böylece nesne tek bir iş parçacığında kalır ve bariyersiz referans sayımı gibi tek iş parçacıklı optimizasyonlar korunabilir
GIL olmadan da tek iş parçacıklı performans iyi hale getirilebilir. Rust’ta sıfır maliyetli soyutlamalar kavramı var ve iş parçacıklarını da iyi ele alıyor. Java da tek iş parçacıklı işleri iyi yapıyor. Başka birçok dil de var; bu bilimkurgu değil. Kilitler optimizasyonla ortadan kalkabilir, hiç kilit içermeyen kod da seçilebilir; ince taneli ya da yapılandırılmış eşzamanlılık da mümkün. Neyin iş parçacığı açısından güvenli olduğu temelde bir API sözleşmesidir. İyimser kilitleme de var. Python’ın benzer şeyler yapamaması için iyi bir neden yok, ama önce GIL’in kaldırılması gerekiyor. GIL’siz Python’daki performans kaybı büyük ölçüde çözülmemiş teknik borca benziyor ve zamanla düzeltilebilir. Çok sayıda kilit eklemek geçici bir çözüm olduğu için yavaşlatır; asıl çözüm muhtemelen iç işleyişi yeniden düşünmek ya da iş parçacığı güvenliğini belgeleyen API sözleşmelerine sahip olmak olacaktır. Daha hızlı bir Python çalışma zamanı ve derleyici, bugün yerel kütüphanelere dayanan birçok şeyin Python’da yeniden uygulanmasını da mümkün kılabilir. Yerel kodla etkileşim, kilit gerektiren birçok noktanın asıl bulunduğu yer; bu yöntem değişmedikçe sorun olmaya devam eder. GIL’i kaldırmanın özü, bu tür şeyleri sistematik biçimde bulup düzeltmekte ve zamanla daha iyi hale gelecektir
Python/multiprocessing’in tek sorunu, bazen kuyruk değil paylaşılan değiştirilebilir duruma ihtiyaç duyulması. Şu anda Python nesnelerini paylaşılan belleğe koyma yolu karmaşık, sınırlı ve verimsiz. Düzeltilmesi gereken hedef bu; Python’ın yerel instance’ları paylaşılan belleğe yerleştirmek için daha iyi desteğe ihtiyacı var
“Tek iş parçacıklı kodda ne kadar performans düşüşü kabul edilebilir?” sorusuna Shannon %15–20 civarında bir tahmin verdi, ancak bu soru genel olarak yanıtsız kaldı
Yani “CPython’ı daha hızlı” hale getiren projedeki bazı kişiler, mevcut Python kodlarının çoğunu bir gecede %15–20 yavaşlatmayı kabul edilebilir mi görüyor? Bence sınır en fazla %5 civarı olmalı. O da ancak GIL’in kaldırılması gelecekteki başka optimizasyonlara yardımcı olacaksa mümkün. Oysa bu değişikliğin başka optimizasyonları daha karmaşık hale getirip geciktirdiği söyleniyor. Öte yandan Shannon, 2020’de kişisel olarak CPython’ı 5 kat hızlandırma vaadiyle bağış toplama önerisinde bulunmuştu; şimdi ise çok daha büyük kurumsal destek alan bütün bir ekip CPython’ı hızlandırıyor, ama hedef çok daha küçük görünüyor
Performans gerçekten önemli olduğunda, başka bir dile yeniden yazmadan yaklaşık 20 kat hız artışı elde edilebiliyorsa bunun anlamı büyük
Başka optimizasyonlar durmayıp yalnızca biraz daha uzun sürecekse bu kabul edilebilir olabilir
Ağ ya da disk erişimi olmadan sayısal ve string işlemleri içeren gerçek kodları karşılaştırınca 3.12 beta, 3.8’den yalnızca yaklaşık %20–25 daha az zaman alıyor. Bu 2.7 seviyesi. Eski kilit isimler, bir sonraki sürümde kurumsal sponsorlara gösterecekleri bullet point özellikleri umutsuzca arıyor gibi görünüyor. Bu yüzden Sam Gross’un çalışmasını kullanıyorlar, ama zamanla itibarın yavaş yavaş onlara geçeceğini düşünüyorum
LWN’ye yakışır şekilde harika bir özet
Python topluluğunu seviyorum. Açık kaynak yazılımın öncü örneklerinden biri ve şeffaflık ile iyi yönetişimin neler başarabileceğini gösteriyor. Meta, Microsoft vb.’nin ayırdığı mühendislik zamanı için minnettarım; ancak teknoloji sektörünün tamamının ve veri bilimi dâhil daha geniş alanların Python ile açık kaynak yazılımdan elde ettiği değerle kıyaslandığında bu hâlâ çok cılız kalıyor
8 yıl önce JPMorgan’da teknoloji liderlik ekibini PyCon UK’ye sponsor olmaya, işe alım standı açmaya ve Birleşik Krallık genelindeki JPMorgan junior geliştiricilerinin katılımını desteklemeye ikna ettim. 5 yıl önce JPM’den ayrıldım, ama hâlâ PyCon UK’nin ana sponsoru. Python ve açık kaynak ekosisteminden elde edilen muazzam faydaya kıyasla tamamen ihmal edilebilir bir maliyetti
E-posta listeleri sansürleniyor, iç çevre eleştirilemiyor. Gerçek katkıda bulunanlar, doğru şirketlerde olup pek bir şey yapmadıkları halde idari yetki pozisyonlarını işgal eden kişiler tarafından sömürülüyor. LWN yazısı çok olumlu ve karar vericilerin adlarını her zaman iyi biçimde anıyor; bu yüzden buna kanmamak gerek. Bana seçici haberciliğe daha yakın görünüyor
Sam Gross’un bunu ilerletme biçimi oldukça etkileyici. Yürütme kurulundan olumlu ama kesin olmayan bir yanıt aldıktan sonra oturup ilerleme bekleyebilirdi; ama karşı çıkıp baskı kurması gerçekten çok takdir edilesi
Çok ilginç. Sam Gross’un “Şu anda hemen bir evet/hayır gerekmiyor, ama kabulün nasıl görüneceğini bilmemiz gerekiyor ve bu mesele çok uzun süredir bekletiliyor” demesi oldukça cesur bir hamleydi: https://github.com/python/steering-council/issues/188#issuec...
Bu etkileşim birçok farklı yöne gidebilirdi, ancak yönlendirme kurulunun tam da ihtiyaç duyduğu dürtü buymuş gibi görünüyor. no-GIL Python’a giden yol hâlâ uzun ve dolambaçlı; çift haneli mühendis-yıl ölçeğinde emek gerektirecek, ama en azından düzgün bir yol oluşmuş görünüyor. En zor kısım, mevcut kod tabanlarının doğruluğunu garanti etmek. Python 2’den 3’e geçişi tekrarlamak istemediğini söylemek başka; kırıcı değişiklik olmayacağını iddia etsen bile, hata korkusu yüzünden insanların gerçekten yükseltmeden kaçınması bambaşka bir mesele. GIL/no-GIL’i yalnızca derleme zamanı anahtarı olarak tutmak bile bakım maliyetini kesinlikle artırır. Yine de uzun vadede bu çabanın değeceğini düşünüyorum. GIL, Python eleştirilerinin paratoneri gibi ve Python ile paralellik hakkındaki HN başlıklarına bakmak bile bunu gösteriyor. Muhtemelen insanlar onlarca yıllık bağlamı anlamadan da “Python’ın daha hızlı olamamasının nedeni bu” diye doğrudan işaret edebilecekleri bir şey olduğu içindir. Bu anlamda Chesterton’ın çiti final boss’una yakın
Yeni yönergeler altında bile GIL’i kaldırmaya yönelik yıllar süren çabanın sonunda reddedilmesi hâlâ mümkün