Bản dựng SciPy trên Windows cho Python 3.12 được xem là một phép màu nhỏ

Vì sao bản dựng SciPy cho Python 3.12 giống như một phép màu

• Python 3.12 vừa được phát hành gần đây.
• Việc các gói chính nhanh chóng tung ra bản phát hành tương thích với phiên bản Python mới thường là điều bình thường.
• Việc SciPy phát hành bản dựng tương thích với Python 3.12 là kết quả may mắn khi nhiều mốc thời gian trùng khớp.

Vai trò của Fortran và trình biên dịch

• Fortran là một ngôn ngữ lập trình quan trọng từ thập niên 1950, và nhiều mã khoa học được viết bằng Fortran.
• Từng có nhiều trình biên dịch Fortran khác nhau, nhưng tất cả đều là độc quyền.
• Trình biên dịch có vai trò chuyển đổi mã do lập trình viên viết sang dạng mà máy tính có thể thực thi.
• GCC là một trình biên dịch có thể sử dụng tự do, hỗ trợ nhiều kiến trúc CPU và hệ điều hành.

Python và vấn đề hiệu năng

• Python có thể dùng mà không cần trình biên dịch, nhưng chậm hơn so với các ngôn ngữ biên dịch.
• Khi hiệu năng là yếu tố quan trọng, một giải pháp tốt là dùng mã đã biên dịch rồi bọc bằng giao diện Python.
• NumPy và SciPy sử dụng mã Fortran để đạt hiệu năng cao, vì vậy người dùng cần có trình biên dịch khi cài đặt gói.

Vấn đề của việc đóng gói Python

• Việc đóng gói Python liên tục phải được tái phát minh vì tính phức tạp của nó.
• Tải trực tiếp mã nguồn gây ra các vấn đề như người dùng phải tự cấu hình trình biên dịch và thời gian build kéo dài.
• Định dạng "wheel" đã cải thiện điều này bằng cách phân phối kèm các thư viện cần thiết trong gói.

Sự xuất hiện của conda và conda-forge

• conda cung cấp một cách tiếp cận toàn diện hơn, bao gồm mọi thứ cần thiết cho việc đóng gói.
• conda-forge là một kênh do cộng đồng dẫn dắt để thực hiện công việc tích hợp gói.
• conda-forge cố gắng hỗ trợ tất cả các nền tảng phổ biến và được vận hành bởi các tình nguyện viên.

SciPy chọn Meson làm công cụ build

• SciPy đã chọn Meson làm công cụ build.
• Meson cung cấp giao diện theo phong cách Python và ít phức tạp hơn CMake.
• Meson có triết lý thiết kế là không cho phép người dùng không chuyên thực hiện các thao tác sai.

Sự hồi sinh của Fortran và LLVM

• Trong vài năm gần đây, Fortran nhận được sự quan tâm ngày càng tăng.
• Việc phát triển các trình biên dịch Fortran mới dựa trên LLVM trở nên sôi động.
• LLVM cung cấp hạ tầng trình biên dịch hoạt động trên nhiều kiến trúc và nền tảng.

Việc chuyển sang Meson của SciPy và vấn đề của conda-forge

• SciPy đã chuyển sang Meson, nhưng phát sinh vấn đề do thiếu trình biên dịch Fortran cho Windows.
• conda-forge phải build lại mọi gói liên quan để phục vụ quá trình chuyển sang Python 3.12.

Ý nghĩa của 'yukatastrophe' và ý kiến của GN⁺

• Bộ kiểm thử của SciPy đã vượt qua 100%, nhờ đó conda-forge có thể tạo bản dựng SciPy tương thích với Python 3.12.
• Đây là kết quả của nhiều nỗ lực và sự trùng hợp tình cờ, mang lại lợi ích lớn cho cộng đồng Python.
• Ý kiến của GN⁺: Bài viết này cho thấy những nỗ lực và sự hợp tác trong cộng đồng Python có thể giải quyết các vấn đề kỹ thuật phức tạp như thế nào. Việc SciPy phát hành thành công bản dựng tương thích với Python 3.12 là một bước tiến quan trọng trong lĩnh vực tính toán khoa học, đồng thời tượng trưng cho sức mạnh của phần mềm nguồn mở và của cộng đồng.

[GN⁺]

Ý kiến trên Hacker News

• Cộng đồng phần mềm tự do nên ngừng hỗ trợ hệ điều hành của Microsoft và để họ tự port những thứ như scipy

  • Ai cần Linux có thể tìm ở WSL2
  • Microsoft nên tích hợp trình biên dịch vào hệ điều hành, như mọi nhà cung cấp hệ điều hành khác đã làm suốt 60 năm qua

• Lý do việc đóng gói Python phức tạp là vì các công cụ build C/C++/Fortran không được chuẩn hóa và hệ sinh thái quá đồ sộ, chứ không phải do bản thân Python

  • Đây là phần phức tạp không thể cắt giảm
  • Việc hệ thống đóng gói Python hoạt động được tự nó đã là một phép màu

• Việc công cụ build Meson từ chối tổ hợp MSVC+gfortran có vẻ là một lỗi

  • Mục đích của công cụ build là chạy các lệnh mà người dùng chỉ định, chứ không phải từ chối người dùng

• Nhiều người đang dùng WSL2 để giải quyết vấn đề, nên có người thắc mắc vì sao lại muốn build phiên bản Windows gốc

• Phần lớn các thư viện BLAS tốt nhất đều được viết bằng C, nên có người tò mò liệu chỉ với C và Python có thể đạt được đến mức nào

  • Fortran có thể là phần không thể tránh khỏi, nhưng việc cải thiện công cụ Fortran trên Windows đã bắt đầu nên đây là tín hiệu tích cực

• Có câu hỏi khá ngây thơ rằng liệu vì ngữ nghĩa của Fortran quá khác C, nên không thể chuyển sang C rồi biên dịch bằng trình biên dịch C hay không, và liệu có thể bảo trì bằng C được không

  • Có lẽ không có nhiều chuyên gia Fortran để bảo trì các thư viện cũ, trong khi việc bảo trì là cần thiết

• Khó theo kịp những thay đổi trong hệ thống build của Python

  • Có sự tò mò về số liệu hiệu năng trên Windows, nhưng phần lớn công việc nghiêm túc có lẽ vẫn sẽ chạy trên máy Linux

• Có câu hỏi liệu aarch64 và arm64 có phải là một không

  • Trên Wikipedia, ARM64 được chuyển hướng sang AArch64

• Fortran từng là đề tài đùa cợt trong bộ phận IT, nhưng vài năm gần đây lại trải qua một đợt hồi sinh mạnh mẽ

  • Lý do của sự hồi sinh này không rõ ràng, nhưng có thể hiểu thêm qua các liên kết liên quan

• Có câu hỏi về sự khác biệt giữa arm64 và aarch64 trong bảng trình biên dịch/kiến trúc

  • Nhắc đến việc bài viết ARM64 trên Wikipedia được chuyển hướng sang AArch64

[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.