C 整数升级会影响64位性能吗？

以以下代码为例：

uint32_t fg;
uint32_t bg;
uint32_t mask;
uint32_t dest;
...
dest = (fg & mask) | (bg & (~mask));

现在这个片段的所有操作数都是32位无符号整数。使用具有32位int大小的C编译器，不会发生整数提升，因此整个操作是在32位中执行的

---

我的问题是，举例来说，即使是64位机器，通常也会有使用32位int大小的编译器。根据C标准，它们不会将操作数提升到64位整数，因此可能会编译成性能较差、甚至可能更大的代码大小（仅假设在32位x86上16位操作的周期和指令大小更昂贵）

首要的问题是：我需要担心吗？（我相信我可能不会，因为启用了优化后，一个理智的编译器可能会忽略严格遵循C标准时会出现的多余的问题。请看过去的示例代码，并总体思考我的信念可能没有多少根据的地方）

如果是这样的话（我真的不得不担心），你能推荐一些方法（书籍、网站等）来涵盖这个领域吗？（好吧，我知道这有点超出了范围，但是如果我只得到一个三个字的回答，我认为这没有多大用处。是的，你可以！作为接受的答案）

我一定要担心吗

不，不是真的。读取主内存或磁盘的成本降低，通常会抵消在64位寄存器中执行32位操作的额外成本。使用32位整数数组的64位程序通常比使用64位整数数组的程序快

---

同样，在编译时，优化大小往往比优化速度更好，因为缓存未命中的成本往往高于节省的cpu周期。

“仅假设在32位x86上16位操作的周期和指令大小更昂贵”，这是真的吗？@glglgl:Yes，由于指令上的操作数大小前缀而导致的额外大小，至少在较旧的奔腾上，需要额外的周期来处理（在这方面我没有检查较新的处理器）。@Jubatian您是在专门谈论x86-64体系结构，还是任何64位体系结构？@anatolyg:现在和这里可能主要是x86-64，而是为了跨平台而保持一般性。如果甚至在一个相当常见的体系结构（如ARM 64位）上也存在一些问题，那么值得一提。C中的

int

应该是该体系结构的“自然”操作数大小。在32位操作比64位操作耗时更长的体系结构上，

sizeof（int）*CHAR\u-bit

应该是

64

。也就是说，在x86-64上，默认操作数大小仍然是32位，而不是64位。因此，32位运算不需要操作数大小前缀，也不比64位运算慢；x86-64上的32位ALU操作（作为一个具体的例子）从根本上来说比64位的ALU操作慢吗？好吧，我在文章中错过了这些。对于那些类型的访问（主要是内存，在磁盘上，您通常需要符合文件格式），我总是计划结构并使用固定大小的类型。我对完全在ALU内部进行的操作相当好奇。