写点什么

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

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

关注

评论

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

开发一个API Gateway

无心

API Gateway

Go 空结构体:零内存的魔力

陈明勇

Go golang 空结构体 6 月 优质更文活动

HAG:首个通过合规STO将RWA通证化应用于比特币Mining的项目

股市老人

揭秘新一代云数仓技术架构与最佳实践

字节跳动数据平台

大数据 数据仓库 云原生 OLAP 数据仓库服务

几个小技巧,提高你的代码质量

飞算JavaAI开发助手

代码质量 程序员、 软件开发、

一篇关于代码质量的实用攻略!

飞算JavaAI开发助手

代码质量 软件开发、

墨天轮国产关系型分布式数据库榜单解读

墨天轮

数据库 GaussDB TiDB oceanbase polarDB

节省90%编译时间,这是字节跳动开源的基于Rust的前端构建工具

字节跳动技术范儿

rust 前端 前端构建

常见的软件可靠性度量和分析方法

穿过生命散发芬芳

可靠性度量 6 月 优质更文活动

Vue.js 最佳实践:提高性能和减少耦合的方法

xfgg

JavaScript Vue 前端 6 月 优质更文活动

10个刚需的Blender小技巧

Finovy Cloud

blender C4D

中企出海成大热趋势,海外用户如何高效触达

MobTech袤博科技

对话 ChatGPT 理解 Rust 异步网络 io

蓬蒿

rust 编程语言 tokio 异步网路io

2023-06-08:给你一棵二叉树的根节点 root ,返回树的 最大宽度 。 树的 最大宽度 是所有层中最大的 宽度 。 每一层的 宽度 被定义为该层最左和最右的非空节点(即,两个端点)之间的长度

福大大架构师每日一题

算法 福大大

Pilota:为什么一个代码生成工具如此复杂丨GOTC Rust系列分享

字节跳动技术范儿

rust GOTC

Vue安装并使用axios发送请求

不觉心动

6 月 优质更文活动

直播倒计时1天 | 一体化智能可观测平台如何保障电商节大促

博睿数据

电商 智能运维 博睿数据 直播预告

3DCAT亮相糖酒会,为元宇宙展会提供实时云渲染支持

3DCAT实时渲染

元宇宙 实时云渲染

模型服务文档自动生成,要素追溯关联、结构规范易读|ModelWhale 版本更新

ModelWhale

大模型 企业团队协同 数据开放和利用 学科交叉 人文社科

C语言编程—头文件

芯动大师

C语言 头文件 6 月 优质更文活动

有哪些内外网都能传输文件的工具-镭速

镭速

从数据开始,构建值得信赖的生成式AI应用

澳鹏Appen

人工智能 nlp 数据标注 ChatGPT 生成式AI

【零售电商系列】走进亚马逊(一)

小诚信驿站

6 月 优质更文活动

火山引擎DataLeap:从短视频APP实践来看,如何统一数据指标口径?

字节跳动数据平台

大数据 指标体系 数据研发 指标建设

Milvus Lite 已交卷!轻量版 Milvus,主打就是一个轻便、无负担

Zilliz

Milvus 向量数据库 MILVUSLITE

浅谈中小企业如何选择适合自己的网络营销方式

石头IT视角

SaaS公司如何成为 AI 独角兽?发挥长板:流程、用户需求和数据积累

B Impact

Vue使用axios进行get请求拼接参数的两种方式

不觉心动

6 月 优质更文活动

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