AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

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

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

关注

评论

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

HAProxy 可观测性最佳实践

观测云

HAProxy

InPlant SCADA笔记 查看工程的网络架构

万里无云万里天

工厂运维 InPlant SCADA

InPlant SCADA笔记 二次确认

万里无云万里天

工厂运维 InPlant SCADA

InPlant SCADA笔记 工程管理的工程属性与全局设置

万里无云万里天

工厂运维 InPlant SCADA

InPlant SCADA笔记 工程管理界面的五种风格

万里无云万里天

工厂运维 InPlant SCADA

汽车辐射大?技术来救它:整车辐射抗扰发射天线仿真建模及性能预测

Altair RapidMiner

人工智能 汽车 仿真 altair 辐射

管理能力达到国际认可水平 智谱获得国内首批ISO/IEC 42001:2023人工智能管理体系认证证书

技术研究院

性能提升20%,字节跳动HTTPDNS从中心下沉到边缘

火山引擎边缘云

边缘计算 HTTP DNS #DNS 边缘计算平台

天工一刻 | 一文看懂3D大模型

新消费日报

InPlant SCADA笔记 背景模版

万里无云万里天

工厂运维 InPlant SCADA

InPlant SCADA笔记 查看工程的数据库与历史趋势的信息

万里无云万里天

工厂运维 InPlant SCADA

澳鹏Appen入选大模型产业链基础层图谱及案例研究

澳鹏Appen

大模型训练 大模型 百模大战

如何借助逻辑数据编织平台实现“数据优先堆栈( DFS )”

Aloudata

数据仓库 数据虚拟化 数据编织

用Python来DIY一个AI面部情绪识别API的简单方案

幂简集成

API

AWS 弹性伸缩特性介绍

AutoMQ

云计算 kafka 云原生 AWS

从0到100:旅拍小程序开发笔记(上)

CC同学

InPlant SCADA笔记 调度任务功能

万里无云万里天

工厂运维 InPlant SCADA

从焦虑症到AI「网红」:这名程序员是如何让AI「助他一臂之力」

新程序员编辑部

ChatGPT Prompt

一文剖析高可用向量数据库的本质

Zilliz

人工智能 大数据 AI Zilliz 向量数据库

如数据血缘探究数据管理的“自治理”

Aloudata

Data 数据管理 数据血缘 Data Fabric

攻坚克难岁月长,自主腾飞世界强——回顾近代中国数据库的发展与飞跃

Geek_b7ce72

InPlant SCADA笔记 报警管理功能

万里无云万里天

工厂运维 InPlant SCADA

InPlant SCADA笔记 io 查看数据库管理与IO驱动

万里无云万里天

工厂运维 InPlant SCADA

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