問題タブ [halide]

ベンチマーク Halide コードの最適なスケジュールを作成しようとしていますが、タイミングの結果があまり意味をなさないため、何かを見落としている可能性があります。

私は AOT コンパイルを使用しています。コードのアルゴリズム部分は次のとおりです。

スケジュールについては、これが私が持っているものです：

current_time 関数を使用して、コードの実行時間を計っています。上記のスケジュールを f1 と f2 の両方に使用すると、これらの Func の 1 つだけにスケジュールを使用する場合よりも実行時間が長くなります。ステンシルの構造を考えると、両方をスケジューリングするとパフォーマンスが向上すると思いました。ここで何が欠けていますか？また、ループを印刷して生成されたコードを確認すると、次のようになります。

それは単なるインデントですか、それとも農産物 f2 が農産物 f1 内にネストされていますか? より良いスケジュールのための提案はありますか?

arctan三角関数のようなものを使用する Halide 言語を使用していくつかのアルゴリズムを実装しました。しかし、インストルメンテーションの目的で、Halide にベクトル命令を生成させないようにしたいと考えています。

Windows では Visual C++ を使用しcl、Visual Studio 2013 ツール チェーンではコンパイラを使用しています。clこれまでのところ、使用を強制しようとして/arch:IA32いますが、それでもベクトル命令が生成されます。

Halide 言語側から何らかの形でこれを強制する方法や、数学ライブラリの呼び出しをインターセプトする方法はありますか?そこで、Halide に、arctanベクトル命令を使用するように最適化されていない私たちが作成した関数を使用するように依頼できます。

ステンシルの計算を最適化するために Halide を使用していますが、スケジューリングの部分はちょっと難しいです! これが私の Halide コードで、AOT コンパイルを使用しています。

分割/タイリング、および各関数の評価場所の指定に関して、スケジュールが異なるとパフォーマンスがどのように変化するかを理解しています。ただし、並列パフォーマンスにはいくつかの問題があります。上記のような、並列化のためのさまざまなスケジューリングを試しました。しかし、効率的な並列スケジュールを見つけることができず、プロファイリングの数値はやや混乱しています。上記のスケジュールでは、スレッドの数が増えると、「結果」が遅くなり、f1_bound が速くなりますが、スレッドとして報告される数 (私が間違っていなければ、各リージョンのアクティブなスレッドの平均数です) は両方で増加します。

4 スレッド:
平均使用スレッド数: 3.586322

ヒープ割り当て: 19500 ピーク時のヒープ使用量: 116640 バイト

解像度: 0.946ms (33%) スレッド数: 3.119

f1_b: 1.873ms (66%) スレッド: 3.823 ピーク: 116640 数値: 19500 平均: 29160

2 スレッド: 平均使用スレッド数: 1.934264

ヒープ割り当て: 19500 ピーク時のヒープ使用量: 58320 バイト

解像度: 0.769ms (19%) スレッド数: 1.794

f1_b: 3.152ms (80%) スレッド: 1.968 ピーク: 58320 数値: 19500 平均: 29160

f1_bound と unbound の両方をスケジュールすると、スレッド数が増えるにつれてスケーリングが向上しますが、局所性が少ないと思うので、単一スレッドのコードは並列化しない場合よりも遅くなります。

より良いスケジュールのための提案はありますか?