Rust đưa vào bộ sinh mã Cranelift

• Cranelift là một backend sinh mã theo giấy phép Apache-2.0, được phát triển như một phần của runtime Wasmtime dành cho WebAssembly
• Vào tháng 10 năm 2023, dự án Rust bắt đầu cung cấp Cranelift như một thành phần tùy chọn trong bộ công cụ nightly
• Giờ đây người dùng có thể sử dụng Cranelift làm backend sinh mã cho các bản dựng debug của dự án viết bằng Rust
• Cranelift cạnh tranh với các compiler hiện có và tạo mã nhanh hơn nhờ thiết kế đơn giản hóa, chỉ ưu tiên các tối ưu hóa quan trọng

Tầm quan trọng của thời gian biên dịch

• Người dùng ngôn ngữ lập trình luôn muốn thời gian biên dịch nhanh
• Rust, cũng như các ngôn ngữ khác sử dụng LLVM, đã có những phàn nàn về thời gian biên dịch
• Một compiler có thể sinh mã đủ nhanh có thể có lợi thế hơn so với việc dùng trình thông dịch
• Một compiler tập trung vào tốc độ biên dịch có thể mang lại nhiều giá trị

Tối ưu hóa của Cranelift

• Cranelift thực hiện tối ưu hóa theo nhiều cách trong quá trình sinh mã
• Pipeline tối ưu hóa dựa trên E-graphs, một cấu trúc dữ liệu biểu diễn hiệu quả tập hợp các biểu diễn trung gian
• Trong các compiler truyền thống, thứ tự tối ưu hóa ảnh hưởng lớn đến chất lượng mã được tạo ra
• Cranelift sử dụng E-graph để thứ tự tối ưu hóa không ảnh hưởng đến kết quả
• Việc trích xuất biểu diễn cuối cùng từ E-graph là một bài toán NP-complete, nhưng Cranelift dùng heuristic để nhanh chóng trích xuất một biểu diễn đủ tốt

Cranelift cho Rust

• Đã có nhiều nỗ lực đáng kể để sử dụng Cranelift làm backend cho Rust
• Compiler Rust dùng mid-level IR để biểu diễn chương trình đã được kiểm tra kiểu
• Để dùng Cranelift, cần có một thư viện chuyển đổi mid-level IR sang CLIF
• Thư viện này chủ yếu được viết bởi "bjorn3", một thành viên của nhóm compiler Rust
• Người dùng có thể thử backend Cranelift bằng rustup và cargo.

Ý kiến của GN⁺

• Việc đưa Cranelift vào có thể được xem là phản hồi trước nhu cầu kéo dài trong cộng đồng Rust về việc rút ngắn thời gian biên dịch. Điều này có thể góp phần nâng cao năng suất của nhà phát triển.
• Cách tiếp cận của Cranelift trong việc dùng E-graphs để giải quyết vấn đề thứ tự tối ưu hóa đưa ra một mô hình mới trong thiết kế compiler. Điều này có thể mở ra những hướng đi mới cho nghiên cứu và phát triển compiler.
• Từ góc nhìn phản biện, mức độ ổn định và hiệu quả của Cranelift so với LLVM vẫn cần được kiểm chứng thêm qua nhiều trường hợp sử dụng thực tế hơn.
• Các backend compiler khác cung cấp chức năng tương tự Cranelift có thể kể đến libgccjit của GCC; việc so sánh với các lựa chọn thay thế này có thể giúp làm rõ hơn ưu và nhược điểm của Cranelift.
• Các nhà phát triển đưa Cranelift vào sử dụng cần cân nhắc khả năng tương thích với hạ tầng hiện có dựa trên LLVM cũng như chi phí chuyển đổi, đồng thời đánh giá kỹ hiệu năng và độ ổn định của Cranelift.

[GN⁺]

Ý kiến Hacker News

• Backend và tối ưu hóa có thể được dùng khác nhau cho từng crate. Với các dependency, thường sẽ hợp lý khi dùng bản dựng LLVM đã tối ưu hóa, còn với mã của chính mình thì dùng LLVM debug hoặc Cranelift.
• Đây là một bài viết cung cấp cái nhìn tổng quan rất tốt về tốc độ tối ưu hóa so với chất lượng tối ưu hóa. Đặc biệt, biên dịch copy-patch dùng mã đã được biên dịch sẵn vẫn là cách nhanh nhất, nhưng có ít dư địa để tối ưu hóa. Cranelift cho phép tối ưu hóa nhiều hơn so với cách tiếp cận copy-patch bằng cách sử dụng e-graphs để biểu diễn tính tương đương trong IR. Kết quả đầu ra được tối ưu hóa tốt nhất có lẽ vẫn đến từ các toolchain biên dịch truyền thống như LLVM hoặc GCC, nhưng với những người dùng muốn có đầu ra “đủ nhanh” càng sớm càng tốt, các kỹ thuật trình biên dịch mới mang lại một lựa chọn thay thế đầy hứa hẹn.
• Có nhiều bình luận về bản dựng debug toàn phần, nhưng tôi nghĩ khác biệt quan trọng nhất là thời gian build tăng dần cho những thay đổi nhỏ. Đây chính là thứ giúp tăng tốc vòng lặp phát triển. Khi so sánh thời gian build sau những thay đổi nhỏ trong rust-analyzer và dự án gleam, việc thêm Cranelift và mold cho thấy cải thiện nhanh hơn nhiều. So với Terraform được build bằng ngôn ngữ Go, điều này cũng cho thấy những cải thiện lớn của Rust.
• Hiện tại dường như chưa có hỗ trợ cho Mac M1-M3 và cũng không có hỗ trợ Windows. Cập nhật mới nhất từ người đóng góp tích cực nhất có kết luận khá mơ hồ. Hỗ trợ Windows hiện bị bỏ qua, còn macOS hiện chỉ hỗ trợ x86_64. Nếu bạn đang dùng bộ xử lý M1, có thể thử cài phiên bản x86_64 của rustc và dùng Rosetta 2, nhưng Rosetta 2 có thể ảnh hưởng đến hiệu năng nên cần so sánh với backend LLVM.
• Đã thử làm theo hướng dẫn trong bài với dự án Bevy và so sánh với bản dựng “bình thường”. Có vẻ bản dựng phát hành nhanh hơn so với bản dựng Cranelift+debug, nhưng đó là do đang dùng sccache và NAS cục bộ để cache. Khi thử lại chỉ với bản dựng debug và không có cache, thời gian biên dịch giảm gần một nửa.
• Qua liên kết về Equality Graphs mà biết đến ESC/Java. Tò mò không biết có ai thực sự thử hoặc triển khai thành công ESC/Java chưa. Sẽ rất thú vị nếu so sánh nó với Spot bugs (trước đây được biết đến với tên Findbugs).
• Rất hào hứng với việc bản dựng debug dùng Cranelift có thể tăng tốc độ lặp phát triển. Đặc biệt trong Rust cho WASM/frontend, nơi tốc độ lặp là rất quan trọng, kỷ nguyên mới của công cụ Rust đôi khi mang lại thời gian build dưới 1 giây. Tuy vậy, do chưa hỗ trợ ARM macOS nên người dùng M1-M3 sẽ phải chờ thêm một chút.
• Tò mò không biết có benchmark về runtime khi dùng Cranelift hay không, chứ không phải thời gian biên dịch. Bài viết có nhắc đến việc “chậm gấp đôi”, nhưng dữ liệu đó là từ năm 2020. Không rõ từ đó đến nay nó đã được cải thiện đáng kể hay chưa.
• Tò mò không biết có ai có thể giải thích vì sao Cranelift được kỳ vọng nhanh hơn LLVM, và vì sao những cải tiến đó lại không thể áp dụng cho LLVM.