为什么快速整数类型比其他整数类型快？

Question

在 ISO/IEC 9899:2018 (C18) 中，它在 7.20.1.3 下说明：

7.20.1.3 最快的最小宽度整数类型

1 以下每种类型都指定了一个整数类型，在所有至少具有指定宽度的整数类型中，该类型通常是最快的²⁶⁸⁾。

2 typedef 名称int_fastN_t指定宽度至少为 Nuint_fastN_t的最快有符号整数类型。 typedef 名称指定宽度至少为 N的最快无符号整数类型。

3 需要以下类型：

int_fast8_t, int_fast16_t, int_fast32_t, int_fast64_t, uint_fast8_t, uint_fast16_t, uint_fast32_t,uint_fast64_t

此表格的所有其他类型都是可选的。

---

²⁶⁸⁾不保证指定的类型在所有用途中都是最快的；如果实现没有明确的理由选择一种类型而不是另一种，它只会选择一些满足符号和宽度要求的整数类型。

---

但是没有说明为什么这些“快速”整数类型更快。

• 为什么这些快速整数类型比其他整数类型快？

  ---

_{我用 C++ 标记了这个问题，因为在 C++17 的头文件中也可以使用快速整数类型cstdint。不幸的是，在 ISO/IEC 14882:2017 (C++17) 中没有关于它们的解释的这样的部分；我已经在问题正文中以其他方式实施了该部分。}

---

信息：在 C 中，它们在stdint.h.

Answer 1

想象一个只执行 64 位算术运算的 CPU。现在想象一下如何在这样的 CPU 上实现无符号 8 位加法。要获得正确的结果，必然会涉及多个操作。在这样的 CPU 上，64 位操作比其他整数宽度上的操作快。在这种情况下，所有Xint_fastY_t可能都是 64 位类型的别名。

如果 CPU 支持窄整数类型的快速操作，因此较宽的类型并不比较窄的类型快，那么Xint_fastY_t将不会（不应该）是比表示所有 Y 位所需的更宽类型的别名。

出于好奇，我检查了某些架构上特定实现（GNU、Linux）的大小。这些在同一架构上的所有实现中并不相同：

??????????????????????????????????????????????????????????????????
? Y  ?   sizeof(Xint_fastY_t) * CHAR_BIT                         ?
?    ?????????????????????????????????????????????????????????????
?    ? x86-64 ? x86 ? ARM64 ? ARM ? MIPS64 ? MIPS ? MSP430 ? AVR ?
??????????????????????????????????????????????????????????????????
? 8  ? 8      ? 8   ? 8     ? 32  ? 8      ? 8    ? 16     ? 8   ?
? 16 ? 64     ? 32  ? 64    ? 32  ? 64     ? 32   ? 16     ? 16  ?
? 32 ? 64     ? 32  ? 64    ? 32  ? 64     ? 32   ? 32     ? 32  ?
? 64 ? 64     ? 64  ? 64    ? 64  ? 64     ? 64   ? 64     ? 64  ?
??????????????????????????????????????????????????????????????????

请注意，虽然对较大类型的操作可能更快，但此类类型也会占用更多缓存空间，因此使用它们不一定会产生更好的性能。此外，人们不能总是相信实现首先做出了正确的选择。与往常一样，为了获得最佳结果，需要进行测量。

表格截图，适用于安卓用户：

^{（Android 没有单色字体中的框绘图字符 - ref）}

Answer 2

它们不是，至少不可靠。

快速类型只是常规类型的 typedef，但是如何定义它们取决于实现。它们必须至少达到要求的尺寸，但也可以更大。

确实，在某些体系结构上，某些整数类型比其他整数类型具有更好的性能。例如，早期的ARM实现具有针对 32 位字和无符号字节的内存访问指令，但它们没有针对半字或有符号字节的指令。半字和有符号字节指令是后来添加的，但它们的寻址选项仍然不太灵活，因为它们必须硬塞到备用编码空间中。此外，ARM 上的所有实际数据处理指令都是针对字进行的，因此在某些情况下，可能需要在计算后屏蔽掉较小的值才能给出正确的结果。

然而，缓存压力也存在竞争问题，即使加载/存储/处理较小的值需要更多的指令。如果它减少缓存未命中的数量，较小的值可能仍然表现得更好。

许多常见平台上的类型定义似乎没有经过深思熟虑。特别是，现代 64 位平台往往对 32 位整数有很好的支持，但“快速”类型在这些平台上通常是不必要的 64 位。

此外，C 中的类型成为平台 ABI 的一部分。因此，即使平台供应商发现他们做出了愚蠢的选择，以后也很难改变这些愚蠢的选择。

忽略“快速”类型。如果您真的关心整数性能，请使用所有可用大小对您的代码进行基准测试。

Answer 3

快速类型并不比所有其他整数类型快——它们实际上与某些“普通”整数类型相同（它们只是该类型的别名）——无论哪种类型恰好是持有值的最快的至少有那么多位。

它只是平台相关的每个快速类型是哪个整数类型的别名。