没人转啊，替T神转一下：安兔兔节操碎了一地？Intel Atom跑分高的”真相“谜团

largewc

　　第三方调研公司ABI Research以安兔兔成绩盛赞Intel Atom处理器性能超过高通、三星一事其实是5月中发生的，今天EETimes上篇博文又谈到了这件事，认为ABI只用安兔兔成绩说事有些武断，他又列举了其他评测项目的成绩来反驳，并认为安兔兔从2.9.3版到3.x的评分机制变化导致Intel处理器得分大幅上升，所以才占到了优势。

　　没想到这件事并没有结束，既然双方争论的焦点是安兔兔软件，Anandtech论坛上就有一位爱较真的网友（应该是个程序员或者开发者）分析了安兔兔软件，结果却让人很震惊，他认为安兔兔有故意为Intel处理器优化甚至使用对ARM不公平的方式了评分。

　　如果此事成真，那么安兔兔的节操就要洒满一地了。

　　下面来看一下他的分析。

安兔兔是怎样的一个程序

　　首先是解包安兔兔程序，APK程序实际上就是一个标准的ZIP压缩文件，这一步没什么难度。解包后在lib库中发现了X86和ARM-v7a目录，分别对应Intel和ARM处理器。然后再解包libabenchmark.so文件，他用的是objump软件。

　　下面就来理解一下安兔兔软件的根基了，原文作者从解包出来的文件中发现安兔兔实际上就是nbench，因为二者的功能及函数之类的东西都是一样的，我们可以说安兔兔的CPU整数和浮点测试都是基于nbench的，后者的源码地址在http://www.tux.org/~mayer/linux/bmark.html。（原来安兔兔的测试部分不是自己开发的，也开源程序DIY的啊）

　　现在继续我们的目的，揭开为啥安兔兔3.x测试中Intel处理器跑分这么高的原因。之前EETimes一文质疑的原因就是在于从2.9.3版升级到3.0之后，Atom处理器总分及内存测试分别提升了122%、292%，而三星Galaxy S4只提升了53%、59%，这其中的区别耐人寻味。

Atom超高跑分第一个疑凶：编译器

　　找出的第一个“疑凶”是编译器，安兔兔针对X86使用的是ICC编译器，这是一种公认的高质量矢量化编译器，而矢量化恰恰是ARM处理器不擅长的，因为后者缺少整数NEON指令。

　　安兔兔针对ARM处理器使用的是GCC编译器，而且也不支持ARM的NEON指令，因为存在着Tegra 2这样早起的处理器不支持NEON指令的情况，但是现在来看这些不是理由，NDK中使用独立代码支持NEON指令不是难事，这也是Google的文档中标准的开发范例。

　　令人奇怪的就是安兔兔不按照Google的开发范例支持原本应该支持的功能，却对不属于NDK标准支持之内的ICC编译器青睐有加。

　　编译器的问题只是一个开始，下面还有更精彩的，它们的作用甚至比编译器更“出色”。

第二疑凶：代码优化

　　Nbench测试时会检查CPU是怎样执行简单的按位操作的，包括shift位移、and加、or或等，为了执行这些，它会在内存载入一系列bit，每次载入一个，具体的代码如下：

再来看ARM和X86是如何具体执行的。

ARM处理器执行的代码

　　X86上的代码在做的是讲整个32bit运行到0或者1，其中的f64c3和f64c6是关键。它用这两个指令取代了ARM循环中的32次迭代。这个的作用就不需多说了，X86用这种方式获得了十多倍的运行速度提升。

　　这种做法打破了整个测试过程。当编译器本来打算用一些被测试程序认定为正确的操作来提升测试程序的性能时，它实际上并没有执行真正的测试程序功能。典型的例子就是如果结果没有被读取，它就省去了代码，或者是在输入数据被认为是常量时，它可以将原本需要的运行时间缩减到只需编译时间即可。

　　在这种情况下Intel肯定会宣称这是他们正当的优化而已，但是原文作者不赞同，认为这种优化很难被当做正常的代码，用处也很有限，因为没谁会用这样的代码来执行。这种伎俩更应该被认为是一种作弊，因为当运行长度不是非常大的时候它甚至会更慢。

　　更重要的是，这种优化是在最近的一次版本升级中才出现在ICC中的，作者不认为他们是最近才发现了这种优化的价值，更可能的情况是他们发现这种优化可以数倍提升安兔兔分数，或者这也可以解释为什么最近曝光的下一代Atom处理器在1.1GHz频率下都能以4万的高分秒了2.3GHz的骁龙800了。

　　我们简单归纳一下作者的观点和论据：Atom处理器跑分高有两个原因，一个是编译器的原因，X86使用的ICC编译器优化很好，而针对ARM所用的GCC编译器甚至都不能支持ARM的NEON指令。第二个就是安兔兔代码中，将X86运行测试程序的代码“优化了”，只需2个指令就能完成ARM处理器需要进行的32次迭代，但是这种优化对实际性能没有好处，这种反常的设计颇有寻味之处。

　　原文最后把矛盾的焦点转向了安兔兔，因为他们默认了这样的性能提升，还认为安兔兔有可能是收钱了（probably for a price），不然这些反常的现象是没法解释的。

Intel、ARM出面掀起新高潮

　　原文的翻译差不多完了，因为是技术文章，个别语句可能把握的不够准，不过大体意思我们是知晓了的。我能这么早看到这篇文章其实是微博所赐，发这个链接的正是ARM移动市场经理王骏超EW，微博发出之后很快就有人回复，其中一个人则是Intel中国研究院首席工程师吴甘沙，看完Intel对ARM还是很关注的嘛，这让人想起了钱钟书说过的一句话：情敌之间的挂念有时候要比情人之间的牵挂还要多。

　　王先生虽然发了链接，不过自己并没有说太多，但他显然是站在揭黑幕、维护ARM的立场上的，而吴先生也客气地解释了这个问题，他认为编译器也是架构竞争力的一部分，用ICC无可厚非，而且ARM的NEON指令是比不过Intel的SSE 4.x指令集的。他还认为原文的分析并不能解释Atom在安兔兔多数程序上的优势。

　　总之，现在这件事已经多多少少地从媒体牵扯到了ARM、Intel两家公司出面了，而涉及最深的应该是安兔兔，目前还没有他们的表态，只是从这篇文章的分析来看，安兔兔不管有没有收钱，在这件事上都是有不光彩行为的。

　　去年华为发布Q1四核之后，安兔兔突然在其英文版网站（选择的还不是中文官网）上义正言辞斥责华为K3V2处理器作弊，因为在相关代码中发现K3V2会针对测试程序全速或者超频运行，而在日常应用中却降频使用，安兔兔好一副公正无私的表现。

　　当然，华为是大公司，大风大浪见多，安兔兔的指责也没改变他们把K3V2当成万年宝贝用在旗下多款高端甚至旗舰手机上。

　　看来不论是什么人或者什么公司，节操都不会第一位的，哪怕碎了一地也可以捡起来继续。

crespo442

元芳们怎么看？

largewc

现在可以赖x86编译器更出色:)

内存性能个人感觉多数是rep这种专用指令带来的，这玩意比你循环拷贝快几倍，可惜arm没有这种专用指令。

needfire

关键是实际的应用软件能不能用得上，能用就不是作弊。
CISC本来就是拼指令集的。

largewc

needfire 发表于 2013-7-12 11:05
关键是实际的应用软件能不能用得上，能用就不是作弊。
CISC本来就是拼指令集的。

历史上证明用得上，2000年附近的时候，ms的编译器跟intel差距较大的，当时可以改用intel的，提升15%-30%左右性能。

gcc跟微软的差距都很大，跟intel差距更大，当然，你要嫌快用gcc也行。

jjx01

编译器比不过就说明你那个cpu落后嘛...

frankincense

needfire 发表于 2013-7-12 11:05
关键是实际的应用软件能不能用得上，能用就不是作弊。
CISC本来就是拼指令集的。

用ICC编译x86代码的话，类似的操作当然还能用得上。桌面因为还存在AMD，而且Intel自家的处理器也有几种，很多程序倾向于使用通用的GCC等第三方编译器，但是针对单独平台的话，用ICC编译是不二之选，就连SPEC都承认ICC编译的性能。

frankincense

largewc 发表于 2013-7-12 11:15
历史上证明用得上，2000年附近的时候，ms的编译器跟intel差距较大的，当时可以改用intel的，提升15%-30%左 ...

全套Intel Xeon+Xeon Phi方案的天河2超算就是用ICC编译的

largewc

frankincense 发表于 2013-7-12 11:25
全套Intel Xeon+Xeon Phi方案的天河2超算就是用ICC编译的

恩，这个不懂了，服务器涉猎较少，多谢

lichlls

最大的问题还是要高的性能来做什么用呢？ 游戏安卓平台目前是根本不可能出什么用心制作的大作的，看电影不觉得有哪个手机是流畅不了自身屏幕级清晰度的电影的， 起码现在希望他们拼节电好过拼性能。

raini

自己不会好好优化，搞个更好的编译器，却要怪对方的编译器太快。
以后呀，干脆这样，测arm的跑x86的库，测x86的跑arm的库，任何优化都不起作用，这样就能反映CPU的真实实力了。
另外，ABI Research赞的是atom这个CPU，又不是赞专门为arm设计的却在atom上跑的android。谈性能的时候，怎么不让arm去跑个windows看看？word rt那感人的打字速度，让你真正实现盲打。

Prescott

甘沙V5

开普勒

ARM版本的so应该用ARM Compiler而不是GCC来编译，以示公平。

asdfjkl

第一种编译器的优化不谈，后一种优化就是作弊，你改变了两者的任务和负担。测评就是干一样的事，然后比较； 不管事件本身有没有意义，有没有可以改进的，一样的事是公平的基础。
就像竞技比赛的举重，赛跑，负重的铁人三项等等。你不能说你又不可能永远的负重生活的，负重总归要拿下来的，所以我就拿下负重和你比。

一个例子：
老师让你从1数到100，看谁数得快。
一个老老实实从1数到100；
一个数了1，然后喊了个100就结束了；然后说我研究了老师你这个要求，中间数的数没啥用的。你又没有让我记下来啥的。。。

raini

asdfjkl 发表于 2013-7-12 13:34
第一种编译器的优化不谈，后一种优化就是作弊，你改变了两者的任务和负担。测评就是干一样的事，然后比较； ...

嗯，意思就跟内置100w位的pi一样的。

jjx01

两个U会在同一个系统同一个程序上跑出两种算法么...

jjx01

raini 发表于 2013-7-12 13:40
嗯，意思就跟内置100w位的pi一样的。

super pi都是迭代算的

needfire

asdfjkl 发表于 2013-7-12 13:34
第一种编译器的优化不谈，后一种优化就是作弊，你改变了两者的任务和负担。测评就是干一样的事，然后比较； ...

这么说不对，举个例子：
从1加到100，对于RISC架构来说最快的方法是1+（1+1）+(1+1+1)......一直到加到100。对于CISC架构直接(1+100)X（100/2），当然也可以1+（1+1）+(1+1+1)......；CISC有指令集，有更好的方法总不能不让用吧。

largewc

needfire 发表于 2013-7-12 13:48
这么说不对，举个例子：
从1加到100，对于RISC架构来说最快的方法是1+（1+1）+(1+1+1)......一直到加到1 ...

这个算不上，这个算是拆loop那种，比较深度优化的了。

asdfjkl

needfire 发表于 2013-7-12 13:48
这么说不对，举个例子：
从1加到100，对于RISC架构来说最快的方法是1+（1+1）+(1+1+1)......一直到加到1 ...

从完成任务的角度看，OK。这个办法聪明。

但从比试的角度看，不合理：
1）  因为测评就是要看CPU设计的性能，测评就是要公平。100米赛跑，风速多少都有限制。 按你这么说，你跑马拉松，我建议开车，开车省时省力效率高。人还舒服。
2） 你这个优化，和RISC，CISC的指令集没有半毛钱关系，完全是优化了执行代码。或者说优化方法。
3） 这种优化，一家采用，一家不用，绝对绝对不公平。