人工智能发现瓶颈，可能使Linux编译速度提升70%

一位Linux内核开发者使用语言模型来定位编译中的瓶颈。尽管该工具生成了他形容为糟糕的代码，但经过人工审查后，成功准备了23个补丁，提升了完整编译的速度达36%，增量编译的速度达70%。

• 洛伦佐·斯托克斯发布了一系列23个补丁，以显著加快Linux内核的编译速度。
• 该工作针对Kbuild、kallsyms、modpost、objtool、mksysmap和Rust编译系统中的单线程任务。
• 测试报告显示，完整编译的速度提升了36%，增量编译的速度提升了70%。

一项人工智能辅助的研究

一位资深的Linux内核开发者利用大型语言模型来定位减缓编译过程的障碍。结果是一系列23个补丁，根据描述的测试，可能显著加速不同类型的编译，尽管在纳入主内核之前仍需经过审查过程。

洛伦佐·斯托克斯于2026年9月8日发布了该提案，目标明确：减少系统在单线程任务上停滞的时间。这个想法并不是用人工智能取代开发者，而是利用它来检查过程，找到等待点，并建议可以进行技术审计的修改。

然而，该工具并没有提供可直接纳入项目的结果。斯托克斯解释说，模型生成了大量代码，其中相当一部分被他形容为糟糕，因此他不得不广泛审查和重写他的提案，才将其转化为一系列连贯的补丁。

这位开发者还指出，模型帮助协调了编译执行、测试、调试和分析。尽管如此，他表示仍手动检查了编译和正在运行的内核的正确性，并亲自验证了性能的提升。

单线程任务的问题

内核编译结合了多个阶段，这些阶段可以在处理器的不同核心上执行，但某些任务仍然限制在单线程上，造成等待点。当一个阶段比另一个阶段先完成时，现有资源并不总能得到充分利用，因此整体速度受到并行化程度较低的部分的制约。

斯托克斯的补丁试图更好地分配这些操作，以便更多的工作能够同时进行。该方法影响了构建系统的组件，如Kbuild、kallsyms、modpost、objtool和mksysmap，以及用于在内核中编译Rust代码的系统。

Kbuild协调了大部分构建过程，而其他工具则生成信息、验证对象或准备最终结果所需的元素。该提案旨在使这些功能更高效地工作，并减少一个阶段等待另一个完成顺序操作的时间间隔。

这一系列的范围也表明，检测瓶颈可能比优化单一工具更为重要。在多个相连阶段的小幅改进可能会在总时间上产生显著节省，尤其是在开发和测试过程中，系统频繁重新编译内核时。

不同编译中报告的改进

引用的结果显示，启用所有模块的内核编译的时间大约减少了36%。这一测量代表了系列中最广泛的场景，因为它包含了大量组件，并允许观察当过程需要构建一个庞大配置时优化的表现。

增量编译只重建受最近更改影响的部分，可能会受益更多。在这种情况下，提到的测试报告显示改善高达70%，这对重复修改代码、编译、测试和调整的开发者来说是一个重要的差异。

这些数字并不代表对每台设备或每种内核配置的普遍承诺，提案本身也包括了不同场景的基准结果。其主要价值在于展示单线程的瓶颈仍然提供了重要的改进编译体验的空间。

人工审核与后续步骤

Stoakes在每个提交的标签中记录了模型的参与，标记为“Assisted-by”。他还指出，他对提交信息、介绍信和评论进行了大量编辑，这是为了让其他维护者能够理解技术决策并评估其后果。

这种监督在像Linux内核这样的项目中尤为重要，因为性能变化不能仅通过编译时间来评估。补丁必须保持系统的正确性，避免在不常见的配置中出现错误，并保持最终在设备和服务器上运行的代码的稳定性。

这一经验揭示了在软件工程中使用语言模型时的已知紧张关系：它们可以快速探索替代方案并检测难以手动审查的模式，但其输出可能包含错误、结构不良或不符合项目标准的决策。在这种情况下，人工智能的实用性体现在研究和分析中，而最终的验证仍由人类负责。

信息由Phoronix报道，收集了Stoakes的发布和补丁系列的结果。下一步将是社区和相关维护者的技术审查，之后该工作可能会进入主内核，加速不同设备和配置的编译。

目前，这些数字应被解读为正在审查的提案结果，而不是已经可用于所有Linux发行版的改进。如果补丁在不引入修正问题的情况下保持其优势，可能会将内核开发中最重复的任务之一转变为一个显著更快的过程。