mold 2.0.0 - 高速リンカー
(github.com/rui314)- ライセンスが AGPLからMIT に移行され、mold 2.0.0の主要な変更点となった
--relocatable使用時にセクションが 65520個 を超えるオブジェクトファイルを作成できなかったバグを修正-undefinedが-u ndefinedではなく--undefinedの同義語として解釈され、GNU linkers およびLLVM lldの挙動に合わせられた-nopieが--no-pieの同義語として扱われるようになった- RISC-V で
R_RISCV_SET_ULEB128およびR_RISCV_SUB_ULEB128再配置タイプをサポート - PPC64 で
R_PPC64_REL32再配置タイプをサポート
1件のコメント
Hacker News の意見
mold は現代のシステムにおいて本当に素晴らしい成果物。
最近プロジェクトのビルドを速くしようとして、リンク段階がものすごいボトルネックだと分かった。24コア * 2スレッドを使っていても、リンカのせいで全体性能の30%ほどが遊んでいる。
以前 mold でビルドしようとしたが、そのときはうまくいかなかったので、また試してみるつもり。
正確な数字は覚えていないが、gold や lld では数秒かかっていたものが mold では1秒未満に下がる、といったかなり大きな差だった。
複雑な C++/Qt コードだった。
mold -run ninjaは自分の環境ではとてもよく動く。ライセンス変更の知らせを見て、とても喜んでいる。プロジェクトで収益も得られることを願っているが、MIT ライセンスになれば業務プロジェクトに統合できる可能性がずっと高くなる。
実際に使うことになったら、会社にこのプロジェクトを支援するよう説得してみるつもり。
AGPL も、私的に修正したリンカをネットワークサービスとして配布する場合だけを制限するだろうが、基本的な開発ツールでは現実的なシナリオではない。
ライセンス変更が気になる。これは実行ファイルではないのか？ 別プロセスとして呼び出すからといって、呼び出すソフトウェアを GPL にする必要はないので、一般的な場合 MIT への移行は影響がないはず。
作者たちが本当により寛容なライセンスを望んでいたなら、AGPL から MIT へ再ライセンスするのではなく、リンク例外付きの AGPL に変えるべきだった。リンク例外付き GPL プロジェクトの例として libgit2 がある https://github.com/libgit2/libgit2#license
こうしたライセンスはより寛容でありつつ、非公開ソースの変更を作る側には引き続き商用ライセンスを売れるようにしてくれる。
macOS 版である
soldは例外のようだ。このリンカは、SeaORM と axum/tokio を使う大きな Web モノリスになろうとしている私の探索用 Rust リポジトリで、開発満足度を目に見えて高めてくれる。
私の
targetディレクトリのサイズは知りたくないだろうが、インクリメンタルビルドはずっと軽快になった。15:55 $ du -Hs --si target/11G target/Mold は素晴らしく、気に入っている使い道がいくつかある。
[target.x86_64-unknown-linux-gnu]linker = "clang"rustflags = ["-C", "link-arg=-fuse-ld=mold","-C", "target-cpu=native"]"-fuse-ld=mold"を追加するとmakepkgも速くなる。とても賢明な判断だ。自分の製品やコードでも、収益化に向かないものがあると認めなければならないつらい瞬間が時々ある。
市場が教えてくれるものだし、残念ながらそれに逆らうより、市場が報いてくれる別のものを探すことが重要だ。
このライセンス／事業戦略の変更が sold にも適用される予定か知っている人はいる？ sold は macOS 用の mold。
https://github.com/bluewhalesystems/sold
https://twitter.com/davidecci/status/1665835119331135488
「このリポジトリには mold リンカの無料版が含まれています。macOS をサポートする商用版を探しているなら、sold リンカのリポジトリを訪れてください。」
作業の対価としてたっぷりお金を払い、世の中を良くすればいいのに。
Apple にとっては簡単すぎることだろうに。
ライセンスが AGPL から MIT に変わった。
ところで、こうした素晴らしい職人はどう報われるべきで、なぜまだそうなっていないのだろう？ 企業は規模に関係なく、重要な依存関係やツールにある程度の予算を割り当て、それを公式サイトで公開すべきだと思う。ある種の文化的規範がもっと必要に見える。
これが高速リンカーだったことを忘れていた
「Mold 2.0.0は、私たちの高速リンカーの新しいメジャーリリースです。今回のリリースでは、ユーザー層の拡大を目指してライセンスをAGPLからMITへ変更しました。進捗を追っていた方ならご存じの通り、私たちはAGPL/商用ライセンスのデュアルライセンス方式で製品の収益化を試みてきたため、簡単な決断ではありませんでした。残念ながら、このアプローチは期待に届きませんでした。ライセンス変更は、この現実を受け入れた結果です。うまく機能しなかった戦略にこだわり続けたくはありません。」
ひどかったし、自社OS向けソフトウェアを使う開発者への扱いとしてもお粗末だった
私たちは長い間、低レベルの開発ツールにはお金を払わず、その代わりにサポート費用を払うことに慣れてきた。ああいう形でライセンスを試したこと自体が驚き
長い間、高速なリンカーについての議論や、リンカーをより速いものに変えたらコンパイル時間が大きく短縮されたという話を何度も見てきたが、たいていリンカーがなぜ遅いのかはよく分かっていなかった
説明できる人がいればありがたい
性能向上のかなりの部分は作業を並列処理することから来ており、現代の強力なマルチコアCPUでは大きな改善につながる
もっと知りたいなら、RuiによるMoldについての良い発表がある: https://www.youtube.com/watch?v=hAt3kCalE0Y
catと同じくらい速いはず。バイナリをつなぎ合わせて終わりで済むからだ。回転式ディスクを使っていた時代にはディスクI/Oが問題だったが、今はそれほどではない時間がかかる部分は、処理しながら内容を書き換える作業。再配置テーブルをたどってコードにアドレスを入れるのは安く、セクション単位のデッドストリッピングもかなり安いが、関数内の個々の基本ブロックをデッドストリッピングしようとすると、はるかに多くの解析が必要になり時間がかかる
定数文字列の重複排除は良いアイデアだが、すべてを何らかの形のハッシュテーブルに流し込む必要がある。共通の接尾辞まで共有できるようにしたいなら、さらに作業が増える
重複排除、デッドストリッピング、デバッグ情報の書き換えにも時間がかかる。デバッグビルドには、書き換える必要のあるDWARFが数GB含まれることもある
興味深いことに、リンカーがスクリプト可能で、解釈するプログラムを渡せる点は大きなコストではないようだ。そのスクリプトがかなり短く、機能もある程度制限されているからだろう
歴史的にlldが非常に速かった理由は、デバッグ情報の加工やその他の重複排除をあまり行わなかったからだ。lldは高速に動いたが、出力バイナリは大きかった
リンク性能の分野から離れて数年たつので、現在の状況はよく分からない。特にmoldやlldが、出力品質と自身の性能の間でどのあたりにいるのかは分からない
https://www.airs.com/blog/archives/38
「繰り返しますが、目標は速度です。この場合は、私の2つ目のリンカーよりも速いことです。そのリンカーは、ELFと共有ライブラリのサポートが追加されるにつれて、何年もの間にかなり遅くなりました。このサポートは最初から設計されていたものではなく、後から付け足されたものです。新しいリンカーの将来計画にはインクリメンタルリンクのサポートも含まれており、これも速度を上げる別の方法です。」
初期Unix時代のアプリを思い浮かべればよい。単純な単一目的のアプリで、おそらくソースファイル1つ、オブジェクト1つ、libcだけをリンクすればよく、共有ライブラリのようなものはなかった
その後、「必須」の機能が追加されるにつれて、リンカーのコードは有機的に大きくなっていった。特に回転式ディスクがボトルネックだった時代には、速度よりも機能の正確さのほうが重要だった