长久以来，开发者们都在询问为何 Visual Studio 没有切换到 64 位。问题的主要原因是性能，而非是精力或是机会成本。
这种说法似乎有悖常理，但是从 32 位切换到 64 位未必会获得提升。当能够存取更多的 CPU 寄存器时，主有益于对在大型数组中进行繁重数字运算的应用程序。对 Visual Studio 这类在大型、复杂数据结构中工作的应用程序而言，64 位指针的开销远超更多寄存器所带来的收益。微软的 Rico Mariani解释道，
指针越大，对齐边界越大，数据越稀疏，等效代码也越大。我们就这样将鸡肋的信息融入高速缓存行、代码或是数据，并因此降低了缓冲区命中率。一切，是的，一切都会受到影响。因为处理器缓存并没有增加。系统中其他程序也会受到影响，即使运行的代码没有发生变化。反正我们并不需要额外的内存。除了减速，我们一无所获。
他继续说道，
大多数 Visual Stduio 并不需要，也无法受益于 4G 以上的内存。即使有程序包真的需要这么大的内存，也可以用自己的 64 位进程建立，并且能够无缝集成到 VS 中无需为其余的部分付费。这在 VS 2008 中就已经可能了，也许更早。硬把所有的 VS 拖进 64 位的世界中，而无视它们的挣扎喊叫，并没有什么太大的意义。
这并不是说无法改善 Visual Studio。但 Rico Mariani 认为，解决方案应当是如何减少 VS 使用的内存，而非给它更多。
现在，如果我们有某个程序包需要 >4G 数据，并且还有一个数据访问模型要求以超级常用的接口随时对这些数据进行访问，这种情况下诸如 SendMessage 这样的函数是无法完成工作的，此时我认为重新考虑存储模型会获得巨大的收益。
VS 的空间中有大量的罪犯。我最喜欢投诉语言服务，它在我的整体解决方案中臭名昭著，会加载大量数据，而仅仅提供智能感知中的一小部分功能。但这好像自从 2010 年后就没有改变过。我常告诫 VS 组织的人们去考虑解决方案中如果有 10k 个项目（显示存在的）或 50k 份文件（也是真实存在的）时，系统应该如何应对。对我来说，将数据全部加载到内存中的方案不太妥当。但如果我们真的、不开玩笑的、有不能节约利用的存储空间，还一定要将数据常驻内存，那么还是将数据从进程中分离开来，放入一个 64 位的程序包中比较好。
再回到更多寄存器的问题，Rico 补充道。
事实也证明了，额外的寄存器对于 VS 这种交互式应用没什么帮助，比如它不会有大量频繁的计算密集型循环。并且当命中 L1 时，载荷出栈的性能如此之好，可与寄存器媲美——除了指令编码的长度更糟一些。但其实 64 位指令编码的长度也好不到哪里去……
所以，没错，见仁见智【你可能不会这么想】，主要是和对计算引擎的显著提升相比，更多的寄存器对于大型应用的作用微乎其微。
这一立场在 16 位应用程序切换为 32 位时饱受批评。但在 90 年代中后期，开发者普遍到处倡导这一转变有益。“既然这样，为什么我们无法从 64 位的切换中获取同样的收益呢？”，这个问题经常被问到。在后续的一篇标题为64 位的 Visual Studio——“超级 64”位参数的文章中，他解释了区别。
很明显，在有大容量硬盘和可交换内存的前提下，我们编写的任何 32 位寻址的程序都能够创建为 16 位的方式（特别是疯狂 x86 段的问题）。但是这么做能够得到优秀的代码么？能够体验到非凡的工程成本么？我们是在硬件的斗争上耗费大量的时间还是做各有意义的事情？在这种情况下，人们自然想到了非常酷的方式，十分经济地解决了某些问题，因为他们有了内存压力和经济动机这么做。这些是伟大的发明。但在某些方面也是一种疯狂。这种为完成任务而不得不编写的 16 位代码就只有丑陋而已。
这里，我的假设就不成立了。这些情况下，它不是相同的代码了。16 位代码迟钝、丑陋 [哔！] 以可怕的方式在内存受限的环境中运行，而 32 位代码则优美简洁，在卓越的算法下，能够直接完成它需要做的工作。因此，相同的代码编码后体积越大运行越慢的现象其实是无关紧要的。它并不是相同的代码！并且众所周知，卓越的算法即便使用更多的内存，也要优于低劣的算法——即使它们更节约内存或代码大小。
这一课适用于我们编写的绝大多数应用程序。如果当某人正在编写计算引擎或者只能历经磨难手动交换内存，切换到 64 位可能有益。但是大多数情况下，保留 32 位并减少内存的消耗，将会对应用程序和操作系统所构成的整体产生更大的影响。
注册/登录 InfoQ 发表评论