28

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

直到几年前，我们还只使用了 MSVC 编译器，因为它并没有真正提供很多超出 SSE 级别的处理器调整选项，所以没有人担心代码是否会偏向一个 x86 供应商而不是另一个供应商。然而，最近我们一直在使用英特尔编译器。我们的东西肯定会从中获得一些显着的性能优势（在我们的英特尔硬件上），它的矢量化能力意味着更少需要去 asm/intrinsics。然而，人们开始对英特尔编译器是否实际上可能没有为 AMD 硬件做得这么好感到有点紧张。当然，如果您进入英特尔 CRT 或 IPP 库，您会看到很多 cpuid 查询显然设置跳转表以优化功能。不过，英特尔似乎不太可能为 AMD 芯片做任何好事。

在这方面有任何经验的人可以评论这在实践中是否重要吗？（我们自己实际上还没有对 AMD 进行任何性能测试）。

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

2010-08-09 更新：似乎 Intel-FTC 的解决方案对这个问题有话要说 - 请参阅本文的“编译器和肮脏技巧”部分。

4

7 回答 7

17

买一个 AMD 盒子并在上面运行它。这似乎是唯一负责任的事情，而不是信任互联网上的陌生人；）

除此之外，我认为 AMD 对英特尔的诉讼的一部分是基于英特尔的编译器专门生成在 AMD 处理器上运行效率低下的代码的说法。我不知道这是否属实，但 AMD 似乎相信如此。

但即使他们不故意这样做，毫无疑问，英特尔的编译器专门针对英特尔处理器进行了优化，仅此而已。

话虽如此，我怀疑它会产生巨大的影响。AMD CPU 仍将受益于编译器的所有自动矢量化和其他巧妙功能。

于 2009-05-08T13:10:17.400 回答
5

我肯定会说显而易见的，如果性能对您的应用程序至关重要，那么您最好在硬件/编译器的所有组合上进行一些测试。没有任何保证。作为局外人，我们只能给你我们的猜测/偏见。您的软件可能具有与我们所见不同的独特特征。

我的经验：

我曾经在英特尔工作，并开发了一个性能至关重要的内部 (C++) 应用程序。我们尝试使用 Intel 的 C++ 编译器，但它总是表现不佳 - 即使在运行配置文件后，使用配置文件信息重新编译（icc 据称用于优化）并在完全相同的数据集上重新运行（这是在 2005-2007 年） ，现在情况可能有所不同）。因此，根据我的经验，您可能想尝试 gcc（除了 icc 和 MSVC），这样您可能会获得更好的性能并回避这个问题。切换编译器应该不会太难（如果你的构建过程是合理的）。

现在我在另一家公司工作，IT 人员进行了广泛的硬件测试，有一段时间英特尔和 AMD 的硬件相当，但最新一代的英特尔硬件明显优于 AMD。因此，我相信他们购买了大量的英特尔 CPU，并向运行我们软件的客户推荐相同的 CPU。

但是，回到英特尔编译器是否专门针对 AMD 硬件运行缓慢的问题。我怀疑英特尔会为此烦恼。某些使用有关英特尔 CPU 架构或芯片组内部知识的优化可能会在 AMD 硬件上运行得更慢，但我怀疑它们专门针对 AMD 硬件。

于 2009-05-08T17:08:54.410 回答
5

我们所看到的是，无论英特尔编译器必须对可用指令集做出运行时选择，如果它不能识别英特尔 CPU，它就会进入他们的“标准”代码（正如您所料，这可能不是最佳的） ）。

请注意，即使我在上面使用了“编译器”这个词，这也主要发生在它们提供的（预编译的）库和检查指令集并调用最佳代码的内部函数中。

于 2010-01-05T17:02:46.067 回答
2

对不起，如果你按了我的通用按钮。

这是关于低级优化的主题，因此仅对 1) 程序计数器花费大量时间和 2) 编译器实际看到的代码很重要。例如，如果 PC 将大部分时间花在您不编译的库例程中，那么它应该不是很重要。

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

进行了几次采样和修复迭代。在这些中的每一个中，都会发现一个问题，并且通常与程序计数器的位置无关。而是在调用堆栈的中层存在函数调用，由于性能至关重要，因此可以替换它们。为了快速找到它们，我这样做了。

请记住，如果有一个函数调用指令在堆栈上的大部分执行时间，无论是在几个长调用中还是在许多短调用中，该调用都对那部分时间负责，因此删除它或不经常执行它可以节省大量时间。而且，这种节省远远超过任何低级优化。

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

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

于 2009-05-11T11:51:21.613 回答
2

在此线程启动时，Microsoft C++ 默认使用代码生成，这在某些情况下对 AMD 有利而对 Intel 不利。他们最近的编译器默认使用对两者都有好处的混合选项，特别是在两个品牌的 CPU 都解决了它们特有的性能错误之后。当我第一次在英特尔工作时，他们的编译器为英特尔特定的架构设置保留了一些优化。我想这可能是一些 FTC 证词的主题，尽管在我 10 小时的证词中没有出现，而且由于最新 CPU 模型和需要更高效地利用编译器开发时间。如果您在最新的 Intel CPU 上使用这些过时的编译器之一，您可能会看到一些相同的性能缺陷。

于 2016-02-10T00:45:30.487 回答
0

如果你不能采取行动，那么担心是没有意义的。可能的措施是：不购买 AMD，或使用不同的编译器。所以显而易见的事情是：

（1）买一台AMD盒子，用Intel编译器测一下代码编译的速度。速度够快吗？如果是，你就完成了，你可以购买 AMD，别担心。

(2) 如果否：使用不同的编译器编译代码并在 AMD 机器上运行。速度够快吗？如果没有，你就完了，你不能买 AMD，别担心。

(3) 如果是：在 Intel 机器上运行相同的代码。速度够快吗？如果是，你就完成了，你可以购买 AMD 但必须切换编译器，不用担心。

(4) 如果不是：可能的情况是：不要购买 AMD，将所有 Intel 计算机扔掉，或者使用两种不同的编译器进行编译。选一个。

于 2014-07-14T15:02:27.200 回答
-1

当供应商试图阻止 Lotus 产品在他们提供之前进入市场时，我直接经历了有目的的技术瘫痪。有一种可行的技术可用，但 Lotus 被禁止使用它。呃，好吧...

几年前，有一些博客向用户展示，在英特尔编译器中修补单个字节会导致它发出在 AMD 上使用时不会被削弱的“最佳”代码。我已经好几年没有寻找那些博客条目了。

我倾向于相信这种竞争行为仍在继续。我没有其他证据可以提供。

于 2015-09-29T22:17:26.387 回答