64位模式下处理32位值时的寄存器尺寸选择问题

在64位模式下执行32位操作时，结果通常会被零扩展至64位，因此后续指令无论使用32位寄存器还是64位寄存器，往往会得到相同结果。例如，当两个操作数均由已知的小数值零扩展而来、且求和结果不超过32位时，add rax, rdx与add eax, edx的执行结果一致。

在此类场景下，寄存器尺寸的选择是否会影响代码大小、性能或功耗（发热），还是完全没有差异？

我正在开发的部分性能敏感型代码中，多达四分之三的指令都可在两种寄存器尺寸间选择，且代码需要在所有可用核心上满负荷运行，因此希望能做出有依据的选择。

代码大小差异 #

• 32位寄存器指令的机器码更短：比如add eax, edx是2字节，add rax, rdx是3字节（多了一个48前缀来指定64位操作数）。如果你的代码里四分之三的指令都能选32位版本，整体二进制体积会明显缩小。更小的代码意味着更高的指令缓存命中率，这在性能敏感场景下能间接提升执行效率。

性能差异 #

1. 前端解码效率：短指令能让CPU在每个周期解码更多指令，缓解前端带宽瓶颈。尤其是当代码量较大、指令缓存压力高的时候，32位指令的优势会更突出。
2. 执行单元效率：对于add、sub、and这类基础算术逻辑操作，32位和64位版本的执行延迟、吞吐量完全一致——现代CPU的执行单元对两种宽度的操作处理效率相同。但乘法、除法这类复杂操作可能有差异：比如32位乘法结果存在edx:eax中，如果后续不需要高32位，32位乘法更省寄存器；如果需要完整64位结果，直接用64位乘法更直接，不用额外拼接。
3. 寄存器依赖问题：32位指令执行后会自动零扩展到64位寄存器，CPU的寄存器重命名机制能正确处理这种情况，不会产生额外的依赖链，所以不用担心因为选32位指令而拖慢流水线。

功耗与发热差异 #

• 单条指令的功耗差异极小：现代CPU的寄存器是全64位设计，32位操作并不会真的只激活一半电路。但代码体积缩小带来的缓存命中率提升，能减少CPU从内存读取指令的次数——内存访问的功耗远高于CPU内部操作，所以整体来看，用32位指令能间接降低功耗和发热。

总结 #

在你的性能敏感型代码中，优先选32位寄存器指令是更稳妥的选择：既能减小代码体积、提升缓存效率，又不会损失执行性能，还能间接降低功耗。只有当后续操作必须用到完整64位结果，或者某些指令的64位版本有明确性能优势时，再考虑用64位指令。

内容的提问来源于stack exchange，提问作者DarthGizka