GCCの最適化

あるいは、app-portage/cpuid2cpuflagsをインストールし、ツールがCPU_FLAGS_X86などの変数を通じて表示した利用可能なCPU特有のオプションを/etc/portage/package.use/00cpuflagsファイルに追加することもできます:

さらにmarchとmtuneの値を含む詳細な情報を得たい場合は、以下の2つのコマンドが使えます。

• 最初のコマンドはコンパイラにリンクを行わないようにさせ(-c)、また、--helpをコマンドラインオプションを明らかにせよとではなく、あるオプションが有効か無効かを示せという意味に解釈させます(-Q)。ここでは、選択されたターゲットで有効なオプションが出力されます:

user $gcc -c -Q -march=native --help=target

• 二つ目のコマンドはヘッダーファイルをビルドしますが、実際には処理は行わずそれらを画面に表示する(-###)ことでコンパイラーディレクティブを表示します。出力の最終行がすべての最適化オプションと選択されたアーキテクチャーを含むコマンドです:

user $gcc -### -march=native /usr/include/stdlib.h

では実際に-marchを見てみましょう。この例は古いPentium IIIチップ向けです。

CFLAGS="-march=pentium3"
CXXFLAGS="${CFLAGS}"

こちらはAMD64向けです。

CFLAGS="-march=athlon64"
CXXFLAGS="${CFLAGS}"

CPUのタイプが決められない場合、またはどの設定を使えばいいかわからない場合、-march=nativeを使うことができます。このフラグを使った場合、GCCはプロセッサを判別して、自動的にふさわしいフラグを設定するでしょう。しかしながら、このフラグは異なるCPU向けにパッケージをコンパイルする目的では使用すべきではありません！

例えば、あるコンピュータでパッケージをコンパイルして、しかしそれらを別のコンピュータで実行しようとしている場合 (処理の早いコンピュータで、古くて遅いマシンのためにビルドしているときなど)、-march=nativeを使わないでください。"native"というのはコンパイルしているマシンのCPUタイプのみに特化して、アプリケーションのコードを生成することを意味しています。AMD Athlon 64上で-march=nativeと共にビルドされたアプリケーションは、古いVIA C3では実行することができないでしょう。

また、-mtuneと-mcpuフラグも利用可能です。これらのフラグはたいてい-marchフラグが利用できない場合にのみ使われます。例えば特定のプロセッサアーキテクチャは-mtuneや-mcpuが必要になるかもしれません。残念ながら、GCCの挙動はそれぞれのフラグの振る舞いが、あるアーキテクチャから近いアーキテクチャであってもあまり一貫性はありません。

x86とx86-64のCPUにおいて、-marchは利用可能な命令セットと正しいABIを使い、そのCPUに特化したコードを生成するでしょう。そのため古かったり種類の異なるCPUとの後方互換性は持っていません。i386やi486のような古いCPU向けにコードを生成する必要があるときのみ、-mtuneの使用を考慮するべきでしょう。-mtuneは-marchよりも一般的なコードを生成します。特定のCPUコードにチューニングしますが、利用可能な命令セットやABIを考慮しないのです。-mcpuはx86やx86-64のシステム上では非推奨となっているので、使わないでください。

x86/x86-64でない(SPARCやAlpha、PowerPCのような)CPUでのみ、-marchの代わりに-mtuneや-mcpuが必要になるでしょう。これらのアーキテクチャ上では、-mtune/-mcpuは(x86/x86-64上での)-marchと同じように振る舞うでしょう･･･しかしフラグの名前は違うのです。繰り返しますが、GCCの振る舞いとフラグ名はアーキテクチャを超えて一貫していないので、システムでどのフラグを使うべきなのかをGCCのマニュアルで必ず確認してください。

-O

次は-Oフラグについてです。これは全体の最適化レベルをコントロールしますが、特にこの最適化レベルを上げることによって、ソースコードのコンパイルの時間がいくらか増えたり、よりたくさんのメモリを使用するようになります。

７つの-O設定があります。-O0、-O1、-O2、-O3、-Os、-Og、-Ofastです。/etc/portage/make.confで指定できるのはこのうちの一つだけです。

-O0を除いて、-Oの設定はいずれもいくつかの追加フラグを有効にします。なので、どの-Oレベルで、どのフラグが有効になり、そのフラグにどんな効果があるのかを学ぶために、GCCマニュアルのoptimization options の章を読んで確認しましょう。

では、それぞれの最適化レベルを見てみましょう。

• -O0: このレベル("O"のあとにゼロが続いてます)は、完全に最適化をオフにします。CFLAGSやCXXFLAGSの中に-Oが定義されていない場合のデフォルトです。このレベルはコンパイル時間を短縮して、生成するデバッグ情報を改善しますが、いくつかのアプリケーションは最適化がないと正しく動作しません。よって、デバッグ以外では推奨されません。

• -O1: これは最も基本的な最適化レベルです。コンパイラは時間をたくさんかけることなく、高速でサイズの小さなバイナリを生成しようと試みるでしょう。これは基本的な最適化しかおこないませんが、その代わり、いつでもうまくいくはずです。

• -O2: -O1から更に踏み込みます。これは特別な理由がない限り"推奨される"最適化レベルです。-O2は-O1で有効になるものに加え、さらにいくつかのフラグを有効にします。-O2を使うと、コンパイラはサイズとコンパイル時間に妥協せずにコードのパフォーマンスを改善しようと試みます。このレベルではSSEやAVXは利用されますが、YMMレジスタは-ftree-vectorizeも有効にしない限り使われません。

• -O3: これは取りうる最も高い最適化レベルです。コンパイル時間とメモリ使用量を犠牲にして最適化を実施します。ただし-O3は性能を改善する保証がありません。実際多くのケースで、バイナリサイズが大きくなり、メモリ使用量が増えることで逆にシステムが遅くなります。-O3はいくつかのパッケージを壊すことがわかっています。これらの理由により-O3は推奨されません。一方、このレベルはコード内のループをベクトル化する-ftree-vectorizeを有効化し、AVX YMMレジスタも利用されます。

• -Os: このレベルはバイナリのサイズを重視して最適化するでしょう。これは-O2フラグの中で、生成されるバイナリのサイズが増えないものを全て有効にします。CPUのキャッシュが小さかったり、ディスクの空き容量が極端に限られている場合などに非常に有効でしょう。

• -Og: GCC 4.8では新しい汎用的な最適化レベル-Ogが導入されました。このレベルはコンパイル時間の短縮とデバッグエクスペリエンスを向上させる一方、妥当なランタイム性能を確保することを目的としています。結果的に開発全体で得られるものはデフォルトの最適化レベル-O0より向上するはずです。-Ogと-gは同じでないことだけ理解しておいてください。-gはデバッガとやりとりするために単純に最適化をオフにするだけです。

• -Ofast: GCC 4.7では、-O3に加えて-ffast-math、-fno-protect-parens、-fstack-arraysが利用できます。このオプションは規格への厳密な適合を犠牲にするため推奨されません。

前述の通り、-O2が推奨される最適化レベルです。もし-O2以外を使用してパッケージのコンパイルが失敗する場合は、-O2で再コンパイルしてみましょう。うまくいかなかった場合は、CFLAGSとCXXFLAGSを(エラー報告や問題の調査向けに)-O1や-O0 -g2 -ggdbのように、最適化レベルを低く設定してみてください。

-pipe

よく使うフラグに-pipeがあります。このフラグは、生成されるバイナリ自体には何の影響もありませんが、コンパイル時間が短縮されます。これはコンパイルにおける各処理の間で一時ファイルを使う代わりにパイプを使うように指示します。これにより多くのメモリを使うことになります。メモリに余裕のないシステムの場合、GCCが強制終了するかもしれません。そのような場合はこのフラグを使わないでください。

-fomit-frame-pointer

これは生成されるバイナリのサイズを減少させるために設計されているフラグで、よく利用されています。このフラグは、(x86-64のように)有効化してもデバッグ作業の阻害をしないアーキテクチャにおいては(-O0を除く)全ての-Oのレベルに対して有効になりますが、有効化する必要がある場合もあります。そのような場合にはこれをフラグに加えてください。GCCマニュアルによれば、全てのアーキテクチャにおいて、-Oを使えば-fomit-frame-pointerが有効になる訳ではありません。GCC 4.6までは、もしくは-Osを使っているときは、x86-32で有効化するためには明示的に-fomit-frame-pointerオプションを使わなければなりません。ただし、-fomit-frame-pointerを使うとデバックは困難もしくは不可能になります。

特に、Javaで書かれgcjでコンパイルされたアプリケーションの問題解決をとても難しくします。もっとも、Javaだけがこのフラグの影響を受けるわけではありませんが。このように、このフラグは役立つ一方でデバッグを難しくしているのです。特にバックトレースは役に立たなくなります。しかしながら、それほどソフトウェアのデバッグを行う予定がなく、他に-ggdbのようなデバッグ関連のCFLAGSを追加していないのであれば、-fomit-frame-pointerを使ってみてもいいでしょう。

-msse、-msse2、-msse3、-mmmx、-m3dnow

これらのフラグはStreaming SIMD Extentions (SSE)、SSE2、SSE3、MMX、3DNow!の命令セットをx86とx86-64アーキテクチャで有効にします。これらは主にマルチメディアやゲーム、その他の浮動小数点を多用する計算処理に向いています。その他にも有用な数学用機能の向上をいくつか含んでいます。比較的新しいCPUならば、これらの命令セットに対応しています。

通常、正しい-marchを使っている限り、これらのどのフラグも/etc/portage/make.confに加える必要はありません(例えば-march=noconaは-msse3を有効にします)。いくつかの注意すべき例外は、比較的新しいVIAとAMD64のCPUです。VIAとAMD64はこれらの命令をサポートしますが、(SSE3のように)-marchでは有効になりません。これらのCPUについては/proc/cpuinfoの出力を確認して、ふさわしいフラグを追加する必要があるでしょう。

最適化FAQ

-funroll-loopsや-fomg-optimizeを使ったら速くなったんだけど！

いいえ違います。フラグを付け加えれば付け加えるほど最適化されると言う誰かに騙されているだけです。システム全体で挑戦的なフラグを使うことはあなたのアプリケーションを傷つけるでしょう。GCC マニュアルでは-funroll-loopsと-funroll-all-loopsを使うとバイナリは大きくなり、実行も遅くなると述べています。またいくつかの理由から、これらの二つのフラグと同時に、-ffast-mathや-fforce-memや-fforce-addrなどの似たようなフラグが、速度を最大限誇示したい人たちの間で、とても人気を博しています。

ここで本当に問題なのは、これらのフラグは危険なほどに挑戦的なフラグということです。それらのフラグが何をやらかしているのかGentoo ForumsとBugzillaあたりをよく見てください。ろくなことないですよ！

それらのフラグをCFLAGSやCXXFLAGSに設定し、システム全体で使う必要はありません。それらはパフォーマンスに悪影響を及ぼすだけでしょう。それらのフラグが、最先端でハイパフォーマンスなシステムを使っているかのように見せるかもしれませんが、しかしそれらは何の効果もないどころか、バイナリのサイズが膨れ上がり、無効(INVALID)や修正の必要無し(WONTFIX)と結論づけられたバグを踏むことになります。

そのような危険なフラグを使う必要はありません。いえ、使わないでください。-march、-O、-pipeという基本を守り通してください。

3より高い-Oレベルはどう？

何人かのユーザーが、-O4や-O9などを使うことによってもっといいパフォーマンスを得たと誇張していますが、3より高い-Oレベルは何の効果もありません。コンパイラは-O4のようなCFLAGSも許容するでしょうが、それらは実質何もしないのです。-O3の最適化を行うだけで、それ以上の最適化はしません。

さらに証拠が必要ですか？ソースコードを試してみてください。

見てのとおり、3より高いレベルであっても、結局-O3として扱われます。

実際のマシンと別のマシンでコンパイルするのはどう？

何人かの読者は、あきらかに劣ったCPUやGCCサブアーキテクチャでコンパイルすることを避けるために他のマシンでコンパイルすることは、（ネイティブな環境でのコンパイルと比較して）劣った最適化になるのか知りたくなるでしょう。答えは単純でいいえです。コンパイルが走る実際のマシンに関係なく、またGCCをビルドしたときのCHOSTに関係なく、同じ引数が使用されている限り(-march=nativeは除く)、そしてGCCのバージョンが同じである限り(マイナーバージョンが違うかもしれません)、最適化の結果は厳密に同じです。

例を一つあげます。GCCのCHOSTがi686-pc-linux-gnuとなっているマシンにGentooをインストールして、CHOSTがi486-linux-gnuとなっている別のPCにDistccサーバーをインストールします。リモートサーバーのコンパイラのサブアーキテクチャもしくはハードウェアが明らかに劣っている場合、最適化が十分なされないのではと心配する必要はありません。結果は、両方のコンパイラに同じ引数が与えられている限り（かつ-marchにnativeが与えられていない限り）、ネイティブにビルドしたときと同じ最適化がかかります。ただしこの特殊なケースではDistcc and -march=nativeで説明されている通り、ターゲットのアーキテクチャが明示的に指定されなければなりません。

異なるサブアーキテクチャに向けてビルドされた２つのGCCの動作には一つしか違いがありません。それは暗に与えられるデフォルトの-marchです。コマンドラインで-marchを明示的に指定しなかった場合、GCCのCHOSTに設定された値が使用されます。

冗長なフラグ指定はどう？

しばしば、/etc/portage/make.confの中で、個々の-Oレベルを指定すれば有効になるフラグを重複してCFLAGSやCXXFLAGSに設定していることがあります。これは時々知らずにやってしまうのですが、一方で(ebuildが行う)フラグの除去や置換を回避するために意図的に行われることがあります。

フラグの除去や置換はPortageツリーの中にある多くのebuildで行われます。大抵は、特定の-Oレベルでパッケージをコンパイルすると失敗するために、もしくはフラグを追加するとそのソースコードでは問題が出るためです。ebuildはどちらの場合も、全部/一部のCFLAGSとCXXFLAGSを除外するか、もしくは異なる-Oレベルに置換するでしょう。

Gentoo Developer Manualにフラグの除去と置換がどのような場合に、どのように使われているのか概要が記載されています。

特定のレベルに対して重複してフラグを設定することによって、-Oに対するフラグ除去をある程度回避することができます。例えば、-O3であれば次のようにします。

しかしながら、これは賢いやり方ではありません。CFLAGSは理由があって除去されるのです！ フラグが除去されるとき、それらのフラグでパッケージをビルドすると安全でないことを意味します。明らかに分かっているのは、-O3でシステム全体をコンパイルすることは"安全ではない"という事です。そうすると、-O3の最適化で有効になるいくつかのフラグによって問題となるパッケージが出てくるでしょう。そのため、それらのパッケージをメンテナンスしている開発者の"裏をかく"ことを試みないでください。 開発者を信用してください。フラグの除去と置換はシステムやアプリケーションの安定性を確保するために行われているのです！ もしebuildに代替のフラグが指定されているなら、それを回避しようとしないでください。

開発者が許可していないフラグでパッケージをビルドすれば、大概は数々の問題に繋がるでしょう。Bugzillaに不具合を報告する際には、/etc/portage/make.confで使っているフラグは容易く見抜かれてしまうので、余計なフラグを除いて再コンパイルする様に開発者に指示されるでしょう。初めから冗長なフラグを指定しないことで、再コンパイルする手間を省いてください！ あなたが開発者よりよく知っていると根拠なく無意識に決めつけないでください。

LDFLAGSはどう？

Gentoo開発者がすでに基本的で安全なLDFLAGSを基本プロファイルにセットしているので、それらを変更する必要はありません。

パッケージごとにフラグを変更出来るの？

パッケージごとに(CFLAGSを含む)環境変数を変更する方法は、Gentoo Handbook, "パッケージごとの環境変数"で説明しています。

参考

• コンパイルオプションを設定する (AMD64 ハンドブック)

外部資料

以下、最適化について理解を深めるための資料を紹介します。

• GCC online documentation

• man make.conf

• ウィキペディア

• Gentooフォーラム

参照