Performance GPU上所需的计算内存比（OP/B）

我试图理解GPU的体系结构，以及我们如何评估GPU上程序的性能。我知道申请可以是：

• 计算范围：性能受触发器速率限制。处理器的核心得到充分利用（总是有工作要做）
• 内存限制：性能受内存限制 带宽。处理器的内核经常处于空闲状态，因为内存不能足够快地提供数据
  下图显示了每个微体系结构的触发器速率、峰值内存带宽和所需的计算内存比（以（OP/B）标记）

我还有一个如何计算这个OP/B度量的示例。示例：下面是应用矩阵乘法的CUDA代码的一部分

for(unsigned int i = 0; i < N; ++i) {
  sum += A[row*N + i]*B[i*N + col];
}

for（无符号整数i=0；i

计算该矩阵乘法的OP/B的方法如下：

• 矩阵乘法执行0.25运算/B
• 每加载2个FP值（8B）1个FP add和1个FP mul
• 忽略商店

如果我们想利用它：

• 但是矩阵乘法具有很高的重用潜力。对于NxN矩阵：
  • 加载的数据：（2个输入矩阵）×（N^2个值）×（4 B）=8N^2 B
  • 运算：（N^2个点积）（N个加法+N个乘法）=2N^3运算
  • 潜在计算内存比：0.25N OP/B

因此，如果我能很好地理解这一点，我有以下问题：

• 通常情况下，OP/B越大越好
• 我们如何知道我们有多少FP操作？是加法和乘法吗
• 我们如何知道每个FP操作加载了多少字节

通常情况下，OP/B越大越好

不总是这样。目标值平衡计算管道吞吐量和内存管道吞吐量上的负载（即，op/字节的级别意味着两个管道都将满载）。当您将op/byte增加到该级别或某个级别之外时，您的代码将从平衡转换为计算绑定。一旦代码绑定到计算，性能将由作为限制因素的计算管道决定。超出这一点的额外op/字节增加可能对代码性能没有影响

我们如何知道我们有多少FP操作？是加法和乘法吗

是的，对于您显示的简单代码，它是加法和乘法。其他更复杂的代码可能具有其他因素（例如，

sin

，

cos

，等等），这些因素也可能起作用

作为“手动计数”FP操作的替代方法，GPU探查器可以指示代码已执行的FP操作数

我们如何知道每个FP操作加载了多少字节

与上一个问题类似，对于简单代码，您可以“手动计数”。对于复杂代码，您可能希望尝试使用探查器功能进行估算。对于您显示的代码：

sum += A[row*N + i]*B[i*N + col];

必须加载

A

和

B

中的值。如果它们是

float

数量，则每个数量为4个字节。总共是8个字节。这行代码将需要1个浮点乘法（A*B）和一个浮点加法运算（sum+=）。编译器会将它们融合到一条指令中（融合乘法-加法），但最终的效果是每8字节执行两个浮点运算。op/字节为2/8=1/4。在这种情况下，循环不会改变比率。要增加这个数量，您需要探索各种优化方法，例如，或者只使用CUBLAS

（像

row*N+i

这样的操作是整数运算，不会对浮点负载产生影响，尽管它们在性能方面可能很重要。）