|
|
51CTO旗下网站
|
|
移动端

为什么Windows内核比其他系统慢

我曾在 Hacker News 上发表过一篇帖子,解释为什么 Windows 内核不管是在性能还是在创新方面都比不上 Linux。后来,有一位 Windows NT 内核开发者发文对此进行了回应

作者:Marc Bevand来源:架构头条|2020-03-18 14:08

 

我曾在 Hacker News 上发表过一篇帖子,解释为什么 Windows 内核不管是在性能还是在创新方面都比不上 Linux。后来,有一位 Windows NT 内核开发者发文对此进行了回应,承认了这个问题的存在,并解释了导致这个问题的根源。但因为监管方面的原因,这篇文章被删掉了。不过,这篇文章意义重大,所以我还是重新把它贴出来。以下是正文。

Windows 在很多方面确实比其他操作系统要慢,而且差距在不断扩大。导致这个问题的根源是人。Windows 世界的改进不够纯粹,不像 Linux 世界那样纯粹。在 Linux 世界,人们做出一项改进可能仅仅是为了获得荣耀。

当然,偶尔也会有那么一些人,他们也想把事情做得更好,但几乎都是以失败告终。我们确实在某些方面做出了改进,因为那些掌握资源的人相信这些改进影响到了业务目标。但这些工作是徒劳的,我们并没有正式或非正式的性能改进计划,我们开始关注安全问题,因为没有 SP3 的 Windows XP 对业务来说是一个巨大威胁,而性能问题在这个时候显得微不足道。

通常,系统组件所有者不太喜欢来自其他团队的补丁。作为开发人员,如果你接受了来自外部的补丁,可能会惹恼你的领导(因为补丁需要维护,导致计划外的设计变更),让测试人员不高兴(给他们带来额外的工作量),让 PM 生气(进度受影响)。所以,一个团队通常没有必要接受来自其他团队的变更,而且总是可以找到拒绝的理由。

在 Windows 世界,人们几乎找不到做出改变的源动力。而在 Linux 世界,哪怕是把遍历文件目录的性能改进了 5%,也会受到表扬和感谢。在 Windows 世界,如果你不是那个团队的人,即使你的代码被接受了,领导们也会不屑一顾。的确,做出一个巨大的改进可以让你引起高层的注意,这对于你的职业生涯来说是件好事,但这个改进要足够大,大到可以引起他们的注意。增量式的小改进只会惹人烦,对你的职业生涯并没有什么好处。如果运气不好,你跟领导说你为其他系统组件做了性能改进,他可能会反过来问你:如果出了问题,你该怎么办?

长此以往,人们不再热心于计划外的工作,这有什么奇怪的吗?

导致这种差距的另一个原因是我们无法留住有才华的人。谷歌和其他位于西雅图的大公司不断挖墙脚,把我们最好最有经验的开发人员都挖走了,我们只能从高校招聘年轻的毕业生来替代他们。你会发现,很多输入系统是初级工程师在维护。这些开发者的出发点是好的,他们也足够聪明,但他们不理解一些决策的初衷是什么,对系统的工作原理没有全面的认识,更重要的是,他们不愿意去修改已有的东西。

这些初级开发者倾向于通过实现新的特性来改进系统,而不是在旧有的基础上做出改变。因为相比修改旧东西,实现新特性可以节省评审时间。

这样的例子有很多,比如:

  • 我们不要去碰命名管道,加个 %INTERNAL_NOTIFICATION_SYSTEM% 吧!
  • 我们不能把 %INTERNAL_NOTIFICATION_SYSTEM% 暴露出去,这样就不用写文档了,而且不影响销售,因为我们只有 90 年代的 Win32 API。
  • 我们不要去碰 DCOM,加个 %C#_REMOTING_FLAVOR_OF_THE_WEEK% 吧!
  • XNA,这个还用说吗?
  • 怎么会有人需要大于 2G 的文件压缩格式?
  • 我们可以支持符号链接,但要确保不会有人用,这样就不用因为安全漏洞遭受骂名!
  • 我们不要去碰 SDX,所以就假装有四个版本在迁移到 TFS,但实际上什么也没改变!
  • NTFS 代码使用了全局递归锁和 SEH,太恐怖了,我们需要写个参考文档。
  • 我们不能实现 C11 支持,在一年内实现可变模板太难了。

看,微软还是有一些有才华的开发者,他们对操作系统开发的复杂性有着敏锐的洞察力,并对简洁设计有着独到的眼光。在某些方面,NT 内核比 Linux 好,但这些有才华的人要么退休,要么去了其他大型的科技公司,替代者很少能够达到他们的水平。我们的员工要么是朝九晚五有孩子的,要么是迫切希望拿到 H1B 的,要么是被谷歌拒绝的。我们偶尔也会遇到好的人才,但那也只是杯水车薪,难怪我们会落后。

这篇文章的作者以匿名的方式联系到我,担心他的文章太过张扬,所以又补充了以下这些内容。

一切都失控了。我太过苛刻了,其实我并没有打算爆料,只是想抱怨一下。我在写这篇文章时应该更谨慎一些。我很抱歉,让你们对微软内部有了一个错误的印象。

首先,我想澄清一下,我之前写的大部分内容都是半开玩笑的,而且言过其实——NTFS 确实在内部使用了 SEH,但文件系统非常可靠,而且经过了良好的测试。维护人员是我所知道的最有才华和最有经验的人。我们的其他核心组件也是如此。的确,有一些组件让更有经验的人来维护会更好,但我们也并没有随便让不合格的人来做这些工作。

当然,我手里也没有有关挖墙脚的内部数据,我的观点带有主观性——我看到了一些非常亲密的朋友离开了,对新招来的员工也没有太多印象。我手里没有全方位的事实和数据。我对人员流动的总体了解可能是错的,我不应该像之前那样陈述这件事。

微软仍然拥有大量的技术人才。我们不会发布没人维护和理解的代码,虽然有时候新人需要一段时间才能上手。我可以访问 Windows 源代码,偶尔也会提交一些代码,但除了我以外,还有成千上万的人也在这么做。我没有什么特别的。我不是什么爆料者。虽然我个人认为对符号链接的限制影响了它的用途,但我们当时确实做了一个合理的工程分析——并不是一个别有用心的家伙试图避免得到糟糕的评审分数。事实上,这样的事情几乎从未发生过。我们几乎从不单独做决定,我想强调的是,我们并不疯狂,也没有出现功能失调。社会力阻碍了创新,我们应该在文化方面做点什么,但还至于到了崩溃的边缘。这种负面影响更像是在汽车上安装了一个不必要的扰流板,远没有拆卸发动机那么严重。我们的工程部门正常运作,发布可靠、有用的软件,这些软件可以在全世界的电脑上运行。不管你怎么看待 Windows 8 的 UI,UI 之下的系统总是坚如磐石,就像 Windows 7 一样,我很自豪自己参与了整个过程。

我还想为我说过的有关开发部门的事情道歉。我可能对编译器团队安排的事项优先级有意见,对为什么某些 C++ 特性需要更长的实现时间感到困惑,但事实是那些优秀的人确实在做工作。他们当然知道什么是依赖循环,我们只不过是世界上仅有的几个从头开发优化编译器的团队之一。

最后,我遇到了一些很好的人,我觉得自己是某个特殊群体的一部分。如果我认为 Windows 是一个工程噩梦,我就不会在这里说这些了。每个人都有自己的问题,但公司以外的人似乎对我们的问题赋予了特殊的含义。我不明白为什么会这样。无论如何,之前的文章给那些敬业、努力工作的人抹黑了,我不应该用丑陋的画笔来刻画他们。

另外,我对同事们没有什么意见,我想收回对他们的随意评判。很多一起工作的同事都很棒,而他们正好有孩子要养。我想说的是,我不喜欢某些人,他们把我们的工作看成是一项工作而不是激情,而且我觉得现在有很多这样的人。

【编辑推荐】

  1. 停止支持近2个月,微软Windows 7用户仍无太大动力升级Windows 10
  2. 微软2020年的巨作!剖析Windows10新版16大新特性
  3. 微软对 Windows 10 收集用户数据的方式进行了更改
  4. 百度输入法日均语音请求超10亿次 AI功能落地撬动输入法行业格局
  5. 标星过万的开源项目:一个功能丰富的 Java 工具包
【责任编辑:张燕妮 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月获赞

订阅专栏+更多

秒杀高并发白话实战

秒杀高并发白话实战

主流高并发架构
共15章 | 51CTO崔皓

50人订阅学习

网络排障一点通

网络排障一点通

网络排障及优化调整案例
共20章 | 捷哥CCIE

402人订阅学习

VMware NSX 入门到实战

VMware NSX 入门到实战

网络虚拟化革命性技术
共16章 | Cloud袁

224人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微