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

想象一个只执行64位算术运算的CPU.现在想象一下如何在这样的CPU上实现无符号8位加法.为了得到正确的结果，它必然需要不止一次的操作.在这种CPU上，64位操作比其他整数宽度上的操作更快.在这种情况下，所有Xint_fastY_t可能都是64位类型的别名.

如果CPU支持窄整数类型的快速操作，因此较宽的类型不比较窄的类型快，那么Xint_fastY_t将(不应该)是较宽类型的别名，而不是表示所有Y位所需的别名.

出于好奇，我判断了一些体系 struct 上特定实现(GNU、Linux)的大小.在同一体系 struct 上的所有实现中，这些都不相同:

┌────╥───────────────────────────────────────────────────────────┐
│ 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  │
└────╨────────┴─────┴───────┴─────┴────────┴──────┴────────┴─────┘

请注意，尽管对较大类型的操作可能会更快，但此类类型也会占用更多缓存空间，因此使用它们不一定会产生更好的性能.此外，人们不能总是相信实现从一开始就做出了正确的 Select .一如既往，需要测量才能获得最佳结果.

表格截图，面向Android用户:

个

^{(Android在mono字体-ref中没有方框绘制字符)}