当移动到64位时,内存使用可能增加多少?

您可能会看到额外的对齐在这里和那里花费了一些额外的字节。由于操作数中有64位常量,代码可能会更大。

至于速度,您可能会遇到由于内存使用增加而导致的速度减慢。CPU缓存将更快地填满。

我已经看到了从x86到X64的显著的速度优势,因为X86的寄存器比X64体系结构少得多。编译器利用额外的寄存器来更好地优化代码。我看到同样的硬件加速了15%。

正如你所指出的,指针会变大。取决于处理器体系结构,因此 ints 和/或 longs . 字符串应该保持相同的大小,但为了提高效率,在内存中的对齐方式不同。通常,64位边界上数据结构的内存对齐在大多数情况下会导致碎片增加。

此外,进程地址空间(在许多体系结构中)可能会大得多,堆栈帧指针出现在高内存中(并向下增长),但由于这些都是虚拟内存指针,因此应用程序使用的实际物理内存通常要小得多。

在一些情况下,您可以保存内存。实际的代码在某些地方可能会短一些,因为由于寄存器数量的增加,需要更少的加载/存储。例如,默认的调用约定在寄存器中传递参数。

总的来说,64位应用程序可能会使用 一点 比32位内存多。但这不会破坏交易。

根据体系结构,代码也可以增长。全局变量和常量通常通过绝对地址引用(由程序加载器重新定位),这些引用在64位模式下为64位。在X64上,有一个针对64位常量的显式MOV指令,因此程序将只增加常量的大小。跳转和调用指令也可能变得更大,但这取决于编译器和链接器的许多参数。在其他架构上,情况可能更糟。例如,在SPARC上,从32位到64位可以使代码显著增长。由于SPARC没有可以加载超过22位的指令,因此在加载全局变量或常量的32位地址时,它需要2条指令,要加载64位常量,它甚至需要5条具有3个寄存器的指令。通过增加寄存器压力,编译器经常会错过优化机会,使代码比需要的要大得多。