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

Question

我从DreamSpark下载了Visual Studio 2013，但它是32位版本，我找不到任何64位版本。是否有，如果是，为什么没有64位版本的Visual Studio？

Answer 1

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

现在，回答原来的问题。

从成本和投资回报率的角度考虑它。从微软多年的发货软件来看，我已经看到了64位构建的考虑因素。

1. 当32位应用程序在64位上工作正常时，考虑64位几乎不是首发。

2. Microsoft的大多数项目都不是简单的小型Visual Studio项目，开发人员可以将项目设置从32位翻转到64位。 （我实际上不知道Visual Studio团队是否使用VS项目编译Visual Studio。）它们通常是使用VS编译器集构建的超过一百万行代码，但是来自命令行和Makefile环境。切换到64位意味着更新大量的构建基础架构。

3. 从32位移植到64位的成本。第一个成本只是修复错误，获取编译代码，重构构建环境，以及所有前期工作只是为了让初始构建进行。

4. 您需要为使用单独的32位和64位版本的应用程序付出代价。你必须每天建两次。你必须每天两次运行测试抵押品。这不是2倍的成本，但它也不是免费的。

5. 使用来自相同代码库的更多SKU，会增加开发人员在办理登机手续时破坏某些内容的机会。当然，可以通过自动化测试来防止这种情况发生，但这会降低开发人员的速度，因为他将不得不返回并修复他未在测试机器上本地安装的其他SKU。

现在有一些转向64位的动机：

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

2. 您需要与已经使用64位编译的内容集成。例如，如果要为Windows编写shell扩展，则需要64位版本才能在64位Windows上运行。这并不意味着必须移植整个应用程序，但它确实意味着该组件需要单独的64位构建。

3. 您有一个平台或API故事供外部开发人员考虑。通常，他们对64位版本有自己的需求。因此，即使您的本机应用程序可以获得32位支持，它们也可能需要64位就绪API。

4. 您的团队刚刚重组为Windows部门，您的团队代码被视为必须包含在下一个Windows版本中。没有决定再做 - 你的代码将编译为32位，64位和ARM（Surface RT）。

Answer 2

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

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

Answer 3

原因与以往一样。将Visual Studio大到64位的代码库移植到64位需要付出巨大的努力，而且根据微软的说法，它们之间的好处很少。

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

鉴于Visual Studio的数千万行代码，转换，测试和调整64位版本的努力似乎充满了延迟，同时看似很小的机会获得了积极的结果。如果有的话，MS似乎更倾向于将Visual Studio移植到托管代码以获得其中带来的好处 - 这个决定对于我们C ++开发人员来说难以接受。

对于本学期，Microsoft建议在64位版本的Windows中运行Visual Studio，从而将可用地址空间（2 GB到4 GB）加倍，而不会在VS进程内为指针存储支付2倍的代价。