我的 gcc 中的错误?我的代码中的错误?两个都?
http://files.minthos.com/code/speedtest_doubles_wtf.cpp
不知何故,它设法“优化”了一个函数,该函数导致双精度数组在我的 q6600 上被清零为 2.6 秒,而不是 33 毫秒,更复杂的函数需要用一些有意义的东西填充数组。
我很想知道其他人是否得到类似的结果,如果是这样,是否有人可以解释发生了什么.. 并找出导致整数和浮点性能之间巨大差异的原因(特别是在没有优化的情况下编译时)。
我的 gcc 中的错误?我的代码中的错误?两个都?
http://files.minthos.com/code/speedtest_doubles_wtf.cpp
不知何故,它设法“优化”了一个函数,该函数导致双精度数组在我的 q6600 上被清零为 2.6 秒,而不是 33 毫秒,更复杂的函数需要用一些有意义的东西填充数组。
我很想知道其他人是否得到类似的结果,如果是这样,是否有人可以解释发生了什么.. 并找出导致整数和浮点性能之间巨大差异的原因(特别是在没有优化的情况下编译时)。
第 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.00000000000000000000000000382652 这样的值。一旦添加到 0.1,低位往往会被删除。
您不会begin
在基准测试之间重置,因此您的计时数字很难解释。也许这就是你困惑的根源?
随机 64 位整数在高 32 位都有零,因为rand()
返回 32 位值(至少对于 32 位平台上的 gcc)。因此,所有双精度数都将被非规范化,因为重新解释的整数位模式对于指数字段将为零。将 0.1 添加到非规范化值会得到规范化值(非常接近 0.1)。
所以每一行ffun2
都是一个非规范化值的乘法;的每一行ffun3
都是一个归一化值的乘积。查看生成的程序集,我看到乘数是在循环之前计算的;在每种情况下,循环都只包含乘法。对执行时间差异的最可能的解释是,如果乘法器是非规范化的,则乘法需要更长的时间。
至于最后一个问题:浮点运算(尤其是双精度)比整数运算复杂得多,因此在相当现代的流水线处理器上,每条指令的执行时间都会更长。