インテルのみ表示可能 — GUID: mwh1391807506544
Ixiasoft
6.5. リソース駆動型最適化
コンパイル中、オフライン・コンパイラーは、さまざまな組み合わせのnum_compute_unitsおよびnum_simd_work_itemsカーネル属性の複数の値を調べ、一連のヒューリスティックを適用してベースデザインを段階的に改善します。オフライン・コンパイラーは、この1組の値を実装して、毎秒実行されるWork-Itemに関してカーネルのパフォーマンスを最大化します。
分析の結果に基づいて、オフライン・コンパイラーは、Work-Itemが頻繁に実行するコードブロックを最適化します。これらのコードブロックの場合、コンパイラーは追加のハードウェア・リソースを使用してより高いスループットで実装を実現します。Work-Itemが頻繁に実行されないコードブロックの場合、コンパイラーは同じハードウェアを再使用して複数の動作を実装しようとします。
発生するハードウェア共有の量は、 sharing degreeと呼ばれます。これは、同じ計算単位内で実行されるWork-Itemによって動作が共有される回数です。Work-Itemが頻繁に実行されないコードブロックは、より高い共有度につながる可能性があります。
オフライン・コンパイラーは、カーネル宣言で指定したカーネル属性またはプラグマの値は変更しません。オフライン・コンパイラーは、不特定の属性とプラグマのみを変更します。
最適化動作
リソース駆動型最適化の例を次に示します。
- カーネルがFPGAに適合しない場合にのみ、頻繁に実行されないコードブロックのリソース共有を試みます。
オフライン・コンパイラーがFPGA内で最適化されたカーネルを識別した後、最適化を適用してパフォーマンスを向上させます。
- マルチカーネルデザインでは、最初に最小限のパフォーマンスでカーネルを改善します。
カーネルの最適化が行われる順序は、1秒あたりのWork-Item数に基づいています。これらのカーネルをそれ以上最適化できない場合、以降のカーネルはスループットの見積もりの順に改善されます。リソース駆動型最適化の間、オフライン・コンパイラーは一連の高性能候補を保持し、それぞれに増分最適化を適用しようとします。これらの最適化は一般的により効率的なハードウェア実装をもたらすので、ループアンローリングおよびSIMDベクトル化は、コンピューティング・ユニット複製よりも好ましい最適化戦略です。
- リソース駆動型最適化の間、オフライン・コンパイラーは、所定の最適化ステップのセットを反復します。
多くの場合、オフライン・コンパイラーは最適化範囲を事前に推定します。たとえば、使用可能なメモリー帯域幅に基づいてコンピューティング・ユニットの最大数を決定します。オフライン・コンパイラーが最適化を実行できない場合、そのステップをスキップして他の最適化を試みます。
制限
静的最適化にはいくつかの固有の制限があります。制御フロー分析は、コンパイル時に未知である、ホストから渡されたカーネル引数の値を仮定します。たとえば、オフライン・コンパイラーでは、境界が未知のループが1024回反復すると想定しています。これらの前提に基づいて、オフライン・コンパイラーは、作業アイテムが予測よりも頻繁に実行されるコードブロックに向けて最適化を誘導することがあります。境界が未知のループの場合、 unrollプラグマを使用してコード内のアンロール係数を指定することによって、アンローリングの量を上書きできます。ループをアンロールする必要がない場合、アンロール係数を1に指定して、ループをアンローリングしないことを指定できます。
もう1つの制限要因は、ハードウェアのコンパイルが行われる前にすべての最適化が行われることです。性能予測は、ハードウェアコンパイラーが達成する最大動作周波数を正確に捕捉しないことがあります。同様に、リソース駆動型最適化で使用される推定リソース使用率は、実際のハードウェア・リソース使用率を反映しない場合があります。
共有とベクトル化の量には範囲の制限もあります。現在、最大共有度は8であり、SIMDベクタレーンの最大数は16です。