mold 2.0.0 - trình liên kết tốc độ cao

• Giấy phép đã được chuyển từ AGPL sang MIT, trở thành thay đổi lớn nhất của mold 2.0.0
• Sửa lỗi khiến không thể tạo tệp đối tượng có quá 65520 section khi sử dụng --relocatable
• -undefined được diễn giải là từ đồng nghĩa của --undefined thay vì -u ndefined, giúp hành vi khớp với GNU linkers và LLVM lld
• -nopie được xử lý như từ đồng nghĩa của --no-pie
• Hỗ trợ các kiểu tái định vị R_RISCV_SET_ULEB128 và R_RISCV_SUB_ULEB128 trên RISC-V
• Hỗ trợ kiểu tái định vị R_PPC64_REL32 trên PPC64

[GN⁺]

Ý kiến trên Hacker News

• mold thực sự là một công trình tuyệt vời trên các hệ thống hiện đại.
  Gần đây khi cố làm cho việc build dự án nhanh hơn, tôi nhận ra bước link là một nút thắt cổ chai rất lớn. Dù dùng 24 lõi * 2 luồng, khoảng 30% hiệu năng tổng thể vẫn bị bỏ không vì linker.
  Trước đây tôi từng thử build bằng mold nhưng lúc đó không ổn lắm, và tôi định sẽ thử lại.

  • Mold rất ấn tượng. Vài tháng trước khi nghịch O3DE, tôi đã chuyển sang Mold để xem có thể rút ngắn vòng lặp build-chạy không, và đúng là nhanh hơn rõ rệt.
    Tôi không nhớ con số chính xác, nhưng đại khái là những gì mất vài giây với gold và lld đã giảm xuống dưới 1 giây với mold, một khác biệt khá lớn.
  • Ở công ty chúng tôi cũng đã làm vài proof-of-concept, và trên một máy build thử nghiệm nhỏ, tổng thời gian build của tầng UI giảm từ 44–45 phút xuống còn 29 phút khi chuyển từ lld sang mold.
    Đó là mã C++/Qt phức tạp.
  • mold -run ninja hoạt động rất tốt trong môi trường của tôi.

• Rất vui khi thấy tin thay đổi giấy phép. Tôi hy vọng dự án cũng kiếm được tiền, nhưng nếu chuyển sang giấy phép MIT thì khả năng tích hợp vào các dự án công việc sẽ lớn hơn nhiều.
  Nếu thực sự dùng nó, tôi sẽ thử thuyết phục công ty tài trợ cho dự án này.

  • Giấy phép của linker lẽ ra không quan trọng lắm. Nó không tiêm mã có bản quyền vào, và ngay cả trong hệ sinh thái GPL cũng đã có tiền lệ coi các boilerplate nhỏ là ngoại lệ, nên không có lý do gì để binary được tạo ra bị ảnh hưởng bởi giấy phép copyleft của công cụ.
    AGPL cũng chỉ hạn chế khi phân phối một linker đã chỉnh sửa riêng tư dưới dạng dịch vụ mạng, mà đó không phải là kịch bản thực tế với công cụ phát triển cơ bản.

• Tôi thắc mắc về việc đổi giấy phép. Đây chẳng phải là một file thực thi sao? Gọi nó như một tiến trình riêng không khiến phần mềm gọi nó phải thành GPL, nên trong trường hợp thông thường việc chuyển sang MIT lẽ ra không có tác động.
  Nếu các tác giả thực sự muốn một giấy phép thoáng hơn, thay vì tái cấp phép từ AGPL sang MIT, họ nên đổi sang AGPL kèm ngoại lệ liên kết. Một ví dụ về dự án GPL có ngoại lệ liên kết là libgit2 https://github.com/libgit2/libgit2#license
  Kiểu giấy phép này vừa thoáng hơn, vừa vẫn cho phép bán giấy phép thương mại cho bên tạo các thay đổi mã nguồn đóng.

  • Có vẻ điểm cốt lõi là các tác giả không muốn tiếp tục bán giấy phép nữa. Có lẽ giá trị mang lại không đáng so với sự phiền phức.
    sold, phiên bản dành cho macOS, có vẻ là ngoại lệ.

• Linker này đã cải thiện rõ rệt mức độ hài lòng khi phát triển trong repo Rust thử nghiệm của tôi, vốn đang dần trở thành một web monolith lớn dùng SeaORM và axum/tokio.
  Bạn sẽ không muốn biết kích thước thư mục target của tôi đâu, nhưng các build tăng dần đã nhẹ nhàng hơn nhiều.

  • Có lẽ tôi nên nghịch thử mold một chút.
    15:55 $ du -Hs --si target/
11G target/

• Mold rất tuyệt, và tôi có vài cách dùng yêu thích.

  1. Build Rust nhanh hơn
     [target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
"-C", "link-arg=-fuse-ld=mold",
"-C", "target-cpu=native"
]
  2. Trên ArchLinux, thêm "-fuse-ld=mold" vào CFLAGS cũng làm makepkg nhanh hơn.
  • Có cách nào chỉ ghi đè cấu hình linker này cho cài đặt cục bộ không? Tôi không muốn thay đổi mã hay binary vận hành, nhưng sẽ rất tốt nếu build nhanh hơn.
  • Tôi tò mò thời gian link của Rust đã thay đổi bao nhiêu trước và sau khi dùng nó.
  • Bản phát hành mới nhất này so với lld thì thế nào? Có chạy được trên alpine/musl không?

• Đây là một quyết định rất khôn ngoan. Đôi khi trong sản phẩm hoặc mã của mình, tôi cũng có những lúc khó khăn khi phải thừa nhận rằng một số thứ không phù hợp để kiếm tiền.
  Thị trường sẽ nói cho bạn biết, và đáng tiếc là thay vì chống lại nó, điều quan trọng là tìm thứ khác mà thị trường sẵn sàng tưởng thưởng.

• Có ai biết thay đổi giấy phép/chiến lược kinh doanh này có dự định áp dụng cho sold không? sold là mold dành cho macOS.
  https://github.com/bluewhalesystems/sold

  • Apple có một linker song song mới, có thể đáng quan tâm hoặc cũng có thể không.
    https://twitter.com/davidecci/status/1665835119331135488
  • Nhìn phần đầu README của mold, tôi đoán nó sẽ không trở thành mã nguồn mở.
    “Kho lưu trữ này chứa phiên bản miễn phí của linker mold. Nếu bạn đang tìm phiên bản thương mại hỗ trợ macOS, hãy ghé kho lưu trữ linker sold.”
  • Tôi không hiểu vì sao Apple không tài trợ dự án này để biến nó thành linker mặc định của Xcode.
    Chỉ cần trả hậu hĩnh cho công sức đó và làm thế giới tốt đẹp hơn là được mà.
    Với Apple thì việc này quá dễ.

• Giấy phép đã đổi từ AGPL sang MIT.
  Nhưng một nghệ nhân xuất sắc như vậy nên được đền đáp như thế nào, và tại sao điều đó vẫn chưa diễn ra? Tôi nghĩ các công ty, bất kể quy mô, nên phân bổ một phần ngân sách nhất định cho các phụ thuộc hoặc công cụ cốt lõi và công khai điều đó trên website chính thức. Có vẻ chúng ta cần thêm một kiểu chuẩn mực văn hóa như vậy.

• Tôi đã quên mất đây là một linker nhanh
  “Mold 2.0.0 là bản phát hành major mới của linker tốc độ cao của chúng tôi. Trong bản phát hành này, để mở rộng cơ sở người dùng, chúng tôi đã chuyển giấy phép từ AGPL sang MIT. Như những ai theo dõi tiến độ đều biết, đây không phải là quyết định dễ dàng, vì chúng tôi đã thử kiếm tiền từ sản phẩm bằng mô hình giấy phép kép AGPL/thương mại. Đáng tiếc là cách tiếp cận này không đạt kỳ vọng. Việc đổi giấy phép là kết quả của việc chấp nhận thực tế đó. Chúng tôi không muốn tiếp tục bám vào một chiến lược không hoạt động tốt.”

  • Có ai còn nhớ thời phải trả phí cc trên Solaris không? https://unix.stackexchange.com/questions/12731/usr-ucb-cc-la...
    Thật kinh khủng, và cũng là cách đối xử tệ hại với các lập trình viên dùng phần mềm cho chính OS của họ
    Chúng ta đã quen từ rất lâu với việc không trả tiền cho các công cụ phát triển cấp thấp, mà thay vào đó trả chi phí hỗ trợ. Chỉ riêng việc họ thử một kiểu giấy phép như vậy đã khiến tôi ngạc nhiên

• Trong thời gian dài tôi đã nhiều lần thấy các cuộc thảo luận về linker nhanh, cũng như những câu chuyện rằng chỉ cần thay một linker bằng linker nhanh hơn thì thời gian compile giảm đáng kể, nhưng thường thì tôi không thật sự biết vì sao linker lại chậm
  Nếu có ai giải thích được thì tốt quá

  • Đây không phải là lời giải thích đầy đủ, nhưng linking là tác vụ ngốn CPU, và các linker cũ nhìn chung là đơn luồng
    Một phần lớn cải thiện hiệu năng đến từ việc xử lý công việc song song, và trên các CPU đa nhân mạnh hiện đại điều đó dẫn đến mức cải thiện lớn
    Nếu muốn tìm hiểu thêm, Rui có một bài thuyết trình hay về Mold: https://www.youtube.com/watch?v=hAt3kCalE0Y
  • Trong trường hợp lý tưởng, linker nên nhanh như cat. Vì chỉ cần nối các binary lại với nhau là xong. Thời còn dùng ổ đĩa quay, I/O đĩa là vấn đề, nhưng bây giờ thì ít hơn
    Phần tốn thời gian là việc vừa làm vừa ghi lại nội dung. Duyệt bảng relocation và đưa địa chỉ vào code là rẻ, dead stripping theo từng section cũng khá rẻ, nhưng nếu muốn dead strip từng basic block riêng lẻ bên trong hàm thì cần phân tích nhiều hơn hẳn nên sẽ tốn thời gian
    Loại bỏ trùng lặp chuỗi hằng là một ý tưởng hay, nhưng phải đẩy tất cả chúng vào một dạng hash table nào đó. Nếu muốn chia sẻ cả các suffix chung thì công việc còn tăng thêm
    Deduplication, dead stripping và ghi lại thông tin debug cũng tốn thời gian. Trong debug build có thể có vài GB DWARF cần phải ghi lại
    Điều thú vị là việc linker có thể script được và có thể truyền một chương trình để thông dịch dường như không phải chi phí lớn. Có lẽ vì các script đó khá ngắn và chức năng cũng bị giới hạn ở mức nào đó
    Về mặt lịch sử, lý do lld rất nhanh là vì nó hầu như không xử lý thông tin debug hay thực hiện các deduplication khác. lld chạy nhanh, nhưng binary đầu ra thì lớn
    Tôi đã rời khỏi mảng hiệu năng linking vài năm rồi nên không rõ tình trạng hiện tại. Đặc biệt là không biết mold hay lld hiện nằm ở đâu trong đánh đổi giữa chất lượng đầu ra và hiệu năng của chính chúng
  • Tài liệu hay nhất tôi từng đọc là blog của Ian Taylor viết về công việc với gold linker
    https://www.airs.com/blog/archives/38
    “Xin nhắc lại, mục tiêu là tốc độ. Trong trường hợp này là nhanh hơn linker thứ hai của tôi. Linker đó đã chậm đi đáng kể qua nhiều năm khi được bổ sung hỗ trợ ELF và thư viện chia sẻ. Hỗ trợ này không được thiết kế ngay từ đầu mà được gắn thêm vào. Kế hoạch tương lai cho linker mới cũng bao gồm hỗ trợ incremental linking, đây cũng là một cách khác để tăng tốc.”
    Hãy nghĩ đến các ứng dụng thời Unix sơ khai. Chúng là những ứng dụng đơn giản, một mục đích, có lẽ chỉ cần link một file source, một object và libc, không có thứ như thư viện chia sẻ
    Về sau, khi các tính năng “thiết yếu” được thêm vào, mã của linker đã phát triển một cách hữu cơ. Đặc biệt trong thời ổ đĩa quay còn là nút thắt cổ chai, độ đúng đắn của tính năng quan trọng hơn tốc độ