写点什么

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

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

关注

评论

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

一文了解 Dubbo 的代码架构

Apache Dubbo

Java 开源 源码 微服务 云原生

架构训练营-第10期-模块2作业

Geek_4db2d5

Raydium被盗造成巨额损失,但Zebec Protocol及其生态并未受影响

BlockChain先知

专利进阶(一):软件专利工程师浅谈如何针对计算机软件类专利申请进行技术挖掘

No Silver Bullet

专利 12月月更 软件专利工程师 技术挖掘

Raydium被盗造成巨额损失,但Zebec Protocol以及$ZBC并未受影响

西柚子

AngularJS进阶(四十二)ng-options渲染的第一项为空问题分析及解决方案

No Silver Bullet

12月月更 ng-options 页面渲染 上拉加载

数据权限就该这么设计!!!

风铃架构日知录

数据 优化 数据权限 rbac 数据库权限

性能优化-内存泄漏、内存溢出、cpu占用高、死锁、栈溢出、FullGC频繁检测手段-总结与分享

C++后台开发

性能优化 后端开发 内存泄漏 linux开发 C++开发

Verilog语言的条件语句

梦笔生花

Verilog Verilog语法 Verilog的条件语句

Vue进阶(贰零柒):Webpack 性能优化措施汇总

No Silver Bullet

性能优化 Vue webpack 12月月更

ZBC陆续在主要CEX开启Staking成近期利好,锁定市场大部分流通量

西柚子

模块2

KING

数据权限就该这么设计!!!

小小怪下士

Java 程序员 数据权限

SQL查找是否"存在",别再count了!

风铃架构日知录

MySQL 后端 Java、 java程序员 sql

Design a messaging queue table in MySQL

David

#架构实战营

架构训练营-模块一作业

Sam

架构实战营

数据库原理及MySQL应用 | 数据库安全加固

TiAmo

安全 数据库· 12月月更

精华推荐 | 【深入浅出RocketMQ原理及实战】「性能原理挖掘系列」透彻剖析贯穿RocketMQ的事务性消息的底层原理并在分析其实际开发场景

洛神灬殇

分布式事务 RocketMQ 可靠消息最终一致 12 月 PK 榜

Atlassian FaaS 云开发平台Forge解析

填空时光

敏捷 Faas Atlassian Jira

聊聊好牛的 MySQL 日志设计!

风铃架构日知录

MySQL Java、 sql java\ Undo Log

设备资产管理系统有什么用?

优秀

设备管理 设备资产管理系统

2022 Gartner全球云数据库管理系统魔力象限发布 腾讯云数据库入选

科技热闻

低代码丨仪表盘使用技巧—【倒计时】

优秀

倒计时 数据看板

2022中国产业数字化发展成熟度区域指数分析——充分利用特长,形成区域比较优势,夯实中国式现代化建设基础

易观分析

数字化 产业

实战整了一个后台服务,真香!

风铃架构日知录

多线程 线程池 网络 HTTP CGI

架构实战营模块8作业

冷夫冲

架构 构架 「架构实战营」

ZBC陆续在主要CEX开启Staking,锁定市场大部分流通量成大利好

鳄鱼视界

架构实战营 - 模块 2 作业

小圆

Data Structure Basics in Python

无人之路

数据结构 Python.

chatGPT的49种应用场景介绍,各开发语言接入chatGPT参考指南

非喵鱼

Java Python 前端 编程语言 ChatGPT

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