写点什么

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:003669
用户头像

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

关注

评论

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

工具词典:中立观点

lidaobing

维基百科 28天写作

58同城风控平台演进

DataFunTalk

架构 中台

史上最全面‘java监听器’解读,读完就能用进项目

Java架构师迁哥

百分点智能对话技术探索实践

DataFunTalk

AI

10次面试,2份offer —— 大龄程序员 2020 求职记录

escray

面试 架构师训练营第 1 期

云原生架构-静态代码扫描SonarQube超时

云原生实验室

DevOps 云原生 jenkins SonarQube Pipeli

小说内容理解

DataFunTalk

AI 推荐系统

全面 Severless 化只需要 7天!看南瓜电影的云上升级

阿里巴巴中间件

阿里巴巴 中间件

生产环境全链路压测建设历程 23:FAQ 3、4 适配改造,目标压力

数列科技杨德华

全链路压测 七日更

被砍伤的技术VP | 法庭上的CTO(24)

赵新龙

CTO 法庭上的CTO

总结2020:5个月出版两本书,日更公众号是一种怎样的体验?

冰河

程序员 程序人生 年终总结

五步带你探究爬虫爬取视频弹幕背后的真相,附爬虫实现源码

小Q

学习 编程 架构 面试 python 爬虫

我对2021的期待,从合上这份2020日历开始

脑极体

犯”集资诈骗罪“、二审判6年的CTO | 法庭上的CTO(21)

赵新龙

CTO 法庭上的CTO

甲方日常 77

句子

工作 随笔杂谈 日常

C语言编程:入门指南(一周内学懂)

计算机与AI

c

阿里P8大牛亲自讲解!Android高级工程师面试实战,Android岗

欢喜学安卓

android 程序员 面试 移动开发

散布消极言论被开除的总监 | 法庭上的CTO(25)

赵新龙

CTO 法庭上的CTO

十大经典排序算法最强总结(含Java、Python码实现)

Java 面试 算法

Serverless 在 SaaS 领域的最佳实践

阿里巴巴中间件

阿里巴巴 中间件

腾讯T2手把手教你!字节跳动历年校招Android面试真题解析,含BATJM大厂

欢喜学安卓

android 程序员 面试 移动开发

互联网大厂有哪些分库分表的思路和技巧?

冰河

分布式数据库 分库分表 分布式存储 数据一致性 数据同步

侵犯著作权、判刑两年半的 CTO |法庭上的CTO(22)

赵新龙

CTO 法庭上的CTO

开设赌场的CTO | 法庭上的CTO(23)

赵新龙

CTO 法庭上的CTO

天下武功,唯”拆“不破之架构篇二 | 技术人应知的创新思维模型 (9)

Alan

架构 技术 技术人应知的创新思维模型 七日更 28天写作

网络模拟器:Cisco Packet Tracer 设备登陆实验

“让专业的人做专业的事”,畅捷通与阿里云的云原生故事

阿里巴巴中间件

云计算 云原生

时空大数据与智能技术的时代共舞,百度地图给2020的答案

脑极体

2020盘点之手机失窃事件复盘分析

石君

信息安全 资金安全 手机失窃

架构师训练营第一周作业

Mark

阿里P8大牛亲自讲解!6年菜鸟开发面试字节跳动安卓研发岗,成功收获美团,小米安卓offer

欢喜学安卓

android 程序员 面试 移动开发

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