64位的Visual Studio Code相对于32位版本有哪些量化的好处？

Question

我不是硬件专家，但我知道微软拒绝了64位版本的Visual Studio请求，称64位版本性能不佳。

我认为两者之间有两个显而易见的明显区别，一个是代码库。其中一个从1997年开始，人们可能认为这意味着Visual Studio方面有更多的负担，更少的机会拥有非常现代的应用程序架构和代码，这可能会使它更难，也可能会构建一些无法适用于64位的32位程序？我不知道。

另一方面，Visual Studio Code是一个现代的Electron应用程序，这意味着它基本上只编译HTML、CSS和JavaScript。我打赌制作Visual Studio Code的版本几乎没有障碍，尽管性能可能不是非常明显的东西，但为什么不呢？

P.S.

我仍然想了解哪些方面可以在性能上改进，以及是否对开发人员来说这种改进可以忽略不计。您知道的任何其他信息或有趣的事实都很好，我希望有尽可能多的信息，并将使用任何未提及的硬性事实更新问题。

- Eric Bishard

---

我认为有必要提到这篇博客文章，我想你已经阅读过了：https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-visual-studio-the-pro-64-argument/ - Simon Mourier

我认为这篇文章https://www.infoq.com/news/2016/01/VS-64-bit 更加有用和信息量丰富，而且我相信它对原始问题给出了很好的答案。 - Stephan

Answer 1

64位的Visual Studio Code的存在主要是因为Node.js和Chromium基于Electron支持32位和64位架构，而不是应用程序的主要设计目标。微软使用Electron开发了VS Code，这是一个用于使用Web技术构建桌面应用程序的框架。

由于Electron已经包含了两种架构（以及不同操作系统的运行时），VS Code可以很少的额外工作提供两个版本——Electron将机器之间的差异抽象出来，从JavaScript代码中隐藏了这些细节。

相比之下，微软将Visual Studio的大部分内容作为包含特定于机器的指令的编译二进制文件进行分发，重写和维护64位源代码的成本历史上超过了任何好处。通常情况下，如果一个64位程序不超过32位系统的限制，那么对最终用户来说，它并没有明显的速度优势。Visual Studio的IDE shell并没有做太多的重活——在典型的工作流程中，大部分昂贵的处理都是由集成的工具链（编译器等）执行的，这些工具链通常支持64位系统。

考虑到这一点，我们从运行64位版本的VS Code中注意到的任何好处类似于使用64位Web浏览器所看到的好处。最显著的是，64位版本可以访问超过4 GB的内存，如果我们需要同时打开很多文件或非常大的文件，或者使用许多繁重的扩展程序时，这可能很重要。因此-对于我们开发人员来说最重要的是-当被滥用时，编辑器不会耗尽内存。

虽然听起来像是值得签署的保险政策，即使我们从未达到那些内存限制，但请记住，64位应用程序通常比它们的32位对应物消耗更多的内存。如果我们希望占用更小的内存空间，则可能希望选择32位版本。大多数开发人员可能永远不会遇到那个4 GB的壁垒。

在极少数情况下，如果我们使用包装为特定体系结构构建的DLL等本机代码的扩展程序，则可能需要选择32位或64位版本。

使用VSCode 64位版本时，我们经历的任何其他后果（积极或消极）都取决于Electron底层运行时组件的版本和它们运行的操作系统。随着开发的进展，这些特性不断变化。因此，很难以一般方式陈述32位或64位版本优于其他版本。

例如，V8 JavaScript引擎在历史上禁用了一些在今天启用的64位系统上的优化。某些优化仅在操作系统提供相关功能时才可用。

未来在 Windows 上的 64 位版本可以利用 地址空间布局随机化 来提高安全性（地址空间中的更多位数增加了熵）。

对于大多数用户来说，这些细微差别并不重要。选择与您系统架构匹配的版本，并仅在遇到问题时切换。编辑器的更新将继续为其基础组件带来优化。如果资源使用是一个重要考虑因素，则您可能不想首先使用 GUI 编辑器。

- Cy Rossignol

Answer 2

4年后的2021年，你现在拥有：

来自Mary Jo Foley的"Microsoft的Visual Studio 2022将转向64位"。

它参考了Amanda Silver，开发者部门产品CVP发布的官方出版物 "Visual Studio 2022"。

Visual Studio 2022是64位的

Visual Studio 2022将成为一个64位应用程序，不再受限于主devenv.exe进程中的约4GB内存。在Windows上使用64位的Visual Studio，即使是最大、最复杂的解决方案，也可以打开、编辑、运行和调试，而不会因为内存不足而停止。

虽然Visual Studio正在转向64位，但这并不改变您使用Visual Studio构建的应用程序的类型或位数。Visual Studio将继续是构建32位应用程序的优秀工具。

我发现观看这个视频非常令人满意，因为Visual Studio扩展了可用于64位进程的额外内存，打开了一个包含1600个项目和约300k个文件的解决方案。
希望以后不再出现内存不足的异常。

- VonC

Answer 3

我在Windows上的工作经验不多，但我曾与x86、x64和ARM（32位和64位指令集大小）处理器进行过交互。基于我的经验，在编写64位格式的代码之前，我们会思考：我们真的需要64位大小的指令吗？如果我们的操作可以在32位内完成，那么我们为什么需要另外的32位呢？

可以这样想：你有一个带有64位地址和64位数据总线以及64位大小寄存器的处理器。你程序中几乎所有的指令都需要最大32位。你会怎么做？我认为现在有两种方式：

1. 创建一个64位版本的程序，并在64位处理器上运行所有的32位指令。（每个指令周期浪费32位或处理器，将程序计数器填充到比当前地址4个字节更远的地址）。你的应用程序/程序本来可以在256MB的RAM上执行，现在却需要512MB，因此正在运行的RAM上的其他程序或进程将受到影响。

2. 将程序格式保持为32位，并将2个32位指令组合推入64位处理器进行执行。

显然，使用相同的资源，第二种方法将运行得更快。

但是，如果你的程序包含更多真正具有64位大小的指令；例如处理4K视频（64位处理器和64位指令集更好）或执行带有高达15个小数位精度的浮点运算等，则最好创建64位程序文件。

简而言之：尽量编写紧凑的软件，并充分利用硬件。

到目前为止，我已经阅读了这里，这里和这里；我知道VS的大多数组件只需要32位指令大小。

希望能解释清楚。

谢谢。

- Manoj

---

除了没有真正回答问题外，这个答案传播了错误的信息（我不知道谁觉得这值得悬赏）：在x86上的64位与32位（我相信对于ARM也是如此）与指令大小几乎无关（x86指令的长度本来就是可变的）- 改变的是指针大小。到目前为止，我还没有看到任何一个应用程序在为x64编译时内存消耗或平均指令长度是x86模式下的两倍（别让我开始谈浮点部分）。 - MikeMB

“浮点运算，精度高达15位小数”与64位指令无关。x86也可以实现，并且支持SIMD指令。32位的x86和32位的ARM的主要缺点是地址范围和寄存器数目较小。您错误地将32位和64位识别为指令大小，这是严重错误的。 - phuclv

“which could have been executed in 256 MB of RAM now requires 512 MB”是另一个严重的错误信息。64位程序中类型的大小仍然相同，除了指针、long或long long之外，并且除非您使用大量指针，否则增加的大小是很小的。如果需要这样做，请保持程序格式为32位并将2个32位指令组合成要推送到64位处理器中的指令。“单指令多数据（SIMD）”甚至更好。您可以在单个AVX指令中同时对8个32位值进行操作，在AVX512中为16个。 - phuclv