5 ms·

I wonder if these graphs capture the new multi-threaded frontend that's on nightly.

by geewee 2y ago

n42 2y ago
genuine question: how much can the frontend really impact compile times at the end of the day? I would guess most of the time spent compiling is on the backend, but IANA compiler engineer
- saagarjha 2y ago
  One obvious example of this would be C++, where a smarter frontend that doesn't do textual inclusion of a million lines would significantly improve compile times.
  - n42 2y ago
    that makes sense. are Rust's macros handled in the frontend? if so, I could see how multithreading could have a dramatic impact
  - menaerus 2y ago
    But that's low-hanging fruit "optimization", no? Once you get around it, and this has been forever, the bottleneck is in the backend generation. So if Rust has already solved this, the area where they can improve most is the backend generation? Most C++ builds I have worked with, and all of them being MMLoC codebases, were actually bottlenecked by the high memory pressure. In part due to heavy templates and symbol visibility.
    - fulafel 2y ago
      I think the history of C++ implementations shows that it's not low hanging fruit, it's a huge effort to implement and the payoffs aren't game changing.
      - menaerus 2y ago
        Modules? Yeah, I don't expect them to be a game changer either. Exactly because of the reasons I mentioned.
- nindalf 2y ago
  > How much can the frontend really impact compile times? Your question is addressed in this blog post - Faster compilation with the parallel front-end in nightly (https://blog.rust-lang.org/2023/11/09/parallel-rustc.html https://blog.rust-lang.org/2023/11/09/parallel-rustc.html). One the example shown there: - Serial took 10.2 seconds in the frontend and 6.2 seconds in the backend. - Parallel tool 5.9 seconds (-42%) and 5.3 seconds (-14.5%). So to answer your question, parallelising the frontend can have a substantial impact. You are right that frontend is only a subset of the total compilation time - backend and linking time matter too. Happily, that's something that's being worked on too! There is an alternate backend called cranelift (https://bjorn3.github.io/2024/11/14/progress-report-nov-2024.html https://bjorn3.github.io/2024/11/14/progress-report-nov-2024...) that compiles faster than LLVM, at the cost of producing slower binaries. That's a good trade-off for debug builds. And there's work on changing the default linker to lld (https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-l...). We may see all 3 efforts land in the next year :)
nindalf 2y ago
These graphs only include stable releases, not nightly ones. Since the multi-threaded frontend hasn't landed on stable yet, we can't see it's effect on these graphs.

I wonder if these graphs capture the new multi-threaded frontend that's on nightly.

by geewee 2y ago

I wonder if these graphs capture the new multi-threaded frontend that's on nightly.

n42 2y ago

genuine question: how much can the frontend really impact compile times at the end of the day? I would guess most of the time spent compiling is on the backend, but IANA compiler engineer

saagarjha 2y ago
One obvious example of this would be C++, where a smarter frontend that doesn't do textual inclusion of a million lines would significantly improve compile times.
- n42 2y ago
  that makes sense. are Rust's macros handled in the frontend? if so, I could see how multithreading could have a dramatic impact
- menaerus 2y ago
  But that's low-hanging fruit "optimization", no? Once you get around it, and this has been forever, the bottleneck is in the backend generation. So if Rust has already solved this, the area where they can improve most is the backend generation? Most C++ builds I have worked with, and all of them being MMLoC codebases, were actually bottlenecked by the high memory pressure. In part due to heavy templates and symbol visibility.
  - fulafel 2y ago
    I think the history of C++ implementations shows that it's not low hanging fruit, it's a huge effort to implement and the payoffs aren't game changing.
    - menaerus 2y ago
      Modules? Yeah, I don't expect them to be a game changer either. Exactly because of the reasons I mentioned.
nindalf 2y ago
> How much can the frontend really impact compile times? Your question is addressed in this blog post - Faster compilation with the parallel front-end in nightly (https://blog.rust-lang.org/2023/11/09/parallel-rustc.html https://blog.rust-lang.org/2023/11/09/parallel-rustc.html). One the example shown there: - Serial took 10.2 seconds in the frontend and 6.2 seconds in the backend. - Parallel tool 5.9 seconds (-42%) and 5.3 seconds (-14.5%). So to answer your question, parallelising the frontend can have a substantial impact. You are right that frontend is only a subset of the total compilation time - backend and linking time matter too. Happily, that's something that's being worked on too! There is an alternate backend called cranelift (https://bjorn3.github.io/2024/11/14/progress-report-nov-2024.html https://bjorn3.github.io/2024/11/14/progress-report-nov-2024...) that compiles faster than LLVM, at the cost of producing slower binaries. That's a good trade-off for debug builds. And there's work on changing the default linker to lld (https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-l...). We may see all 3 efforts land in the next year :)

nindalf 2y ago

These graphs only include stable releases, not nightly ones. Since the multi-threaded frontend hasn't landed on stable yet, we can't see it's effect on these graphs.