Tốc độ biên dịch Rust nhanh hơn nhờ frontend song song trong bản nightly

Có thể biên dịch nhanh hơn với frontend song song của trình biên dịch Rust

• Frontend của trình biên dịch Rust giờ có thể dùng thực thi song song để giảm đáng kể thời gian biên dịch.
• Frontend song song là một tính năng thử nghiệm, có thể dùng thử trên trình biên dịch nightly với tùy chọn -Z threads=8.
• Dự kiến sẽ được phát hành trên trình biên dịch ổn định trong năm 2024.

Thời gian biên dịch và tính song song

• Thời gian biên dịch của Rust luôn là một mối quan tâm thường trực, và nhóm công tác hiệu năng trình biên dịch đã liên tục cải thiện hiệu năng trình biên dịch trong nhiều năm.
• Trong 10 tháng đầu năm 2023, thời gian biên dịch giảm trung bình 13%, mức sử dụng bộ nhớ giảm 15% và kích thước nhị phân giảm 7%.
• Trình biên dịch đã được tối ưu rất nhiều nên ngày càng khó tìm ra các cải tiến mới, và tính song song vẫn là một hướng cải tiến lớn nhưng khó.

Tính song song liên tiến trình hiện có

• Khi biên dịch chương trình Rust, Cargo sẽ chạy song song nhiều tiến trình rustc để biên dịch nhiều crate.
• Việc chạy song song hoạt động tốt khi phụ thuộc giữa các crate ít, nhưng mức độ song song sẽ giảm khi số lượng phụ thuộc tăng lên.

Tính song song nội tiến trình hiện có: backend

• Trình biên dịch được chia thành frontend và backend; backend phụ trách sinh mã và LLVM xử lý phần này theo cách song song.
• Frontend thực hiện các việc như phân tích cú pháp, kiểm tra kiểu, v.v., nhưng cho đến tuần này vẫn chưa thể dùng thực thi song song.

Tính song song nội tiến trình mới: frontend

• Frontend giờ có thể dùng Rayon để thực hiện công việc biên dịch với mức song song hạt mịn.
• Khi frontend song song được bật và cấu hình dùng 8 luồng, có thể thấy thời gian chạy của frontend giảm đáng kể.

Sự kết hợp tổng thể

• Việc biên dịch Rust từ lâu đã được hưởng lợi từ tính song song liên tiến trình qua Cargo và tính song song nội tiến trình ở backend, và giờ đây frontend cũng có thể hưởng lợi từ tính song song nội tiến trình.
• Trình biên dịch dùng giao thức jobserver để giới hạn số luồng được tạo ra, tránh vượt quá số lõi CPU.

Cách sử dụng

• Trình biên dịch nightly được phát hành với frontend song song đã được kích hoạt, nhưng mặc định vẫn chạy ở chế độ một luồng.
• Người dùng có thể chuyển sang chế độ đa luồng bằng tùy chọn -Z threads.

Tác động tới hiệu năng

• Khi chạy frontend song song ở chế độ một luồng, thời gian biên dịch có thể chậm hơn từ 0% đến 2% so với trước đây.
• Ở chế độ đa luồng, thời gian biên dịch có thể giảm tới 50%, nhưng hiệu quả sẽ khác nhau tùy theo đặc tính mã nguồn và cấu hình build.

Tính chính xác

• Ở chế độ một luồng, độ tin cậy được kỳ vọng là cao.
• Ở chế độ đa luồng, có thể tồn tại các lỗi đã biết và deadlock, nhưng tệp nhị phân do trình biên dịch tạo ra phải giống nhau bất kể dùng frontend nào.

Phản hồi

• Nếu gặp vấn đề với frontend song song, có thể xem các issue gắn nhãn "WG-compiler-parallel" và gửi issue mới.

Công việc sắp tới

• Việc cải thiện hiệu năng của frontend song song và sửa lỗi trong chế độ đa luồng vẫn đang được tiếp tục.
• Mục tiêu là ổn định tùy chọn -Z threads để đến năm 2024, bản phát hành ổn định sẽ mặc định chạy ở chế độ đa luồng.

Ý kiến của GN⁺

Điểm quan trọng nhất của bài viết này là frontend của trình biên dịch Rust nay đã hỗ trợ thực thi song song, nhờ đó có thể rút ngắn đáng kể thời gian biên dịch. Đây là một lợi ích lớn cho các nhà phát triển Rust vì giúp tăng tốc độ biên dịch và góp phần tạo ra môi trường phát triển hiệu quả hơn. Việc đưa frontend song song vào sử dụng là một tin đáng chú ý đối với cộng đồng Rust và có thể xem là kết quả của những nỗ lực liên tục nhằm cải thiện hiệu năng.

[GN⁺]

Ý kiến trên Hacker News

• Kỳ vọng về việc cải thiện tốc độ biên dịch của Rust
  • Tốc độ biên dịch chậm của Rust thường bị xem là một nhược điểm, đặc biệt khi làm việc với các kho mã lớn vì nó làm tăng chi phí CI/CD và kéo dài thời gian phát triển. Vấn đề này càng rõ hơn khi phải xóa cache (thỉnh thoảng xảy ra do lỗi Docker). Phản ứng nhìn chung là tích cực trước tiến triển này.
• Trải nghiệm cá nhân về tốc độ biên dịch của Rust
  • Khi dùng Rust từ lâu trước đây, tốc độ biên dịch khá chậm, nhưng sau khi quay lại dùng gần đây thì hầu như không còn phải bận tâm đến thời gian biên dịch. Tuy vậy, khi dự án lớn dần thì vẫn có lúc cảm nhận được độ trễ, nên đây là tin rất đáng mừng trên phương diện cá nhân.
• Câu hỏi về quy trình biên dịch của Rust
  • Có câu hỏi liệu frontend của Rust có phải hoàn tất kiểm tra borrow rồi backend mới bắt đầu làm việc hay không. Người bình luận đặt vấn đề rằng nếu backend phát hiện lỗi kiểm tra borrow thì liệu có thể loại bỏ phần công việc mang tính suy đoán hay không.
• Quan sát về việc biên dịch binary crate trong Rust
  • Khác với library crate, binary crate thường mặc định lớn và có cấu trúc đơn khối, nên việc biên dịch khó được song song hóa và crate lớn nhất có xu hướng trở thành nút thắt tuần tự. Việc cải thiện vấn đề này được đánh giá cao.
• Câu hỏi về việc tận dụng các lõi CPU
  • Có câu hỏi liệu có thể để quá trình biên dịch tự động sử dụng số lượng lõi CPU hiện có hay không, hay phải đặt một giá trị cố định trong tệp cấu hình vốn cũng được dùng trên các máy khác.
• Cảnh báo về lỗi trong chế độ đa luồng
  • Có các lỗi đã biết và tình trạng deadlock trong chế độ đa luồng; nếu quá trình biên dịch bị treo thì có thể đã gặp một trong các vấn đề này. Có thái độ thận trọng với việc dùng tùy chọn -Z threads.
• Đánh giá tích cực về tình hình hiện tại của tốc độ biên dịch Rust
  • Sau vài năm không dùng Rust rồi gần đây quay lại, tốc độ biên dịch gần như tức thì. Nhờ dùng các công cụ như ChatGPT, những vấn đề Rust trước đây khó xử lý nay có thể được giải quyết dễ dàng hơn, nên tình hình hiện tại được xem là rất tốt.
• Băn khoăn về hướng tối ưu hóa biên dịch Rust
  • Có lo ngại rằng Rust vốn đã được song song hóa rất mạnh ở cấp độ tệp, nên việc tăng tốc biên dịch một tệp đơn lẻ có thể sẽ lấy mất tài nguyên từ việc song song hóa ở cấp cao hơn. Vấn đề là hiện không có dữ liệu cụ thể để đánh giá điều này.
• Bình luận chào đón việc cải thiện tốc độ biên dịch của Rust