64bit比32bit快是想当然了，多媒体指令集早都不是32bit的了，剩下的应用有多少能发挥64bit的大数据吞吐优势，别跟我说memcpy

64bit的劣势现在倒是很明显：浪费内存浪费硬盘。4g内存多寻址的那部分给64bit指针浪费掉还不够

64bit的cpu能直接寻址大于4g的空间，没有人会认为寻址空间全是内存的

引用:

原帖由 himula 于 2009-11-18 08:45 发表

这也不能一概而论啊，虽然目前win32下的程序都是以2G为标准的，但是能用4g的软件也不是没有啊~~~
何况，64为操作系统能寻址超过4G内存这是确实的啊~~~程序用不用那是另外一说~~~

用户进程看到的都是独立内存空间，讨论它用多少内存根本没意义。2g的意思是2的32次方总共4g的寻址空间里有2g是用户空间，另2g是内核空间，用户进程不能访问内核空间（被mmu设置了权限）。注意这4g是虚拟地址，当然2g对2g是windows的分法，linux默认是3g用户空间1g内核空间

2g的用户空间是每个进程都独享的，2g内核空间是所有进程所共有的，OK，理论上一个程序可以使用无限大的虚拟内存，只要开足够多的进程即可。用户进程所使用的每个byte内存都是存在于内核空间被映射的物理内存的page上的，由内核统一分配管理，粗俗点说用户进程看到的整个2g用户空间都是浮云

至于寻址超过4g的内存则是另一个概念，这里的内存指的是物理内存。另外物理地址上不可能把2的32次方全部用于映射内存，还有总线和各控制器的寄存器地址需要映射否则cpu无法访问外设，所以32bit的系统不可能用满4g的物理内存

引用:

原帖由 日霜衣 于 2009-11-28 21:41 发表

那么说到底，64位系统插上超过4g内存，用32位的软件，这软件能用上超过3g的内存吗？

首先，你对physical memory，virtual memory，address space，process的概念不清，user process无权过问physical memory，只有kernel mode下才能决定使用nonpaged pool还是paged pool

其次，你对“软件”的定义不明确，一个application可以有多个process，每个process有独立的2G user address space（一个32bit的process在windows默认设置下），想要allocate更多的内存只要多开进程就可以了，至于究竟最多可以allocate多少内存，这个问题电脑城的装机小工也知道和系统设置的paging file大小有关，paging file的大小加上available physical memory大致就决定了commit charge的多少（commit limit本身在windows中就是动态的，而且registry作为雷打不动的paged pool也会占掉一定的paging file），也就是系统同时可以分配出多少virtual memory

还不明白的话可以先看看扫盲的msdn:D

http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx

抛英文名词出来不是为了装逼，而是刻意提供关键字方便放狗搜罢了，勿怪

[ 本帖最后由 henvelleng 于 2009-11-29 02:25 编辑 ]

引用:

原帖由 himula 于 2009-11-29 15:55 发表

你说的这么专业，只能让不懂的人更不懂
一句话就解决了，想实实在在用到4G内存以上，就装64位windows~~~

某种程度上你说的没错，实际上内存3G以上就该考虑装64bit了，因为还要映射device memroy，特别是如今显存已经开始以G作单位的时候，装64bit的OS的确是最省事的方法。只能说，从这次灾难上我们可以得出这样的结论：在框架没有提供行之有效的规范限制的情况下要让程序员自觉遵守规范编写出普适性强而健壮的驱动现在看来的确是一件很难的事情。否则，我们只要简单地打开PAE（哦不，那时候微软早就会在xp sp2下默认打开pae了）就能在32bit下安全地使用64G或128G的物理内存了

果然，在搞不清物理内存，虚拟内存，寻址空间，进程空间的情况下，是没办法讨论的