Bản dựng SciPy trên Windows cho Python 3.12 được đánh giá là một kỳ tích nhỏ

• Bản dựng SciPy trên Windows của conda-forge đã có mặt chỉ hai ngày sau khi Python 3.12.0 phát hành, khiến quá trình di chuyển lên Python 3.12 của nhánh SciPy chỉ chậm vài ngày thay vì đình trệ hàng tháng
• Khi distutils bị loại khỏi thư viện chuẩn trong Python 3.12, SciPy đã quyết định chuyển từ numpy.distutils sang công cụ build Meson
• Meson dự kiến sẽ từ chối tổ hợp MSVC+gfortran mà conda-forge đang dùng, và trên Windows không có trình biên dịch Fortran miễn phí tương thích ABI mà conda-forge có thể sử dụng
• conda-forge dự đoán rằng nếu không thể build lại SciPy trên Windows, việc di chuyển của ít nhất khoảng 1.000 gói phụ thuộc vào SciPy sẽ bị trì hoãn trên mọi nền tảng, hoặc Windows sẽ phải bị loại khỏi đợt di chuyển Python
• LLVM 17.0 là bản phát hành đầu tiên loại bỏ cờ -flang-experimental-exec khỏi Flang, và Flang được ước tính ở mức “độ trưởng thành 0.8”
• Sau khi bổ sung xử lý llvm-flang vào Meson, họ đã build và cài đặt SciPy thành công; các bài kiểm thử đạt 100% với 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning {p:100}

[GN⁺]

Các ý kiến trên Hacker News

• Đây là một bài viết thật sự xuất sắc; giờ thì tôi đã hiểu vì sao pip install trên Python 3.12 từng thất bại, nhưng tương lai có vẻ sáng sủa hơn
  Tôi thích Python, và bài viết cũng giúp tôi hiểu vì sao việc đóng gói Python lại là một mớ hỗn độn nhưng vẫn ở mức có thể quản lý
  Nguyên nhân không phải bản thân Python, mà là sự thiếu chuẩn hóa của các công cụ build C/C++/Fortran và quy mô khổng lồ của hệ sinh thái; ở một mức nào đó, đây là độ phức tạp không thể giảm bớt
  Việc mọi thứ chạy được đã gần như là một phép màu

  • Đúng vậy, lý do gốc rễ khiến việc đóng gói Python phức tạp nằm ở đó
    Thành công của Python phần lớn đến từ việc có thể dùng các gói đa ngôn ngữ cốt lõi, còn trình quản lý gói của các ngôn ngữ phổ biến khác hầu như không phải xử lý vấn đề như vậy
    Ví dụ, cargo của Rust rất tuyệt, nhưng phần lớn có thể giả định việc đóng gói mã chỉ dành cho Rust; dù là ngôn ngữ biên dịch, bản thân ngôn ngữ lại “sở hữu” compiler, nên chiến lược phân phối bằng cách build từ mã nguồn vẫn hiệu quả
    Tôi không biết cargo xử lý Fortran mặc định như thế nào, nhưng nếu các gói cargo hàng đầu trên Windows yêu cầu mã Fortran thì có lẽ khó mà chạy trơn tru
    Cải tiến lớn nhất của hệ sinh thái Python là việc chuẩn hóa wheel, định dạng gói nhị phân; chỉ từ lúc đó hệ sinh thái Python khoa học mới bắt đầu phát triển mạnh trên Windows
    Tuy nhiên, tương thích nhị phân là một cơn đau đầu khổng lồ, đặc biệt khi vượt qua ranh giới giữa các ngôn ngữ và CPU
  • Nói là không liên quan đến Python thì cũng không ổn, vì lý do các FFI binding này tồn tại là do Python quá chậm
  • Tôi đồng ý với câu “việc mọi thứ chạy được đã gần như là một phép màu”
    Độ phức tạp của hệ sinh thái phần mềm dường như đang tăng theo cấp số nhân, và tôi tự hỏi điều gì đang ngăn nó cuối cùng không đi đến một vụ sụp đổ kiểu tháp Babel
    Tất nhiên đây không phải vấn đề chỉ có trong phần mềm, nhưng là một ví dụ hay
  • Đây thật sự là một bài viết mở mang tầm mắt
    Tôi thường thấy người ta so sánh trình quản lý gói yêu thích của họ với của Python rồi kết luận Python tệ hại, nhưng thực tế không phải vậy
    Tuy nhiên điều tôi chưa hiểu rõ là tại sao phía Python không dùng thư viện toán học C/C++ thay cho Fortran
  • Vấn đề thực sự có vẻ là Python có xu hướng thu hút những người chưa được đào tạo về phát triển phần mềm
    Tức là một mớ hỗn độn lại được chất thêm lên một mớ hỗn độn khác

• Khi Linux còn là một trường hợp ngoại biên ọp ẹp do những hacker phối hợp lỏng lẻo vận hành, đôi khi mang các ràng buộc ý thức hệ thiếu thực tế, việc những người tài giỏi bỏ rất nhiều công sức để hỗ trợ nó là điều thật tuyệt vời
  Nhưng giờ đây, khi trường hợp ngoại biên ọp ẹp đó lại là một hệ thống độc quyền với các ràng buộc gần như mang tính thù địch, do những lãnh chúa mạng điều hành, thì thật khó nhìn công việc hỗ trợ nó tích cực như trước
  Mặt khác, sự quan tâm sâu sắc nhằm làm cho các công cụ này sẵn dùng cho mọi người thật sự rất đáng quý, và tôi hoan nghênh công việc đó
  Tôi hoàn toàn không nói họ nên đổi hướng, chỉ là điều này khiến tôi phải suy ngẫm
  Trước đây tôi sẽ nghĩ “Chà, thật may vì công việc này đang được thực hiện”, còn bây giờ tôi lại nghĩ nhiều hơn rằng “Chà, nếu những con người xuất sắc kia không phải bám vào việc này thì họ đã có thể đạt được gì”

  • Thật ra đó không phải là việc họ nhất thiết phải làm
    Như đã được nhắc nhiều lần, các nhà phát triển SciPy là tình nguyện viên
    Phần lớn câu chuyện giải thích vì sao SciPy chỉ có thể hy vọng ai đó tạo ra một trình biên dịch Fortran mã nguồn mở cho Windows, và sự cứu trợ dường như chủ yếu đến từ các nhà phát triển NVIDIA
  • Ngay cả điều đó cũng không phải điểm cốt lõi
    SciPy đang phải trả giá cho quyết định ngớ ngẩn và rất thiên lệch của các nhà phát triển lõi Python khi chọn MSVC thay vì MinGW làm toolchain cho Python trên Windows
    Tôi cho rằng động cơ đến từ sự tài trợ của Microsoft
    Trong danh sách nhà phát triển lõi có khá nhiều nhân viên Microsoft; họ được Microsoft trả tiền để tham gia danh sách đó, hơn nữa Microsoft còn chi trả chi phí máy chủ CI cho dự án CPython
    Nếu Python không dùng công cụ độc quyền trong toolchain thì toàn bộ vấn đề này đã có thể tránh được

• Việc “Meson đã định từ chối tổ hợp MSVC+gfortran từng được dùng trên conda-forge” nghe giống một lỗi hơn
  Theo tôi, mục đích của công cụ build là thực thi lệnh được yêu cầu, chứ không phải chặn lại kiểu “xin lỗi nhé Dave”

  • Bên thực sự phàn nàn là MSVC linker
    Vấn đề là C runtime mà MSVC và gfortran dùng, đặc biệt thư viện runtime riêng của gfortran, được viết bằng C, nhưng hai bên không tương thích ABI
    Cách lách mà NumPy từng dùng là link các object Fortran thành DLL để thêm một tầng gián tiếp là import library, rồi xoa dịu MSVC
    Vì vậy cần thêm công việc để tạo các DLL kiểu này
    Việc đó phải làm hoặc trong file mô tả build, hoặc trong Meson, nhưng phía SciPy không muốn triển khai tầng gián tiếp này ở cả hai nơi, và các nhà phát triển Meson cũng không mặn mà chủ động hỗ trợ
    Tất nhiên các nhà phát triển Meson đã hỗ trợ những phần chung như Fortran và Cython, nhưng họ không muốn cung cấp một bệ đỡ nguy hiểm
    Thực tế đây gần như là một kiểu hack, chẳng hạn nó chỉ hoạt động vì phía Fortran không dùng các file được mở từ phía Python/C
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • Bài viết hay và chi tiết, nhưng tôi hơi ngạc nhiên trước nhận định rằng Meson “được dùng rộng rãi trong các dự án C và C++”
    Cá nhân tôi thấy Bazel thường xuyên hơn Meson
    Có vẻ vì Meson được viết bằng Python nên trông như một lựa chọn tốt cho SciPy, và cuối cùng mọi chuyện cũng ổn, vậy thì đáng chúc mừng
    Dù vậy, bất chấp nhiều điểm kỳ quặc, phức tạp và vấn đề, tôi vẫn cho rằng CMake gần như là chuẩn
  • Meson làm nhiều hơn là chỉ thực thi các lệnh mà người dùng chỉ định
    Nó còn có thể tự tổng hợp lệnh để hỗ trợ MSVC/gcc/clang
    Nếu yêu cầu nó tổng hợp lệnh cho một tổ hợp mà nó không biết, thì dĩ nhiên nó chỉ có thể nói “xin lỗi nhé Dave”
  • Đồng ý
    Tôi xin nói rõ là mình là tác giả của một hệ thống build cạnh tranh với Meson sắp được công bố
    Tuy nhiên, một bài rant nhỏ ít người biết, như một viên ngọc nhỏ, đã khiến tôi nhận ra điều tôi vừa nói, đó là [1]
    Tóm lại, hệ thống build nên thực thi các lệnh mà người dùng bảo nó chạy, hết
    Vì đôi khi lập trình viên thật sự biết mình đang làm gì
    Thật xấu hổ, nhưng trước khi đọc bình luận đó, tôi đã định biến hệ thống build của mình thành một thứ đầy “ma thuật”
    Nhưng sau khi đọc nó, tôi nhận ra chính thứ “ma thuật” đó là lý do mọi người ghét hệ thống build
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• Tôi cứ tưởng những chuyện kiểu này thì mọi người dùng WSL2 là xong
  Vì sao lại phải cố build bản Windows native?

  • Điều đó cũng giống như hỏi các nhà phát triển macOS rằng sao không thôi đòi bản build native mà làm việc trong máy ảo Linux cho rồi
    Làm việc trong máy ảo thì bất tiện và khả năng tích hợp cũng kém hơn
  • Nhiều nhà nghiên cứu dùng Windows hơn bạn tưởng rất nhiều
    Sinh viên cũng vậy
  • Các tập đoàn lớn nơi gần như không thể được cấp máy không chạy Windows có lẽ là một nhóm người dùng quan trọng
  • Việc Microsoft và NVIDIA giải quyết vấn đề driver CUDA của WSL2 thật sự như một sự cứu rỗi
    Đặc biệt là khi có thể dùng Docker Desktop trên đó
    Đó là cách tận dụng tốt nhất trong một tình huống không lý tưởng

• κατα trong καταστροφή không phải là “sự đột ngột”, mà gần với “xuống dưới” hoặc “theo đó”, và hàm ý mạnh là bị bẻ ngoặt theo hướng xấu
  Đối lập với κατα thường là ανα, nhưng αναστροφή theo nghĩa đen là “quay lên” hoặc sự đảo chiều
  Vì vậy ευστροφη, tức eustrophe, với nghĩa “chuyển biến tốt”, có lẽ là một từ mới ghép tốt hơn
  Dù vậy, nếu có thể tranh luận về việc tạo từ với JRR Tolkien mà thắng, thì đó sẽ là ευκαταστροφη, tức là may mắn
  Nhìn chung tôi thích cách nó nắm bắt được ân sủng tràn đầy, thứ đem lại niềm vui và hạnh phúc cho thế gian

  • kata trong katastrofi thực ra gần với “against”, nên katastrofi tương ứng với việc sự vật “quay lưng lại”

• Tôi có ấn tượng rằng các BLAS tốt nhất nhìn chung được viết bằng C
  Ý là những thứ như MKL, BLIS, OpenBLAS
  Tôi tò mò không biết chỉ với C và Python thì đã có thể đi xa đến đâu
  Cũng tò mò nếu bắt đầu bây giờ thì có lẽ họ chỉ chọn libflame hay không
  Tất nhiên SciPy còn có nhiều chức năng khác như phương pháp lặp, ma trận thưa, nên có lẽ khó tránh Fortran
  Dù vậy Fortran là một ngôn ngữ tuyệt vời, và thật mừng là tình hình công cụ trên Windows ít nhất cũng đã bắt đầu cải thiện

  • Đã có vài lần thảo luận về việc loại bỏ Fortran khỏi SciPy, nhưng vì các lý do nói trên nên không tiến triển
    Bản thân SciPy cũng chứa rất nhiều mã Fortran, và để viết lại sẽ cần nhân lực tính theo nhiều năm
    Sau khi khả thi, một vài phần cốt lõi từng dùng Fortran cũng đã được loại bỏ
    Ví dụ như các phần liên quan đến FFT
  • Thành thật mà nói, tôi không ngờ sẽ thấy câu “Fortran là một ngôn ngữ tuyệt vời, và thật mừng là tình hình công cụ trên Windows bắt đầu cải thiện” vào năm 2023

• Bài viết rất hay
  Năm nay tôi đã dành nhiều thời gian hiện đại hóa một dự án CMake C++ có Python binding, và sau khi thêm thành công nó vào conda-forge dưới dạng feedstock mới, tôi có thể tự tin nói rằng
  Nếu tôi trở thành thần hoàng đế, hành động đầu tiên liên quan đến IT của tôi sẽ là nhổ tận gốc Windows khỏi mọi vũ trụ, mãi mãi

• Một câu hỏi rất ngây thơ: ngữ nghĩa Fortran khác biệt đến mức không thể chuyển sang C trước rồi biên dịch bằng trình biên dịch C sao?
  Sau đó chẳng phải cũng có thể bảo trì bằng C được sao?
  Có vẻ không có nhiều người dùng Fortran bảo trì những thư viện cũ như thế này, nhưng dù sao vẫn cần bảo trì chứ?

  • Nếu chấp nhận chậm đi thì có thể
    Fortran không có con trỏ mà chỉ có mảng, và đối số hàm không thể có alias, nên nếu tạm gác nỗi kinh hoàng của các khối COMMON sang một bên, việc tối ưu hóa mạnh tay và vector hóa sẽ dễ hơn
    Các thư viện toán học Fortran chuẩn cứ thế hoạt động tốt và nhanh
    Trong C/C++ cũng có thể viết mã đạt tốc độ tương đương, đặc biệt nếu dùng từ khóa restrict của C
    Nhưng nếu chuyển mã hiện có qua bước f2c thì trong nhiều trường hợp hiệu năng sẽ giảm mạnh
  • Fortran là ngôn ngữ bậc cao hơn C
    Lập trình viên Fortran cũng có rất nhiều
    Nó rất tệ cho phát triển ứng dụng, nhưng đó không phải là lĩnh vực chính của Fortran
  • Chuyện đó đã có rồi
    f2c đã tồn tại từ hàng chục năm trước
  • Đúng vậy, Fortran có mảng native

• Có một thắc mắc nhỏ: theo tôi biết thì aarch64 và arm64 là cùng một thứ
  Tôi có hiểu sai không?

  • Là cùng một thứ, nhưng trước đây ở phía backend từng có hai triển khai LLVM cạnh tranh nhau
    [1] https://www.phoronix.com/news/MTY5ODk
  • Liên kết bắt buộc: https://lkml.org/lkml/2012/7/15/133
  • Theo tôi thấy trong Python, aarch64 thường chỉ Linux, còn arm64 thường chỉ macOS ARM
    Tôi không rành lĩnh vực này đến mức hiểu vì sao tên gọi lại khác nhau

• Các thay đổi trong hệ thống build của Python thật sự rất khó theo kịp
  Tôi cũng tò mò về số liệu hiệu năng trên Windows
  Tuy nhiên ở mức ưu tiên đầu tiên thì có lẽ điều đó không quan trọng
  Vì các công việc nghiêm túc có lẽ sẽ chạy trên máy Linux

  • May là giờ có vẻ sẽ chậm lại
    Bước chuyển lớn là khiến mọi người chấp nhận PEP 517, đặc biệt là chuyển đổi các dự án Setuptools hiện có
  • Với tính toán CPU thuần túy, Windows cũng nhanh như Linux
    Vì 99,9% thời gian là chạy mã người dùng, chứ không phải hệ điều hành

[ahwjdekf]

Đúng là một trường hợp phơi bày trần trụi cảnh phải phụ thuộc vào các ngôn ngữ biên dịch nhị phân chết tiệt.

[kayws426]

Python thì đã giải quyết được, nhưng chẳng phải ở các hệ sinh thái khác vẫn chưa giải quyết được sao? Vì vậy nên mới cung cấp các binary được build sẵn.