MS 为什么只让32位server版本搞支持4G内存
是效率差还是别的什么？为什么不让vista, win7 32 bit也支持。在内存如此白菜的今天。 本帖最后由 tonyunreal 于 2009-8-17 07:31 编辑因为没有必要吧，横竖一个32位应用程序只能用到2G物理内存
32位服务器上也基本只有数据库在用大内存 因为你用不到4G
32位服务器通过PAE最多可以支持64G-128G 我........我们要5开魔兽下副本！
对于vista来说2G足够了，win7也是，不过……现在新出的游戏随便一占就1个G的内存，何来用不到。。 PAE对于MS的个人系统来说本来就不是啥好的解决方案，首先设备驱动上MS就无法很顺利的推广。
一个没有按照MS相关PAE规范编写的声卡驱动就能让系统蓝屏，想象一下成千上万的设备和相关驱动。
非MS系统，用PAE方式支持超大内存。最关键的前提条件就是，平台相对封闭，设备数量有限。
如果哪天某个linux也有和现在XP一样的支持率，那默认情况下它也不敢开PAE。 坚守32位是没有意义的 操作系统什么时候大举普及到64,也是说不准的事 套用大猫的话
支持64需要多写30%的编码
当然 支持多核的话编码还要更多 个人系统内核全部64位化，同时兼容32位。这是否意味着安全性在一个时期内，比如两年左右大幅提高：写威胁系统内核的病毒和木马需要多写30%的代码，但非恶意程序就32位就可以了，大厂全面64位化。
我是觉得，硬件厂商靠广告宣传硬件性能来糊弄用户的伎俩快玩不下去了。我用PSCS4在win764bit上加4g内存快到飞起，而cpu仅仅是2180。而就在几个月前我还在发帖问配一台可以流畅运行PSCS4的机器配置。小厂软件无所谓效率，大厂软件如果真到了瓶颈那就直接放64bit上，软件怎么也得买，硬件要和软件一起换那怎么也不甘心。 喂死他和7可以用readyfor4GB
好像64驱动不用重新写一样
Elisha 发表于 2009-8-17 19:19 http://bbs.saraba1st.com/images/common/back.gif
你的理解能力让人失望，楼主纠结的只是“为何微软个人操作系统在PAE上不给予官方支持”。64位驱动需不需要重新写，和楼主讨论的问题有何关系？你觉得是让微软要求某个国内山寨厂出的设备重新写个完全支持PAE的驱动比较现实？还是推X64成为主流后想要上去的写个64位驱动比较现实？
微软给出的解决方案就是直接X64，即科学又合理。你要是有更科学合理的方案，在这和我扯什么皮，直接写信给微软。 WIN 7是最后
还有发行32bit版本的windows了
早点改了吧
这绝对不是我说的
我的原话是：相同的源代码，编译出x64的binary比x86大约大30%，由此对cache和取指令带来的副作用可能会抵消x64带来的性能提升。
HyperIris 发表于 2009-8-17 10:28 http://bbs.saraba1st.com/images/common/back.gif
那我记错了
反正如果想支持多核 就要多写代码是肯定的 个人系统内核全部64位化，同时兼容32位。这是否意味着安全性在一个时期内，比如两年左右大幅提高：写威胁系统内核的病毒和木马需要多写30%的代码，但非恶意程序就32位就可以了，大厂全面64位化。
我是觉得，硬件厂 ...
sakerping 发表于 2009-8-17 09:29 http://www.saraba1st.com/images/common/back.gif
CS4原来在64下快很多啊 我试试去！
CS4原来在64下快很多啊 我试试去！
RPG-7 发表于 2009-8-17 23:04 http://bbs.saraba1st.com/images/common/back.gif
即使不是在64下也是在win7下。bridge里操作的感觉就跟windows资源管理器一样快。 坚守32位是没有意义的
宅男的爱 发表于 2009-8-17 09:07 http://bbs.saraba1st.com/images/common/back.gif
做x64最用心的恰恰是对64位最不起劲的Intel, MS和PC专属的自动桌等等一干人马，您不觉得很讽刺么
程序资源多有时也是累赘，Linux的多层权限放到Windows上来就变成了人人骂的UAC, 要是为了安全降级到power user估计一半的程序都要挂。NT6开始为了解决这个问题把程序配置文件集中存放，很多人还有意见。。。
我吐槽的是这句话，谢谢
Elisha 发表于 2009-8-17 22:30 http://bbs.saraba1st.com/images/common/back.gif
这句有何歧义？微软不可能靠自身在个人系统上推广符合PAE要求的驱动。一旦用户添加无法符合要求的设备和相关驱动后出现问题，难道再让用户把PAE关了？
Intel是被AMD64轮了很久才回过味，把重心从从安腾转移到x64
想当年，微软的全部文档都叫AMD64，后来才改成x64。
HyperIris 发表于 2009-8-18 10:16 http://bbs.saraba1st.com/images/common/back.gif
Server2008 R2之前的64位服务器操作系统都是AMD64
问题是没有x64的软件，用x64系统跑32位程序等于是毫无意义的挂虚拟机，AMD和linux玩x86-64那么多年说白了就是在瞎折腾 Rambus正好赶上操作系统换代到XP,内存容量需求猛增，死的活该。
lixianglover 发表于 2009-8-18 12:22 http://bbs.saraba1st.com/images/common/back.gif
i845换回廉价量足的SDRAM,搭配带宽欲求不满P4性能烂得一塌糊涂，那段时间Intel很没面子，比Netburst的垮掉的时候还要难堪
再烂也比搭配低容量rambus内存桌面体验要好。
lixianglover 发表于 2009-8-18 12:30 http://bbs.saraba1st.com/images/common/back.gif
贪便宜买了P4 1.6和华硕T2P4的受害者路过，性能也就是图拉丁赛扬那个水准，升级的时候主板还是要换
什么叫瞎折腾，服务器和家用平台完全是两回事。
服务器上64位软件普及远早于家用平台。
04年之前oracle就有AMD64的版本了。
lixianglover 发表于 2009-8-18 12:07 http://bbs.saraba1st.com/images/common/back.gif
楼上也有人说了，能用到大内存的也只有数据库服务器，现在某些工作站也需要大内存，这个范围之外的需要完全可以通过PAE实现，何必多折腾
x64需要多个环节支持，在大部分应用上只会造成性能下降，只不过现在普遍的情况是性能过剩，感觉不明显罢了
x64 架构64位下运行32位代码不需要任何硬件上的虚拟化，是纯粹的原生支持，仅需要操作系统做一些额外的工作。
HyperIris 发表于 2009-8-18 12:54 http://bbs.saraba1st.com/images/common/back.gif
WoW64说是子系统，其实我觉得更接近VM一点，IA64如果不计效率一样可以通过WoW64模拟x86， pae分页机制原来是蹩脚的解决方案啊，pae在奔腾pro上就已经做了，能想出pae这种兼容方案的人很神，实际上intel一路搞兼容方案搞过来，每一次拿出的方案都很神。结果最后搞不妥协的安疼时就马上就吃瘪了233
pae不改变两级页表大小（还是4k），只是把虚拟地址中两极页表偏移位从10位都缩为9位，多出来的两位作为新引入的PDPT的偏移，这样就需要3级页表转换。由于10位缩成9位，这样在同样4k大小里原本的4byte * 1024项变成了8byte * 512项，两级页表都从32位变成64位，但仍保持4k大小不变。所以每个进程还是只能看到4g，只是内核可以通过改变PDPT基址和入口来寻址64g的地址空间
开关pae修改的幅度和32bit到64bit的升级是不能比的，而且64bit升级使得应用层的程序也要修改甚至可能重写（如果一开始框架没做好），x64下能运行32bit应用程序没错，前提是先有32bit的运行库，而且在64bit下编译的程序也是64bit的，想以32bit来编还要32bit的库（这个要实现很麻烦，通常还是直接用传统的交叉编译方法了） 64bit缺点很明显的就是浪费内存，原本32bit情况下，mmu开小页模式，每个page是4k，64bit下我不知道每个page是多大，但过大的page无疑会使mmu映射的细粒度严重下降，加大内存管理上的难度，内存碎片变得更加频繁，而另一方面dma等硬件设备仍然需要物理上连续的内存空间，恩…… 服务器当然乐于这种空间换时间的买卖，而且服务器还就是偏重于大规模复杂运算，个人用户情况不同，没有必要跟风
进程哪需要那么大的寻址空间，用户进程不需要，内核进程整个stack还要和自己的pcb分享一个page，在32bit系统下，一个pcb就占1.7k，想想吧，当然动态分配内存是没有上限的
PAE还是洗洗睡吧，这个技术从来都只是一个蹩脚的解决方案。
服务器和家用平台不一样的是，软件完全可以根据应用环境的需求特化，所以64bit的普及比家用平台快的多。
现在工作站级应用软件64bit版本性能已经明显强 ...
lixianglover 发表于 2009-8-18 12:44 http://www.saraba1st.com/images/common/back.gif
64位果然棒！
页:
[1]