Python 3.12 için Windows SciPy derlemesi küçük bir mucize olarak değerlendiriliyor

• conda-forge’un SciPy Windows derlemesi, Python 3.12.0’ın yayımlanmasından iki gün sonra sunuldu; böylece SciPy kolundaki Python 3.12 geçişi aylarca takılmak yerine yalnızca birkaç günlük gecikmeyle ilerledi
• Python 3.12’de distutils standart kütüphaneden kaldırılınca SciPy, numpy.distutils yerine Meson derleme aracına geçmeye karar verdi
• Meson, conda-forge’un kullandığı MSVC+gfortran kombinasyonunu reddetmeyi planlıyordu ve Windows’ta conda-forge’un kullanabileceği ücretsiz, ABI uyumlu bir Fortran derleyicisi yoktu
• conda-forge, Windows’ta SciPy’yi yeniden derleyemezse SciPy’ye bağımlı en az yaklaşık 1.000 paketin geçişinin tüm platformlarda gecikeceğini ya da Python geçişinde Windows’un hariç tutulması gerekeceğini öngördü
• LLVM 17.0, Flang’de -flang-experimental-exec bayrağını kaldıran ilk sürümdü ve Flang’in “0.8 seviye olgunlukta” olduğu tahmin ediliyordu
• Meson’a llvm-flang işleme desteği eklendikten sonra SciPy derleme ve kurulumunda başarı sağlandı; testler 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning sonuçlarıyla %100 geçti {p:100}

[GN⁺]

Hacker News yorumları

• Gerçekten harika bir yazıydı; artık Python 3.12'de pip install neden başarısız oluyordu biliyorum, ama bundan sonrası daha parlak görünüyor
  Python'ı seviyorum; ayrıca Python paketlemesinin neden yönetilebilir düzeyde bir keşmekeş olduğunu anlamama da yardımcı oldu
  Sebep Python'ın kendisi değil, C/C++/Fortran derleme araçlarının standartlaşmamış olması ve ekosistemin devasa boyutu; bir ölçüde azaltılamayan bir karmaşıklık
  Bunun çalışıyor olması bile mucizeye yakın

  • Doğru, Python paketlemesinin karmaşık olmasının temel nedeni burada yatıyor
    Python'ın başarısı büyük ölçüde kritik karma dilli paketleri kullanabilmesinden kaynaklandı; diğer ana akım dil paket yöneticileri bu tür sorunlarla pek ilgilenmez
    Örneğin Rust'ın cargosu harika, ama çoğunlukla yalnızca Rust kodu paketlemeyi varsayabiliyor; derlenen bir dil olmasına rağmen dil derleyiciyi “sahiplendiği” için kaynak koddan derleyerek dağıtım stratejisi işe yarıyor
    cargonun Fortran'ı varsayılan olarak nasıl ele aldığını bilmiyorum ama Windows'ta üst düzey cargo paketleri Fortran kodu gerektirseydi, düzgün çalışması zor olurdu gibi geliyor
    Python ekosistemindeki en büyük iyileştirme, ikili paket biçimi olan wheel'in standartlaşmasıydı; bilimsel Python ekosistemi Windows'ta ancak o zaman gerçekten serpilip gelişmeye başladı
    Ne var ki ikili uyumluluk, özellikle diller ve CPU'lar arasında geçiş yaparken muazzam bir baş belası
  • Bunun Python'la ilgisi yok demek zor; bu FFI bindinglerinin var olmasının nedeni Python'ın çok yavaş olması
  • “Bunun çalışıyor olması bile mucize” ifadesine katılıyorum
    Yazılım ekosistemlerinin karmaşıklığı üstel biçimde artıyor gibi görünüyor; sonunda Babil Kulesi tarzı bir çöküşe gitmesini neyin engellediğini merak ediyorum
    Elbette yalnızca yazılıma özgü bir sorun değil, ama iyi bir örnek
  • Gerçekten ufuk açıcı bir yazıydı
    İnsanların sevdikleri paket yöneticisini Python'ınkiyle karşılaştırıp Python'ın berbat olduğu sonucuna vardığını sıkça görüyorum; oysa gerçekte öyle değil
    Yalnız anlayamadığım şey, Python tarafındakilerin neden Fortran yerine C/C++ matematik kütüphaneleri kullanmadığı
  • Asıl sorun, Python'ın yazılım geliştirme eğitimi almamış insanları kendine çekme eğiliminde olması gibi görünüyor
    Keşmekeşin üstüne bir keşmekeş daha eklenmiş oluyor

• Linux, gevşek biçimde koordine olmuş hacker'ların kimi zaman pratik olmayan ideolojik kısıtlarla yürüttüğü gıcırdayan, uç bir örnekken; parlak insanların ona destek eklemek için muazzam çaba harcaması fantastikti
  Ama şimdi o gıcırdayan uç örnek, kısıtlarının niteliği düpedüz düşmanlığa yakın olan tescilli bir sisteme ve siber derebeyleri tarafından işletilen bir yere dönüşünce, onu destekleme işini eskisi kadar olumlu görmek zorlaşıyor
  Bir yandan, bu araçları herkesin kullanabilmesini sağlamaya yönelik derin özen gerçekten harika ve bu çalışmayı alkışlıyorum
  Yön değiştirmelerini söylediğim falan yok; sadece insanın aklını kurcalıyor
  Eskiden “vay be, bu çalışmanın ilerlemesine gerçekten sevindim” diye düşünürken, şimdi daha çok “vay be, şu harika insanlar bu işe takılıp kalmasaydı neler başarabilirlerdi” diye düşünüyorum

  • Aslında bunu mutlaka onların yapması gerekmiyor
    Birçok kez belirtildiği gibi SciPy geliştiricileri gönüllü
    Hikâyenin büyük kısmı, SciPy'ın Windows için açık kaynak bir Fortran derleyicisi yapacak birilerinin çıkmasını neden beklemek zorunda kaldığını açıklıyor; kurtuluşu da ağırlıklı olarak NVIDIA geliştiricileri sağlamış gibi görünüyor
  • Bu bile meselenin özü değil
    SciPy, Python çekirdek geliştiricilerinin Windows'ta Python araç zinciri için MinGW yerine MSVC'yi seçme yönündeki aptalca ve son derece taraflı kararının bedelini ödüyor
    Bunun motivasyonunun Microsoft sponsorluğundan kaynaklandığını düşünüyorum
    Çekirdek geliştiriciler listesinde epey Microsoft çalışanı var; Microsoft onlara bu listede yer almaları için ödeme yapıyor, ayrıca CPython projesinin CI sunucularının masrafını da Microsoft karşılıyor
    Python araç zincirinde tescilli araçlar kullanmasaydı, bu bütün sorun önlenebilirdi

• “Meson’ın conda-forge’da kullanılan MSVC+gfortran kombinasyonunu reddetmeye çalıştığı” ifadesi kulağa bir hata gibi geliyor
  Derleme araçlarının amacı verilen komutları çalıştırmaktır; “üzgünüm Dave” deyip engel olmak değil diye düşünüyorum

  • Aslında şikâyet eden taraf MSVC bağlayıcısı
    Sorun, MSVC ile gfortran’ın kullandığı C çalışma zamanı; özellikle de gfortran’ın kendi çalışma zamanı kitaplığı C ile yazılmış durumda ve bu ikisi ABI açısından uyumlu değil
    NumPy’nin kullandığı geçici çözüm, Fortran nesnelerini DLL olarak bağlayıp içe aktarma kitaplığı şeklinde dolaylı bir katman eklemek ve MSVC’yi yatıştırmaktı
    Bu yüzden böyle bir DLL oluşturmak için ek iş gerekiyordu
    Bunu ister derleme açıklama dosyasında ister Meson’da yapmak gerekiyordu; ancak SciPy tarafı bu dolaylı katmanı iki tarafta da uygulamak istemedi, Meson geliştiricileri de aktif biçimde yardımcı olmak istemedi
    Elbette Meson geliştiricileri Fortran ve Cython desteği gibi genel konularda yardım ettiler, ama tehlikeli bir basamak sunmak istemediler
    Gerçekte bu daha çok bir hack’e yakındı; örneğin yalnızca Fortran tarafı Python/C tarafında açılmış dosyaları kullanmadığı için çalışıyordu
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • Yazı iyi yazılmış ve ayrıntılıydı, ama Meson’ın “C ve C++ projelerinde yaygın kullanıldığı” iddiası beni biraz şaşırttı
    Şahsen Bazel’ı Meson’dan daha sık gördüm
    Meson Python ile yazıldığı için SciPy için iyi bir tercih gibi görünmüş olmalı; sonuçta işler yoluna girdiğine göre kutlamak gerekir
    Yine de onca tuhaflığı, karmaşıklığı ve sorununa rağmen CMake’in hâlâ standarda yakın olduğunu düşünüyorum
  • Meson, kullanıcının verdiği komutları çalıştırmaktan daha fazlasını yapar
    MSVC/gcc/clang’i destekleyebilmek için komutları kendisi de sentezleyebilir
    Bilmediği bir kombinasyon için komut sentezlemesini isterseniz doğal olarak “üzgünüm Dave” demek zorunda kalır
  • Katılıyorum
    Yakında yayımlayacağım Meson’a rakip bir derleme sisteminin yazarı olduğumu belirtmeliyim
    Ancak az önce söylediğim şeyi fark etmemi sağlayan, pek bilinmeyen küçük bir mücevher niteliğindeki rant [1] idi
    Özetle, derleme sistemi kullanıcının çalıştırmasını istediği komutları çalıştırmalı; hepsi bu
    Çünkü bazen programcı gerçekten ne yaptığını biliyordur
    Utanç verici ama o yorumu okumadan önce kendi derleme sistemimi sihirli hâle getirmeyi düşünüyordum
    Fakat o yorumu okuduktan sonra, insanların derleme sistemlerinden nefret etmesinin nedeninin tam da o “sihir” olduğunu fark ettim
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• Böyle işlerde herkesin WSL2 kullanıp geçeceğini sanıyordum
  Yerel Windows sürümünü özellikle derlemek istemenin nedeni ne olabilir?

  • Bu, macOS geliştiricilerine yerel derleme istemeyip Linux sanal makinesinde çalışsalar olmaz mı diye sormakla aynı şey
    Sanal makinede çalışmak zahmetli ve entegrasyon da daha zayıf
  • Sandığınızdan çok daha fazla araştırmacı Windows kullanıyor
    Öğrenciler de öyle
  • Windows olmayan bir cihaz almanın neredeyse imkânsız olduğu büyük şirketler önemli bir kullanıcı kitlesi olabilir
  • Microsoft ve NVIDIA’nın WSL2’nin CUDA sürücüsü sorununu çözmesi gerçekten kurtarıcı oldu
    Özellikle bunun üzerinde Docker Desktop kullanabildiğinizde daha da öyle
    İdeal olmayan bir durumdan en iyi sonucu çıkarmak bu

• καταστροφή içindeki κατα, “ani oluş”tan ziyade “aşağı” ya da “doğrultusunda” anlamına daha yakın; kötü bir yöne kırılma çağrışımı güçlü
  καταnın karşıtı genelde αναdır, ama αναστροφή kelimenin tam anlamıyla “yukarı dönme” ya da tersine çevirme anlamına gelir
  Bu yüzden “iyi dönüş” anlamındaki ευστροφη, yani eustrophe, daha iyi bir türetme olabilir
  Yine de JRR Tolkien’le dil türetme konusunda tartışıp kazanırsanız, bu ευκαταστροφη, yani talih olurdu
  Genel olarak taşan lütfu yakalaması hoşuma gidiyor; böyle şeyler dünyaya sevinç ve mutluluk verir

  • katastrofideki kata aslında “against”e daha yakın; bu yüzden katastrofi, bir şeyin “sırtını dönmesi”ne karşılık gelir

• En iyi BLAS’ların çoğunlukla C ile yazıldığı izlenimindeyim
  MKL, BLIS, OpenBLAS gibi şeylerden söz ediyorum
  Sadece C ve Python ile ne kadar ilerlenebilirdi merak ediyorum
  Bugün başlanmış olsaydı belki doğrudan libflame mi seçilirdi, onu da merak ediyorum
  Elbette SciPy’de yinelemeli yöntemler, seyrek matrisler gibi başka pek çok özellik de var; bu yüzden Fortran’dan kaçınmak zor olabilir
  Yine de Fortran harika bir dil ve Windows’ta araç durumunun en azından iyileşmeye başlamış olması sevindirici

  • SciPy’de Fortran’ı kaldırma konusu birkaç kez tartışıldı, ama yukarıda sayılan nedenlerden dolayı ilerleme olmadı
    SciPy’nin kendi içinde de çok sayıda Fortran kodu var ve yeniden yazmak yıllar düzeyinde insan gücü gerektirir
    Mümkün hâle geldikten sonra Fortran kullanan bazı temel bölümler de kaldırıldı
    Örneğin FFT ile ilgili kısımlar
  • Açıkçası 2023’te “Fortran harika bir dil ve Windows’ta araç durumunun iyileşmeye başlamış olması sevindirici” cümlesini göreceğimi hiç düşünmezdim

• Harika bir yazı
  Bu yıl Python bağlamaları olan bir CMake C++ projesini modernleştirmek için çok zaman harcadım ve yeni bir feedstock olarak conda-forge’a başarıyla ekledikten sonra güvenle söyleyebilirim
  Tanrı-imparator olursam IT ile ilgili ilk icraatım, Windows’u tüm evrenlerden sonsuza dek kökünden kazımak olurdu

• Çok naif bir soru ama Fortran semantiği o kadar farklı mı ki önce C’ye çevirip sonra C derleyicisiyle derlemek mümkün değil?
  Sonrasında C olarak bakımı da yapılamaz mı?
  Bu eski kütüphanelerin bakımını yapan çok fazla Fortran insanı varmış gibi gelmiyor; yine de bakım gerekmiyor mu?

  • Yavaşlaması sorun değilse mümkün
    Fortran’da pointer yok, yalnızca diziler var; fonksiyon argümanları da alias olamadığı için, COMMON bloklarının dehşetini bir kenara bırakırsak, agresif optimizasyon ve vektörleştirme daha kolay
    Standart Fortran matematik kütüphaneleri gayet iyi çalışır ve hızlıdır
    C/C++’ta da, özellikle C’nin restrict anahtar sözcüğünü kullanarak eşdeğer hızda kod yazmak mümkün
    Ancak mevcut kodu f2c aşamasından geçirerek dönüştürürseniz çoğu durumda performans ciddi biçimde kötüleşir
  • Fortran, C’den daha yüksek seviyeli bir dildir
    Fortran geliştiricileri de yeterince çok
    Uygulama geliştirme için berbat, ama Fortran’ın ana kullanım alanı zaten bu değil
  • Böyle bir şey zaten var
    f2c onlarca yıldır mevcut
  • Doğru, Fortran’da yerel diziler var

• Küçük bir şeyi merak ediyorum: bildiğim kadarıyla aarch64 ile arm64 aynı şey
  Yanlış mı biliyorum?

  • Aynı şeyler, ama eskiden backend tarafında birbiriyle rekabet eden iki LLVM implementasyonu vardı
    [1] https://www.phoronix.com/news/MTY5ODk
  • Zorunlu bağlantı: https://lkml.org/lkml/2012/7/15/133
  • Python’da gördüğüm kadarıyla aarch64 genellikle Linux’u, arm64 ise genellikle macOS ARM’ı ifade ediyor
    İsimlerin neden farklı olduğunu anlayacak kadar bu alana hâkim değilim

• Python’ın build sistemi değişikliklerini takip etmek gerçekten zor
  Windows’taki performans rakamlarını da merak ediyorum
  Ancak ilk etapta önemli olmayabilir
  Çünkü ciddi işler muhtemelen Linux makinelerde çalışacak

  • Neyse ki artık yavaşlayacak gibi görünüyor
    Büyük geçiş, herkesin PEP 517’yi benimsemesini sağlamaktı; özellikle de mevcut Setuptools projelerini geçirmekti
  • Saf CPU hesaplamalarında Windows da Linux kadar hızlıdır
    Çünkü zamanın %99,9’unda işletim sistemi değil, kullanıcı kodu çalışır

[ahwjdekf]

İkili derlenen dillere muhtaç hâlde oluşumuzun ne kadar çıplak biçimde ortaya çıktığı bir durum bu.

[kayws426]

Python için çözülmüş olabilir ama diğer ekosistemlerde çözülmemiş değil mi? Bu yüzden önceden derlenmiş ikili dosyalar sunuyorlar herhalde.