开发者生态
morning
2026 年 9 月如何加速 Rust 编译器
摘要
My last post on the Rust compiler’s performance was two months ago and a lot has happened since then. Overall progress The measurements for the period 2026-07-29 to 2026-09-28 can be seen here . The m...
the
for
some
and
The
this
benchmarks
LLVM
borrow
checker
2026-10-01
1 阅读
约7分钟阅读
trickypr
字号:
我上一篇关于 Rust 编译器性能的文章是两个月前,从那时起发生了很多事情。总体进度 2026-07-29 至 2026-09-28 期间的测量结果可在此处查看。平均挂墙时间减少了 4.57%,这在短短两个月内就取得了显着的改善。在 629 项基准测量中,其中 555 项有所改善,只有 74 项有所下降。许多基准都出现了两位数的百分比下降。这一结果的技术术语是“一片绿色的海洋”。 rustdoc 在我的上一篇文章中,我提到了 Noah Lev 如何在 rustdoc 上取得了巨大的速度胜利。他最近写了一篇文章,详细解释了他是如何做到这一点的。这是一本有趣且令人满意的读物。 Clippy #159642:在此 PR 中,Jakub Beránek 为 Clippy 启用了 PGO,在大多数 Clippy 基准测试中提供了墙时间改进,在最好的情况下提高了 18%! LLVM 更新 #158734:在此 PR Nikita Popov 将编译器使用的 LLVM 版本升级到 LLVM 23。正如我们升级 LLVM 时经常发生的那样,我们看到了一些不错的加速。所有基准测试的平均挂起时间减少了 1.2%,这听起来可能不多,但对于单个 PR 来说确实令人印象深刻。 LLVM 人员的出色工作!新的借用检查器 新的借用检查器 Polonius Alpha(与 Napoleon Dynamite 无关)在 Nightly 上启用。它比现有的借用检查器更精确,并且接受旧借用检查器会拒绝的一些有效程序。它确实比旧的借用检查器做了更多的工作,足以在少数情况下(包括流行的 serde crate)编译时间产生可衡量的差异。幸运的是,杰克·休伊一直在处理这个案子。 #161938:在此 PR 中,Jack 进行了一些惰性计算,这将 serde 的指令计数减少了 3-5%,而其他一些基准测试的指令计数减少了不到 1%。 #163027:在此 PR 中,Jack 调整了数据结构并调整了一些内联,在众多基准测试中指令数减少了 1% 以下。要减少剩余的 Polonius Alpha 回归,还有更多工作要做,但值得注意的是,“绿色海洋”表明这些回归被许多其他最近的改进所淹没。新的特质求解器 新的特质求解器,Penelope Hammertime,[Ed.注意:是吗?] 也在 Nightly 上启用。正如我所说,已经发生了很多事情。与新的借用检查器一样,新的特征求解器在少数情况下速度较慢。 Jana Dönszelmann 撰写了一篇详细的文章,介绍了为提高这个新求解器的性能所做的努力。 Jana 的帖子足够详细,我不会更多地谈论新求解器正在进行的大量工作,但我会在传递我所做的 PR 时提到:#160479、#160605、#160801、#160892、#161077 和 #161211。其中一些极大地减少了某些异常值包的编译时间:这里减少了 50%,那里减少了 25%,那里减少了 15%,甚至在一次压力测试中减少了更多时间。我并不是唯一一个在这里取得进展的人……去阅读 Jana 的帖子。 xmakro 新贡献者 xmakro 继续进行良好的改进。 #157281:在此 PR xmakro 优化了构建专业化图时的 impl 处理。这使得所有基准测试的平均周期数减少了 1.58%,这对于单个 PR 来说是巨大的。 #158059:在此 PR 中,xmakro 优化了增量编译数据加载的一个方面,减少了多个基准测试的指令数,在最好的情况下减少了 6%。 #160473:在此 PR 中,xmakro 避免了热义务处理路径中的一些分配,从而减少了多个基准测试中的指令数量,在最好的情况下减少了 2%。 #160268:在此 PR 中,xmakro 通过更改旧/新特征求解器选择代码以使用静态调度而不是动态调度,避免了大量分配。这使得许多基准测试中的指令数减少了 1% 以下。这个热分配路径已经在配置文件中出现了一段时间,我之前在 #155714 中尝试过完全相同的想法。但我在几个基准测试中得到了回归,可能是由于放置一些 #[inline] 属性的位置选择略有不同。很高兴看到这种明显的低效率问题得到了解决。数据流分析 #160193:在此 PR 中,我更改了编译器中数据流分析所使用的 CFG 遍历算法。这些分析迭代到固定点,并且遍历算法可以影响到达固定点的速度。对于大多数代码来说,新算法没有什么区别,但是 Cranelift-codegen 包具有一个包含超过 18,000 个基本块的巨大功能。旧算法需要 150 万次调用 apply_effects_in_block 才能达到借用检查器使用的 EverInitializedPlaces 分析的固定点;新算法需要90,000。对于该板条箱的检查构建来说,这极大地减少了约 30% 的墙时间。 #160033:在此 PR 中,我再次提高了 EverInitializedPlaces 的效率,这次不跟踪不必要的预测数据。这将匹配压力基准的指令数减少了 17%,其他一些指标也减少了 17%。
这篇文章对您有帮助吗?
订阅66必读
每日精选科技资讯,直达你的邮箱