问为什么没有64位版本的VS2013？

EN

更新(2021年5月) Visual Studio2022将作为64位版本发布：https://visualstudiomagazine.com/articles/2021/04/19/vs-2022.aspx

原始答案(2013年12月)

首先，Visual Studio工具集附带了一个64位C++编译器。因此，您可以随时更改您的项目设置，以便根据需要构建应用程序的64位版本。

现在，来回答最初的问题。

从成本和ROI的角度来考虑。在微软多年的软件发布过程中，我看到了64位构建的考虑。

1. 当32位应用程序在64位上运行得很好时，考虑64位几乎是不可能的。

1. 微软的大多数项目都不是简单的Visual Studio小项目，在这些项目中，开发人员只需将项目设置从32位翻到64位即可。(实际上，我不知道Visual Studio团队是否使用VS项目编译Visual Studio。)它们通常有超过一百万行的代码，这些代码是使用VS编译器集构建的，但是是从命令行和Makefile环境构建的。切换到64位意味着要更新此构建infrastructure.

的大量内容

1. 从32位移植到64位是有成本的。第一个成本就是修复bug、编译代码、重新构建环境，以及所有的前期工作，仅仅是为了让初始构建运行起来。

1. 您需要为应用程序的32位和64位版本分别支付持续成本。您必须每天构建两次。你必须每天在上面运行两次测试抵押品。这不是2倍的费用，但也不是免费的。

1. 具有来自相同代码库更多SKU，这增加了开发人员在签入时破坏某些东西的机会。当然，可以使用自动化测试来防止这种情况，但这会减慢开发人员的速度，因为他必须返回并修复其他没有在测试计算机上本地安装的SKU。

下面是迁移到64位的一些动机：

1. 你真的需要利用64位的性能和内存架构。使用尽可能多内存的大型数据库服务器将受益于对32位Windows进程施加的超过2 2GB的访问限制。

1. 你需要集成一些已经用64位编译的东西。例如，如果要为Windows编写shell扩展，则需要64位版本才能在64位Windows上运行。这并不意味着必须移植整个应用程序，但它确实意味着该组件将需要单独的64位版本。

API您有一个平台或

• 可供外部开发人员考虑。通常，他们对64位构建有自己的需求。因此，即使您的原生应用程序可以获得32位支持，他们也可能需要您提供的64位就绪应用程序接口。

1. 你的团队刚刚被重新组织到视窗部门，你的团队的代码被认为有必要包含在下一个视窗版本中。不再需要做任何决定-您的代码将编译为32位、64位和ARM (Surface RT)。

源代码文件不应该有多as -文本编辑器/开发环境没有理由使用64位指针，因为64位指针会消耗两倍的RAM而没有任何好处。更大的指针使包含指针的数据结构更大，需要更多的内存带宽来移动它们，并且在CPU的数据高速缓存中容纳的更少，因此高速缓存未命中的数量也可能增加。

32位编辑器完全能够在需要时启动64位编译器、链接器和调试器并与之交互。只有一个32位的编辑器也大大简化了插件模型。

原因一如既往。将像Visual Studio这样大的代码库移植到64位需要付出巨大的努力，根据微软的说法，好处将是微乎其微的。

事实上，微软声称这样的端口可能会因为消耗更多的内存而减慢Visual Studio的速度。由于64位指针存储在代码中的不同位置，因此缓存局部性会较差。在VS中有很多使用基于自定义竞技场的分配器的代码，尽管微软正试图摆脱它们。这也可能导致较差的性能，因为竞技场中的指针管理将处理64位指针，这将占用当前32位对应指针的两倍空间。

考虑到Visual Studio的数千万行代码，转换、测试和调优64位版本的工作似乎充满了延迟，而获得积极结果的可能性似乎很小。如果有什么不同的话，那就是微软似乎更倾向于将Visual Studio移植到托管代码中，以便获得那里的好处--这是我们C++开发人员难以接受的决定。

就目前而言，Microsoft建议在64位版本的Windows中运行Visual Studio，从而使可用的地址空间加倍(2 GB到4 GB)，而不会对VS进程中的指针存储造成2倍的损失。