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

2020 年 3 月 19 日 InfoQ

作者丨Marc Bevand

译者丨无明

策划丨小智

我曾在 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 是一个工程噩梦，我就不会在这里说这些了。每个人都有自己的问题，但公司以外的人似乎对我们的问题赋予了特殊的含义。我不明白为什么会这样。无论如何，之前的文章给那些敬业、努力工作的人抹黑了，我不应该用丑陋的画笔来刻画他们。

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

参考链接：

https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/

InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字“进群”申请入群。大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！