gold リンカーは、BFD ld よりも保守しやすく高速なリンカーを作成することを目的として、ELF 固有のリンカーとして設計されました。 (「従来の」GNU binutils リンカ)。副作用として、BFD ld よりも少ないメモリを使用して非常に大きなプログラムをリンクできます。 おそらく、処理する抽象化の層が少なく、リンカのデータ構造が ELF 形式により直接的にマップされるためです。
2 つのリンカーの設計上の違いと、メモリ使用への影響を具体的に説明しているドキュメントがあまりないかどうかはわかりません。さまざまな GNU リンカーの作成者である Ian Lance Taylor によるリンカーに関する非常に興味深い一連の記事があり、gold に至るまでの多くの設計上の決定について説明しています。 .彼はこう書いています
私が現在取り組んでいるゴールドと呼ばれるリンカーは、私の 3 番目になります。これは ELF リンカ専用です。繰り返しますが、目標は速度です。この場合、2 番目のリンカーよりも高速です。そのリンカは、ELF と共有ライブラリのサポートを追加することで、長年にわたって大幅に遅くなりました。このサポートは、設計されたものではなく、パッチが適用されたものです。
(2 番目のリンカーは BFD ld です。 .)
ゴールド リンカは、リンク プロセスを大幅に高速化するために作成されました。ゴールドオーサーのイアン・ランス・テイラーによると
<ブロック引用>現時点では、ゴールドには既存のリンカーに対する重要な利点が 1 つだけあります。それは、より高速であることです。大規模な C++ プログラムでは、実行速度が 5 倍になったと測定しました。
彼は、ゴールド リンカーのパフォーマンスを従来の GNU リンカーと比較しています。 gold (GNU リンカとは異なり) は、オブジェクト ファイルの処理に BFD ライブラリを使用しません。
gold の制限は、(多くのオブジェクト ファイル タイプを処理できる GNU リンカとは異なり) ELF 形式のオブジェクト ファイルしかリンクできないことです。
GNU リンカを使用する際に直面した問題に関して、SO に関する同様の質問に対する Michael Adam の興味深い回答を次に示します。
<ブロック引用>ゴールド リンカは、一部の詳細に関して従来のリンカよりも正確であるように思われるため、コードにいくつかの依存関係の問題も発見しました。参照してください。この Samba コミット。
gold vs ld ベンチマーク
https://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience/53921263#53921263
で、ld と gold の具体的な合成ベンチマークを公開しました。結果の要約:gold は ld よりも 2 倍から 3 倍高速でした。
この時間の増加は、制御不能なテンプレートとコード生成を伴う複雑な C++ プロジェクトの大きなゲーム チェンジャーになる可能性があります。これは、リンク ステップにはプロジェクトのすべてのファイルが含まれ、コンパイルとは異なり、変更した場合でも常に実行する必要があるためです。 1 つの .cpp ファイルだけです。
そのため、リンク時間が遅いと開発サイクルが耐えられなくなり、Google がリソースを投入した主な理由になる可能性があります。ささいなファイル変更ごとに 30 秒ではなく 10 秒待つことのメリットを想像してみてください。
合成ベンチマークの時間の増加は、その回答にも記載されているように、複雑な実世界のプロジェクト (gem5) で得た実際の増加とも一致しました。