我为Windows移动设备上的代码性能做了一些基准测试,并注意到一些算法在某些主机上表现得非常好,而在其他主机上则要差得多。当然,考虑到时钟速度的差异。
供参考的统计数据(所有结果都是由Visual 2005针对ARMv4编译的同一个二进制文件生成的):
英特尔XScale PXA270
ARM1136EJ-S核心(嵌入MSM7201A芯片)
ARM926EJ-S核心(嵌入OMAP 850芯片)
我检查了浮点作为一个可能的原因,虽然算法B确实使用浮点代码,但它并不从内部循环使用浮点代码,而且似乎没有一个核心有FPU。
因此,我的问题是,是什么机制造成了这种差异,更好地提出了如何解决/避免瓶颈的建议。
提前谢谢。
发布于 2009-10-07 00:21:29
一个可能的原因是,926有一个较短的流水线(5个周期对1136,iirc 8周期),所以分支错误预测是较低的成本在926。
也就是说,这些处理器之间存在着许多架构上的差异,太多了,无法确切地解释为什么在不了解实际执行的指令的情况下就会看到这种效果。
发布于 2009-10-06 17:05:51
时钟速度只是一个因素。总线宽度和延迟是很大的,如果不是更大的因素。缓存是一个因素。程序的运行速度是从媒体运行的,而不是内存运行的。
这个测试是在测试的任何一点上使用任何共享库,还是全部是内部代码?在媒体上获取不同平台的共享库(即使是相同的sd卡)。
这是为每个平台单独编译的相同算法还是相同的二进制?您也可以并将看到一些编译器诱导的变化。通过改变编译器设置,50%的速度和更慢的速度可以很容易地来自同一个平台上的同一个编译器。如果可能的话,您希望执行相同的二进制文件,并确保在所测试的循环中没有使用共享库。如果不是相同的二进制,则为每个平台拆卸正在测试的循环,并确保除了寄存器选择之外没有其他变化。
发布于 2009-10-07 05:02:33
根据您提供的数据,很难指出确切的问题,但我们可以分享一些以前的经验。
为了分析,
进一步分解您的代码,不仅是算法,而且是块级,并尝试理解导致瓶颈的块。找到导致瓶颈的块后,尝试拆卸块的源代码,并检查程序集。也许会有帮助。
https://stackoverflow.com/questions/1524558
复制相似问题