4 ms·

GCC Rust Monthly Report – October 2021

82 points by philberty 5y ago

egnehots 5y ago
I know it's very early, but I wonder if the compile times could be faster with GCC Rust?
- philberty 5y ago
  It is indeed early to say, but the design of the compiler pipeline is very different to rustc, it is a more traditional pass based system with plenty of side table lookups. Some of the notions are similar we are using HIR but we are not using MIR, GCC's generic IR is very similar. So we have AST->HIR->GCC-Generic->GCC where as rustc is: AST->HIR->THIR->MIR->LLVM-IR->LLVM
  - est31 5y ago
    The rust compiler used to be pass based too, but then became on-demand as that architecture is more amenable for incremental compilation. In that time the performance has improved, although I'm not sure how much this architectural change was responsible for it, I think it were mostly unrelated changes.
  - fnord77 5y ago
    isn't there basically some sort of static analysis going on during the rust compilation to ensure memory is accounted for?
    - kibwen 5y ago
      There are a variety of static checks that Rust performs in order to ensure memory safety. rustc might perform these checks at various parts of the pipeline, but it might be possible for a different compiler to perform these checks at other points depending on what information its chosen IRs encode (for example, borrow checking requires a control-flow graph, which only exists at the MIR stage in rustc).
  - pornel 5y ago
    How are you going to do borrow checking without MIR? Is GCC-Generic suitable for that? Rust moved it from HIR to MIR to handle more edge cases.
- lpapez 5y ago
  From my anectodal experience latest GCC tends to be sligthly/noticeably faster than Clang when compiling C++. I predict the same for Rust - slightly faster but still slow overall since its such a complex language.
jfbaro 5y ago
Hey people, first, congrats for the great work on GCC for RUST, second I have a basic question here from someone who is not experienced with low level languages. Would it be possible (and beneficial to the community) to have a "compiler as a service" in the cloud (either GCC or LLVM based) that would have the most powerful hardware setup available to compile RUST? Really cheap/free per seconds of compilation... so anyone would be able to compile Rust faster and also ANY improvement would de added to this Service... and once new and more powerful hardware is available it could be shared and used by the community. I know we still have to work on improving the compilation times, but maybe having a shared compilation pipeline that can be used by everyone could somehow alleviate the pain a little. Thanks
- bool3max 5y ago
  That sounds terrible.
  - keskadale 5y ago
    People who disagree with it. Why exactly?
    - m4rtink 5y ago
      Security - who knows what ended up in the binaries ?
- kristianpaul 5y ago
  That compiler service is usually put together as part of a Continuous Integration process where if hosted in the cloud you can launch beefy instances on demand and or spot (aws jargon) as part of your development workflow/loop.
- option_greek 5y ago
  I don't mind my laptop not screaming obscenities at me every time I do a cargo build/run. The local changes will have to be synced frequently enough for this to work. May be have the remote compiler named "cargor" and let is seamlessly run the compilation step in cloud. However this might not really work well at all unless the network connection is insanely fast as the build sizes are huge with rust (especially in debug modes).
cletus 5y ago
A fallacy of youth is to overreact to things. This means you buy into hype too easily and overstate doom and gloom. After getting disappointed by hype repeatedly you start to become skeptical and hopefully not jaded. I've been watching Rust for years now and I honestly think it's the most exciting thing in decades in low-level programming. My personal opinion is that C++ is an unsalvageable Frankenlanguage. Memory safety is simply too important going forward and it's one thing Rust is designed for from the ground up. Mistakes have been made and these particularly impact compile-time [1]. I'm not an expert in this field but reading this it sounds like it's difficult to walk back at this point. I don't know how GCC's approach will differ here but I'm excited that it exists and continues to receive significant investment and matures. This can only be good for the Rust ecosystem. [1]: https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/rust-compilation-model-calamity
- mlindner 5y ago
  That blog post is mostly a history of the Rust compiler than it is actually about Rust compile times, which have been continuously getting better. I wouldn't put a lot of stock in it.

82 points by philberty 5y ago

egnehots 5y ago

I know it's very early, but I wonder if the compile times could be faster with GCC Rust?

philberty 5y ago
It is indeed early to say, but the design of the compiler pipeline is very different to rustc, it is a more traditional pass based system with plenty of side table lookups. Some of the notions are similar we are using HIR but we are not using MIR, GCC's generic IR is very similar. So we have AST->HIR->GCC-Generic->GCC where as rustc is: AST->HIR->THIR->MIR->LLVM-IR->LLVM
- est31 5y ago
  The rust compiler used to be pass based too, but then became on-demand as that architecture is more amenable for incremental compilation. In that time the performance has improved, although I'm not sure how much this architectural change was responsible for it, I think it were mostly unrelated changes.
- fnord77 5y ago
  isn't there basically some sort of static analysis going on during the rust compilation to ensure memory is accounted for?
  - kibwen 5y ago
    There are a variety of static checks that Rust performs in order to ensure memory safety. rustc might perform these checks at various parts of the pipeline, but it might be possible for a different compiler to perform these checks at other points depending on what information its chosen IRs encode (for example, borrow checking requires a control-flow graph, which only exists at the MIR stage in rustc).
- pornel 5y ago
  How are you going to do borrow checking without MIR? Is GCC-Generic suitable for that? Rust moved it from HIR to MIR to handle more edge cases.
lpapez 5y ago
From my anectodal experience latest GCC tends to be sligthly/noticeably faster than Clang when compiling C++. I predict the same for Rust - slightly faster but still slow overall since its such a complex language.

jfbaro 5y ago

Hey people, first, congrats for the great work on GCC for RUST, second I have a basic question here from someone who is not experienced with low level languages. Would it be possible (and beneficial to the community) to have a "compiler as a service" in the cloud (either GCC or LLVM based) that would have the most powerful hardware setup available to compile RUST? Really cheap/free per seconds of compilation... so anyone would be able to compile Rust faster and also ANY improvement would de added to this Service... and once new and more powerful hardware is available it could be shared and used by the community. I know we still have to work on improving the compilation times, but maybe having a shared compilation pipeline that can be used by everyone could somehow alleviate the pain a little. Thanks

bool3max 5y ago
That sounds terrible.
- keskadale 5y ago
  People who disagree with it. Why exactly?
  - m4rtink 5y ago
    Security - who knows what ended up in the binaries ?
kristianpaul 5y ago
That compiler service is usually put together as part of a Continuous Integration process where if hosted in the cloud you can launch beefy instances on demand and or spot (aws jargon) as part of your development workflow/loop.
option_greek 5y ago
I don't mind my laptop not screaming obscenities at me every time I do a cargo build/run. The local changes will have to be synced frequently enough for this to work. May be have the remote compiler named "cargor" and let is seamlessly run the compilation step in cloud. However this might not really work well at all unless the network connection is insanely fast as the build sizes are huge with rust (especially in debug modes).

cletus 5y ago

A fallacy of youth is to overreact to things. This means you buy into hype too easily and overstate doom and gloom. After getting disappointed by hype repeatedly you start to become skeptical and hopefully not jaded. I've been watching Rust for years now and I honestly think it's the most exciting thing in decades in low-level programming. My personal opinion is that C++ is an unsalvageable Frankenlanguage. Memory safety is simply too important going forward and it's one thing Rust is designed for from the ground up. Mistakes have been made and these particularly impact compile-time [1]. I'm not an expert in this field but reading this it sounds like it's difficult to walk back at this point. I don't know how GCC's approach will differ here but I'm excited that it exists and continues to receive significant investment and matures. This can only be good for the Rust ecosystem. [1]: https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/rust-compilation-model-calamity

mlindner 5y ago
That blog post is mostly a history of the Rust compiler than it is actually about Rust compile times, which have been continuously getting better. I wouldn't put a lot of stock in it.