Cranelift 代码生成进入 Rust

原文 ↗ Hacker News 讨论 ↗

编译时性能 vs LLVM

  • 多个基准测试显示，Cranelift 在各种项目上将总编译时间削减了约 17–30%，包括 Rust 自身；在一项详细测量中，CPU 时间节省约为 40%，增量重建也更快。
  • 一些用户在某些配置下只看到边际改善，直到把缓存效应（如 sccache + NAS）算进去后才更明显。
  • 文中强调，编译时间包括解析、类型检查、MIR 和链接；代码生成只是其中一部分，因此 Amdahl 定律限制了收益。
  • 更快的链接器（LLD、mold）还能进一步缩短构建时间，再结合前端并行工作，Rust 构建速度有望大幅提升。

运行时性能 / 优化质量

  • 较早的研究表明，Cranelift 编译速度快得多，但生成的代码明显更慢；评论者表示自那以后 Cranelift 已经变化很大。
  • 当前的预期是，Cranelift 生成的代码通常比 LLVM 慢 10–30%，有时接近，但不太可能系统性地达到最好的 LLVM/GCC 输出。
  • Cranelift 的定位是“开发时足够快”，而不是可直接替代高性能发布构建。

E-graphs 与优化器设计

  • 讨论将基于等式图的优化与传统的 pass 流水线进行对比。
  • E-graphs 通过保留多个等价表示并稍后再选择，避免了阶段顺序问题，但可能会变得很大；Cranelift 使用一种受约束、无环的变体，并通过即时重写来保持速度。
  • 一些评论者对 e-graphs 作为未来方向充满热情；另一些人则指出抽取策略和内存增长等实际问题仍未解决。

增量构建与缓存

  • 多位用户报告称，增量开发构建能获得很大的收益（通常快 2–4 倍），尤其是在将 Cranelift 与快速链接器结合时。
  • 人们希望与 sccache 更紧密集成，并实现更细粒度的缓存（例如 MIR 级别），以避免对非语义变化重复工作。
  • 有人提出这是否与 Rust 现有的增量编译重叠；当前机制到底覆盖多远仍不清楚。

ABI、后端与生态系统

  • 据说在同一编译器版本中混用 Cranelift 和 LLVM 是安全的，因为 ABI 决策位于共享的、与后端无关的代码中。
  • 平台支持尚不完整：Windows 可用；macOS arm64 存在调用约定方面的复杂性，尚未完全支持。
  • 有些人希望将 Cranelift 用于非 Rust 语言；提到的选项包括文本 IR、Rust 库绑定，或者像 QBE 这样的替代方案。

超级优化与“最大化”优化

  • 线程探讨了为什么超级优化器没有成为标准：计算成本巨大、收益递减、实际应用仅限于很小的热点循环，以及正确性证明复杂。
  • 形成的共识是：如今的编译器会随着时间缓慢提升性能；为构建分配“无限”CPU，实际能带来的收益可能也只是适度的。

总体情绪

  • 许多人对更快的调试和增量构建感到兴奋，并把 Cranelift 视为提升 Rust 易用性的重要一步。
  • 也有人批评这篇文章过于乐观，并强调 LLVM 在峰值运行时性能和广泛的平台成熟度方面仍然更强。