当我使用 Intel 编译器编译应用程序时，它比使用 GCC 编译它要慢。英特尔编译器的输出速度慢了 2 倍以上。该应用程序包含多个嵌套循环。 GCC 和我所缺少的 Intel 编译器之间有什么区别吗？我是否需要打开其他一些标志来提高英特尔编译器的性能？我预计 Intel 编译器至少和 GCC 一样快。
编译器版本：
英特尔版本 12.0.0 20101006 海湾合作委员会版本4.4.4 20100630
两个编译器的编译器标志相同：
-O3 -openmp -parallel -mSSE4.2 -Wall -pthread
我没有使用英特尔编译器的经验，所以我无法回答您是否缺少一些标志。
然而，根据我的记忆，最近版本的 gcc 在优化代码方面通常与 icc 一样好（有时更好，有时更差（尽管大多数来源似乎表明通常更好）），因此您可能会遇到 icc 特别擅长的情况坏的。有关每个编译器可以执行哪些优化的示例，请参阅此处和此处。 即使 gcc 通常不是更好，您也可能只是遇到 gcc 识别优化而 icc 不识别的情况。编译器可能对优化什么、不优化什么非常挑剔，尤其是在自动向量化等方面。
如果您的循环足够小，那么比较 gcc 和 icc 生成的汇编代码可能是值得的。此外，如果您显示一些代码或至少告诉我们您在循环中做了什么，我们也许能够为您提供更好的推测导致此行为的原因。例如在某些情况下。如果它是一个相对较小的循环，则很可能是 icc 缺少一个（或一些，但可能不是很多）优化，这些优化要么具有固有的良好潜力（预取、自动向量化、展开、循环不变运动……），要么启用其他优化优化（主要是内联）。
请注意，当我比较 gcc 和 icc 时，我只是在谈论优化潜力。最后，icc 通常可能会生成比 gcc 更快的代码，但不是那么多，因为它做了更多优化，而是因为它有更快的标准库实现，并且因为它更智能地优化哪里（在高优化级别上，gcc 得到了一点）过于热衷于（或者至少过去）为了（理论上的）运行时改进而交换代码大小，这实际上会损害性能，例如，当仔细展开和矢量化的循环仅执行 3 次迭代时。
-inline-level=1 -inline-forceinline
来确保我显式声明
inline的函数确实被内联。除此之外，我预计 ICC 性能至少与 gcc 一样好。您需要分析您的代码以了解性能差异来自何处。如果这是 Linux，那么我建议使用Zoom，您可以免费获得 30 天评估。