为什么在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视图中，并使gpu每个线程进行约4次额外读取，比尝试快6倍。找出当场的界限。（请注意，由于我要处理动态网格物体，因此在每次执行之前都要重新计算它们）

那么，为什么在GPU上进行比较却如此缓慢呢？

GPU是SIMD架构。在SIMD架构中，需要为您处理的每个元素执行每条指令。（此规则有一个例外，但很少有帮助）。

因此，在您的MinMax例程中，不仅每个调用都需要获取所有三个分支指令（即使平均只评估了2.5条指令），而且每个赋值语句也占用一个周期（即使实际上并未“执行”） ）。

该问题有时称为线程发散。如果您的计算机具有32条SIMD执行通道，则它仍将只有一个获取单元。（这里的“线程”基本上是指“ 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指出的那样，如果您的编程语言和体系结构具有谓词条件移动操作（尤其是形式之一if (c) x = y else x = z），则您可能会做得更好。（但可能不会好得多）。

此外，将所述c < min的条件内else的c > max是不必要的。当然，这并不能为您节省任何费用，并且（考虑到GPU必须将其自动转换为谓词）将其嵌套在两个不同的条件中实际上可能会很有害。