GPUでの比較がなぜそれほど高価なのですか？

衝突検出クラスのパフォーマンスを向上させようとしているときに、gpuで費やされた時間の約80％がループするバケットの境界を把握しようとするif / else条件に費やされたことがわかりました。

より正確に：

1. 各スレッドはIDを取得し、そのIDによってメモリから三角形（それぞれ3つの整数）をフェッチし、それらの3つによって頂点をフェッチします（それぞれ3つの浮動小数点数）。

2. 次に、頂点を整数グリッドポイント（現在は8x8x8）に変換し、それらをそのグリッドの三角形の境界に変換します。

3. 3つのポイントを境界に変換するために、各ポイント間で各次元の最小/最大を見つけます

私が使用しているプログラミング言語にはminmax組み込み関数がないため、次のように自分で作成しました。

procedure MinMax(a, b, c):
   local min, max

   if a > b:
      max = a
      min = b
   else:
      max = b
      min = a
   if c > max:
      max = c
   else:
      if c < min:
         min = c

   return (min, max)

したがって、平均すると2.5 * 3 * 3 = 22.5の比較になるはずです。これは、実際の三角形よりもずっと多くの時間を消費することになります-エッジ交差テスト（約100 * 11-50命令）。

実際、私はCPUで必要なバケットを事前計算し（シングルスレッド、ベクトル化なし）、バケット定義と一緒にそれらをGPUビューに積み重ねて、GPUにスレッドごとに4回以上の追加の読み取りを行わせると、試行より6倍高速であることがわかりましたその場で境界を把握する。（動的メッシュを扱っているため、実行する前に再計算されることに注意してください）

では、なぜGPUでの比較がひどく遅いのでしょうか。

GPUはSIMDアーキテクチャです。SIMDアーキテクチャでは、処理するすべての要素に対してすべての命令を実行する必要があります。（このルールには例外がありますが、ほとんど役に立ちません）。

したがって、MinMaxルーチンでは、すべての呼び出しで3つの分岐命令すべてをフェッチする必要があるだけでなく（平均して2.5しか評価されない場合でも）、すべての代入ステートメントもサイクルを消費します（実際に「実行」されない場合でも） ）。

この問題は、スレッドの相違と呼ばれることもあります。マシンに32個のSIMD実行レーンがある場合でも、フェッチユニットは1つだけです。（ここで、「スレッド」という用語は基本的に「SIMD実行レーン」を意味します。）したがって、内部的に各SIMD実行レーンは「有効/無効」ビットを持ち、ブランチは実際にはそのビットを操作するだけです。（例外は、すべてのSIMDレーンが無効になる時点で、フェッチユニットは通常、「else」句に直接ジャンプします。）

したがって、コードでは、すべてのSIMD実行レーンが次のことを実行しています。

compare (a > b)
assign (max = a if a>b)
assign (min = b if a>b)
assign (max = b if not(a>b))
assign (min = a if not(a>b))
compare (c > max)
assign (max = c if c>max)
compare (c < min if not(c>max))
assign (min = c if not(c>max) and c<min)

一部のGPUでは、条件式から述語への変換が、GPUがそれ自体を実行している場合は遅くなる場合があります。@ PaulA.Claytonで指摘されているように、プログラミング言語とアーキテクチャに述語付きの条件付き移動操作（特にの形式の1つif (c) x = y else x = z）がある場合は、より適切に実行できる可能性があります。（しかし、おそらくあまり良くありません）。

また、配置c < min条件内部elseのことはc > max不要です。それは確かにあなたに何も保存していません、そして（GPUがそれを自動的に予測に変換しなければならないことを前提として）実際にそれを2つの異なる条件にネストさせることは害を及ぼすかもしれません。