关于性能：根据C中的操作数，浮动乘法执行速度较慢

cfloating-pointperformancestencilsx86

Floating multiplication performing slower depending of operands in C

我正在对以前从文件中读取的矩阵执行模板计算。我使用两种不同的矩阵(非零类型和零类型)。这两种类型都共享边界值(通常为1000)，而其余元素为0(零类型)和1(非零类型)。

代码将文件的矩阵存储在两个相同大小的分配矩阵中。然后，它使用自己的值和邻居的值(加上x 4和mul x 1)在一个矩阵的每个元素中执行操作，并将结果存储在第二个矩阵中。计算完成后，交换矩阵的指针，并在有限的时间内执行相同的操作。下面是核心代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#define GET(I,J) rMat[(I)*cols + (J)]
#define PUT(I,J) wMat[(I)*cols + (J)]

for (cur_time=0; cur_time<timeSteps; cur_time++) {
for (i=1; i<rows-1; i++) {
for (j=1; j<cols-1; j++) {
PUT(i,j) = 0.2f*(GET(i-1,j) + GET(i,j-1) + GET(i,j) + GET(i,j+1) + GET(i+1,j));
}
}
// Change pointers for next iteration
auxP = wMat;
wMat = rMat;
rMat = auxP;
}

我要介绍的这个例子使用了固定数量的500个时间步(外部迭代)，矩阵大小为8192行和8192列，但在更改时间步数或矩阵大小时，问题仍然存在。注意，我只测量算法的这个具体部分的时间，所以从文件中读取矩阵或其他任何东西都不会影响时间测量。

会发生的是，根据我使用的矩阵类型，我得到不同的时间，在使用零类型时获得更差的性能(其他每个矩阵都与非零类型执行相同，因为我已经尝试生成一个充满随机值的矩阵)。

我确信这是乘法运算，就好像我把它去掉，只留下加法，它们执行相同的运算。注意，对于零矩阵类型，大多数类型的求和结果将为0，因此操作将为"0.2*0"。

这种行为对我来说确实很奇怪，因为我认为浮点操作独立于操作数的值，这里的情况与此不同。我还尝试捕获并显示SIGFPE异常，以防出现问题，但没有得到任何结果。

如果有帮助的话，我使用的是IntelNehalem处理器和GCC4.4.3。

相关讨论

您是否使用硬编码数据来测试这一点，以便编译器可以在编译时看到矩阵中的值，并使您的代码的内联版本对该固定数据进行优化？如果它知道一个元素是零，它可能会完全优化乘法…
如果您使用double而不是float(用于常量——0.2f)和矩阵值，它会改进吗？
如何初始化零矩阵？特别是，零真零还是非常小的值看起来是零？具有次正规值(绝对值小于flt_min的非零值)的计算通常比具有正规值的计算慢。
我认为你的主要问题是缓存压力。每个矩阵的大小都是8192^2*sizeof(float)large。这远远超过了二级缓存，更不用说一级缓存的大小了。您应该更改您的算法，使其在大约8K个数据块上运行。另外，我会尝试使用simd指令处理这些值。这看起来像是使用MAD指令(乘法加法)的主要示例。
@johnb数据不是硬编码的，我是从文件中读取的。我还检查了用objdump-s生成的汇编程序，内部循环的代码看起来非常清楚，4个adds和1个muls在指针上进行了更改以加载下一个迭代，我在汇编程序中做得不好。@PMG令人惊讶地改进了零类型矩阵的结果，使非零类型的性能比带浮点的差，但非零类型的性能仍然比零类型好。
@你说的话很有道理。由于算法的性质，边界上的值被分散到中心。最初，这些值足够大，但经过几次迭代后，新的排列值接近0。当我用非零值(如1)填充矩阵时，不会发生这种情况，因为操作的结果至少是1。@我知道算法的问题在于它是内存限制的，实际上我对代码进行了一些优化以提高性能。但是浮点运算的问题与内存无关。
@我刚将0.2f改为1.2f(这样操作的结果就永远不会给出低于flt_min的值)，然后两个矩阵给出的时间完全相同。现在我必须找到一个解释这种行为的来源，但是如果我找不到它，我可以用它来证明实验结果改变了常数。非常感谢大家。
@你应该加上你的评论作为答案，这样它才能被接受。

这个问题基本上已经被诊断出来了，但我会把这里发生的事情写下来。

本质上，发问者是在模拟扩散；边界上的初始量扩散到一个大网格的整体中。在每个时间步骤t，扩散前缘的值将为0.2^t(忽略拐角处的影响)。

最小归一化单精度值为2^-126；当cur_time = 55时，扩散前沿值为0.2^55，略小于2^-127。从现在开始，网格中的一些单元格将包含非规范值。在发问者的Nehalem上，非规范化数据的操作比标准化浮点数据的操作慢大约100倍，这解释了速度的减慢。

当网格初始填充了1.0的常量数据时，数据永远不会变得太小，因此避免了非正规失速。

请注意，将数据类型更改为double将延迟，但不会缓解此问题。如果使用双精度进行计算，则非正规值(现在小于2^-1022)将首先出现在441次迭代中。

以扩散前沿的精度为代价，您可以通过启用"flush to zero"来解决速度减慢的问题，这将导致处理器在算术运算中产生零而不是非非正规结果。这是通过在fpscr或mxscr中切换一位来完成的，最好是通过C库中头中定义的函数。

另一个(hackier，不太好)"fix"是用非常小的非零值(0x1.0p-126f，最小的正常数)填充矩阵。这也可以防止计算中出现非规范化。

相关讨论

也许您的ZeroMatrix使用了稀疏矩阵的典型存储方案：将每个非零值存储在一个链接列表中。如果是这种情况，那么可以理解为什么它的性能比典型的基于阵列的存储方案差：因为它需要对您执行的每个操作运行一次链接列表。在这种情况下，您可以通过使用一个矩阵乘法算法来加速这个过程，该算法考虑到有一个稀疏的矩阵。如果不是这样的话，请发布最少但完整的代码，这样我们就可以玩了。

以下是有效地乘法稀疏矩阵的一种可能性：

http://www.cs.cmu.edu/~scandal/cacm/node9.html

号