38

C++ プロジェクトにリンクされている約 50 の異なる静的ライブラリがあり、リンクには平均 70 秒かかります。

今回、ライブラリのリンク順序を変更することで移動することがわかりました。これは、リンカーがその時点までに構築されたシンボル テーブル全体で一連のシンボルを検索し続ける必要がない場合に予想されます。

「nm」を使用して、静的ライブラリ間の依存関係グラフを取得できると思います。ただし、それでは「正しい」リンク順序が 1 つしか得られません。最速のリンク順序を取得する要因は何ですか?

量を最小限に抑えようとするトラバーサルを取得することで、上記の依存関係グラフと関係があるように感じますが、どちらが正しいかはわかりません。

どんな助けでも大歓迎です。

私は主に intel コンパイラーと gcc コンパイラーを時々使用しています。topで確認すると、どちらもGNU ldリンカーを使用しているようです。お役に立てれば...

私が質問しようとしていることをもう少し明確にするために、一連の静的ライブラリから 1 パスの順序を取得する方法を既に知っています。私はこのスクリプトを自分で書きましたが、以下の Olaf の回答が示唆するように、これを行うためのよく知られたツールがあります。

私の質問は、既に 2 つの 1 パス リンクの順序付けがあり、そのうちの 1 つは ~85 秒で実行され、もう 1 つは ~70 秒で実行されます。明らかに、1 パス注文内で実行できる最適化がまだいくつかあります。

4

4 に答える 4

7

別の方法として、静的ライブラリではなく共有ライブラリにライブラリをコンパイルしてみませんか？

私が働いている場所では、1つの大きなプロジェクトのリンク時間は約6分でしたが、これは5つのライブラリのみでした。

私の解決策は（デバッグバージョンの場合）、アルファベット順に.soファイル（libA.so、libB.soなど）を作成することでした。これにより、個々のリンクは長すぎず、すべての（部分的な）リンクのため、最終的なリンクははるかに短くなりました。以前に行われていました。私の新しい方法には「危険」が認識されていたため、リリースバージョンは昔ながらの方法で作成されました。

この方法を使用して、1モジュールのコンパイル/リンクサイクルを6分から10秒に短縮することができました。

于 2013-03-06T22:48:33.720 に答える
6

以前は、静的ライブラリ内のオブジェクトの順序が重要でした。それに応じてオブジェクトを並べ替えることができます：

$ ロード *.o | ソート

メインのオブジェクトとライブラリで同じことができるかもしれませんlorder main.o test.o libsome.a libthing.a | tsort。マンロードを見ろ

于 2012-11-13T20:00:10.593 に答える
3

オブジェクトとライブラリの順序に基づくワンパスの順序について話しているのですが、静的ライブラリを検索している場合、静的ライブラリ内の何かが特定の順序になることを保証することはできず、実際にはそれを制御することしかできません。静的ライブラリを特定の方法で注文することによってar。

さらに、リンカが静的ライブラリ（y | ies）をどのように使用するかを理解していなければ、考えられる2つの最良の仮定は次のとおりです。

  1. シンボルを提供または必要とするオブジェクトを参照するシンボルのハッシュテーブルを作成します。これが正確な仮定である場合、静的ライブラリで取得できる最良の下限は、そのようなハッシュテーブルにデータを入力してそこから読み取るのにかかる時間です。
  2. アーカイブのインデックスに指定された順序に基づいて、アーカイブから盲目的に読み取ります。

最適なリンク時間の下限を見つけるために、アーカイブ内のオブジェクトのすべてまたはサブセットを再配置可能なオブジェクトとしてリンクしてみてください。サブセットについては、可能であれば、で実際にリンクされているすべてのオブジェクトを識別します。

のマニュアルページは、...でlorder同じ結果を得ることができることを示していますar ts <archive>。これにより、順序付きリストが印刷されます。のマニュアルページは、フラグarを指定して実行すると、その最適な順序がアーカイブのインデックスに自動的に保存されることを示しているようです。ars

また、循環依存関係が存在する可能性があることに注意してください。ただし、すでに混乱しているtsort場合は、そのことをすでに認識している必要があります。

最後に、最後の情報を1つ残しておきます。必要なのは、NP完全問題を解決できるものです。幸運を。

私が取り組んでいるビルドのために、最後の少しの間、いくつかのタイミングテストを実行してきました。sフラグを追加して、ARFLAGSどのような効果があるかを確認しました。

全体として、ビルド時間が長くなったようですが、その理由には論理的な説明があると思います。

  • ほとんどの実行可能ファイル/共有オブジェクトは静的リンクを使用しません
  • 各静的ライブラリのPICバージョンと非PICバージョンを構築しています

静的ライブラリをもっと多用しているとしたら、おそらくこれを行うことでメリットが得られるでしょう。

于 2013-03-07T17:54:32.140 に答える
3

ld と gold を比較した情報に基づいて、ld の速度はシンボル テーブルの大きさの影響を受けます。オブジェクト ファイルの処理によってシンボル テーブルが大きくなるにつれて、リンク ステップが遅くなります。したがって、2 つの異なる 1 パス リンク順序がある場合、より多くのシンボルを含むライブラリをその順序で後でフィックスアップする方が、リンクが速くなります。トポロジカル ソートを変更して、順序付け基準にシンボル数を含めることができるはずです。

于 2012-11-14T02:26:07.417 に答える