我正在编写一个 CUDA 内核来对矩阵的每个元素执行单个操作（例如，对每个元素求平方根，或求幂，或者如果所有数字都在 [-1;1] 之间，则计算正弦/余弦）等。）
我选择了块/线程网格尺寸，我认为代码非常简单明了，但我问自己......我可以做些什么来最大化合并/SM 占用率？
我的第一个想法是：让所有 semiwarp（16 个线程）从全局内存中加载数据集合，然后将它们全部用于计算，但它发现没有足够的内存传输/计算并行化。我的意思是所有线程加载数据，然后计算，然后再次加载数据，然后再次计算.. 就性能而言，这听起来很糟糕。
我认为使用共享内存会很棒，也许使用某种局部性使线程加载的数据比促进其他线程工作实际需要的数据多，但这听起来也很愚蠢，因为第二个会等待前者在开始工作之前完成加载数据。
我不确定我是否就我的问题提出了正确的想法，我只是在开始着手处理具体问题之前获得想法。
每条评论/建议/批评都被广泛接受，谢谢。
【问题讨论】：
如果您定义了网格，以便线程沿着包含矩阵的数组的主要维度读取，那么您已经保证了合并的内存访问，并且几乎没有其他工作可以提高性能。这类 O(N) 复杂度运算实际上不包含足够的算术强度，无法在优化的 CPU 实现上提供良好的并行速度。通常最好的策略是将多个 O(N) 操作融合到一个内核中，以提高 FLOP 与内存事务的比率。
【讨论】：
在我看来你的问题是这样的
load data ensemble from global memory
看来你的算法思路是：
这种计算几乎每次都受到 I/O 带宽限制（IO = 内存 IO），而不是计算能力限制。 GPGPU 计算可以维持非常高的内存带宽 - 但仅限于从设备内存到 gpu - 从全局内存的传输总是通过非常慢的 PCIe（与设备内存连接相比慢，可以提供高达 160 GB/s + on快速卡）。因此，获得良好结果的一件主要事情是将数据（矩阵）保存在设备内存中 - 如果可能的话，最好在其中生成它（取决于您的问题）。永远不要尝试在 cpu 和 gpu 之间来回迁移数据，因为传输开销会耗尽你所有的加速。另外请记住，您的矩阵必须具有一定的大小来分摊传输开销，这是您无法避免的（计算一个具有 10 x 10 元素的矩阵几乎不会带来任何好处，它甚至会花费更多）
交换传输/计算/传输完全正常，这就是这种 gpu 算法的工作原理 - 但前提是传输来自设备内存。
【讨论】：
GPU 用于这种微不足道的事情是矫枉过正的，而且会比仅仅将其保持在 CPU 上要慢。特别是如果你有一个多核 CPU。
我已经看到许多项目展示了 GPU 相对于 CPU 的“巨大”优势。他们很少经得起审查。当然，想要给经理留下深刻印象的愚蠢经理想要展示他的团队是多么“领先”。
部门中的某个人辛勤工作数月来优化愚蠢的 GPU 代码（通常比同等 CPU 代码更难阅读 8 倍），然后让某个印度血汗工厂编写的“同等”CPU 代码（上一个项目是PGP），用他们能找到的最慢版本的 gcc 编译它，没有优化，然后吹嘘他们的速度提高了 2 倍。顺便说一句，许多人忽略了 I/O 速度并不重要。
【讨论】：