5 ms·

Any fresh compilation time benchmarks and comparisons to LLVM?

• zokier 3y ago
  From the article: > A full debug build of Cranelift itself using the Cranelift backend took 29.6 seconds on my computer, compared to 37.5 with LLVM (a reduction in wall-clock time of 20%) That seems much smaller difference than what I would have expected
  • __s 3y ago
    Those numbers are the entire compile time, parsing/typecheck/MIR+MIR optimization/linking Don't have numbers handy, so hard to say how much faster Cranelift is making the codegen portion, but gets into Amdahl's Law
    • Filligree 3y ago
      And there are faster linkers than the default. …why is it still the default?
      • 3836293648 3y ago
        Compatibility with niche usecases
        • Filligree 3y ago
          That sounds like a good reason to keep the existing one as an opt-in possibility.
      • kibwen 3y ago
        Because the linker provided by the system itself is the one that's guaranteed to be the most broadly compatible. For a toolchain to begin distributing an alternative linker is a lot of work on every supported platform (future versions of Rust may sidestep this issue by making LLD the default on certain platforms, which they get "for free" by dint of shipping alongside LLVM). But also, because there are about ten people on planet Earth qualified to write a production-grade linker, which is why LLD still isn't broadly recommended yet.
• boxed 3y ago
  The very last paragraph: > A full debug build of Cranelift itself using the Cranelift backend took 29.6 seconds on my computer, compared to 37.5 with LLVM (a reduction in wall-clock time of 20%). Those wall-clock times don't tell the full story, however, because of parallelism in the build system. Compiling with Cranelift took 125 CPU-seconds, whereas LLVM took 211 CPU-seconds, a difference of 40%. Incremental builds — rebuilding only Cranelift itself, and none of its dependencies — were faster with both backends. 66ms of CPU time compared to 90ms.
• AlexErrant 3y ago
  Not quite fresh, but > A paper from 2020 [0] showed that Cranelift was an order of magnitude faster than LLVM, while producing code that was approximately twice as slow on some benchmarks. [0] https://arxiv.org/pdf/2011.13127.pdf https://arxiv.org/pdf/2011.13127.pdf
  • Findecanor 3y ago
    The changes in Cranelift since 2020 have been quite significant so I would not put any trust in those benchmarks.
• nindalf 3y ago
  Few reports comparing Cranelift to LLVM from this day old reddit thread [1] - 29.52s -> 24.47s (17.1%) - 27s -> 19s (29.6%) - 11.5s -> 8.4s (26.9%) - 37.5s -> 29.6s (28.7%) - this measurement from TFA. To put these numbers in context, all the perf improvements over the last 4 years have helped the compiler become faster on a variety of workloads by 7%, 17%, 13% and 15%, for an overall speed gain of 37% over 4 years. [2] So one large change providing a 20-30% improvement is very impressive. When you add that to the parallel frontend [3] and support for linking with LLD [4], Rust compilation could be substantially faster by this time next year. [1] - https://old.reddit.com/r/rust/comments/1bgyo8a/try_cranelift_codegen_backend_for_faster_compile/ https://old.reddit.com/r/rust/comments/1bgyo8a/try_cranelift... [2] - https://nnethercote.github.io/2024/03/06/how-to-speed-up-the-rust-compiler-in-march-2024.html https://nnethercote.github.io/2024/03/06/how-to-speed-up-the... [3] - https://blog.rust-lang.org/2023/11/09/parallel-rustc.html https://blog.rust-lang.org/2023/11/09/parallel-rustc.html [4] - https://github.com/rust-lang/rust/issues/39915 https://github.com/rust-lang/rust/issues/39915
  • k_bx 3y ago
    Thanks, that's really great news. The only thing I wish for now is aarch64 support on Apple Silicon