服务器软件现在只有64位(自从Server 2008 R2 for
Windows,甚至更早的Exchange和Sharepoint),甚至Ubuntu都在推动您从服务器操作系统的32位版本.
但有没有任何好的,可量化的理由来维持32位桌面操作系统？我们正在准备我们的Windows 8图像(不幸的是)少数将成为早期采用者.
我们的大多数台式电脑都有4GB或更少的RAM,但我不想再打扰支持32位风格的操作系统了.
我应该有什么理由？
在某些使用情况下,> 32位可能稍快一些 – 较小的地址意味着代码更紧凑,这意味着更高的缓存效率.在我看到的基准测试中,64位在重度计算环境中的计算效率更高,这种效率往往会被黯然失色.但实际上32位确实偶尔会赢得一些基准测试.因人而异.软件的时代很重要,因为较新的版本利用了旧版本不具备的64位内容.
>更紧凑的代码意味着更少的磁盘空间.只需下载64和32位风格的最喜欢的操作系统的ISO,就可以看到差异.这不是微不足道的.一旦你解压缩二进制文件,它也会更多.正如OrangeDog所指出的那样：大部分空间消耗来自于64位操作系统除了64位操作系统之外还提供32位库.
>您仍然可以与32位的传统组件和软件更好地兼容.这在主机上动态编译但同时引入第三方二进制库的系统中尤为明显.微软的.NET框架就是一个很好的例子：虽然这些程序在理论上与架构无关,但只要你链接到本机二进制文件,你就会绑定到一个或另一个.许多开发人员甚至不知道这种情况正在发生,并且运送生产组件将无法在64位系统上运行而无需进行一些调整以明确指示.NET以32位模式运行.大多数人不知道该怎么做.
>正如Daniel B所指出的那样：在64位计算机上进行Windows .NET开发会使您对 frustrating inconsistency开放,在某些情况下,操作系统会屏蔽异常.
>传统硬件.您无法在64位内核上运行32位驱动程序.
>更紧凑的代码意味着更少的磁盘空间.只需下载64和32位风格的最喜欢的操作系统的ISO,就可以看到差异.这不是微不足道的.一旦你解压缩二进制文件,它也会更多.正如OrangeDog所指出的那样：大部分空间消耗来自于64位操作系统除了64位操作系统之外还提供32位库.
>您仍然可以与32位的传统组件和软件更好地兼容.这在主机上动态编译但同时引入第三方二进制库的系统中尤为明显.微软的.NET框架就是一个很好的例子：虽然这些程序在理论上与架构无关,但只要你链接到本机二进制文件,你就会绑定到一个或另一个.许多开发人员甚至不知道这种情况正在发生,并且运送生产组件将无法在64位系统上运行而无需进行一些调整以明确指示.NET以32位模式运行.大多数人不知道该怎么做.
>正如Daniel B所指出的那样：在64位计算机上进行Windows .NET开发会使您对 frustrating inconsistency开放,在某些情况下,操作系统会屏蔽异常.
>传统硬件.您无法在64位内核上运行32位驱动程序.
对于大多数人来说,这些都不会成为一个阻碍.但是,您必须决定这些因素如何影响您的环境.
