英特尔编译器真的比微软编译器好吗？[关闭]

多年前，当我发现英特尔销售与Visual Studio兼容的编译器时，我感到很惊讶。我特别针对C / C ++和出色的诊断工具进行了尝试。但是，代码根本就没有那么多计算量来注意到差异。唯一的印象是：英特尔真的为我真正做到了，哇，令人难以置信的纳秒分辨率的出色工具。但是审判结束了，团队从未认真考虑过购买。

根据您的经验，如果许可成本无关紧要，那么哪个供应商是获胜者？

引发一场圣战不是一个广泛或模糊的问题或动机。这种问题是关于两个非常明显的工具。没有人喜欢工具有任何神秘或惊奇之处。在最佳与最佳之间做出选择始终是痛苦。我也了解草总是绿色的说法。我想听听所有的“假设”故事。

如果Intel仅针对本月的芯片升级进行本地优化，而并非每个硬件目标都能像Microsoft编译的那样正常工作，该怎么办？如果目标是AMD硬件，而一切都会毫无原因地降低速度，该怎么办？或者，另一方面，如果英特尔的硬件拥有如此众多的机会，而微软的编译器编写者却太慢而无法采用，并且从未在编译器中实现它，该怎么办？如果两者完全相同，实际上是将单个代码库包装到两个不同的盒子中并由某个第三方商店授权给这两个供应商，该怎么办？

等等。但是有人知道一些答案。

警告：根据自己的经验回答-YMMV

如果代码确实在计算上很昂贵，那么肯定可以。与以前的Microsoft Visual C ++编译器相比，以前的Intel C ++编译器（如果我没记错的话，现在是Intel Studio）使我的性能提高了20倍以上。的确，代码远非完美，而且可能发挥了作用（实际上，这就是我们费心使用Intel编译器的原因，它比重构庞大的代码库更容易），并且用于运行代码的CPU是Intel Core 2 Quad，这是处理此类问题的理想CPU，但结果令人震惊。编译器本身包含无数种优化代码的方法，包括针对特定CPU的SSE功能。这确实使-O2/ -O3羞愧。那是在使用探查器之前。

但是请注意，启用真正激进的优化将使编译花费相当长的时间，对于一个大型项目来说，这根本不是两个小时。同样，通过高水平的优化，代码中更容易出现错误（这种情况也可以通过gcc观察到-O3）。对于一个您很了解的项目，这可能是一个加分，因为您会发现并修复您之前未发现的所有最终错误，但是在编译毛茸茸的烂摊子时，您只需交叉手指并向x86众神祈祷。

关于AMD的机器性能的东西：它并不像英特尔CPU一样好，但它仍然方式比微软的C ++编译器更好的（再次，从我的经验）。原因是您还可以将具有SSE2支持的通用CPU作为目标。这样，带有SSE2的AMD CPU就不会有太多区别。不过，英特尔CPU上的英特尔编译器确实抢了风头。但是，这并非全部都是双彩虹和闪闪发光的独角兽。已经有关于二进制文件不运行在所有非GenuineIntel CPU和（这一个被承认）人工诱导的性能差一些沉重的指责其他厂商的CPU。还要注意，这是至少3年前的信息，到目前为止，其有效性尚不清楚，但是新产品描述使二进制文件完全按英特尔认为适合非英特尔CPU的速度运行。

我不知道英特尔的含义，也不知道为什么它们制造如此出色的数值计算工具，但也可以看看以下内容：http : //julialang.org/。有一个比较，如果您看一下最后一行，MATLAB击败了C代码和Julia，使我大放异彩。令我震惊的是，作者认为原因是英特尔的Math Kernel Library。

我意识到这听起来很像是英特尔编译器工具包的广告，但以我的经验，它确实做得很好，甚至简单的逻辑也表明制造CPU的人应该最了解如何为其编程。IMO，Intel C ++编译器压缩了性能的最后每一点。

英特尔编译器享有生产非常高效的数字代码的声誉：

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_revisited/

请注意，我并不是说它是目前最快的编译器，但是它肯定以效率着称。请注意，用于Windows的“官方” LAPACK二进制文件的作者使用Intel Fortran编译器来构建它们：http : //icl.cs.utk.edu/lapack-for-windows/，他们应该对效率有所了解。

英特尔C ++除代码生成器外，还具有优于gcc的多个优点。这两者（很大程度上）源于它基于EDG前端的事实。不管是好是坏，这两者都在（逐渐）受到侵蚀，因此优势并没有以前那么大。

首先，它通常会发布更好的错误消息。您可能想看一下Clang和gcc之间的错误消息比较。多年来，英特尔C ++（以及其他大多数基于EDG前端的软件）一直在发布类似于Clang的诊断程序。

其次，EDG前端因其出色的语言一致性而闻名，就像英特尔代码生成器用于产生快速代码一样。通过几乎所有合理的措施，EDG前端比任何其他可用的编译器都能更好地满足C ++ 98、03或（当前版本）C ++ 0x的要求。

正如我所说，随着时间的流逝，这两个优势都在不同程度上受到侵蚀。最新版本的gcc具有相当不错的语言一致性。Clang具有更好的错误消息，并且在实现整个C ++语言方面也取得了良好的进展。但是，当您完全了解它时，英特尔C ++在这两个方面仍然比任何一个都要好，并且它是一个可以正确完成大多数事情的软件包，而不是需要一个编译器来进行良好的诊断，而需要一个编译器来进行更好的一致性和代码生成。

我们前一段时间在工作中尝试过。我们的大多数代码库都在Delphi中，但是我们拥有一些高度计算密集型的功能，有人认为这是回想C ++ DLL的好主意。我的一位同事听说了有关英特尔编译器的很棒的事情，因此他决定尝试一下。我们在Intel编译器中重建了DLL，并进行了一些速度测试，结果令他大吃一惊，以至于他认为他一定做错了什么。

DLL必须计算一些非常困难的组合和拓扑组件问题，如果我们“正确”地进行操作，则从技术上讲它们属于NP困难类，但是我们使用各种启发式方法来避免NP性能。即便如此，仍然有很多数字运算在进行。在我们进行的测试中，VS编译器与Intel编译器之间的差异要么在epsilon之内，要么Intel编译器明显更慢，通常在20％左右。不管他对编译设置进行了什么更改，以试图使Intel编译器生成更快的代码，它都保持不变。因此，我们最终没有切换到它。

当然，这只是一个真实的例子。你的旅费可能会改变。

在我曾经研究过的嵌入式应用程序中，对Intel编译器的试用表明，这将使我们不必旋转性能更高的新硬件。新硬件的成本约为每台10美元，预计销售100万台，增加了开发成本和项目延误。选项2是配置文件/微优化，已经合理地配置文件/优化的代码库-未知结果，未知时间。

当我们要求资金购买编译器时，老板怎么说？

但是，这是一种非常幸运和罕见的优势案例，英特尔编译器的代码输出速度提高了10％，使我们回到了性能的正确方面。如果我们已经在右边，或者超过10％，那不会有什么不同。如果我们拥有工程师，我们可能可以优化代码并节省硬件成本，并且不需要Intel编译器，但是风险很高，并且Intel编译器的成本比工程时间便宜。

总而言之，我会说这是微优化的一种形式-除非您知道需要，然后再进行概要分析并找到问题的实际原因，然后再执行。这是一个非常好的选择，您的个人资料表明您“到处都是”缓慢且没有确定的瓶颈。

我只遇到了三个优点：

1. 它比其他编译器更快地支持较新的Intel CPU的功能。

2. 这是一个很棒的附加编译器，它可以发出警告并捕获其他编译器遗漏的问题。GCC捕获了ICC无法捕获的某些内容，反之亦然。Visual Studio捕获了ICC无法捕获的某些内容，反之亦然。

3. 自动并行化循环（自动将它们分配到多个线程上）比其他任何编译器的工作要好得多。这样做并不会带来太多的代码好处，但是当您有这样做的代码时，它可能会有所作为。

我们将intel编译器用于我们代码库的每个性能关键项目。很棒的事情是，它使优化代码真正可维护。无需在任何地方手动添加__mm调用，并告诉编译器预取数据（在下一发行版中所有这些都将再次变为次优），您只需重新排列代码并获得疯狂的加速即可。

通常，经过优化的代码比经过手工优化的代码更易于遵循，比经过手工优化的代码更快速，并且当发布新的指令集时，编译器将使用该指令集。这是梦幻般的。

对于arm编译器（从arm而不是intel）也是如此，如果您在arm上释放，则可以在向量化方面做得很好。

检查此基准页面。简而言之，英特尔胜出。

但是余量可能不会那么大：如果编译为32位，并且您的构建系统无法支持配置文件引导的优化，则收益约为10％。这样的改进值得麻烦和更长的编译时间吗？

据说英特尔已经发布了适用于Android操作系统的英特尔C ++编译器v13.0，这是其首次尝试提供专门针对Google移动平台设计的优化C / C ++编译器。

开发人员可以在基于Linux *的系统上使用编译器为基于Intel处理器（包括Intel®Atom™处理器）的Android设备创建应用程序。英特尔编译器与GNU C ++和Android本机开发工具包（NDK）中的开发人员工具兼容。您也不能仅在任何开发计算机上使用该编译器。Windows和OS X均不受支持。这些工具仅经过认证可用于Ubuntu 10.04或11.04

当前，Android NDK的当前版本默认使用开源Gnu编译器集合（GCC）工具链的4.6版。但是，英特尔的编译器对自己的芯片进行了许多专有的优化，并且通常可以输出性能比第三方编译器（如GCC）更好的可执行代码。