什么时候应该使用CUDA的内置warpSize而不是我自己的适当常数？

问题描述

nvcc设备代码可以访问内置值warpSize ，该值设置为执行内核的设备的扭曲大小（即在可预见的将来为32）。 通常，您只能将其与常量区分开来-但是，如果您尝试声明一个长度为warpSize的数组，则会抱怨它是非常量的（使用CUDA 7.5）。

因此，至少出于这个目的，您有动力拥有类似（ 编辑 ）的东西：

enum : unsigned int { warp_size  = 32 };

标头中的某处。 但是，现在-我更喜欢哪个，什么时候？ ： warpSize还是warp_size ？

编辑： warpSize显然是PTX中的编译时常量。 问题仍然存在。

与talonmies的答案相反，我发现warp_size常数完全可以接受。 使用warpSize的唯一原因是使代码与将来可能具有不同大小扭曲的硬件向前兼容。 但是，当此类硬件到货时，内核代码很可能也需要进行其他更改才能保持效率。 CUDA不是与硬件无关的语言-相反，它仍然是相当底层的编程语言。 生产代码使用随时间变化的各种内在函数（例如__umul24 ）。

当我们获得不同的变形大小（例如64）的一天，许多事情都会改变：

• 显然必须调整warpSize
• 许多经水平的内在需要他们签名调整，或未来的新版本，如int __ballot ，虽然int并不需要是32位，这是最常见的左右！

• 迭代操作（例如减少经线级）将需要调整其迭代次数。 我从未见过有人写作：

   for (int i = 0; i < log2(warpSize); ++i) ... 

  在通常是时间紧迫的一段代码中，这将过于复杂。

• warpIdx和laneIdx的计算出threadIdx需要进行调整。 目前，我看到的最典型的代码是：

   warpIdx = threadIdx.x/32; laneIdx = threadIdx.x%32; 

  简化为简单的右移和遮罩操作。 但是，如果将32替换为warpSize这将突然变得相当昂贵！

同时，在代码中使用warpSize阻止优化，因为从形式warpSize ，它不是编译时已知的常量。 同样，如果共享内存的数量取决于warpSize这将迫使您使用动态分配的shmem（根据talonmies的回答）。 但是，该语法使用起来很不方便，特别是当您有多个数组时-这迫使您自己进行指针算术并手动计算所有内存使用量的总和。

使用用于warp_size模板是部分解决方案，但会增加每个函数调用所需的语法复杂性层：

deviceFunction<warp_size>(params)

这会混淆代码。 样板越多，代码越难读取和维护。

我的建议是有一个标头来控制所有特定于模型的常量，例如

#if __CUDA_ARCH__ <= 600
//all devices of compute capability <= 6.0
static const int warp_size = 32; 
#endif

现在，您的CUDA代码的其余部分可以使用它，而没有任何语法开销。 在决定添加对较新架构的支持的那一天，您只需要更改这一段代码即可。