VC++ 2K8 中 SSE 编码的内在函数与内联 ASM答案

【问题标题】：Intrinsics Vs inline ASM for SSE coding in VC++ 2K8VC++ 2K8 中 SSE 编码的内在函数与内联 ASM
【发布时间】：2010-04-01 16:12:50
【问题描述】：

我之前为 SSE 做过一些内联 ASM 编码，即使对于不了解 ASM 的人来说，这也不是太难。但我注意到 MS 还提供了包含许多此类特殊指令的内在函数。

是否存在特定的性能差异，或者有什么其他强有力的理由为什么应该在另一个之上使用一个？

重复标题，这是专门介绍 VC++ 2008 为非托管原生 C++ 公开的内在函数。

【问题讨论】：

【解决方案1】：

Visual C++ for x64 中没有内联汇编。内在函数也可以在 x64 上使用。如果您想将代码移植到 x64，则必须使用内部函数。

【讨论】：

【解决方案2】：

一般来说，使用内部函数会更好——它对程序员来说效率更高，一个好的编译器（例如 Intel ICC）在寄存器分配、指令调度等方面做得不错。微软编译器在这方面没有那么好，但是它可能仍然可以正常工作 - 如果您需要获得更好的性能，您可以随时切换到 ICC。

【讨论】：

生产力参数是内在函数的正确参数。对于大多数任务，生成的代码将足够好，以至于使用内在函数带来的生产力收益远比使用汇编带来的额外性能更有价值。确实，只有对性能至关重要的库和小部分才应该用汇编语言编写。

【解决方案3】：

内在函数与其等效的汇编指令相同，如果可能，您应该使用它们 - 编译器知道直接翻译它们，没有性能差异。

【讨论】：

真的一模一样？将数据移动到寄存器等等怎么样，这是否涵盖/相关？
我经常发现我可以编写比等效的 SSE 内在函数快约 2 倍的程序集，因为编译器会破坏寄存器分配和/或指令调度。也就是说，我每天都在写矢量代码。您的里程可能会有所不同。
@Stephen：您是否尝试过与英特尔 ICC 编译器进行比较？恕我直言，这很难打败，但我很想知道你是否能够用手工编码的汇编程序打败它？
@Paul R：对于相对简单的任务，ICC 通常比手写汇编更有竞争力。对于具有恒定寄存器压力的复杂算法，我发现我通常可以以很大的优势击败它（但是，ICC 生成输出所需的时间几乎没有我做的那么长）。
@Paul R：我在 32 位和 64 位代码中都看到了这一点（尽管在 32 位代码中肯定更常见）。在通过洗牌进行大量算法水平数据移动的情况下，我看到编译器（包括 ICC）偶尔会产生并非绝对必要的寄存器 - 寄存器移动（例如，可以通过仔细的指令重新排序来避免它们）。如果您已经处于使用所有寄存器的风口浪尖，这可能会导致一系列溢出，使加载/存储单元饱和并导致停顿。

【解决方案4】：

使用内在函数。

使用组装通常会导致几天不间断的工作，只是发现编译器比您的最佳性能高出 5%。（如果你真的很好，则为 5%；很可能为 30%。）

【讨论】：