liangbch
发表于 2008-5-9 09:03:46
原帖由 无心人 于 2008-5-8 17:53 发表 http://images.5d6d.net/dz60/common/back.gif
1、清零的速度还可以提升
我算过,每秒可达到2.5GB/s以上,我的机器不如你的, 但我测试清零速度似乎能达到2.0G以上,你的似乎达不到
...
1. 清零的性能测试程序确有问题,其他性能测试函数都是取8次中的最小值,而清零测试函数没有,故导致测试结果偏大。
2. 对于清零,拷贝,求补,我分别增加了使用64bit MMX寄存器的版本。
3. 所有数据度都将随后更新,敬请关注。
无心人
发表于 2008-5-9 09:33:15
:)
这三个函数都应该能达到每秒2GB的处理速度, 加减法也是可以的
我算过,我的机器是2G频率,加法平均5周期处理一个双字
则速度是2*4/5=1.6GB/s
无心人
发表于 2008-5-9 09:35:45
:)
另外你的说法不对,不应该取最小值
要取平均值
而且,最好提高进程到最高级优先级
关掉任何其他消耗资源程序再测试
我这里运行麦森数查找程序GIMPS和停掉测试
对是否用MMX和SSE的比较结果有时都能造成颠倒
liangbch
发表于 2008-5-9 10:03:33
这三个函数都应该能达到每秒2GB的处理速度, 加减法也是可以的
我算过,我的机器是2G频率,加法平均5周期处理一个双字
则速度是2*4/5=1.6GB/s
由于采用2^30进制,故清零,复制,加,减,其复杂度是不同的,清零最最简单的,只有内存写,处理每个DWORD只需1条指令;减是最复杂的,处理每个DWORD需要7条指令,比加函数还多一条指令.
无心人
发表于 2008-5-9 10:08:13
:)
关键不是多少指令
关键是每双字消耗周期
有时候多1个指令,不一定多一个消耗周期
所以俺承认2^30不一定比2^32多多少周期
就在CPU能并行处理指令上
liangbch
发表于 2008-5-9 10:10:07
原帖由 无心人 于 2008-5-9 09:35 发表 http://images.5d6d.net/dz60/common/back.gif
:)
另外你的说法不对,不应该取最小值
要取平均值
而且,最好提高进程到最高级优先级
关掉任何其他消耗资源程序再测试
我这里运行麦森数查找程序GIMPS和停掉测试
对是否用MMX和SSE的比较结果有时都能造 ...
不管怎么提高进程有限级别,CPU 资源都可能别其他进程占用,因此我使用最小值的方法,可避免其他进程的干扰。
另外,我记得gxq的某次测试中,也是采用多次测试取其最小值。
另一个例子,FFTW中的性能测试技巧 也使用了类似的方法,下面的内容引用自 http://www.fftw.org/speed/method.html
The timing procedure consists of two loops. First, we compute enough repeated FFTs so that the total time is sufficient for accurate timing, and divide by the number of iterations to obtain the average time. Second, we repeat this averaging process eight times, and report the minimum average time (to avoid fluctuations due to system interrupts, cache priming, etcetera).
无心人
发表于 2008-5-9 10:28:23
:)
那能确保是准确时间么?
要知道乱序执行引擎受各种因素影响
即使固定的代码序列排除我说的干扰
执行时间也是不固定的
即使用单任务OS
也测不到固定数值
所以我猜测
测试最小值并不是个好主意
无心人
发表于 2008-5-9 10:47:09
次数函数12 3 4 561255724413223323134927395225752456322432693375 6479325822455322332473375646142675246932003251334564925259627333416324633506485
红色为最小值,蓝色为最大值
单位: 毫秒
做了个测试
发现几个有意思的现象
1、某些函数执行时间在单调增加,然后突然减少
2、有时几次测量结果,不同函数最小值不同时出现
3、有时,某函数出现最大值,其他函数却出现最小值
4、剔除最大值后,其他测试值是很接近的