为什么CUDA探查器指示重播指令：82%！=全球重播+；本地重播+；共享重播？

我从CUDA档案器得到信息。我很困惑为什么 重放指令！=Grobal内存重播+本地内存重播+共享银行冲突重播

请参阅我从探查器获得的以下信息：

Replayed Instructions(%): 81.60
Global memory replay(%): 21.80
Local memory replays(%): 0.00
Shared bank conflict replay(%): 0.00

---

你能帮我解释一下吗？是否存在导致指令重放的其他情况？

因为SM可以由于其他因素（如不同的分支逻辑）重放指令

所以我可以假设60%的代码是由于分支而重新发布的，20%是由于全局内存。你能发一个片段吗

从Cuda 4.0探查器的F1帮助菜单：

Replayed Instructions(%): 81.60
Global memory replay(%): 21.80
Local memory replays(%): 0.00
Shared bank conflict replay(%): 0.00

重放的指令（%）这给出了 在内核执行期间重放的指令。重放指令 所使用的指令数之间是否存在差异 硬件实际发出的指令数是多少 由内核执行。理想情况下，这应该是零。这是 计算为100*（发出的指令-执行的指令）/ 发出的指示

全局内存重播（%）重播指令的百分比 由于全局内存访问而导致。这计算为100*（l1 全局加载未命中）/发出的指令

本地内存重播（%）导致重播的指令的百分比 由于本地内存访问。这计算为100*（l1局部 加载未命中+l1本地存储未命中）/发出的指令

共享银行冲突重播（%）重播的百分比 由于共享内存库冲突而导致的指令。这是 计算为100*（l1共享冲突）/发出的指令

---

谢谢你，法布里奇姆。你的解释有道理。我确实有很多导致分支的if-else，但是在这个程序中很难避免。简而言之，我在那个程序中使用二进制搜索。如果else很难逃脱~~我认为在大多数情况下，共享存储组冲突是重放的主要部分，然后是全局内存重放，然后是其他冲突，如持续内存冲突、指令缓存未命中等。不幸的是，没有关于这方面的官方信息。