所以我对在 CUDA 中合并内存访问的想法是，warp 中的线程应该访问连续的内存地址，因为这只会导致单个内存事务（然后将每个地址上的值广播到线程）而不是以串行方式执行的多个。
现在，我的总线宽度是 48 字节。这意味着我可以在每个内存事务中传输 48 个字节，对吧？因此，为了充分利用总线，我需要能够一次读取 48 个字节（通过每个线程读取一个以上的字节 - 内存事务由 warp 执行）。但是，假设单个线程一次读取 48 个字节不会提供相同的优势（我假设我可以通过读取大小为 48 个字节的结构一次读取 48 个字节）？
我的合并问题是我必须对数据进行转置。我有很多数据，所以转置需要时间，如果可以的话，我宁愿将其用于其他用途。
我正在使用计算能力 2.0。
【问题讨论】：
标签： memory cuda coalescing
GPU 的内存总线不仅仅是 48 字节宽（这会很麻烦，因为它不是 2 的幂）。相反，它由 6 个内存通道组成，每个通道有 8 个字节（64 位）。内存事务通常比通道宽度宽得多，以便利用内存的突发模式。良好的事务大小从 64 字节开始，以产生大小为 8 的突发，这与计算能力 1.x 设备上半扭曲的 16 个 32 位字完美匹配。
128 字节宽的事务仍然要快一些，并且与计算能力 2.0（及更高版本）设备的经线宽 32 位字访问相匹配。高速缓存行也是 128 字节宽以匹配。请注意，所有这些访问必须在事务宽度的倍数上对齐，以便映射到单个内存事务。
现在关于你的实际问题，最好的办法可能是什么都不做，让缓存解决它。这与您在共享内存中显式执行的方式相同，只是它由缓存硬件为您完成，并且不需要代码，这应该会使其速度稍快一些。唯一需要担心的是有足够的缓存可用，以便每个 warp 可以有必要的 32×32×4 字节 = 4kbytes 的缓存用于字宽（例如 float）或 8kbytes 用于双重访问。这意味着限制同时处于活动状态的 warp 的数量是有益的，以防止它们破坏彼此的缓存行。
对于特殊优化，还可以使用float2 或float4 等向量类型，因为所有支持 CUDA 的 GPU 都具有将 8 或 16 个字节映射到同一线程的加载和存储指令。然而，在计算能力 2.0 及更高版本上，我并没有真正看到在一般矩阵转置情况下使用它们有任何优势，因为它们会更多地增加每个 warp 的缓存占用空间。
由于 16kB 缓存/48kB 共享内存的默认设置只允许每个 SM 四个 warp 在任何时候执行转置（假设您同时没有其他内存访问），选择48kB 缓存/16kB 共享内存设置超过使用cudaDeviceSetCacheConfig() 拆分的默认 16kB/48kB。较新的设备具有更大的缓存并提供更多不同的拆分以及选择使用超过 48kB 的共享内存。详细信息可在链接文档中找到。
为了完整起见，我还要提到计算能力 3.0 中引入的 warp shuffle 指令允许在 warp 内交换寄存器数据，而无需通过缓存或共享内存。有关详细信息，请参阅 CUDA C 编程指南的Appendix B.22。
（请注意，存在没有此附录的编程指南版本。因此，如果您的副本中的附录 B.13 涉及其他内容，请通过提供的链接重新加载）。
【讨论】：
正如您所说，出于合并的目的，您应该专注于使 warp 中的 32 个线程访问连续的位置，最好也对齐 32 字节或 128 字节。除此之外，不必担心 DRAM 内存的物理地址总线。内存控制器由大部分独立的分区组成，每个分区都是 64 位宽。内存控制器将尽快满足您从扭曲中出来的合并访问。访问 int 或 float 的完整 warp（32 个线程）的单个合并访问无论如何都需要检索 128 个字节，即物理总线上到 DRAM 的多个事务。当您在缓存模式下操作时，无论如何，您无法真正控制对全局内存的请求粒度一次低于 128 字节。
不可能导致单个线程在单个事务中请求 48 个字节或类似的东西。即使在 c 代码级别，如果您认为自己正在一次访问整个数据结构，在机器代码级别，它也会被转换为一次读取 32 位或 64 位的指令。
如果您觉得一次 128 字节的缓存限制对您的代码不利，您可以尝试在非缓存模式下运行，这会将全局内存请求的粒度降低到一次 32 字节。如果您的访问模式分散（未很好地合并），则此选项可能会提供更好的性能。
【讨论】：