zlib-rs nhanh hơn C

• zlib-rs là một triển khai zlib viết bằng Rust cho nén dữ liệu, và bản 0.4.2 mới phát hành gần đây đã cải thiện hiệu năng đáng kể
• Hiện đây là triển khai zlib tương thích API nhanh nhất, đặc biệt vượt trội hơn các đối thủ ở hiệu năng giải nén
• Các cải tiến hiệu năng chính: tự động chọn triển khai SIMD tối ưu khi chạy, áp dụng tối ưu hóa DFA, v.v.

Đa phiên bản (Multiversioning)

• Tự động chọn phiên bản hàm nhanh nhất tùy theo CPU tại thời điểm chạy
• Rust hiện không hỗ trợ đa phiên bản theo mặc định nên phải tự triển khai thủ công
• Cung cấp hiệu năng tối ưu đồng thời giảm thiểu overhead khi chạy của mã

Tối ưu hóa DFA (Deterministic Finite Automata)

• Ngôn ngữ C cải thiện hiệu năng bằng cách dùng fallthrough ngầm trong câu lệnh switch
• Rust không có cơ chế tương tự nên gây suy giảm hiệu năng
• Áp dụng tùy chọn -Cllvm-args=-enable-dfa-jump-thread của LLVM → khôi phục hiệu năng
• Chưa có trong cấu hình mặc định của LLVM, nhưng dự kiến sẽ được bật mặc định trong Rustc về sau

So sánh hiệu năng benchmark

1. So sánh hiệu năng với zlib-ng

• zlib-rs cho hiệu năng nhanh hơn zlib-ng ở hầu hết kích thước đầu vào
• Đặc biệt nhanh hơn khoảng 10% với đầu vào 1KB và nhanh hơn khoảng 6% với đầu vào 65KB
• Dù hơi chậm hơn ở kích thước đầu vào nhỏ nhất, nhìn chung vẫn vượt trội về hiệu năng

Ví dụ:

• Khi kích thước đầu vào là 4 byte, zlib-ng nhanh hơn đôi chút, nhưng ít ảnh hưởng trong sử dụng thực tế
• Khi kích thước đầu vào là 1KB, zlib-rs nhanh hơn khoảng 10%
• Khi kích thước đầu vào là 65KB, zlib-rs nhanh hơn khoảng 6%

→ zlib-rs có ưu thế hiệu năng rõ rệt với các chunk lớn so với zlib-ng

2. So sánh hiệu năng với zlib-chromium

• Với chunk nhỏ, zlib-chromium nhanh hơn
• Nhưng với chunk lớn, zlib-rs chiếm ưu thế
• Với kích thước đầu vào thông thường, zlib-rs mang lại hiệu năng tốt hơn

Ví dụ:

• Khi kích thước đầu vào là 4 byte, zlib-chromium nhanh hơn khoảng 12%
• Khi kích thước đầu vào là 16 byte, zlib-chromium nhanh hơn khoảng 6%
• Khi kích thước đầu vào từ 1KB trở lên, zlib-rs chiếm ưu thế về hiệu năng

→ zlib-rs vượt trội về hiệu năng ở các kích thước thông thường

So sánh hiệu năng nén

• Hiệu năng nén đang tiếp tục được cải thiện nhưng kết quả vẫn còn pha trộn
• Tăng 6% ở mức nén mặc định (6) và tăng 13% ở mức nén cao nhất (9)
• Ở các mức nén khác, zlib-ng vẫn nhanh hơn

Ví dụ:

• Ở mức nén 6, zlib-rs nhanh hơn zlib-ng khoảng 6%
• Ở mức nén 9, zlib-rs nhanh hơn zlib-ng khoảng 13%
• Nhưng ở mức nén 1~4, zlib-ng vẫn chiếm ưu thế

Kết luận

• zlib-rs vượt trội hơn zlib-ng và zlib-chromium ở hiệu năng giải nén
• Hiệu năng nén vẫn đang được cải thiện, và đã cho thấy mức tăng đáng kể ở các mức nén chính
• Có thể dùng cho cả dự án Rust và C
  • Rust → dùng cờ zlib-rs trong crate flate2
  • C → có thể biên dịch dưới dạng thư viện động rồi sử dụng

[GN⁺]

Ý kiến Hacker News

• Nhận ra rằng mình đã biết Rust

  • Tôi nghĩ mục tiêu của Rust là an toàn, nhưng thư viện này lại dùng khá nhiều từ khóa unsafe
  • Tôi tự hỏi đến thời điểm nào thì sự khác biệt giữa C và Rust trở nên không còn nhiều ý nghĩa
  • Nếu dùng inline assembly, cả hai ngôn ngữ đều có thể tạo ra cùng một mã máy
  • Tôi tự hỏi liệu trình biên dịch Rust có tối ưu tốt hơn trình biên dịch C hay không

• "Nhanh hơn C" cuối cùng thường quy về thiết kế, cách triển khai, thuật toán, v.v.

  • Nó có thể nhanh hơn một implementation đã tồn tại, nhưng tuyên bố "nhanh hơn C" thì khá kỳ lạ

• zippy trong Nim tuyên bố nhanh hơn zlib từ 1,5 đến 2 lần

  • Trong hệ sinh thái C cũng có những bản zlib nhanh hơn bản cài đặt tiêu chuẩn
  • zlib ngày nay đã khá cũ, nhưng vẫn còn phổ biến
  • Nó được dùng làm nền tảng cho các định dạng mới thân thiện hơn với xử lý song song

• Tò mò không biết hiệu năng của Rust có thực sự liên quan đến bản thân Rust, hay chỉ là vì nó được tối ưu tốt hơn các phiên bản C khác

  • Có những trường hợp sắp xếp mà C++ cho hiệu năng tốt hơn C một cách nhất quán
  • Tôi tự hỏi giữa Rust và C có điều gì tương tự không

• Chromium dùng zlib vì các thuật toán có trong tiêu chuẩn

  • Chọn thuật toán tốt hơn có thể cho hiệu năng tốt hơn
  • Zstandard nhanh hơn và cũng nén tốt hơn
  • LZ4 nhanh hơn rất nhiều, nhưng kích thước không nhỏ bằng

• Zstandard và digest blake3 được chấp nhận

• Nói Rust nhanh ngang C thì có lẽ chính xác hơn

  • Dù vậy đây vẫn là một thành tựu lớn

• Thư viện nào biên dịch nhanh hơn

  • Thư viện nào có ít dependency hơn
  • Kích thước của mỗi thư viện có giống nhau không, và cái nào nhỏ hơn

• Người dùng Rust thích so sánh Rust với C, nhưng người dùng C thì hiếm khi so sánh C với Rust

• Khi làm việc với các ngôn ngữ hệ thống được biên dịch, ngôn ngữ gần như không ảnh hưởng nhiều đến tốc độ

  • Một phiên bản được tối ưu tốt, kiểm soát cấp phát, dùng mẫu truy cập bộ nhớ tốt, đồng thời tận dụng SIMD và đa luồng, có thể dễ dàng nhanh hơn hơn 100 lần
  • Chỉ riêng việc truy cập bộ nhớ tốt hơn cũng có thể tăng tốc chương trình lên hơn 20 lần

• Ý ở đây là implementation này nhanh hơn bản viết bằng C

  • Không có chuyện "nhanh hơn C"