C语言编译器和amd兼容吗,Intel的“霸道”：深究编译器对CPU性能的影响

Intel的“霸道”：深究编译器对CPU性能的影响

编译器：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处理器，优化时一视同仁。

VS 2010 SP1

TDM-GCC (MinGW/GCC 4.6.1)

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

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

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

测试平台及软件说明

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

在这部分测试中，微软编译器在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中使用。

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

458.sjeng测试

语言：C

负载类型：整数

多线程：不支持

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

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

473.astar

语言：C++

负载类型：整数

多线程：不支持

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

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

SPEC性能测试之namd、lbm及sphinx3

444.namd

语言：C++

负载类型：浮点

多线程：支持

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

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

482.sphinx3

语言：C

负载类型：浮点

多线程：支持

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

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

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

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

TSCP

语言：C

负载类型：整数

多线程：不支持

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

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

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

汇编语言的影响：X264测试

cl base性能

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%的性能提升，你会责怪开发者选择了能给消费者最佳体验的那条路吗p>

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

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

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

阅读更多：

相关阅读：

文章知识点与官方知识档案匹配，可进一步学习相关知识C技能树首页概览114812 人正在系统学习中 相关资源：…跑步者,铁人三项运动员和教练的性能软件-其它代码类资源-CSDN…