Question

我的gcc中的错误？我的代码中的错误？既？

http://files.minthos.com/code/speedtest_doubles_wtf.cpp

不知何故，它设法“优化”一个函数，导致双精度数组在我的q6600上被归零为2.6秒，而不是33毫秒，更复杂的函数用一些有意义的东西填充数组。

我有兴趣知道其他人是否得到类似的结果，如果有的话，是否有人可以解释发生了什么..并且还要弄清楚是什么导致整数和浮点性能之间的巨大差异（特别是在没有编译时）优化）。

Answer 1

第99行：

memcpy(floats, ints, sizeof(floats));

使用浮点垃圾有效地部分初始化floats[]。其余的保持为零。这源于用整数位图替换浮点数，然后将它们解释为双精度数。溢出和下溢可能会影响性能？为了进行测试，我将随机数种子更改为常数1000以获得可重复性，并得到了这些结果：

[wally@zenetfedora Downloads]$ ./speedtest_doubles_wtf.cpp
no optimization
begin: 0.017000
floats: 27757.816000
ints: 28117.604000
floats: 40346.196000
ints: 41094.988000
sum: 7999999.998712
sum2: 67031739228347449344.000000
mild optimization
begin: 0.014000
floats: 68.574000
ints: 68.609000
floats: 147.105000
ints: 820.609000
sum: 8000000.000001
sum2: 67031739228347441152.000000
heavier optimization
begin: 0.014000
floats: 73.588000
ints: 73.623000
floats: 144.105000
ints: 1809.980000
sum: 8000000.000001
sum2: 67031739228347441152.000000
again, now using ffun2()
no optimization
begin: 0.017000
floats: 22720.648000
ints: 23076.134000
floats: 35480.824000
ints: 36229.484000
floats: 46324.080000
sum: 0.000000
sum2: 67031739228347449344.000000
mild optimization
begin: 0.013000
floats: 69.937000
ints: 69.967000
floats: 138.010000
ints: 965.654000
floats: 19096.902000
sum: 0.000000
sum2: 67031739228347441152.000000
heavier optimization
begin: 0.015000
floats: 95.851000
ints: 95.896000
floats: 206.594000
ints: 1699.698000
floats: 29382.348000
sum: 0.000000
sum2: 67031739228347441152.000000

使用正确的赋值替换memcpy后重复，因此可以进行类型转换，以防止浮点边界条件：

for(int i = 0; i < 16; i++)
{
    ints[i] = rand();
    floats[i]= ints[i];
}

修改后的程序仍然以常量1000为随机种子，提供以下结果：

[wally@zenetfedora Downloads]$ ./speedtest_doubles_wtf.cpp
no optimization
begin: 0.013000
floats: 35814.832000
ints: 36172.180000
floats: 85950.352000
ints: 86691.680000
sum: inf
sum2: 67031739228347449344.000000
mild optimization
begin: 0.013000
floats: 33136.644000
ints: 33136.678000
floats: 51600.436000
ints: 52494.104000
sum: inf
sum2: 67031739228347441152.000000
heavier optimization
begin: 0.013000
floats: 31914.496000
ints: 31914.540000
floats: 48611.204000
ints: 49971.460000
sum: inf
sum2: 67031739228347441152.000000
again, now using ffun2()
no optimization
begin: 0.014000
floats: 40202.956000
ints: 40545.120000
floats: 104679.168000
ints: 106142.824000
floats: 144527.936000
sum: inf
sum2: 67031739228347449344.000000
mild optimization
begin: 0.014000
floats: 33365.716000
ints: 33365.752000
floats: 49180.112000
ints: 50145.824000
floats: 80342.648000
sum: inf
sum2: 67031739228347441152.000000
heavier optimization
begin: 0.014000
floats: 31515.560000
ints: 31515.604000
floats: 47947.088000
ints: 49016.240000
floats: 78929.784000
sum: inf
sum2: 67031739228347441152.000000

这是一台较旧的PC，大约在2004年，否则装载很轻。

看起来这让事情变得更慢了。也许更少的零做算术？这就是许多随机位模式的样子。或者值为0.0000000000000000000000000382652。一旦将其添加到0.1中，低位就会被删除。

Answer 2

您没有在基准测试之间重置begin，因此很难解释您的时间数字。也许这是你混乱的根源？

Answer 3

随机64位整数都在高32位中都为零，因为rand()返回32位值（至少对于32位平台上的gcc）。因此，所有双精度都将被非规范化，因为整数的重新解释的位模式对于指数字段将为零。将0.1添加到非规范化值会得到归一化值（非常接近0.1）。

因此ffun2的每一行都是一个非规范化值的乘法; ffun3的每一行都是一个标准化值的乘法。查看生成的程序集，我看到在循环之前计算乘数;在每种情况下，循环只包含乘法。对执行时间差异的最可能的解释是，如果乘法器被非规范化，乘法会花费更长的时间。

至于最后一个问题：浮点运算（特别是双精度）比整数运算复杂得多，因此在一个相当现代的流水线处理器上，每条指令的执行时间都会更长。

g ++，双打，优化和大型WTF

3 个答案: