【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

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

关注

评论

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

架构训练营模块一作业

高铎

架构实战营

介绍一款Hive数仓可视化神器、Dbeaver的配置和使用方法

白程序员的自习室

7月日更 Dbeaver 数仓工具 数据库客户端

模块一作业

Mr.He

架构实战营

树莓派/PC实现实时摄像头数据共享(Python—OpenCV)

不脱发的程序猿

Python 树莓派 OpenCV 视频通信

蜕变中的B站:给各大自媒体平台带来那些启发

石头IT视角

GitHub标星90K+ 的算法小抄,全球排名 36,到底有多牛逼?

Java 程序员 架构 面试

微信业务架构图 & 学生管理系统

gawaine

架构实战营

分析一下微信朋友圈的高性能复杂度

NewBranSTONE

架构实战营

yidong

方白

树莓派/PC实现实时摄像头数据共享—最优方法(搭建网络摄像头)

不脱发的程序猿

树莓派 网络摄像头 视频通信

🏆(不要错过!)【CI/CD技术专题】「Jenkins实战系列」(2)Jenkins实现自动化部署+自动化合并其他分支

洛神灬殇

jenkins CI/CD 7月日更

非对称风险:你需要为行为结果负责吗?

石云升

读书笔记 风险 7月日更

架构实战营第一期--模块一作业

clay

架构实战营

架构实战营模块1作业

技术是伙伴

草稿20210707

cc=o

架构实战营 草稿

[架构实战营一期]模块一作业

trymorewang

#架构实战营

不同阶段考证有哪些作用

耳东@Erdong

7月日更 考试

模块一作业

乌黑の云

架构训练营 模块一作业

小卷儿

iOS如何提升,首先得知自己的处境!(欢迎评论留言)

程序员 编程之路 IT技能 iOS 知识体系

智能运维(AIOps)系列之二:什么是人工智能

micklongen

人工智能 AIOPS 智能运维

模块一:

kk

#架构实战营

使用perf解决JDK8U小版本升级后性能下降的问题

毕昇JDK社区

如何轻松启动Docker服务

DisonTangor

Docker

数仓开发人员经常说的 ETL、ELT,又有什么区别

奔向架构师

大数据 数据架构 话题讨论 7月日更

架构实战营作业-模块1

袁小芬

架构实战营

架构训练营第1期 模块一作业

高远

靠着这份Java面试题跟答案,我从 14K 变成了 28K!

Java 程序员 架构 面试

模块一作业

MX

5G云计算齐发力,云电脑的春天到了吗?

脑极体

树莓派/PC实现实时摄像头数据共享(Python—picamera)

不脱发的程序猿

Python 树莓派 视频通信 picamera

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