带有“fastcall”调用约定的“内联”函数对性能的影响答案

【问题标题】：performance impact of "inline" function with "fastcall" calling convension带有“fastcall”调用约定的“内联”函数对性能的影响
【发布时间】：2012-07-05 21:36:39
【问题描述】：

我有一个 CRC 计算函数，它以极高的频率被调用。我已经声明为inline，我尝试将其设为__attribute((hot))__，但我不确定这是否能买到任何东西。我正在考虑将其设为fastcall。

根据gcc docs，

快速通话在 Intel 386 上，fastcall 属性使编译器在寄存器 ECX 中传递第一个参数（如果是整数类型），然后寄存器 EDX 中的第二个参数（如果是整数类型）。随后的和其他类型的参数在堆栈上传递。这被调用的函数会将参数从堆栈中弹出。如果数 arguments 是可变的，所有参数都被压入堆栈。

fastcall 会大大提高速度，因为输入参数将通过寄存器发送，而不是将它们推入堆栈。使用inline，编译器会将函数调用替换为函数体。

所以问题是fastcall 与inline 一起使用是否有意义？

【问题讨论】：

对于执行 CRC，我希望函数调用开销与执行 CRC 的函数内部的实际工作相比非常小（除非您正在计算极短的缓冲区数字节）。我假设您正在使用表查找算法。优化循环的内部比内联更有价值。
我正在使用 FNV-1a，它是一个很好的 CRC。我想进一步优化它以挤出 CPU 周期。
FNV 不是 CRC，而是可用于类似目的的哈希。 FNV 既快速又简单，但我仍然猜想，除非您的平均缓冲区长度非常小，否则您将从内联中获得可忽略不计的加速。
我使用 FNV 作为 CRC，它解决了我的目的。

标签： c compiler-construction inline fastcall

【解决方案1】：

如果你将你的函数设为inline，编译器会简单地将它“粘贴”到你写它的任何地方，正如你所说的。

因此，不会调用任何内容，因此使用 fastcall 将毫无意义。

【讨论】：

也许将调用约定设置为fastcall 可以让你在编译器不内联函数的情况下得到覆盖。
严格来说这不是真的。内联是编译器建议。根据标准，编译器不负责实际内联函数。因此，内联函数仍然需要调用约定。