【问题标题】:Why does Rust compile a simple program 5-10 times slower than gcc/clang?为什么 Rust 编译一个简单的程序比 gcc/clang 慢 5-10 倍?
【发布时间】:2016-05-21 11:59:13
【问题描述】:

跟进Rust minimal compiled program size

rustc hello.rs
> 600 ms

为什么rustc 编译一个简单的 Hello World 比 gcc/clang 慢 5-10 倍?

Rust 使用 LLVM,因此它应该与 clang 相当。无论如何,我们谈论的是一个只有三行代码的程序。

rustc hello.rs -C opt-level=0 -C prefer-dynamic
> 400 ms

gcc hello.c
> 60 ms

clang hello.c
> 110 ms

【问题讨论】:

  • 我猜是类型检查和借用检查。另请注意,println! 会扩展为一些非常复杂的代码,这与 C 的 printf 不同,后者是一个简单的函数调用。
  • @kennytm, 500 ms 对一行代码进行类型检查?
  • 查看this 讨论并查看此compilation times 移植到Rust 的C++ 程序。
  • 您可以通过将-Z time-passes 传递给编译器来检查编译器的每次传递需要多长时间。经验表明你会发现大部分时间都花在了后端(翻译到 LLVM IR、LLVM 的优化和代码生成、链接)。
  • 单个数据点几乎无关紧要,尤其是考虑到很少有实际程序只有一行代码。对多个同类项目执行相同的分析。一个 10KLOC 程序在两者中编译需要多长时间?然后,您可以开始讨论编译时的开销(如果有的话)是否会妨碍程序员在其他地方的时间,例如在调试中(请参阅之前所有关于“编写和运行测试的时间太长”的讨论以获取类似的论点)。

标签: rust


【解决方案1】:

首先,我认为比较两个极其简单的程序的编译时间并期望结果更普遍地代表两种语言之间的编译时间,我认为没有什么意义。

也就是说,我确实希望 Rust,作为一种提供比高级语言更常见的抽象级别且几乎没有运行时性能成本的语言,必须在编译时在一定程度上为此付出代价。

这段摘自the Rust FAQ:

Rust 编译似乎很慢。这是为什么呢?

代码翻译和优化。 Rust 提供了高级别的 编译成高效机器代码的抽象,以及那些 翻译需要时间来运行,尤其是在优化时。

但是 Rust 的编译时间并没有看起来那么糟糕,而且还有 有理由相信它会改善。在比较类似项目时 大小介于 C++ 和 Rust 之间,整个项目的编译时间为 一般认为具有可比性。 Rust 的普遍看法 编译速度慢很大程度上是由于 C++ 和 Rust 之间的编译模型:C++ 的编译单元是 文件,而 Rust 是箱子,由许多文件组成。因此,期间 开发,修改单个 C++ 文件可能会导致更少 重新编译比在 Rust 中。正在进行一项重大努力 重构编译器以引入增量编译,这将 为 Rust 提供 C++ 模型的编译时间优势。

除了编译模型,还有其他几个方面 Rust 的语言设计和编译器实现会影响 编译时性能。

首先,Rust 有一个中等复杂的类型系统,并且必须花费 执行约束的编译时间不可忽略 让 Rust 在运行时安全。

其次,Rust 编译器长期存在技术债务, 尤其是生成质量差的 LLVM IR,LLVM 必须花费时间 “定影”。希望未来基于 MIR 的优化和 翻译通行证将减轻 Rust 编译器的负担 LLVM。

第三,Rust 使用 LLVM 进行代码生成是一把双刃剑 剑:虽然它使 Rust 拥有世界级的运行时性能, LLVM 是一个不关注编译时的大型框架 性能,尤其是在处理质量较差的输入时。

最后,Rust 首选的单态泛型策略 (ala C++)生成快速代码,它需要更多的代码 比其他翻译策略生成。 Rust 程序员可以 使用 trait 对象通过使用动态来交换这个代码膨胀 而是派遣。

【讨论】:

  • 太糟糕了,C++ 编译时间慢得令人无法接受。 “看,当我们与最糟糕的语言进行比较时,我们是不相上下的。”这不是一个令人信服的论点。
  • @RolandIllig 但很高兴知道您是否将 Rust 与 C++ 进行比较,很多人都会这样做。
猜你喜欢
  • 1970-01-01
  • 2022-01-22
  • 1970-01-01
  • 2019-04-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-12-21
  • 2014-10-05
相关资源
最近更新 更多