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

Why is there no 64-bit version of VS2013?

提问by Niklas

I downloaded Visual Studio 2013 from DreamSpark but it's the 32-bit version and I couldn't find any 64-bit version. Is there none, and if so why is there no 64-bit version of Visual Studio?

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

采纳答案by selbie

First, there is a 64-bit C++ compiler that comes with Visual Studio tool set. So you can always change your project settings to make 64-bit builds of your app as needed.

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

Now, to answer the original question.

现在，回答最初的问题。

Think of it from a cost and ROI perspective. From years of shipping software at Microsoft, here's how I've seen the consideration for 64-bit builds get made.

从成本和投资回报率的角度考虑。从 Microsoft 多年的交付软件中，以下是我如何看待 64 位构建的考虑。

1. When the 32-bit app works just fine on 64-bit, it's almost a non-starter to consider 64-bit.

2. Most of the projects at Microsoft aren't simple little Visual Studio projects in which the developer can just flip the Project settings from 32-bit to 64-bit. (I actually don't know if the Visual Studio team compiles Visual Studio with a VS project.) They are often well over a million lines of code that build with the VS compiler set, but from a command line and Makefile environment. Switching to 64-bit means updating a lot of this build infrastructure.

3. There is a cost of porting from 32-bit to 64-bit. The first cost is just fixing the bugs, getting the code to compile, restructuring the build environment, and all the upfront work just to get the initial build going.

4. There is an ongoing cost you pay for having separate 32-bit and 64-bit builds of an application. You have to build it twice every day. You have to run the test collateral on it twice every day. It's not a 2x cost, but it's not free either.

5. With more SKUs from the same code base, it increase that chances that a developer will break something when he checks in. Of course there can be automated tests to prevent this, but it will slow the developer down since he will have to go back and fix the other SKU that he doesn't have installed locally on his test machine.

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。

Now here are some of the motivations for moving to 64-bit:

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

1. You really need to take advantage of 64-bit performance and memory architectures. Large database servers that use as much memory as possible will benefit from accessing more than 2GB limit imposed on a 32-bit Windows process.

2. You need to integrate with something already compiled with 64-bit. For example, if you want to write a shell extension for Windows, you will need a 64-bit build to run on 64-bit Windows. That doesn't mean the entire app has to be ported, but it does mean this component will need a separate 64-bit build.

3. You have a platform or API story for external developers to consider. Usually, they have their own needs for 64-bit builds. Hence, they may need a 64-bit ready API from you even if your native app can get away with 32-bit support.

4. Your team has just been re-organized into the Windows division and your team's code has been deemed necessary to be included into the next Windows release. There's no decision to be made anymore - your code will be compiling for 32-bit, 64-bit, and ARM (Surface RT).

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) 进行编译。

回答by Ben Voigt

Source code files should not be multiple gigabytes -- there's no reason for a text editor / development environment to use 64-bit pointers, which consume twice as much RAM for no benefit. Larger pointers make data structures containing pointers larger, requiring more memory bandwidth to move them around, and fitting fewer inside the CPU's data cache, so that the number of cache misses may increase as well.

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

The 32-bit editor is perfectly capable of launching and interacting with the 64-bit compilers, linkers, and debuggers when needed. Having only a 32-bit editor also simplifies the plugin model greatly.

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

回答by Michael Goldshteyn

The reason is the same as it has always been. It would require a significant effort to port a code base as large as Visual Studio to 64-bit and according to Microsoft, the benefits would be few and far in between.

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

In fact, MS claims that such a port could slow down Visual Studio due to the consumption of more memory. There would be poorer cache locality due to 64-bit pointers being stored in various places in the code. There is much code in VS that uses custom arena based allocators, although MS is trying to get rid of them. These could also possibly result in poorer performance, since pointer management within the arena would deal with 64-bit pointers which would occupy twice the space of their current 32-bit counterparts.

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

Given the tens of millions of lines of code that are Visual Studio, the effort to convert, test and tune a 64-bit version seems fraught with delays while having a seemingly small chance of having a positive outcome. If anything, MS seems more intent on porting Visual Studio to managed code in order to reap the benefits present there - a decision that is hard for us C++ developers to swallow.

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

For the present term, Microsoft recommends running Visual Studio in a 64-bit version of Windows, thus doubling the available address space (2 GB to 4 GB) without paying a 2x penalty for pointer storage within the VS process.

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