ARM在Android兼容性与Windows性能优于英特尔

ZDNet至顶网服务器频道 05月04日 编译： ARM已经公布了一组测试结果，旨在验证英特尔的x86解决方案在现有Android环境下的实际运作效果是否与其宣传相符。

第一组测试的内容是将完全没有经过重新编译的原生应用程序运行在基于英特尔架构的Android设备之上，这些应用程序需要利用“二进制翻译”机制进行模拟、从而将原生ARM代码转换成原生英特尔x86代码。

英特尔公司表示用户对此无需担心——其二进制翻译器只会“对性能造成极为轻微的影响”，而且“在大部分应用程序中这种性能影响根本不会被察觉。”然而正如大家所料，ARM对这一结论表示无法苟同。

“无论大家曾经查阅过或者听取过怎样的解释说明，二进制翻译机制对于用户的使用体验以及系统性能都会造成相当严重的影响，”ARM高级技术营销工程师Rod Watt在该公司本周于德克萨斯州奥斯汀市举办的2014 Tech Day大会上向与会者们解释称。

Watt给出的结论完全基于他本人亲自得到的测试结果。他所使用的基准与游戏性能测试机制由中文网站“爱搞机”提供。

在进行此次性能与功耗测试之前，Watt首先确认了到底有多少款热门Android应用需要经过翻译以运行在基于x86架构的Android设备之上。为了得出确切结论，他通过两论筛选指定了总计100款应用程序，即在线Google Play软件商店上的前25位免费与付费应用外加前25位免费与付费游戏。

Watt将全部注意重点放在了包含原生代码的应用程序在x86平台上的性能表现。不过需要强调的是，在他所调查的这100款应用当中仅有约20%能够在Android Dalvik虚拟机上完美运行;其它应用则或多或少包含了一部分系统中的原生组件。

他得出的结论多少令人有些吃惊。尽管利用Android原生开发套件（简称NDK）能够相对轻松地实现由32位ARMv7 Android应用向原生x86应用的移植，但他在2013年7月进行的这次测试中仍有42%的热门应用需要经过二进制翻译处理才能正常运行;而到了今年1月，他在第二轮测试中发现这一比例上升到了44%。

你们对x86 Android应用的转换情况作何感想，英特尔？（点击放大）

更重要的是——请雇，这些都只是Watt公布的数据，我们并没有对其加以验证——这100款热门应用当中的原生x86 Android应用数量也由去年7月的30款下降至今年1月的23款，而即使经过二进制翻译也仍然无法运行的应用数量则由6款上升至9款。

当然，开发人员可能拥有多种多样且极为充分的理由而没有选择使用Android NDK来将其应用成品移植至x86平台——例如需要为测试工作投入时间或者懒得多此一举——但Watt则对此作出了更为直观的分析结论。“如今移动领域早已是ARM的天下，”他指出。“开发人员们就是在面向ARM环境编写代码，他们根本没必要考虑英特尔平台。”

也许这些为ARM架构编写应用的开发人员应该重新思考自己放弃将软件移植到x86 Android环境下的决定。因为如果Watt通过“爱搞机”网站所获得的性能测试数据准确可信，那么移植与不移植在运行效果上真的存在巨大差异。

该网站的一众中国测试者们在一台联想K800智能手机（采用英特尔凌动Z2460处理器）上运行了多项基准测试以及由虚幻3引擎开发的《史诗城堡》游戏，后者的测试过程分为原生运行与二进制翻译模式两种。

在“爱搞机”网站的测试中，将二进制翻译机制描述为“对性能有所影响”实在是太过轻描淡写了。正如Watt所指出，二进制翻译机制的介入导致几乎每一项性能指标都出现了60%甚至80%的显著下降。

“爱搞机”网站得出结论——性能更糟糕、功耗更夸张（点击放大）

除此之外，《史诗城堡》游戏在原生运行状态下的每秒帧数为49.5帧、经过二进制翻译处理后只剩下31.2帧，而且二进制翻译还导致设备的CPU占用率由前者的58.9%上升到73.4%。再有，应用运行时的耗电量也由621毫安增长到717毫安——这对于极为重要的智能手机电池使用时间来说无疑不是个好消息。

我们可以初步假设，这一切都是那该死的翻译机制搞出的后果。从实际情况来看，Watt发现二进制翻译还给Primate Lab的Geekbench 3.1.4基准套件中的各个组件带来了持续性影响——这种影响在该套件运行在原生ARMv7模式与x86翻译模式下都始终存在。

测试结果依旧令人汗颜：在将二进制翻译机制引入以CPU为核心的基准测试过程中时，手机的功耗指标上升了近90%、而性能则下降超过40%。

正如我们所预料，通过二进制翻译实现的模拟方案会疯狂吞噬手机电量（点击放大）

Watt指出，结合各项围绕二进制翻译所展开的测试结果，这证明“该机制不符合任何一项用户希望在移动设备上满足的需求。它会降低设备的性能表现、拉低应用程序的每秒运行帧数并导致卡顿现象的出现。它会延长应用程序的载入时间、降低电池使用时间。总而言之，一切我们不希望在移动设备上感受到的状况都会由它引发。”

“英特尔根据地”环境下的功耗表现如何？

不过Watt并没有止步于对二进制翻译机制的诟病。他还打算对ARM与英特尔两大阵营的计算核心执行效率作出比较，并为此在自己的华硕Transformer Book T100（配备22纳米四核心英特尔Bay Trail凌动Z3740芯片、主频为1.86GHz）外加一款诺基亚Lumia系列平板设备（推测为Lumia 2520，采用配备Krait 400计算核心的四核28纳米高通Snapdragon 800处理器）上载入了测试平台。

通过对这两款硬件设备的精心打理，Watt表示他得以将二者系统芯片的功耗加以隔离并单独测试、旨在尽可能准确地把握其实际能耗情况。他同时解释称，之所以选择对系统芯片整体加以考量，主要是考虑到单单审视CPU、GPU或者视频引擎有可能导致结果出现误差。他希望能从全局角度出发、更为客观地对系统芯片整体的功耗表现作出评估。更重要的是，不同供应商可能会对CPU及GPU的功耗缓存进行配置与修改，而这将给测试结果造成重大影响。

在两款设备中，T100运行的是Windows 8.1系统，而Lumia方面则为Windows RT。“我们选择的环境可以说是英特尔的根据地，”Watt解释道。“我们运行的是Windows系统，很明显英特尔对这一系统平台非常熟悉、多年的运行经验也使其有能力显著改善执行效率。”尽管拥有这一优势，22纳米的Bay Trail仍然比28纳米Snapdragon消耗掉了更多电能——就连本应发挥巨大作用的先进制程工艺也没能改变这一事实。

Watt首先检查了设备在运行Kraken、SunSpider以及Octane JavaScript基准测试时的功耗水平，三者皆采用IE浏览器作为标准环境。基于ARM Cortex-A15的高通Snapdragon继续领先于基于x86架构的英特尔Bay Trail凌动，前者的功耗水平比后者低出约30%。

“诚然，ARM架构的性能表现确实落后于英特尔设备，”Watt坦言，“不过需要再次强调，此轮测试是运行在Windows环境之下、而我们的功耗水平明显更低。”

基准测试的过程与结果都没有问题，但Watt提醒称这样的数字对于用户并没有实际意义。用户真正需要掌握的是，ARM平板设备与英特尔平板设备在真正运行应用程序时各自能够拿出怎样的电池续航能力成绩。

为了找到答案，Watt分别进行了以下五种测试：连续十分钟进行fitbit.com网站首页开启操作、播放YouTube视频、操作谷歌地图（他承认这是五项测试当中可重复性最低的项目）、在Halo中播放简介影片以及来自Big Buck Bunny的测试影片。

尽管拥有更为先进而精密的芯片制程工艺、并且运行自身最为擅长的Windows系统，英特尔仍然未能压倒ARM（点击放大）

另外，Snapdragon的功耗表现也始终优于凌动芯片——只不过有时候优势较为明显、有时候则相对微弱。当被问到是否还存在其它经过测试但未被整理到报告当中的应用时，Watt发誓称他此次只测试了这五款应用。应用程序的选择方式“是随机的”，而且每一款都重复了“五次或十次”以获取更为准确的平均成绩。

最后Watt对本轮测试作出了总结：首先，面向ARM 32位ARMv7架构编写的Android应用在由二进制翻译机制处理并运行在基于英特尔硬件的x86 Android平台之上时，其性能表现受到显著影响、载入时间变长、电池续航能力也因此变差。

第二点，尽管英特尔的移动处理器更为先进，但基于ARM的系统芯片在功耗表现方面仍然将英特尔远远甩在了身后;而考虑到英特尔在Windows优化领域的悠久历史与丰富经验，再加上采用22纳米制程工艺的技术优势，采用28纳米制程的Snapdragon顶住种种压力、化不可能为可能，成功捍卫了自己的功率王者头衔。

或者可以用Watt的一句话来概括此番比拼的结果：“我们仍然是赢家。”