Intel和ARM都觊觎移动互联网市场，在这两家公司的资本来看，很不巧地都是玩儿芯片出身的，于是消费者买手机对于这两家公司来说只是结果，更深层次的东西我们几乎没有机会触及。但是当智能手机平台，也出现了各式各样的跑分软件之后，口水战也就司空见惯了。

事情起因于一款叫做“安兔兔（Antutu）”的硬件测试工具，由于对ARM与X86两大阵营的测试数据差距悬殊（主要体现在增长率方面），导致国外媒体anandtech开发者论坛的一位技术研发型网友，深入地剖析了Antutu 3.x程序安装包，并且果然发现了其中一些问题。

发现：Antutu的测试部分原来是基于开源代码nbench二次开发的（可参考tux.org）

发现：Antutu针对ARM架构处理器使用GCC编译器，但这种编译器不支持ARM的NEON指令，虽然在NDK（可以理解为面向开发者的工具库，用于开发动态库、创建so文件，并将so与java打包生成apk文件）中额外支持NEON指令完全可以实现，但Antutu并没有支持这一Google的标准开发案例。相反的，对于X86架构处理器所使用的是ICC编译器，其中包含的矢量化是ARM架构不擅长的。

nbench CPU整数和浮点运算需要32次循环（图片截取自forums.anandtech）

发现：ARM与X86两种架构，在执行nbench测试过程中，ARM架构需要顺序完整地执行32次循环，而X86架构的代码部分针对这一循环做了优化，可以绕过这一循环，从而提升了不止一点儿的执行效率。

ARM架构需要顺序完整地执行32次循环

（图片截取自forums.anandtech）

发现：发现中的情况，并不是一直存在的，而是最近的一次升级时才出现在ICC编译器中，有意而为之的可能性较大。

X86架构的代码针对这一循环做了优化，可以绕过这一循环

（图片截取自forums.anandtech）

简单总结一下上述的4个发现，简单来说，就是在Antutu在测试不同架构处理器性能的时候，首先，针对不同的架构而使用不同的编译器测试本无可厚非，但至少应该保证不同的测试平台在同一起跑线上。其次，到底这样的代码优化是不是合理的，还是说仅仅为了提高Antutu跑分成绩，目前Antutu官方并没有明确表态。再次，经过了这样的代码优化之后，用户能否在实际使用中，得到超高跑分应有的表现，这也是个未知数。

实话实说，我个人虽然学过计算机，但这种水平的代码确实超出了我的能力范围。但既然争论已经存在，就说明的确有事实，有事实就一定有真相。我始终不认为跑分能够说明什么问题，我也并不认为用哪一种或哪几种测试方法得出的结果才具备参考价值。站在用户的角度看这个问题，其实一点都不难回答，用户要的永远都只是体验，没人会拿个手机天天拼跑分。无论是ARM还是Intel，只要是能够带给用户好的体验，只要让用户觉得这钱花得值，我觉得就足够了。至于Antutu或者说是安兔兔，从编译器的选择到测试部分代码的二次开发的严谨度，到频繁升级给用户带来的选择性困扰，哪怕不公开表态，也至少是值得反思的。（本文技术部分参考了expreview的译文）