オフロードされないコード領域を調査

モデル化できません: マークされた領域の外部

インテル® Advisor は、解析対象としてマークされていないコード領域のパフォーマンスをモデル化できません。

コード領域がマークの規則を満たしていることを確認するか、別のマーク方法を使用してください。

• システムモジュールまたはシステム関数ではないこと。
• 命令ミックスがあること。
• 実行されていること。
• 実行時間は 0.02 秒以上です。

モデル化できません: 未実行

コード領域はコールツリー内にありますが、インテル® Advisor はサーベイ中に使用されたデータセットに対するコード領域の呼び出しを特定できません。

これはループの実行時間が極端に短く、インテル® Advisor のサンプル間隔に近い場合に発生する可能性があります。このようなループでは時間測定がかなり不正確になる可能性があります。デフォルトのサーベイサンプル間隔は 0.01 秒です。

インテル® Advisor のサンプル間隔を短くしてみます。

• GUI から:
  1. [Project Properties (プロジェクトのプロパティー)] > [Survey Hotspots Analysis (サーベイ・ホットスポット解析)] > [Advanced (高度)] へ移動します。
  2. [Sampling Interval (サンプリング間隔)] を 10ms 未満に設定します。
  3. オフロードのモデル化を再実行します。
• CLI から: --collect=survey を実行するには、--interval オプションを使用します。

モデル化できません: 内部エラー

内部エラーは、データ収集または処理中にインテル® Advisor で問題が発生したため、不正なデータが生成されたかデータが欠如していることを意味します。

オフロードのモデル化パースペクティブを再実行して、メトリック属性の問題を解決してください。問題が解決しない場合、アナライザー・コミュニティー・ フォーラムのテクニカルサポートにお問い合わせください。

モデル化できません: システムモジュール

このコード領域はシステム関数/ループです。

これは問題ではありません。このコード領域がオフロード領域またはランタイム呼び出し内にある場合、その時間はオフロード領域の実行時間に追加されます。

モデル化できません: 実行カウントなし

インテル® Advisor は、特性化解析のトリップカウント解析中にループの呼び出しを検出できなかったため、ループの実行カウントに関連する情報はありません。

分岐がループでどのように実行されるか確認します。

誤ったループが見つかった場合、オフロードのモデル化を再実行して、メトリック属性の問題を解決してください。

子のオフロードよりも利点が少ないか同等です

コード領域の子ループ/子関数をオフロードすると、すべての子を含む領域全体をオフロードするよりも収益が高くなります。これは、注目する領域のターゲット・プラットフォームで推測された時間が、オフロードに有益な子領域のターゲット・プラットフォームで推測された時間の合計以上であることを意味します。

合計実行時間、コスト、トリップカウント、または依存関係が原因でオフロードできない場合があります: 。

利益がなくとも特定のコード領域のオフロードをモデル化します。詳細については、特定のループのオフロードを強制するを参照してください。

親のオフロードよりも利点が少ないか同等

注目する領域の親コード領域全体をオフロードするほうが、子領域を個別にオフロードするよりも収益が高くなります。これは、注目する領域のターゲット・プラットフォームで推測される時間が、オフロードに有益な親領域のターゲット・プラットフォームで推測される時間以上であることを意味します。

子コード領域のオフロードは、高いオフロードの負荷によって制限されることがあります。

解決方法 1

カーネルの実行がオフロードのコストとオーバーラップすると想定される場合、--collect=projection アクションオプションまたは analyze.py スクリプトとともに--assume-hide-taxes オプションを使用します。詳細は、呼び出しコストの管理を参照してください。

解決方法 2

利益がなくとも特定のコード領域のみのオフロードをモデル化します。詳細については、特定のループのオフロードを強制するを参照してください。

利点なし: 依存関係により並列実行の効率が制限される

依存関係は並列実行を制限し、コード領域はターゲットデバイスへのオフロードの恩恵を受けることができません。予測されるアクセラレートの実行時間は、元の実行時間以上です。

解決方法 1

想定される依存関係を無視し、全体または選択したコード領域のオフロードのモデル化を行います。

• GUI から:
  1. [Project Properties (プロジェクトのプロパティー)] > [Performance Modeling (パフォーマンスのモデル化)] に移動します。

  2. [Other Parameters (他のパラメーター)] フィールドに次のいずれかのオプションを入力します。

     • --no-assume-dependencies は、依存関係に関する情報を持たないすべてのコード領域が並列であると想定します。
     • --set-parallel=[<loop-IDs/source-locations>] は、指定するコード領域の依存関係を無視します。
  3. パフォーマンスのモデル化を再実行します。
• CLI から: --collect=projection または analyze.py とともに使用します。次のいずれかを使用します。
  • --no-assume-dependencies は、すべてのコード領域の依存関係を無視します。
  • --set-parallel=[<loop-IDs/source-locations>] は、指定するコード領域の依存関係を無視します。

詳細については、依存関係がモデル化に影響するか確認を参照してください。

解決方法 2

データを収集する際に依存関係解析を有効にしない場合、解析を実行してコード内の実際の依存関係に関する詳細情報を取得します。

• GUI から: [Analysis Workflow (解析ワークフロー)] ペインで、依存関係とパフォーマンスのモデル化を有効にし、パースペクティブを再実行します。
• CLI から: --collect=dependencies を使用して依存関係分析を実行し、--collect=projection または analyze.py を使用してパフォーマンスのモデル化を再実行します。

詳細については、依存関係タイプのメトリックの説明を参照してください。

利点なし: ループ反復数が、ターゲット・プラットフォームの機能を十分に活用するのに十分でありません

ループの反復数が少ないため、ターゲット・プラットフォームにオフロードしても利点がありません。

多くの場合、このようなコード領域はオフロードの恩恵を得ることができません。コードの移行中に並列ワークの量が増加し、コンパイラーやプログラミング・モデルによってループがチャンクに分割されると予想される場合、次の回避策を試してください。

• GUI から:
  1. [Project Properties (プロジェクトのプロパティー)] > [Performance Modeling (パフォーマンスのモデル化)] に移動します。
  2. [Other Parameters (その他のパラメーター)] フィールドに --batching または --threads=<target-threads> を入力します。<target-threads> には、ターゲットデバイスの能力に等しい並列スレッド数を指定します。
  3. パフォーマンスのモデル化を再実行します。
• CLI から: --collect=projection または analyze.py を実行するときは、次のいずれかを使用します。
  • --batching によるバッチ処理のような手法モデル化
  • --threads=<target-threads><target-threads> には、ターゲットデバイスの能力に等しい並列スレッド数を指定します。

バッチ処理を有効にすると、カーネルを起動するコストが増加します。タスクを減らすには --assume-hide-taxes オプションを使用できます。詳細は、呼び出しコストの管理を参照してください。

利点なし: データ転送のコストが計算時間とメモリー帯域幅時間を上回ります

ターゲットデバイスへのデータ転送に費やされた時間が、計算時間とメモリー帯域幅時間 を上回ります。データ転送コストがあるターゲット・プラットフォームでの推測時間は、ホスト・プラットフォームでの測定時間を上回ります。

[Estimated Bounded By (推測される制限)] カラムと [Estimated Data Transfer with Reuse (再利用が推測されるデータ転送)] カラムグループの [Bounded By (制限される要因)] と [Data Transfer Tax (データ転送のコスト)] カラムを確認します。高い値は、コード領域がオフロードの恩恵を得られないことを意味します。

メトリックの解釈の詳細については、制限要因を参照してください。

それでもそのようなコード領域をオフロードしたい場合、--data-transfer=offを使用してデータ転送解析を無効にして、スピードアップと収益性の計算にのみ推測時間を使用します。

すでにデータ転送メトリックが収集済みである場合、コマンドライン・オプション --hide-data-transfer-tax を使用して、データ転送コストのモデル化を無効にできます。

利点なし: ターゲットデバイスの能力を十分に使用しているにもかかわらず計算時間が長いままです

コード領域は、ターゲット・プラットフォームの能力を十分に活用していますが、計算時間はまだ長いままです。その結果、ターゲット・プラットフォームの予測時間は、ホスト・プラットフォームで測定された時間を上回ります。

[Estimated Bound-by (推測される制限)] カラムグループの [Compute (計算)] カラムの値を確認します。予想外に値が高い場合、つぎのいずれかに該当します。

• プログラミング・モデルに問題があることを示します。
• ターゲット GPU の計算能力が、ベースラインの CPU の計算能力よりも低い場合。
• 計算時間の推測が正しくないことにより、インテル® Advisor に内部エラーが発生する場合。

利点なし: キャッシュ/メモリー帯域幅時間は、ターゲットデバイスの他の実行時間コンポーネントよりも長くなっています。

キャッシュまたはメモリー帯域幅で費やされた時間は、ターゲット・プラットフォームの予測時間の大部分を占めます。その結果、ホスト・プラットフォームで計測された時間よりも大きくなります。

レポートでは、キャッシュ/メモリーは、オフロードを妨げる特定のキャッシュまたはメモリーレベル (L3 や LLC) に置き換えられます。最大帯域幅時間の詳細は、[Throughput (スループット)] カラムを参照してください。

1. 大部分の実行時間を占めオフロードを妨げるコード領域の子を特定します。
2. ベースラインのプラットフォームで測定された時間の大部分を占めるコード領域を最適化し、パースペクティブを再実行します。

オフロードのオーバーヘッド (コスト) により利益が得られません

カーネルの起動コスト、データ転送コストを含むオフロードコストの合計時間は、ターゲット・プラットフォームの予測時間の大部分を占めます。その結果、ホスト・プラットフォームで計測された時間よりも大きくなります。

コード領域をターゲット・プラットフォームにオフロードするのに必要な最大および合計コストは、[Estimated Bounded by (推測される制限)] グループの [Taxes with Reuse (再利用のコスト)] カラムを調べます。[Estimated Bounded by (推測される制限)]  グループを展開すると、領域をターゲット・プラットフォームにオフロードする際に必要な時間コスト全体が表示されます。カラムの値が大きいとオフロードのコストが高く、コード領域がオフロードの恩恵を受けられないことを意味します。

カーネル起動コストが髙く、カーネルの実行が起動コストとオーバーラップする必要があると想定される場合、次のように起動コストを非表示にしてモデルを作成します。

• GUI から: [Analysis Workflow (解析ワークフロー)] から [Single Kernel Launch Tax (単一カーネル起動コスト)] チェックボックスをオンにして、パフォーマンスのモデル化解析を実行します。
• CLI から: --assume-hide-taxes オプションを --collect=projection またはanalyze.py とともに使用します。

詳細は、呼び出しコストの管理を参照してください。

利点なし: カーネル起動コストがカーネル実行時間とデータ転送時間よりも大きい場合

カーネルの起動にかかる時間は、ターゲット・プラットフォームで推測される実行時間およびデータ転送時間よりも長くなります。データ転送コストがあるターゲット・プラットフォームでの推測時間は、ホスト・プラットフォームでの測定時間を上回ります。

[Estimated Bounded By (推測される制限)] カラムグループの [Bounded By (制限される要因)] と [Kernel Launch Tax (カーネル起動コスト)] カラムを調べます。

メトリックの解釈の詳細については、制限要因を参照してください。

カーネルの起動コストが高いということは、インテル® Advisor が、高い収益性が見込まれるコード領域で高い呼び出し回数を検出し、カーネルの起動回数分の呼び出しコストがかかると仮定することを意味します。そのため、コード領域はオフロードの利点が得られないと想定されます。

カーネルの実行が起動コストとオーバーラップする必要があると想定される場合、次のように起動コストを非表示にしてモデルを作成します。

• GUI から: パフォーマンスのモデル化解析の [Single Kernel Launch Tax (単一カーネルの起動コスト)] チェックボックスを選択します。
• CLI から: リンク時に SVML ABI 互換ライブラリーを使用するには、--assume-hide-taxes オプションを --collect=projection アクションオプション、または analyze.py とともに使用します。

詳細は、呼び出しコストの管理を参照してください。

利点なし: アトミック・スループット時間が、ターゲットデバイスの他の実行時間コンポーネントよりも長くなっています。

アトミック操作には、呼び出し間で他のスレッドの影響を受けないように、データのロード、変更、ストアが含まれます。

アトミック操作をモデル化する場合、インテル® Advisor はすべてのスレッドが相互に待機することを前提としているため、アトミック・スループット時間が長くなり、ホットスポットになる可能性があります。

技術サポートやアドバイスについては、アナライザーのコミュニティー・フォーラム (英語) にアクセスしてください。

利点なし: 命令レイテンシーが計算時間およびメモリー帯域幅時間を上回ります。

メモリー読み取り命令ごとに GPU スレッドのストールが発生します。ストールは、メモリー・レイテンシーと呼ばれます。通常、他のスレッドの実行とオーバーラップする可能性があります。

ただし、オーバーラップしないレイテンシーの量がパフォーマンスに影響する場合があります。インテル® Advisor は、オーバーラップなしのメモリー・レイテンシーを推測し、カーネルの推定実行時間に加えることができます。

スレッドの占有率を減らすと、オーバーラップしないメモリー・レイテンシーの量が増加する可能性があります。

[Latency (レイテンシー)] カラムを調べて、ロード・レイテンシーの時間を確認し、[Thread Occupancy (スレッド占有率)] カラムでその理由を理解します。占有率が低いと、それが高いロード・レイテンシーの原因であることを意味します。この場合、コードをオフロードする際に、カーネルの並列性を増やすか、他の命令でレイテンシーを隠匿します。

ロード・レイテンシーがコード内の並列処理とオーバーラップすることが確実である場合、次のようにすることでレイテンシー隠匿モードを有効にできます。

• GUI から:

  1. [Project Properties (プロジェクトのプロパティー)] > [Performance Modeling (パフォーマンスのモデル化)] に移動します。

  2. [Other Parameters (その他のパラメーター)] フィールドに --count-send-latency=first を入力します。

  3. パフォーマンスのモデル化を再実行します。
• CLI から: --count-send-latency=first オプションと--collect=projection アクションオプションを使用するか、analyze.py を使用します。