Build SciPy Windows untuk Python 3.12 dinilai sebagai keajaiban kecil

• Build SciPy Windows di conda-forge tersedia dua hari setelah rilis Python 3.12.0, sehingga migrasi Python 3.12 di cabang SciPy berlangsung dengan keterlambatan beberapa hari, bukan mandek berbulan-bulan
• Karena distutils dihapus dari pustaka standar pada Python 3.12, SciPy memutuskan untuk bermigrasi dari numpy.distutils ke alat build Meson
• Meson berencana menolak kombinasi MSVC+gfortran yang digunakan conda-forge, dan di Windows tidak ada kompiler Fortran gratis yang kompatibel ABI yang bisa digunakan conda-forge
• conda-forge memperkirakan bahwa jika tidak dapat membangun ulang SciPy di Windows, migrasi setidaknya sekitar 1.000 paket yang bergantung pada SciPy akan tertunda di semua platform, atau Windows harus dikecualikan dari migrasi Python
• LLVM 17.0 adalah rilis pertama yang menghapus flag -flang-experimental-exec dari Flang, dan Flang diperkirakan berada pada tingkat kematangan “0.8 level maturity”
• Setelah menambahkan penanganan llvm-flang ke Meson, build dan instalasi SciPy berhasil, dan pengujian lulus 100% dengan hasil 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning {p:100}

[GN⁺]

Pendapat di Hacker News

• Ini tulisan yang benar-benar bagus, dan sekarang saya tahu kenapa pip install gagal di Python 3.12, tetapi ke depannya terlihat lebih cerah
  Saya suka Python, tetapi ini juga membantu memahami kenapa packaging Python adalah kekacauan yang masih bisa dikelola
  Penyebabnya bukan Python itu sendiri, melainkan tidak adanya standardisasi pada tool build C/C++/Fortran dan besarnya ekosistem; sampai batas tertentu, ini adalah kompleksitas yang tidak bisa dikurangi
  Fakta bahwa ini bisa berjalan saja sudah hampir seperti keajaiban

  • Benar, di situlah akar penyebab rumitnya packaging Python
    Keberhasilan Python sebagian besar karena bisa memakai paket campuran bahasa yang penting, dan manajer paket bahasa arus utama lain hampir tidak menangani masalah seperti ini
    Misalnya, cargo milik Rust memang hebat, tetapi sebagian besar bisa mengasumsikan packaging untuk kode khusus Rust; meski Rust adalah bahasa terkompilasi, bahasanya “memiliki” compiler, sehingga strategi distribusi build dari source bisa berjalan
    Saya tidak tahu bagaimana cargo menangani Fortran secara bawaan, tetapi jika paket-paket cargo papan atas di Windows membutuhkan kode Fortran, rasanya akan sulit berjalan mulus
    Perbaikan terbesar dalam ekosistem Python adalah standardisasi wheel, format paket biner, dan baru sejak itu ekosistem scientific Python mulai benar-benar berkembang di Windows
    Namun kompatibilitas biner adalah sumber masalah yang luar biasa besar, terutama ketika melintasi bahasa dan CPU
  • Rasanya sulit mengatakan ini tidak terkait dengan Python, karena alasan binding FFI seperti ini ada adalah karena Python terlalu lambat
  • Saya setuju dengan pernyataan “Fakta bahwa ini bisa berjalan saja sudah seperti keajaiban”
    Kompleksitas ekosistem perangkat lunak tampak tumbuh secara eksponensial, dan saya penasaran apa yang pada akhirnya mencegahnya berujung pada keruntuhan ala Menara Babel
    Tentu ini bukan masalah yang hanya berlaku pada perangkat lunak, tetapi ini menjadi contoh yang bagus
  • Tulisan ini benar-benar membuka mata
    Saya sering melihat orang membandingkan manajer paket favorit mereka dengan milik Python lalu menyimpulkan bahwa Python buruk, padahal kenyataannya tidak begitu
    Namun satu hal yang belum saya pahami adalah kenapa orang-orang Python tidak memakai library matematika C/C++ alih-alih Fortran
  • Masalah sebenarnya tampaknya adalah Python cenderung menarik orang-orang yang tidak mendapat pelatihan pengembangan perangkat lunak
    Jadinya kekacauan ditumpuk di atas kekacauan lain

• Ketika Linux masih merupakan kasus pinggiran yang reyot, dijalankan oleh para hacker yang terkoordinasi longgar dan kadang memikul batasan ideologis yang tidak praktis, sungguh fantastis melihat orang-orang hebat mencurahkan upaya besar untuk menyediakan dukungan baginya
  Namun sekarang kasus pinggiran yang reyot itu menjadi sistem proprietari yang sifat pembatasannya nyaris seperti permusuhan dan dioperasikan oleh para tuan tanah siber, sulit melihat pekerjaan untuk mendukungnya sepositif dulu
  Di sisi lain, kepedulian mendalam agar tool seperti ini bisa dipakai semua orang benar-benar luar biasa, dan saya memberi tepuk tangan untuk pekerjaan itu
  Saya sama sekali tidak mengatakan mereka harus mengubah arah, hanya saja ini membuat saya merenung
  Dulu saya berpikir, “Wah, untung sekali pekerjaan ini berjalan,” tetapi sekarang yang lebih sering terpikir adalah, “Wah, apa yang mungkin dicapai orang-orang hebat itu seandainya mereka tidak perlu berkutat dengan hal seperti ini”

  • Sebenarnya itu bukan sesuatu yang wajib mereka lakukan
    Seperti sudah beberapa kali disebut, para developer SciPy adalah sukarelawan
    Sebagian besar kisahnya menjelaskan mengapa SciPy hanya bisa berharap seseorang membuatkan compiler Fortran open-source untuk Windows, dan penyelamatannya tampaknya terutama datang dari developer NVIDIA
  • Itu pun bukan inti masalahnya
    SciPy sedang membayar harga dari keputusan bodoh dan sangat bias para developer inti Python yang memilih MSVC alih-alih MinGW sebagai toolchain untuk Python di Windows
    Saya melihat motivasinya berasal dari sponsor Microsoft
    Di daftar developer inti ada cukup banyak karyawan Microsoft, mereka dibayar oleh Microsoft untuk berpartisipasi dalam daftar itu, dan Microsoft juga menanggung biaya server CI proyek CPython
    Jika Python tidak memakai tool proprietari dalam toolchain-nya, seluruh masalah ini bisa dihindari

• Pernyataan bahwa “Meson mencoba menolak kombinasi MSVC+gfortran yang digunakan di conda-forge” terdengar seperti bug
  Menurut saya tujuan alat build adalah menjalankan perintah yang diminta, bukan menghalangi dengan berkata “maaf, Dave”

  • Yang sebenarnya mengeluh adalah linker MSVC
    Masalahnya adalah C runtime yang digunakan MSVC dan gfortran, terutama library runtime milik gfortran sendiri yang ditulis dalam C, tidak kompatibel secara ABI
    Solusi putar yang dipakai NumPy adalah menautkan objek-objek Fortran sebagai DLL untuk menambahkan lapisan tidak langsung berupa import library, lalu menenangkan MSVC
    Jadi diperlukan pekerjaan tambahan untuk membuat DLL semacam ini
    Entah dilakukan di file deskripsi build atau di Meson, itu tetap harus dilakukan, tetapi pihak SciPy tidak ingin mengimplementasikan lapisan tidak langsung ini di keduanya, dan para pengembang Meson juga tidak terlalu ingin membantu secara aktif
    Tentu saja para pengembang Meson memberi bantuan umum seperti dukungan Fortran dan Cython, tetapi mereka tidak ingin menyediakan pijakan yang berbahaya
    Pada kenyataannya ini nyaris seperti hack, dan misalnya hanya berfungsi karena sisi Fortran tidak menggunakan file yang dibuka dari sisi Python/C
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • Tulisannya bagus dan terperinci, tetapi saya agak terkejut dengan klaim bahwa Meson “banyak digunakan untuk proyek C dan C++”
    Secara pribadi, saya lebih sering melihat Bazel daripada Meson
    Karena Meson ditulis dengan Python, mungkin ia tampak seperti pilihan yang baik untuk SciPy, dan pada akhirnya semuanya berjalan baik, jadi itu patut diberi selamat
    Meski begitu, terlepas dari berbagai keanehan, kerumitan, dan masalahnya, menurut saya CMake masih cukup dekat dengan standar
  • Meson melakukan lebih dari sekadar menjalankan perintah yang diperintahkan pengguna
    Ia juga dapat menyusun perintah itu sendiri agar bisa mendukung MSVC/gcc/clang
    Jika diminta menyusun perintah untuk kombinasi yang tidak diketahuinya, tentu saja ia hanya bisa berkata “maaf, Dave”
  • Setuju
    Perlu saya ungkapkan bahwa saya adalah penulis sistem build pesaing Meson yang akan segera dirilis
    Namun rant kecil yang kurang dikenal, yang membuat saya menyadari hal yang baru saja saya katakan, adalah [1]
    Ringkasnya, sistem build harus menjalankan perintah yang diminta pengguna untuk dijalankan, titik
    Karena kadang-kadang programmer benar-benar tahu apa yang sedang ia lakukan
    Memalukan, tetapi sebelum membaca komentar itu, saya sempat berpikir untuk membuat sistem build saya seperti sulap
    Namun setelah membaca komentar itu, saya sadar bahwa alasan orang membenci sistem build justru adalah “sihir” tersebut
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• Saya kira untuk hal semacam ini semua orang cukup memakai WSL2 lalu selesai
  Mengapa repot-repot membangun versi Windows native?

  • Itu sama saja seperti bertanya kepada pengembang macOS, mengapa tidak usah menginginkan build native dan bekerja saja di mesin virtual Linux
    Bekerja di mesin virtual itu merepotkan dan integrasinya juga lebih buruk
  • Jauh lebih banyak peneliti yang memakai Windows daripada yang dibayangkan
    Begitu juga mahasiswa
  • Perusahaan besar yang hampir mustahil memberi perangkat selain Windows tampaknya merupakan kelompok pengguna penting
  • Fakta bahwa Microsoft dan NVIDIA menyelesaikan masalah driver CUDA di WSL2 benar-benar seperti penyelamat
    Terutama saat Docker Desktop bisa dipakai di atasnya
    Itu artinya mengambil hasil terbaik dari situasi yang tidak ideal

• κατα pada καταστροφή bukan berarti “mendadak”, melainkan lebih dekat ke “ke bawah” atau “menurut”, dengan implikasi kuat bahwa sesuatu berbelok ke arah yang buruk
  Lawan dari κατα biasanya ανα, tetapi αναστροφή secara harfiah berarti “berputar ke atas” atau pembalikan
  Jadi ευστροφη, yakni eustrophe, yang berarti “peralihan baik”, mungkin merupakan bentukan kata yang lebih baik
  Meski begitu, jika bisa berdebat soal penciptaan kata dengan JRR Tolkien dan menang, itu adalah ευκαταστροφη, yaitu keberuntungan
  Secara keseluruhan saya suka karena ia menangkap rahmat yang melimpah, dan hal semacam itu membawa sukacita dan kebahagiaan bagi dunia

  • kata dalam katastrofi sebenarnya lebih dekat ke “against”, sehingga katastrofi berarti sesuatu “memalingkan punggung”

• Saya punya kesan bahwa BLAS terbaik umumnya ditulis dalam C
  Maksudnya seperti MKL, BLIS, OpenBLAS
  Saya penasaran sejauh apa mereka bisa melangkah hanya dengan C dan Python
  Saya juga penasaran apakah jika memulainya sekarang mereka mungkin cukup memilih libflame
  Tentu saja SciPy punya banyak fungsi lain seperti metode iteratif, matriks sparse, dan sebagainya, jadi mungkin sulit menghindari Fortran
  Meski begitu Fortran adalah bahasa yang bagus, dan saya senang situasi tool di Windows setidaknya mulai membaik

  • Penghapusan Fortran dari SciPy pernah dibahas beberapa kali, tetapi karena alasan-alasan yang sudah disebutkan, tidak banyak kemajuan
    SciPy sendiri juga berisi banyak kode Fortran, dan menulis ulangnya akan membutuhkan tenaga kerja selama bertahun-tahun
    Setelah memungkinkan, beberapa bagian inti yang sebelumnya memakai Fortran memang sempat dihapus
    Misalnya bagian terkait FFT
  • Sejujurnya saya tidak menyangka akan melihat kalimat “Fortran adalah bahasa yang bagus, dan saya senang situasi tool di Windows mulai membaik” pada tahun 2023

• Tulisan yang sangat bagus
  Tahun ini saya menghabiskan banyak waktu memodernisasi proyek CMake C++ yang memiliki binding Python, dan setelah berhasil menambahkannya ke conda-forge sebagai feedstock baru, saya bisa mengatakan ini dengan percaya diri
  Jika saya menjadi kaisar-dewa, tindakan pertama saya terkait IT adalah mencabut Windows dari seluruh alam semesta untuk selamanya

• Ini pertanyaan yang sangat naif, tetapi apakah semantik Fortran memang sebegitu berbeda sehingga tidak bisa terlebih dahulu dikonversi ke C lalu dikompilasi dengan compiler C?
  Setelah itu, bukankah bisa juga dipelihara sebagai C?
  Rasanya tidak banyak orang Fortran yang memelihara library lama seperti ini, tetapi tetap saja bukankah pemeliharaan diperlukan?

  • Bisa, kalau tidak masalah menjadi lebih lambat
    Fortran tidak punya pointer dan hanya punya array, serta argumen fungsi tidak bisa memiliki alias, jadi jika kengerian blok COMMON dikesampingkan dulu, optimisasi agresif dan vektorisasi menjadi lebih mudah
    Library matematika Fortran standar memang bekerja dengan baik dan cepat
    Di C/C++ pun, terutama jika memakai keyword restrict di C, memang bisa menulis kode dengan kecepatan setara
    Namun jika kode yang ada dikonversi lewat tahap f2c, dalam banyak kasus performanya turun drastis
  • Fortran adalah bahasa yang lebih high-level daripada C
    Developer Fortran juga cukup banyak
    Memang mengerikan untuk pengembangan aplikasi, tetapi itu bukan bidang utama Fortran
  • Hal seperti itu sudah ada
    f2c sudah ada sejak puluhan tahun lalu
  • Benar, Fortran punya array native

• Ada satu hal kecil yang membuat penasaran: setahu saya aarch64 dan arm64 itu sama
  Apakah saya salah paham?

  • Memang sama, tetapi dulu di sisi backend ada dua implementasi LLVM yang bersaing
    [1] https://www.phoronix.com/news/MTY5ODk
  • Tautan wajib: https://lkml.org/lkml/2012/7/15/133
  • Dari yang saya lihat di Python, aarch64 biasanya merujuk ke Linux, sedangkan arm64 biasanya merujuk ke macOS ARM
    Saya tidak cukup paham bidang ini untuk mengerti mengapa namanya berbeda

• Perubahan sistem build Python benar-benar sulit diikuti
  Saya juga penasaran dengan angka performa di Windows
  Namun mungkin itu bukan hal yang penting pada tahap pertama
  Karena pekerjaan serius kemungkinan berjalan di mesin Linux

  • Untungnya sekarang tampaknya akan melambat
    Peralihan besarnya adalah membuat semua orang menerima PEP 517, khususnya memigrasikan proyek Setuptools yang sudah ada
  • Untuk komputasi CPU murni, Windows juga secepat Linux
    Karena 99,9% waktunya yang berjalan adalah kode pengguna, bukan sistem operasi

[ahwjdekf]

Ini benar-benar memperlihatkan dengan gamblang betapa kita bergantung pada bahasa yang dikompilasi menjadi biner.

[kayws426]

Bukankah itu berarti masalahnya hanya terselesaikan di Python, tetapi belum terselesaikan di ekosistem lain? Karena itulah mereka menyediakan biner yang sudah dibangun sebelumnya.