@
gnup 大清早的不想聊太多这种事情,累。
还是那句话,64位和32位比,不是比个浏览器比个魔兽就能解决问题的。
每个应用的情况都不一样。
比如32位程序因为有内存寻址模型影响,所以有2G的上限。
就算打开LAA大内存寻址,最大寻址空间也不能超过3G,因为3G以外的区域是内核保留的。
对于仅仅只有2G大小的内存空间来说,像山口山这样的程序就必须严格限制自己的内存消耗。
明明读取了一张图片或者一个材质,却因为顾及内存大小而不得不在稍后就清理掉以释放内存。
而对于64位的程序来说,内存空间可以用起来更轻松。
稍后还会用到的图片或者资源,就先在内存里放一下,反正就算整体内存占用超过2G也不会出问题。
这样虽然内存占用更大了,但是运行起来更流畅,延迟是更小。
山口山这种即时游戏,当然是运行效能越高越好。
浏览器里大量的图片、图层、javascript代码、flash广告,当然也是效能越高越好。
为了效能,多使用一些内存,就和ramdisk一样。要是这样就指责说占用内存过多,实在是冤枉了。
因此说64位的软件可以运行得更快,不只是纸上谈兵,是有实际依据的。
另外64位下可用的寄存器也更多。32位程序做64位计算的时候,必须要用到SSE指令集才能快速计算,否则就只能用32位计算来模拟,效率非常差。64位指令集加入了RAX等扩展寄存器,直接在寄存器上就可以做64位运算,节约了拷贝到SSE寄存器的时间,或是用32位计算来模拟的时间。
而且64位程序在编译的时候可以更好地利用编译器特性进行优化。例如现在很多Linux发行版里的32位程序都是基于i386编译,因为32位从20多年前的386就出现了。而64bit则可以直接对应现代处理器,例如P4或者速龙之后的版本,因此可以直接假定处理器会带有SSE指令集,也因此所有的可以并行的操作,都会去用SSE指令集来优化。例如memcpy,32位下为了兼容性可能只能逐字节复制,最多用MMX来优化(但是会和浮点数运算冲突),而64位下可以直接做MEM->XMMREG->MEM的批量复制,速度快得多。
对比以下代码
32位,i386兼容:
MOV EAX, [p]
MOV [q], EAX
一次复制4字节
64位,使用SSE:
MOVNTDQA XMM0, [p]
MOVNTDQA [q], XMM0
一次复制16字节
后者的性能至少是前者的2倍或者更多。
所以在同一个基准线上,64位的程序会运行得更快。