krabby: xây dựng trình biên dịch Rust nhanh

 (bal-e.org)
1 điểm bởi GN⁺ 1 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Krabby là một triển khai trình biên dịch Rust viết mới từ đầu ưu tiên hiệu năng, nhằm cải thiện tốc độ biên dịch chậm của rustc
  • Những cải thiện hiệu năng mà người dùng có thể cảm nhận trong rustc hiện nay không còn đến từ việc chỉnh sửa một hàm đơn lẻ, mà chủ yếu đến từ thay đổi API và cấu trúc dữ liệu; tuy nhiên, do codebase lớn và yêu cầu ổn định cao, các thay đổi quy mô lớn rất khó thực hiện
  • Krabby tìm cách kiểm chứng các cơ hội tối ưu hóa mới và một kiến trúc gắn kết hơn bằng cách cùng thiết kế lại các thành phần trình biên dịch trong một codebase nhỏ do một người kiểm soát, nơi tính ổn định không được đặt lên hàng đầu
  • Mục tiêu là kiểm nghiệm giả thuyết rằng để tăng mạnh hiệu năng trình biên dịch thì cần phải suy nghĩ lại hoàn toàn về thiết kế, ngay cả với một ngôn ngữ phức tạp như Rust
  • Mã nguồn được công khai tại kho krabby trên Codeberg, và mục tiêu là đăng cập nhật tiến độ trên Fediverse ít nhất mỗi 1–2 tuần

Mục tiêu và bối cảnh của Krabby

  • Rust là ngôn ngữ được tác giả ưa thích, nhưng trình biên dịch rustc lại chậm một cách dễ nhận thấy
  • Đã có rất nhiều người nỗ lực cải thiện hiệu năng của rustc, và các cải tiến có thể nâng hiệu năng cảm nhận được chỉ bằng cách thay đổi một hàm đơn lẻ gần như đã được khai thác hết
  • Những cải thiện có ý nghĩa hiện nay chủ yếu đến từ thay đổi API và cấu trúc dữ liệu, nhưng với một codebase lớn như rustc, việc thay đổi ở quy mô lớn gần như không khả thi do còn phải phát triển nhiều tính năng và đảm bảo tính ổn định
  • Krabby là một triển khai trình biên dịch Rust viết mới từ đầu đặt hiệu năng lên ưu tiên hàng đầu, và có mục tiêu về bản chất khác với rustc
  • Vì là codebase nhỏ do một người kiểm soát và không ưu tiên tính ổn định, dự án chọn cách thiết kế mọi thành phần trong mối liên hệ với nhau để tìm ra các cơ hội tối ưu hóa mới và tạo nên một kiến trúc gắn kết hơn
  • Dự án khởi đầu từ giả thuyết rằng nếu muốn cải thiện mạnh hiệu năng trình biên dịch thì phải suy nghĩ lại hoàn toàn về thiết kế của trình biên dịch
  • Tác giả cũng muốn cho thấy rằng các tối ưu hóa kiến trúc quy mô lớn có thể đang ẩn giấu bất kể ngôn ngữ mục tiêu là gì, và điều này không chỉ áp dụng cho các ngôn ngữ đơn giản như C mà còn có thể áp dụng với ngôn ngữ phức tạp như Rust
  • Ngay cả khi thiết kế cuối cùng trở nên chuyên biệt cho Rust, tác giả vẫn cho rằng những gì học được trong quá trình đó là có giá trị

Tình trạng dự án và tài liệu công khai

Bài viết liên quan

1 bình luận

 
GN⁺ 1 giờ trước
Ý kiến trên Lobste.rs

  • Có vẻ ai cũng muốn có giấy phép phù phiếm của riêng mình https://codeberg.org/bal-e/krabby/…

    • Với một dự án làm vì sở thích thì có thể ổn, nhưng nó cũng phát đi tín hiệu rằng đây là một dự án mang tính casual hơn là một dự án nghiêm túc
      Giấy phép này cho phép sử dụng và chia sẻ miễn phí cho mục đích cá nhân, phi thương mại, nhưng phần mềm xây dựng dựa trên nó cũng phải được chia sẻ theo cùng điều kiện, và mục đích thương mại chỉ được dùng thử trong 30 ngày
      Tôi thắc mắc liệu Codeberg có yêu cầu điều kiện libre/open source nghiêm ngặt đối với giấy phép dự án hay không. Tôi cứ nghĩ Codeberg chỉ host FOSS, nên điều khoản hạn chế dùng phi thương mại này khá bất ngờ, dù cũng có thể là tôi không theo kịp tình hình mới nhất
    • Đúng vậy, tôi cũng biết chuyện đó... tôi đã suy nghĩ về vấn đề giấy phép này khá lâu rồi, và đang cân nhắc chuyển sang AGPL khi vẫn còn là lúc tôi làm một mình

  • Rust là một hệ sinh thái rất lớn. Dự án này có vẻ dễ hơn một chút so với “tự làm một trình duyệt web”, nhưng hoàn toàn không hề dễ. Dù vậy, tôi đánh giá cao việc mục tiêu rất lớn
    Xem krabby: motivations, có vẻ tốc độ là lý do chính của dự án này
    Theo hiểu biết của tôi về Rust, kiểm tra kiểu, borrow checking v.v. vốn đã rất nhanh, còn nút thắt cổ chai là code generation, trong đó một phần đáng kể liên quan đến LLVM hơn là bản thân Rust
    Tôi tò mò không biết phía Cranelift dạo này tiến triển ra sao, và liệu có chồng lấn với các ý tưởng nhằm tăng tốc code generation hay không

    • Tiền đề đó giả định rằng toàn bộ kiến trúc của rustc+LLVM là đúng, và giờ chỉ còn hệ số hằng là quan trọng
      Cá nhân tôi khá chắc rằng nếu nhìn toàn bộ pipeline biên dịch thì điều đó không hợp lý lắm. Cần có rlib chỉ chứa MIR, và cần một backend có thể tối ưu hóa toàn bộ thế giới mà không cần RAM vô hạn (bình luận này có nói đến)
      “Codegen Unit” hoàn toàn là độ phức tạp phát sinh ngẫu nhiên
    • Còn tùy chính xác bạn đang làm gì: Depends on what exactly you're doing
      Đặc biệt, phần phân rã chi tiết của libraries và binaries có thể sẽ thú vị
      LLVM không phải là thứ nhanh nhẹn gì, nhưng tôi nhớ là rustc cũng có xu hướng chuyển cho LLVM một IR phình to quá mức, điều này cũng chẳng giúp ích gì
    • Cảm ơn :) Có vẻ mỗi người có một góc nhìn khá khác nhau về thời gian biên dịch Rust. Có người đổ lỗi cho kiểm tra kiểu, có người lại đổ lỗi cho LLVM
      Mục tiêu trung hạn của tôi, tức trong khoảng 5 năm tới, là cargo check, nên tôi sẽ không đụng vào code generation
      Dù vậy, tôi vẫn thấy còn rất nhiều dư địa tối ưu ở khả năng song song hóa tốt hơn, tách hot path của mã chẩn đoán, giảm công việc trùng lặp giữa kiểm tra kiểu và borrow checking, cải thiện memory layout của các cấu trúc dữ liệu cốt lõi, v.v.
      Việc tôi quen thân với các nhà phát triển rustc và thường xuyên nghe họ nói về nhiều vấn đề trong codebase cũng giúp ích
    • rustc có Cranelift backend
    • Có vẻ LLVM đúng là phần chậm trong thực tế. Tôi cũng thấy xu hướng đó trong các cuộc thảo luận về thời gian biên dịch của Zig, và triển khai tương ứng tự host thì nhanh hơn LLVM đáng kể 1