写点什么

Rico Mariani 对 Visual Studio 不是 64 位的解释

  • 2016-02-26
  • 本文字数:1762 字

    阅读完需:约 6 分钟

长久以来,开发者们都在询问为何 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 位并减少内存的消耗,将会对应用程序和操作系统所构成的整体产生更大的影响。

查看英文原文: Rico Mariani on Why Visual Studio Isn’t 64-bit

2016-02-26 18:003679
用户头像

发布了 36 篇内容, 共 14.6 次阅读, 收获喜欢 2 次。

关注

评论

发布
暂无评论
发现更多内容

Walgreens商品详情API接口的开发应用与收益

科普小能手

数据分析 爬虫 跨境电商 API 接口 API 测试

鸿蒙Flutter性能调优之性能分析定界

flfljh

阿里云大模型矩阵:千问&Qwen解锁多元智能

测吧(北京)科技有限公司

测试

从单一领域到系统级仿真与优化:Altair在消费电子产品设计中的应用

Altair RapidMiner

制造 仿真 altair Hypermesh jabra

Capture One Studio for Mac中文直装 专业RAW照片处理软件

小玖_苹果Mac软件

如何成功养成一个TikTok账号?

Ogcloud

TikTok tiktok运营 TikTok养号 tiktok起号

天翼云全栈混合云应用场景

天翼云开发者社区

云计算 混合云 天翼云

自动化测试AI智能体:掌握AI,人人都是自动化测试工程师

测吧(北京)科技有限公司

测试

Aseprite for Mac 专业的像素艺术与动画制作工具

小玖_苹果Mac软件

Capture One 23 Pro for Mac专业RAW照片处理利器

小玖_苹果Mac软件

出海电商的关键:原生IP的重要性解析

Ogcloud

海外原生IP 海外IP 海外直播IP 原生IP 海外IP代理

软件测试常用抓包工具 Charles 与 Fiddler

测试人

软件测试

Flex 组件的简略使用

flfljh

HarmonyOS NEXT基础入门

flfljh

关键帧动画

flfljh

鸿蒙+next+封装轻量级缓存工具PreferencesUtil

flfljh

京东API接口详解:轻松获取商品详情与SKU信息(1次15个),提升业务效率

代码忍者

京东API接口

AlertDialog的简易使用

flfljh

Flutter OHOS flutter appscheme插件

flfljh

Flutter OHOS flutter_dart_native

flfljh

harmony_flutter_udid

flfljh

Topaz Video AI for Mac 强大的视频增强与修复工具

小玖_苹果Mac软件

OmniPlan Pro 4 for Mac:强大的项目管理工具

小玖_苹果Mac软件

Flutter OHOS harmony_fluwx 集成微信服务(二)

flfljh

harmony_flutter_FlutterEngineGroup

flfljh

Bartender 5 for Mac智能管理菜单栏的神器

小玖_苹果Mac软件

Ableton Live 11 Suite for Mac 强大的音乐创作与表演工具

小玖_苹果Mac软件

《Django 5 By Example》阅读笔记:p561-p613

codists

Python django

鸿蒙Flutter环境相关问题解决方法

flfljh

鸿蒙Flutter怎样调试dart代码

flfljh

快速记笔记软件SideNotes for mac 1.4.15激活版

小玖_苹果Mac软件

Rico Mariani对Visual Studio不是64位的解释_.NET_Jonathan Allen_InfoQ精选文章