英特尔编译器与GCC

我没有英特尔编译器的经验，所以我不能回答你是否缺少一些标志。

然而，根据我的回忆，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天的评估。