我们一直是英特尔商店 . 所有开发人员都使用英特尔机器，最终用户的推荐平台是英特尔，如果最终用户希望在AMD上运行，那就是他们的了望 . 也许测试部门有一台AMD机器在哪里检查我们没有运送任何完全损坏的东西，但那是关于它的 .
直到几年前我们才使用MSVC编译器，因为它并没有真正提供超出SSE级别的许多处理器调优选项，所以没有人担心代码是否有利于一个x86供应商而不是另一个 . 但是，最近我们一直在使用英特尔编译器 . 我们的东西肯定会从它（在我们的英特尔硬件上）获得一些显着的性能优势，它的矢量化功能意味着更少需要去asm / intrinsics . 然而，人们开始对英特尔编译器是否真的不能为AMD硬件做得如此出色而感到有些紧张 . 当然，如果你进入英特尔CRT或IPP库，你会看到很多cpuid查询显然设置了跳转表到优化的函数 . 看起来英特尔不太可能为AMD芯片做任何好事 .
任何有此领域经验的人都可以评论这在实践中是否是一个大问题？ （我们还没有真正对AMD进行任何性能测试） .
Update 2010-01-04 ：支持AMD的需要从来没有变得足够让我自己做任何测试 . 关于这个问题有一些有趣的读物here，here和here .
Update 2010-08-09 ：英特尔 - 美国联邦贸易委员会的解决方案似乎有关于这个问题的说法 - 请参阅"Compilers and Dirty Tricks"的"Compilers and Dirty Tricks"部分 .
7 回答
买一个AMD盒子并运行它 . 这似乎是唯一负责任的事情，而不是信任互联网上的陌生人;）
除此之外，我认为AMD对英特尔的部分诉讼是基于英特尔编译器专门 生产环境 在AMD处理器上运行效率低下的代码的说法 . 我不知道这是不是真的，但AMD似乎也这么认为 .
但即使他们没有故意这样做，毫无疑问，英特尔的编译器专门针对英特尔处理器进行了优化，而不是别的 .
说到这一点，我怀疑它会产生巨大的影响 . AMD CPU仍将受益于编译器的所有自动矢量化和其他聪明功能 .
我们所看到的是，无论英特尔编译器必须对可用指令集进行运行时选择，如果它无法识别英特尔CPU，它就会进入“标准”代码（正如您所料，可能不是最佳代码） ） .
请注意，即使我使用上面的“编译器”一词，这主要发生在它们提供的（预编译的）库和内在函数中，它检查指令集并调用最佳代码 .
我肯定会说明显而易见的，如果性能对您的应用程序至关重要，那么您最好对硬件/编译器的所有组合进行一些测试 . 没有保证 . 作为局外人，我们只能给你猜测/偏见 . 您的软件可能具有与我们所见不同的独特特征 .
我的经验：
我曾经在英特尔工作，并开发了一个内部（C）应用程序，其中性能至关重要 . 我们尝试使用英特尔的C编译器，并且在执行配置文件之后 always - 甚至在执行配置文件运行后，使用配置文件信息重新编译（icc据称用于优化）并在完全相同的数据集上重新运行（这是在2005-2007 ，现在可能会有所不同） . 所以，根据我的经验，你可能想尝试gcc（除了icc和MSVC），它很难切换编译器（如果你的构建过程是合理的） .
现在我在一家不同的公司工作，IT人员进行了广泛的硬件测试，并且有一段时间英特尔和AMD的硬件相对可比，但最新一代的英特尔硬件显着优于AMD . 因此，我相信他们购买了大量的英特尔CPU，并为运行我们软件的客户推荐相同的产品 .
但是，回到英特尔编译器是否专门针对AMD硬件运行缓慢的问题 . 我怀疑英特尔对此感到困扰 . 使用有关英特尔CPU架构或芯片组内部的知识的某些优化可能会在AMD硬件上运行得更慢，但我怀疑它们是否专门针对AMD硬件 .
对不起，如果你点击我的常规按钮 .
这是关于低级优化的主题，所以它只对1）程序计数器花费很多时间的代码很重要，2）编译器实际看到的 . 例如，如果PC将大部分时间花在您不编译的库例程中，那么它应该无关紧要 .
无论条件1和2是否满足，这是我对优化如何进行的体验：
完成了几次采样和修复迭代 . 在每一个中，问题是确定并且通常不是关于程序计数器的位置 . 而是在调用堆栈的中间级别存在函数调用，因为性能是最重要的，所以可以替换 . To find them quickly, I do this.
请记住，如果堆栈中有一个函数调用指令执行的时间相当长，无论是在几次长调用还是很多短调用中，该调用都要负责这段时间，所以删除它或不经常执行它可以节省大量时间 . 并且，这种节省远远超过任何低级优化 .
该程序现在可以比开始时快许多倍 . 我从来没有见过任何大小合适的程序，无论多么精心编写，都无法从这个过程中受益 . 如果尚未完成该过程，则不应假设低级优化是加速程序的唯一方法 .
在完成此过程后，它无法再进行，如果样本显示PC处于编译器看到的代码中，则低级优化可能会有所不同 .
在这个线程启动时，Microsoft C默认代码生成，这在某些情况下对AMD有利，对英特尔有害 . 他们最近的编译器默认使用混合选项，这对两者都有好处，特别是在两个品牌的CPU都解决了他们特有的性能错误之后 . 当我第一次在英特尔工作时，他们的编译器保留了针对英特尔特定架构设置的一些优化 . 我想这可能是一些FTC证词的主题，虽然它在我的10个小时的证词中没有出现，并且由于最新CPU模型和最新CPU模型之间的优化要求的融合，这种做法已经走了出来 . 需要更有效地利用编译器开发时间 . 如果您在最新的Intel CPU上使用其中一个过时的编译器，您可能会看到一些相同的性能缺陷 .
如果你不能采取行动，那就无所谓了 . 可能的操作是：不购买AMD，或使用不同的编译器 . 所以明显的事情是：
（1）购买一个AMD盒子，并测量用英特尔编译器编译的代码的速度 . 它足够快吗？如果是的话，你已经完成了，你可以购买AMD，不用担心 .
（2）如果否：用不同的编译器编译代码并在AMD框上运行它 . 它足够快吗？如果没有，你已经完成了，你不能买AMD，不用担心 .
（3）如果是：在英特尔盒子上运行相同的代码 . 它足够快吗？如果是的话，你已经完成了，你可以购买AMD，但必须切换编译器，不用担心 .
（4）如果否：可能性是：不要购买AMD，抛弃所有英特尔计算机，或使用两个不同的编译器进行编译 . 选一个 .
当供应商试图阻止Lotus产品在其产品发布之前进入市场时，我直接经历了有目的的技术瘫痪 . 有一种工作技术可供使用，但Lotus禁止使用它 . 呃，好吧...
几年前，有一些博客向用户表示，修补英特尔编译器中的单个字节会导致它发出“最佳”代码，而这些代码在AMD上使用时并未瘫痪 . 多年来我没有找过那些博客文章 .
我倾向于相信这种竞争行为仍在继续 . 我没有其他证据可以提供 .