このトピックの情報は、パフォーマンスの拡張手法を使用していて、最適化しているアプリケーション形式の解析が済んでいることを前提に説明しています。
最適な手法を判断するためにアプリケーションのプロファイリングを行った後、コンパイラーによって行われた最適化および制限を確認します。そして、コンパイラー・レポートを使用して、次に何を行うかを決定します。
レポートの内容に応じて、コンパイラーが重要なアーキテクチャー上の機能を活用して最高レベルのパフォーマンスを達成できるように、オプション、プラグマを選択し、必要なコード修正を行います。
コンパイラー・レポートは、コンパイラーによって行われた仮定に基づいて、行うことができる処理とできない処理を示します。オプションとプラグマを色々と試すことで、コンパイラーが行った仮定を理解し、また、新しい最適化の手法やテクニックを導き出すことができます。
いくつかの重要な方法でコンパイラーを効率的に利用できます。
適切なレポートを読み、コンパイラーが行っていることとコンパイラーがコードに関して行った仮定を理解する。
アプリケーションから最高レベルのパフォーマンスが得られるように、特定のオプション、組み込み関数、ライブラリー、およびプラグマを使用する。
例えば、単精度値の平方根を絶えず計算する場合、単精度データ型用の適切な組み込み関数を使用すると、パフォーマンスを向上できます。例えば、C で sqrt() の代わりに sqrtf() を使用します。
他の推奨する手法は、「最適化手法の適用」を参照してください。
メモリー・エイリアシングは、IA-64 アーキテクチャー・ベース・システム用インテル(R) コンパイラーの最適化に最も大きな影響を与える問題です。メモリー・エイリアシングは、2 つ以上のポインターで指定されたメモリーの場所に書き込みます。このような場合、コンパイラーが最適化しすぎないように注意する必要があります。コンパイラーが最適化しすぎると、予期しない動作 (正しくない結果、異常終了、その他) を引き起こすことがあります。
コンパイラーは、通常、モジュールや関数ベースで最適化を行うので、関数へ渡されるグローバル変数やローカル変数の使用を全体から見て判断していません。このため、コンパイラーは、通常、関数に渡されたすべてのポインターがエイリアスされると仮定します。コンパイラーは、エイリアスされないことがわかっているポインターにもこの仮定を行います。このような動作は、完全に安全なループがパイプライン化またはベクトル化されず、パフォーマンスが向上しないことを意味します。
ポインターがエイリアスされないことをコンパイラーに知らせる方法はいくつかあります。
-fno-alias (Linux*) または /Oa (Windows*) のような、包括的なコンパイラー・オプションを使用します。これらのオプションは、すべてのモジュールのポインターがエイリアスされないことをコンパイラーに知らせます。プログラムが正確であることの責任は、開発者が負うことになります。
-fno-fnalias (Linux) または
/Ow (Windows) のような、あまり包括的ではないコンパイラー・オプションを使用します。これらのオプションは、関数の引数で渡されたポインターがエイリアスされないことをコンパイラーに知らせます。
関数の引数は、コンパイラーに明確にできる潜在的なエイリアシングの一般的な例です。関数に渡される引数はエイリアスされないことがわかっていますが、コンパイラーはエイリアスされると仮定します。しかし、これらのオプションは、関数の引数がエイリアスされないと仮定しても安全であることをコンパイラーに知らせます。このオプションは、-fno-nalias (Linux) または /Ow
(Windows) オプションを使用してコンパイルされたモジュールのすべての関数に影響する点に注意してください。
ivdep プラグマを使用します。または、関数の指定されたループに適用するプラグマを使用します。すべての関数を指定するよりも正確です。プラグマは、指定されたループについては、ベクトルの依存性がないと断定します。本質的には、ポインターが指定されたループでエイリアシングしていないと言うのと同じことです。
restrict キーワードを使用します。ポインターを明確にするより正確な方法は、restrict キーワードです。restrict キーワードは、エイリアスされていない個々のポインターを識別するために使用されます。restrict キーワードは、指定されたメモリーの場所が他のポインターによって書き込まれないようにコンパイラーに知らせます。
次の例は、restrict キーワードを使用して、z で指されたメモリーアドレスが他のポインターによって書き込まれないことをコンパイラーに知らせます。この新しい情報により、コンパイラーはループを次のようにベクトル化またはソフトウェアのパイプライン化できます。
例 |
---|
// One-dimension array. void restrict1(int *x, int *y, int * restrict z) { int A = 42; int i; double temp; for(i=0;i<100;i++) { z[i] = A * x[i] + y[i]; } } // Two-dimension array. void restrict2(int a[][100], int b[restrict][100]) { /* ... */ } |
上記の例のように restrict キーワードを使用するには、コンパイル行で -restrict (Linux) または /Qrestrict (Windows) オプションを使用する必要があります。
パフォーマンスに大きな影響を与える別の問題は、非ユニットストライド方式におけるメモリーアクセスです。これは、内部ループが連続的にインクリメントし、隣接していない場所からメモリーにアクセスしていることを意味します。例えば、次のような行列乗算コードを考えてみます。
例 |
---|
// Non-Unit Stride access problem with b[k][j] void non_unit_stride(int **a, int **b, int **c) { int A = 42; for(int i=0; i<A; i++) for(int j=0; j<A; j++) for(int k=0; k<A; k++) c[i][j] = c[i][j] + a[i][k] * b[k][j]; } |
配列に関連した最内ループがインクリメントされるときに、c[i][j] および a[i][k] の両方が連続するメモリーの場所にアクセスする点に注意してください。しかし、配列 b は、インデックス k および j のループでメモリー・ユニット・ストライドにアクセスしません。ループが b[k=0][j=0] を読んだ後、k ループが 1 から b[k=1][j=0] にインクリメントされます。
この問題に対処するには、ループ変換 (ループ交換とも呼ばれます) を行います。コンパイラーでループ交換を自動的に行ったとしても、必ずしもすべての機会を認識するとは限りません。
上記の例のメモリー・アクセス・パターンは、次の図のようになります。
上記の例に、ループ交換を行うために次のような変更を加えたとします。
例 |
---|
// After loop interchange of k and j loops. void unit_stride(int **a, int **b, int **c) { int A = 42; for(int i=0; i<A; i++) for(int k=0; k<A; k++) for(int j=0; j<A; j++) c[i][j] = c[i][j] + a[i][k] * b[k][j]; } |
ループ交換の後、メモリー・アクセス・パターンは次の図のようになります。