我应该多么担心英特尔 C++ 编译器为 AMD 生成次优代码？

Question

我们一直是英特尔商店。所有开发人员都使用 Intel 机器，向最终用户推荐的平台是 Intel，如果最终用户想在 AMD 上运行，那就要注意了。也许测试部门有一台 AMD 机器来检查我们没有运送任何完全损坏的东西，但仅此而已。

直到几年前，我们还只是使用 MSVC 编译器，并且由于它并没有真正提供超出 SSE 级别的大量处理器调整选项，因此没有人太担心代码是否可能更青睐某个 x86 供应商而不是另一个供应商。然而，最近我们大量使用英特尔编译器。我们的产品肯定会从中获得一些显着的性能优势（在我们的英特尔硬件上），并且其矢量化功能意味着更少需要使用 asm/内在函数。然而，人们开始有点担心英特尔编译器是否真的无法为 AMD 硬件做好工作。当然，如果您进入 Intel CRT 或 IPP 库，您会看到大量 cpuid 查询，显然是为了设置优化函数的跳转表。不过，英特尔似乎不太可能费尽心思为 AMD 芯片做任何好事。

有这方面经验的人可以评论一下这在实践中是否有什么大不了的吗？（我们自己还没有对 AMD 进行过任何性能测试）。

更新2010-01-04: ：嗯，支持 AMD 的需求从未变得具体到足以让我自己进行任何测试。关于这个问题有一些有趣的读物 这里, 这里 和 这里 尽管。

更新2010-08-09: ：英特尔与 FTC 的和解似乎对这个问题有话要说 - 请参阅《编译器和肮脏技巧》部分 本文.

Answer 1

购买一个AMD框和上运行它。这似乎是唯一负责的事情，而不是在互联网上的信任陌生人;）

除此之外，相信AMD的针对英特尔诉讼的部分是基于Intel的编译器具体产生低效运行在AMD处理器代码的要求。我不知道这是否是真还是假，但AMD似乎认为如此。

不过，即使他们不故意这样做，但毫无疑问，英特尔的编译器针对英特尔处理器，并没有别的特别优化。

在那说，我怀疑它会产生巨大的变化。 AMD的CPU仍然会受益于所有的自动向量化和编译器的其他功能巧妙

Answer 2

我们所看到的是，无论英特尔编译器必须做出运行时的选择有关可用指令集，如果它不承认的英特尔CPU，它会在自己的“标准”代码（如你所期望的那样，可不是最佳的）。

请注意，即使我用了“编译”以上，这主要发生在它们的供给（预编译）库和检查指令集和调用最好的代码。内在

Answer 3

我肯定说明明显，如果性能是你的应用是至关重要的，那么你最好做一些测试 - 硬件/编译器的所有组合。有没有保证。作为局外人，我们只能给你我们的猜测/偏见。您的软件可能具有完全不同于我们所看到的独特的特点。

我的经验：

我曾经在英特尔工作，并开发在性能是至关重要的一个内部的（C ++）的应用程序。我们试图采用英特尔C ++编译器，它的总是下进行GCC - 甚至做曲线运行，使用异型信息（ICC理应用来优化）和重新编译上完全相同的数据集重新运行后， （这是在2005- 2007年，东西现在可能有所不同）。所以，根据我的经验，你可能会想尝试GCC（除了ICC和MSVC），很可能你会得到更好的性能，这种方式和侧步的问题。它不应该太硬切换的编译器（如果您的构建过程是合理的）。

现在我在不同的公司工作，而IT人员做广泛的硬件测试，并且有一段时间Intel和AMD硬件相对可比性，但显著Intel最新一代的硬件外执行的AMD。因此，我相信他们购买的显著大量英特尔CPU，并推荐为我们的客户谁运行我们的软件是相同的。

不过，回到了一个问题，英特尔编译器是否专门针对AMD硬件运行缓慢。我怀疑英特尔与困扰。这可能是因为使用有关Intel的CPU架构或芯片组的内部知识某些优化可以运行在AMD硬件慢，但是我怀疑他们特异性靶向AMD硬件

Answer 4

抱歉，如果您按下了我的通用按钮。

这是低级优化的主题，因此仅对以下代码重要：1）程序计数器花费大量时间，2）编译器实际看到的代码。例如，如果 PC 将大部分时间花费在您不编译的库例程中，那么这应该不会有太大影响。

无论条件 1 和 2 是否满足，以下是我的优化过程的经验：

进行了多次采样和修复迭代。在每个问题中，都会识别出一个问题，但大多数情况下，问题与程序计数器的位置无关。相反，由于性能至关重要，因此可以替换调用堆栈中层的函数调用。 为了快速找到他们，我这样做了。

请记住，如果有一条函数调用指令在执行时间的很大一部分时间内位于堆栈上，无论是在几次长调用中，还是在许多短调用中，该调用都会占用该部分时间，因此删除少执行或少执行可以节省大量时间。而且，这种节省远远超过任何低级优化。

该程序现在可以 多次 比开始时更快。我从未见过任何大型程序，无论编写得多么仔细，都不能从这个过程中受益。如果该过程尚未完成，则不应假设低级优化是加速程序的唯一方法。

当这个过程完成到根本无法再完成的程度之后，如果样本显示 PC 处于编译器看到的代码中，那么低级优化可以产生影响。

Answer 5

在这个线程开始的时间，微软C ++默认为代码生成这在某些情况下，AMD好的和坏的英特尔。其最近的编译器默认这是很好的两个，尤其是在这两个品牌的CPU已经摸索出其独特的性能缺陷的混合选项。 当我第一次曾在英特尔，他们的编译器保留用于英特尔架构的具体设置一些优化。我想这可能是一些FTC沉积的话题，虽然它没有拿出我10小时证词，和实践已经在路上了，由于最新的CPU型号和之间的优化要求收敛需要更多的生产使用的编译器的开发时间。 如果你在使用这些过时的编译器的一个最新的英特尔CPU，您可能会看到一些相同的性能缺陷的。

Answer 6

这是毫无意义的担心，如果你不会演戏。可能的操作是：不买AMD，或者使用不同的编译器。所以显而易见的事情要做的：

（1）购买一个AMD中，并测量与Intel编译器编译的代码的速度。它是速度不够快？如果是的话，你就大功告成了，可以买AMD的，不用担心。

（2）如果没有：编译用不同的编译器的代码，并在AMD框运行它。它是速度不够快？如果没有，你就大功告成了，你可以不买AMD，不用担心。

（3）如果是：运行在Intel盒相同的代码。它是速度不够快？如果是的话，你就大功告成了，你可以购买AMD，但必须切换编译器，不用担心。

（4）如果没有：可能性是：不要购买AMD，扔掉所有的英特尔电脑出来，或者用两个不同的编译器进行编译。选一个。

Answer 7

我直接经历技术的目的性瘫痪当供应商试图阻止Lotus产品从发行前到达市场。一个工作的技术是可用的，但莲花禁止使用。啊...

几年前，有网友认为表明用户是在修补英特尔编译器一个字节导致它发出了AMD使用时并没有削弱“最优”的代码。我没有看过那些博客条目年。

我倾向于认为，这种竞争的行为仍在继续。我没有其他证据提供。