g ++で静的ライブラリを作成するための最適化とフラグ

Question

Linux上でg ++コンパイラを使い始めたばかりで、コンパイラフラグについていくつか質問があります。ここで私は最適化フラグG ++のマニュアルページで-O1、-O2と-O3について読み、彼ら

最適化

です。私はこれらのフラグをいつ使用するのか理解していませんでした。通常どのような最適化レベルを使用していますか？ g ++のマニュアルでは、-O2について次のように述べています。

さらに最適化します。 GCCは、空間速度のトレードオフを伴わないほとんどすべてのサポートされた最適化を実行します。コンパイラは、-O2を指定すると、ループアンローリングまたは関数インライン化を実行しません。 -Oと比較して、コンパイル時間と生成されたコードのパフォーマンスの両方が向上します。

インライン展開とループアンローリングを行っていない場合、そのパフォーマンスがどのように達成され、このオプションが推奨されていますか？

静的ライブラリ、私はグラムを使用して静的ライブラリを作成するにはどうすればよい

++？ Visual Studioでは、私はクラスライブラリプロジェクトを選択することができ、それは "lib"ファイルにコンパイルされます。 g ++で同等のものは何ですか？

Answer 1

ループアンローリングおよびインライン化以外に、コンパイラが実行できる最適化は多数あります。ループアンローリングとインライン化は、コードがより高速になりますが、より大きなものにするため、そこに特に記述されています。

静的ライブラリを作成するには、 'g ++ -c'を使用して.oファイルを生成し、 'ar'を使用してライブラリにアーカイブします。

Answer 2

どのような最適化オプションを使用するかについては、1つの正解はありません。

特定の最適化レベルでは、パフォーマンスが低下することがあります。これは、書いているコードの種類とその実行パターンに依存し、実行している特定のCPUに依存します。

（単純な正規の例を与えるために、コンパイラはあなたのコードを以前よりも少し大きめにする最適化を使用することがあります）これにより、コードの特定の部分が命令キャッシュメモリへのより多くのアクセスが必要となります（ループなど）。

必要なものを測定して最適化することをお勧めします。試して、測定し、決定してください。

重要な経験則 - コードの最適化が増えるほど、C/C++ソースビューは生成されたバイナリから遠ざかるため、デバッガを使用してデバッグすること（またはその逆アセンブリを読み込むこと）が難しくなります。 。このような理由で開発/デバッグを行う際には、より少ない最適化で作業することは大まかな経験則です。

Answer 3

経験則：（。とデバッグシンボルを生成する-g）

デバッグする必要がある場合は、-O0を使用

あなたは-O2を使用し、それを出荷する準備をしているとき。

gentooを使用するときは、-O3 ...を使用してください。

あなたは、組み込みシステムの上に置く-Osを使用する必要があります（サイズのため、ない効率のために最適化されます。）

Answer 4

すべてすべての最適化レベルでオプションを暗示gccのマニュアルのリスト。 O2では、コードに応じて、アプリケーションの速度を大幅に変えることができる定数の折り畳み、分岐予測、およびcoのようなものが得られます。正確なオプションはバージョンに依存しますが、詳細については文書化されています。

ar rc libfoo.a foo.o foo2.o .... 
ranlib libfoo.a 

RANLIBは必ずしも必要ではありませんが、それを使用しないための理由はありません。

は、静的ライブラリを構築するには、次のようにarを使用します。

Answer 5

静的ライブラリの質問に関しては、David Cournapeauの答えは正しいですが、静的ライブラリファイルでranlibを実行するのではなく、代わりに 'ar'で 's'フラグを使用することもできます。 'ar' manual pageは、そのことを

としています。アーカイブ上での実行は、ranlibを実行するのと同じです。

どの方法を使用するかは、個人的な好みの問題です。