性能综述：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的普通应用一样，要记住不论是谁控制了虚拟机，终端才是控制每个架构性能的关键。