写点什么

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

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

关注

评论

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

国企数字化转型如何拥抱低代码开发?

不在线第一只蜗牛

低代码 数字化转型

以低代码技术加速推动企业数字创新

快乐非自愿限量之名

低代码 数字化转型 企业转型

积硅步以致千里,积怠惰以致深渊

Anliven

成长 激励

DNS解析如何设置合适的TTL值?

国科云

如何在Ubuntu 20.04|18.04上安装FreeSwitch

百度搜索:蓝易云

一文读懂PINGPONG:0成本在普通家用机上运行多个网络节点

股市老人

ETL数据集成丨SQLServer到Doris的无缝数据同步策略

RestCloud

数据库 Doris ETL SqlServer 数据集成

如何在Python程序中使用NFT资产服务API接口?

幂简集成

API NFT

一文读懂PINGPONG:0成本在普通家用机上运行多个网络节点

加密眼界

一图看懂天润云(2167.HK)2024年中期业绩

天润融通

共促国产AI生态繁荣,天翼云重磅发布魔乐开发者社区

天翼云开发者社区

云计算 开发者社区 天翼云

服务重启了,如何保证线程池中的数据不丢失?

快乐非自愿限量之名

Java 数据结构 线程池

一文读懂PINGPONG:0成本在普通家用机上运行多个网络节点

石头财经

零售商商品规划新纪元:全面策略融合与智能计划系统引领未来

第七在线

Kuasar 最前沿:KubeCon China 2024 精彩回顾

华为云原生团队

云计算 容器 云原生

一文读懂PINGPONG:0成本在普通家用机上运行多个网络节点

大瞿科技

Mybatis-Plus常见注解

百度搜索:蓝易云

去中心化网络PINGPONG,让普通人也可以参与到节点运行并获益

BlockChain先知

天翼云HBlock:Step by step,一杯咖啡的时间轻松搭建企业存储集群

三掌柜

天翼云HBlock

未完待续

Anliven

职业发展 价值

安装门槛极低!30分钟完成企业存储搭建

Swift社区

HBlock用户使用指南:盘活系统,解锁存储潜力

数字扫地僧

天翼云 HBlock 天翼云HBlock

一文读懂PINGPONG:0成本在普通家用机上运行多个网络节点

西柚子

有效阅读

Anliven

方法 个人提升 阅读

金九银十来了,你准备好了吗?——迎接技术行业的旺季

EquatorCoco

程序员 面试 金九银十

轻松上手:快速部署天翼云 HBlock 轻量存储系统的真实体验

申公豹

天翼云HBlock

淘宝拍立淘接口,以图搜索相似商品接口

tbapi

淘宝API接口 淘宝拍立淘接口

Rust China Conf 2024

非凸科技

Linux中的chsh命令及示例

百度搜索:蓝易云

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