我不确定是否应该在这里发布这个问题，因为这似乎是一个面向编程的网站。
无论如何，我认为必须有一些大师知道这一点。
现在我有一台运行CentOS 5的AMD Opteron服务器。我想为一个相当大的基于c ++ Boost的程序安装一个编译器。我应该选择哪种编译器？
答案 0 :(得分：25)
有一个有趣的PDF here比较了许多编译器。
答案 1 :(得分：19)
我希望这不仅有助于伤害：）
我在一年前的某个时候做了一个小编译器枪战，我要记忆了。
我测试了我写过的多个模板重音频信号处理程序。
编译时间：英特尔编译器是迄今为止编制速度最慢的编译器 - 超过另一篇文章引用的“慢2倍”。
与英特尔相比，GCC处理的模板非常好。
英特尔编译器生成了巨大的目标文件。
GCC + LLVM产生了最小的二进制文件。
由于程序的构造，以及可以使用SIMD的地方，生成的代码可能会有很大的差异。
对于我写作的方式，我发现GCC + LLVM生成了最好的代码。对于我在认真对待优化之前编写的程序（正如我所写），英特尔通常更好。
英特尔的结果各不相同;它处理的程序要好得多，有些程序要差得多。它很好地处理了原始处理，但我给了GCC + LLVM蛋糕，因为当它被放入更大（正常）程序的环境中时......它做得更好。
英特尔赢得了开箱即用，数据处理庞大的数据集。
单独使用GCC生成最慢的代码，尽管它可以通过测量和纳米优化来快速生成。我宁愿避免这些，因为风可能会随着下一个编译器的发布而改变方向，可以这么说。我从来没有在这个测试中测量写得不好的程序（即结果优于流行性能库的发行版）。
最后，这些程序写了几年，当时使用GCC作为主编译器。
更新：我还为Core2Duo启用了优化/扩展。程序足够干净，可以实现严格的别名。
答案 2 :(得分：15)
MySQL团队发布过一次，icc给了他们10％的性能提升。我会尝试找到这个链接。
总的来说，我发现'原生'编译器在各自平台上的性能优于gcc
编辑：我有点偏僻。典型的收益是20-30％而不是10％。一些窄边案例的性能翻了一番。 http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2004-Intel.pdf
答案 3 :(得分：6)
我认为它会因代码而异，但是我现在正在使用的代码库，ICC 11.035在Xeon 5504上比gcc 4.4.0提高了近2倍。
icc选项：-O2 -fno-alias
gcc选项：-O3 -msse3 -mfpmath=sse -fargument-noalias-global
这些选项仅适用于包含计算密集型代码的文件，我知道没有别名。具有5级嵌套循环的单线程代码。
虽然启用了自动向量化，但两个编译器都没有生成矢量化代码（不是编译器的错误）
更新（2015/02/27）： 在优化一些地球物理代码（Q2，2013）以在Sandy Bridge-E Xeon上运行时，我有机会将ICC 11.1与GCC 4.8.0的性能进行比较，而GCC现在生成的代码比ICC更快。该代码使用了AVX内在函数并且确实使用了8向量化向量指令（由于某些数据布局要求，编译器无法正确地自动向量化代码）。此外，GCC的LTO实施（嵌入在.o文件中的IR核心）比ICC更容易管理。使用LTO的GCC比没有LTO的ICC运行速度快大约3倍。如果没有LTO，我现在无法找到GCC的数字，但我记得它仍然比ICC更快。这绝不是关于ICC性能的一般性陈述，但结果足以让我们继续使用GCC 4.8。*。
期待GCC 5.0（http://www.phoronix.com/scan.php?page=article&item=gcc-50-broadwell）！
答案 4 :(得分：5)
我们在产品（DB2），Linux和Windows IA32 / AMD64以及OS X（即除SunAMD之外的所有英特尔平台端口）上使用英特尔编译器。
我不知道数字，但表现足够好，我们：
答案 5 :(得分：3)
PHP - 从源代码编译，使用ICC而不是GCC，可以使速度提高10％到20％ - http://www.papelipe.no/tags/ez_publish/benchmark_of_intel_compiled_icc_apache_php_and_apc
MySQL - 从源代码编译，使用ICC而不是GCC，可以使速度提高25％到50％ - http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2005-Intel.pdf
答案 6 :(得分：1)
我曾经在一个在大型集群上运行的相当大的信号处理系统上工作。我们曾经认为重型数学运算，英特尔编译器给我们的CPU负载比GCC少10％。这是非常不科学的，但这是我们的经验（大约18个月前）。
如果我们能够使用英特尔的数学库以及更有效地使用他们的芯片组，那将会是有趣的。
答案 7 :(得分：1)
我在openSUSE 12.2（内核3.4.33-2.24-默认x86_64）上使用UnixBench（v.5.1.3），先用GCC编译，然后用Intel编译器编译。
使用1个并行副本，使用Intel编译的UnixBench比使用GCC编译的版本快20％左右。 然而，这隐藏了巨大的差异。使用英特尔编译器，Dhrystone的速度降低约25％，而Whetstone的运行速度提高了2倍。
随着4个UnixBench并行运行，英特尔编译器相对于GCC的改进仅为7％。英特尔在Whetstone（> 200％）上的表现要好得多，在Dhrystone上的表现要慢一些（约20％）。
答案 8 :(得分：0)
英特尔编译器常规执行的许多优化都需要特定的源语法，并且对gcc使用-O3 -ffast-math。不幸的是，-ffast-math -O3 -march = native的-funsafe-math-optimizations组件已证明与-fopenmp不兼容，因此我必须将源文件拆分为使用Makefile中的不同选项命名的组。今天我遇到了一个失败，使用-O3 -ffast-math -fopenmp -march = native的g ++构建能够写入屏幕但不能重定向到文件。 在我看来，一个更令人震惊的差异是icpc仅对std :: max和min进行优化，其中gcc / g ++想要fmax | min [f]和-ffast-math来改变它们的含义，远离标准。