编译器：CPU性能对比的另一秘诀

当前的CPU市场格局大家都有个了解，Intel从Core架构特别是进入Core i7/i5/i3之后以Tick-Tock战略连连得胜，而且在CPU架构和制造工艺上一骑绝尘，AMD这几年时间只更新了K10及Bulldozer推土机两代，后者独特的模块化设计也一言难尽，并没有达到预期目标，已经落于下风了。

如今的对比就是这样，Intel在CPU性能上大幅领先AMD，AMD只能用性价比以及APU的剑走偏锋来应对。虽然豪言CPU速度竞争已经不再重要，但是个中滋味也自在心头。

除了架构设计，CPU性能高低是不是还存在别的影响因素？一个由来已久的争论就是编译器(compiler)优化。江湖人人皆知，Intel不仅有自己的编译器，而且在针对性的优化中区分Intel系及非Intel系，并针对自家的处理器做重点优化。

2008年开始美国联邦贸易委员会在调查Intel垄断案件中就以编译器优化作为Intel不公平竞争的证据。2010年，FTC与Intel达成和解，Intel承诺编译器不再区分Intel和非Intel处理器，优化时一视同仁。

Intel的编译器优化注意事项中就提到在Intel处理器上会有额外的性能提高

这是前因后果，但是具体到测试上不同的编译器又对CPU性能有多少影响呢？很少有媒体做这样的测试，不过Behardware网站出手了，他们以Core i7-2600K、AMD FX-8150以及上一代的Phenom II X4 975处理器为例对比了不同的编译器下的性能。

全文内容非常多，基础原理、SSE/AVX指令集特点、编译器优化历史等等都有涉及，这部分内容就不再翻译了，因为内容过于专业，大部分人都不是专业人士，读起来晦涩难懂，同行超能网为我们选取了其中的重点内容。

编译器有各种各样的，Behardwar的测试以使用最多的C/C++编译器作为测试对象，编译环境是微软的VS 2010 SP1、Intel的C++ Compiler XE 12.0u5以及TDM-GCC (MinGW/GCC 4.6.1)三种，

VS 2010 SP1

C++ Compiler XE 12.0u5

TDM-GCC (MinGW/GCC 4.6.1)

重要问题：AMD为什么没有自己的编译器

这个要着重写一下，Intel在CPU上有优势主要是因为他们有自己的编译器，为什么AMD没有？这倒不是说AMD不关注这个问题，因为他们主要选择了跟其他厂商或者开发组织合作。首先，AMD也参与了GCC编译器工程，而微软开发VS时也会跟AMD及Intel保持合作以便对他们的CPU作出公正(微软语)而又统一的优化支持。

另外，AMD赞助并推广了Open64编译器，它脱胎于一个编译器研究计划，后者最早是Intel赞助的、针对安腾架构所优化的编译器项目。安腾架构或多或少地应用了VLIW指令，每条指令其实包含三条指令，可以由三个超标量单元执行。它实际上超越了编译器，在安腾架构上可以选择混合哪条指令以获得最大性能，这是一个非常困难的任务。

后来，Intel不再继续这个项目了，AMD还在选择性支持部分Open64编译器，Intel只在Linux平台下才支持Open64，这就与本文无关了。

测试平台及软件说明

测试的CPU前面已经提过了，是Core i7-2600K、AMD FX-8150以及上一代的Phenom II X4 975这三颗，他们支持的指令集也不一样，适合对比，具体如下：

·Intel Core i7 2600k：Sandy Bridge架构，支持所有的SSE、AVX指令集，除了SSE4a

·AMD Phenom II X4 975：Deneb架构，支持最高SSE4a

·AMD FX-8150：(Bulldozer架构，支持所有的SSE、AVX指令集，包括SSE4a

需要说明的是SSE4a指令是AMD支持的指令，而Intel从没支持这个指令。它实际上使用的也非常少，后面的测试中只有一个例子用到了这个指令，而X4 975也不支持任何SSE 4.1或者SSE 4.2指令。

另外，SSE 4.1与SSE4a之间只有很少部分是重叠的，大部分应用都不支持，这也为Intel的编译器带来了一些问题。

测试平台配置

主板：华硕P8Z68-V Pro (Intel)、华硕M5A97-Evo (AMD)
内存：2×2GB DDR3 1600MHz
显卡：Radeon HD 5450
硬盘：海盗船F120
操作系统：Windows 7 SP1

测试程序

测试使用的主要是SPEC 2006 v1.2，2011年9月的新版本，具体内容不表。

SPEC性能测试之bzip2、mfc

401.bzip2测试

语言：C
负载类型：整数
多线程：支持

bzip2是Linux平台下很流行的压缩软件，测试用的程序经过改进，只能在内存中压缩和解压数据，这样就避免了磁盘性能不足带来的负面影响。

第一个测试就让人有些吃惊，微软的VS编译器在Core i7以及FX处理器上都有着最好的性能。更讽刺的是Intel的编译器在Phenom II X4 975上速度最快。

微软的编译器在Core i7上甚至要比AVX版还要快12%，后者本来应该是有最佳性能的。

结果有些出乎意料，SSE 4.1/4.2/AVX指令在i7/FX处理器上都是最慢的，但是Phenom X4上并非如此。

429.mcf测试

语言：C
负载类型：整数
多线程：不支持

在这部分测试中，微软编译器在SSE2及AVX指令上并没有获益，获益的主要是Intel编译器。

先看一下dispatcher builds，SSE3版的性能提升了30%，其他三种就只有轻微性能提升。这里有什么问题吗？如果是使用“arch” builds，那么SSE3的性能优势就没有了。

在这里，SSE3性能更快，但对其他模型来说就不一样。

这里要为Intel说一句话，如果没有dispatcher，那么它的编译器在AMD处理器和Intel自家处理器上表现是一样的，Phenom II X4处理器在arch:SSE3模式下性能比Intel还好。

调度器(Dispatcher)在AMD FX和Phenom II处理器上表现是一致的，这正是我们期待的结果。

◆ SPEC性能测试之gombk、hmmer及sjeng

445.gombk性能测试

语言：C
负载类型：整数
多线程：支持

gombk是游戏中常用的人工智能AI算法，主要在开源游戏中GPNU Go中使用。

这个测试中不同的优化差异相对比较小，不过在i7处理器上微软和GCC编译器要比Intel自家的更快，不过Intel编译器在Phenom II依然是最快的。毫无疑问，Intel编译器在这个CPU上表现的很好。

456.hmmer测试

语言：C
负载类型：整数
多线程：不支持

hmmer是基因数据库中常用的算法，同时在蛋白质序列分析中也很常用。

结果让人很吃惊。不同的Intel编译器调度器版本在Intel i7处理器上有明显性能提升，同样在AMD FX处理器上也有明显提升。

458.sjeng测试

语言：C
负载类型：整数
多线程：不支持

sjeng是国际象棋软件中使用的算法，来源于同名软件。

SSE 4.1/4.2/AVX在i7处理器上有轻微性能提升，不过同样的调度器下在AMD处理器上有一点下降。一旦去掉调度器，AVX在FX处理器确实有一点性能提升。

SPEC性能测试之h264ref、astar及milc

464.h264ref

语言：C
负载类型：整数
多线程：支持

h264ref是H264/AVC视频编码中使用的压缩标准，这个测试包括baseline和main两个视频配置。

微软的编译器在i7处理器上要比Intel编译器要快，而Intel编译器不仅在Phenom II处理器要更快，在FX处理器上也是如此。有调度器的Intel编译器是最有效率的。

GCC编译器在Phenom II上优化的很好，但是在FX甚至起到反作用了。corei7avx在i7处理器还有一点性能优势。

473.astar

语言：C++
负载类型：整数
多线程：不支持

astar是一种RTS游戏中常用的寻路算法。

这是本文第一个C++编译器测试，不过表现并不怎么好，它的优化甚至有反作用。微软编译器是最优效率的，不过i7处理器除外。

需要的注意的是，在没有调度器的情况下，只有SSE3版才能在Intel编译器优化中受益，而其他版本不会。当然，这与指令集支持无关。

433.milc

语言：C
负载类型：浮点
多线程：支持

milc是量子色动力学中QCD中常用的物理模拟算法。

跟之前的测试一样，有调度器的情况下，Intel编译器在i7处理器商用SSE3模式会有性能增益，性能几乎翻倍。在FX处理器上性能没有变化，在Phenom II处理器上提升提升了9%。

SPEC性能测试之namd、lbm及sphinx3

444.namd

语言：C++
负载类型：浮点
多线程：支持

namd是分子运动动态模拟测试。

Intel编译器的AVX调度器模式有轻微性能提升，在FX处理器上也是如此。微软编译器的AVX模式获得了最多的性能提升，特别是在AMD平台上。

在这里，AMD和GCC的优化在i7处理器上要比Core i7的优化还要好。

470.lbm测试

语言：C
负载类型：浮点
多线程：支持

lbm是一个模拟流动行为的科学计算程序。

在这里，Intel编译器发威了，表现比其他编译器要好。另外，AVX以及有调度器下的SSE 4.1模式有些小问题，在AMD处理器上明显要慢，这也不是第一次遇到这个问题了。

482.sphinx3

语言：C
负载类型：浮点
多线程：支持

sphinx3是SPEC测试软件中一个声音识别算法。

首先来看微软编译器的表现，虽然SSE2模式明显影响了三套平台的性能，但是在i7处理器上AVX模式跟SSE2一样慢，但是在FX处理器上它又突然变成最快的。

Intel编译器的AVX模式在i7处理器上有一些性能提升，不过在其他平台的非调度模式下就有性能下降。

性能测试之C-Ray、TSCP及7-Zip

除了SPEC，他们还测试了其他几个软件。

微软编译器在从X87到SSE2中性能翻倍还多，在三套平台下都是如此，AVX模式在i7处理上甚至比Intel编译器还要快。

与之前的情况一样，Intel编译器在AMD平台上效率最好，Intel编译器的不同调度器对此也没什么影响，甚至关掉也一样，不过FX处理器在SSE 4.2和AVX模式下有一些性能下降。

另外，GCC编译器对i7处理器甚至有反作用，但是在AMD处理器上就不一样。

TSCP

语言：C
负载类型：整数
多线程：不支持

TSCP是源于Tom Kerrigan软件中的国际象棋AI算法。

在这里，Intel编译器无论是否有调度器都没有影响，有的话AVX模式下有一点优势。GCC编译器在三套平台下表现都是最好的。

7-Zip

语言：C
负载类型：整数
多线程：支持

7-zip就无需过多介绍了，他们使用的是9.20版本，用LZMA2算法来评估性能。

7-zip是唯一一个用性能而非时间为基准的测试，数字越大越好。

测试结果中，微软的编译器在i7和FX处理器上是最快的，Intel编译器只在Phenom II处理器上领先。

汇编语言的影响：X264测试

X264视频压缩软件在这篇测试中非常特殊，因为它使用了大量汇编语言。而且作者也并非单独针对X86优化，它还支持ARM架构中的NEON指令。如果禁用汇编优化，那么它还可以作为编译软件使用，这样就可以检查出优化的影响。

首先要指出的是，X264一旦检测到GCC编译的带有SSE4a优化的build就会停止执行，只有同时支持AVX和SSE4a指令的FX处理器才能完成整个编译过程。

第二，用汇编语言写成的代码是获得最高性能的最佳方式，虽然汇编语言从2600K的corei7/corei7avx配置及AMD处理器的bdver1及barcelona配置中受益很小。更让人吃惊的是在无汇编语言的代码上并不受欢迎。

最后，强制使用AVX 128bit指令确实会有影响，不过影响非常小。

当然这里的测试结果并不能与我们之前测过的结果直接比较，但是我们还是要说，虽然编译器现在扮演着重要角色，但是开发者总是可以大幅优化C/C++代码的。

性能综述：Intel编译器占优

前面一大堆的结果看的大家都累了，来看看综合性的性能评述吧，这些表格平均了前面的测试结果，更方便对比。

cl base性能

cl SSE2平均性能

icc base性能

如果看完了前面的介绍，那么这里的结论并不让人吃惊。Intel编译器的是性能最好的，GCC也不错，但是部分测试中市场有相反的作用。

VS 2010的标准版明显最慢，主要是因为默认的浮点操作默认使用的还是X87代码，吐过改用SSE2性能就会大幅提升，特别是在AMD处理器上。

如果对比默认的Intel模式(同样为SSE2编译)，那么Intel编译器就会领先，而FX-8150受益最为明显，可提升24%的性能，i7才提升了20%。

总结：编译器的抉择困境

Behardware在最后表示希望他们的文章可以阐明有关编译器的问题，让大家了解到编译器在处理器性能中扮演的角色。他们在文中问了几个问题，现在我们可以自己找到答案了。(看过之后还是觉得一头雾水的路过)

首先，编译器的不同选择会影响性能。之前一直在说Intel编译器性能最好的说法得到证实，虽然有一些反例，但是Intel编译器还是要比默认设置的微软VS要好，就算后者强制使用SSE2数学操作，微软的编译器依然要比Intel编译器慢上15-20%。

如果Intel投资开发了一款编译器，那么它当然可以作为性能战争中的一项优势。Intel可以为自己的处理器自动优化，甚至可以通过命名的方式把这些优化当作指令集，比如为AVX优化的qaxAVX就是一例。Intel总是把最新的优化留给最新的处理器，这样一来在测试中就会获得性能优势，然后加深大家对Intel处理器的性能优势的印象。看看Phenom II在那些无AVX调度的应用中的性能就非常明显了。

一个无指令调用功能的例子

如果禁用了调度器，就会因为一些优化层面的问题变得更复杂，这已经跟处理器是否支持某种指令集无关了。更差的情况就是，部分型号的表现反而要比其他型号更有效率，比如SSE3模式就是平均最快的了。

总之，Intel的编译器给开发者带来了复杂的选择，要么选择没有优化，要么就是使用Intel制定的指令集以便在Intel处理器上获得额外的15%性能提升，而在AMD处理器上没有或者是降低了性能。

这个问题能怪开发者吗？这是一个两难的问题，如果你给开发者一个公平的编译器，它在AMD处理器上能获得35%的性能提升，但是Intel处理器上能获得54%的性能提升，你会责怪开发者选择了能给消费者最佳体验的那条路吗？

那么AMD处理器用户呢？他们是会接受一个公平但是性能更慢的情况,还是更愿意接受一个自己有性能提升但是竞争对手性能提升更多的方案呢？真实世界中，用户的观点并不重要，软件程序用户没得选择，好与坏的决定权是在开发者手中。

实际上我们的处理器测试就已经受到了开发者的选择的影响，尽管我们的原则是尽可能避免盲目推崇测试。一旦哪个非常流行的程序选择了某个处理器而不是另一个，那么测试性能不同反映的其实只是软件的用户体验。

给出一个公正客观的选择也非常难，实际上也没有多少解决方案。开发向LLVM那样的编译器以及编写可管理的代码是一个可行的方案，这就像.NET的普通应用一样，要记住不论是谁控制了虚拟机，终端才是控制每个架构性能的关键。