4 ms·

I think it would be a massive boost to the ecosystem to have at least stable and beta use PGO; 16% speed ups are amazing at this point in Rust’s lifetime!

chrismorgan 6y ago
If stable and beta used PGO and nightly didn’t and was consequently 10–20% slower, then there would suddenly be an actual reason to not use nightly! I’m not sure whether that would be good or bad.
- fluffything 6y ago
  I would just use beta instead and "turn it" into a nightly compiler with RUSTC_BOOTSTRAP=1.
  - dodobirdlord 6y ago
    That flag does more than just enable unstable features in the stable compiler, and it should be avoided unless you are actually compiling rustc.
- est31 6y ago
  There are multiple reasons to avoid nightly. One of them is that you don't have to constantly rebuild the entire graph when you want to stay up to date because stable is "only" updated every 6 weeks. Another being that you are less subject to regression bugs hitting you.
  - gpm 6y ago
    You can "only"update nightly every 6 weeks as well, or every 6 months. Nothing says you have to stay up to date. In practice I update when there is something I want in a more recent release. This happens more often with nightly because there are more bugs to be fixed and feature changes, but it isn't that often.
    - est31 6y ago
      And if you find a bug? If it's in a recent nightly or a stable release, you can rightfully file a bug. It will be either fixed on master or a point release will be made. If your nightly is weeks old, you don't really know whether master has fixed it weeks ago or a bug report would be welcome. So you lose this advantage. Anyways, that's not an exhaustive list. Not wanting to deal with rustup might be another reason so you use your distro rustc packages instead.
      - gpm 6y ago
        Finding a compiler bug is rare... but when I do being on an old nightly tends to speed up the reporting process. That's because this is the process 1. Search the bug tracker for the message/symptoms. If you find the bug (more likely on older nightly's) stop here. 2. Create a minimal test case by creating a copy of the code and then deleting large portions of it until you have a dozen or so lines and no dependencies that reproduce it and are all needed to reproduce it. 2.5. If using an old version of rustc, `rustup override set nightly` to use a recent nightly on this directory and see if the bug is gone/changed. This takes about 30 seconds (compilation is instantaneous since I've already deleted all but a dozen lines of code). 3. Search the bug tracker again now that we have a better idea what is going on. 4. If there really is nothing, report it. The time savings by bailing out early at 1. greatly exceed the time cost introduced by 2.5. If you're using nightly you should be using rustup... but since rustup is so easy to use that's a very very low cost.
    - bluejekyll 6y ago
      The problem I’ve found with working on nightly is that APIs and certain impls of features you might rely on are constantly in flux. This ends up requiring you to pin to a specific nightly build date. And then the ecosystem that might also be relying on night starts to shift, and all the sudden you don’t have a stable build anymore. I never experience that on stable, and it’s been my primary reason for not recommending Rocket for so long, even though that it’s an excellent library in all other regards. (I believe it’s working with stable in the master branch at this point, and just waiting on a release of 0.5).
kibwen 6y ago
Experiments with a post-link optimization pass (for rearranging symbols in the binary for optimal access patterns, e.g. BOLT) have suggested another 5% speedup is possible. If LLD ever gets enabled by default that could be another 25-50% off when compared to the system linker (e.g. https://github.com/rust-lang/rust/issues/39915#issuecomment-704595063 https://github.com/rust-lang/rust/issues/39915#issuecomment-... ). And so far Cranelift ( https://github.com/rust-lang/rust/pull/77975 https://github.com/rust-lang/rust/pull/77975 ) shows about 20-30% improvement on debug builds, keeping in mind that what it's gaining from doing less optimizations is being partially offset by giving the linker more to chew on; using Cranelift in conjunction with LLD can give much better results ( https://github.com/bjorn3/rustc_codegen_cranelift/issues/878#issuecomment-599125567 https://github.com/bjorn3/rustc_codegen_cranelift/issues/878... ).
- Ar-Curunir 6y ago
  I'm very excited for my rust builds to get 2x faster over the next year =D
- pjmlp 6y ago
  I look forward to when Rust toolchains can compete with Delphi/Eiffel/.NET/Java in what concerns debug builds, I can let the CI/CD take care of release ones. On a positive note, congratulations to everyone involved doing this work.

chrismorgan 6y ago

If stable and beta used PGO and nightly didn’t and was consequently 10–20% slower, then there would suddenly be an actual reason to not use nightly! I’m not sure whether that would be good or bad.

fluffything 6y ago
I would just use beta instead and "turn it" into a nightly compiler with RUSTC_BOOTSTRAP=1.
- dodobirdlord 6y ago
  That flag does more than just enable unstable features in the stable compiler, and it should be avoided unless you are actually compiling rustc.
est31 6y ago
There are multiple reasons to avoid nightly. One of them is that you don't have to constantly rebuild the entire graph when you want to stay up to date because stable is "only" updated every 6 weeks. Another being that you are less subject to regression bugs hitting you.
- gpm 6y ago
  You can "only"update nightly every 6 weeks as well, or every 6 months. Nothing says you have to stay up to date. In practice I update when there is something I want in a more recent release. This happens more often with nightly because there are more bugs to be fixed and feature changes, but it isn't that often.
  - est31 6y ago
    And if you find a bug? If it's in a recent nightly or a stable release, you can rightfully file a bug. It will be either fixed on master or a point release will be made. If your nightly is weeks old, you don't really know whether master has fixed it weeks ago or a bug report would be welcome. So you lose this advantage. Anyways, that's not an exhaustive list. Not wanting to deal with rustup might be another reason so you use your distro rustc packages instead.
    - gpm 6y ago
      Finding a compiler bug is rare... but when I do being on an old nightly tends to speed up the reporting process. That's because this is the process 1. Search the bug tracker for the message/symptoms. If you find the bug (more likely on older nightly's) stop here. 2. Create a minimal test case by creating a copy of the code and then deleting large portions of it until you have a dozen or so lines and no dependencies that reproduce it and are all needed to reproduce it. 2.5. If using an old version of rustc, `rustup override set nightly` to use a recent nightly on this directory and see if the bug is gone/changed. This takes about 30 seconds (compilation is instantaneous since I've already deleted all but a dozen lines of code). 3. Search the bug tracker again now that we have a better idea what is going on. 4. If there really is nothing, report it. The time savings by bailing out early at 1. greatly exceed the time cost introduced by 2.5. If you're using nightly you should be using rustup... but since rustup is so easy to use that's a very very low cost.
  - bluejekyll 6y ago
    The problem I’ve found with working on nightly is that APIs and certain impls of features you might rely on are constantly in flux. This ends up requiring you to pin to a specific nightly build date. And then the ecosystem that might also be relying on night starts to shift, and all the sudden you don’t have a stable build anymore. I never experience that on stable, and it’s been my primary reason for not recommending Rocket for so long, even though that it’s an excellent library in all other regards. (I believe it’s working with stable in the master branch at this point, and just waiting on a release of 0.5).

kibwen 6y ago

Experiments with a post-link optimization pass (for rearranging symbols in the binary for optimal access patterns, e.g. BOLT) have suggested another 5% speedup is possible. If LLD ever gets enabled by default that could be another 25-50% off when compared to the system linker (e.g. https://github.com/rust-lang/rust/issues/39915#issuecomment-704595063 https://github.com/rust-lang/rust/issues/39915#issuecomment-... ). And so far Cranelift ( https://github.com/rust-lang/rust/pull/77975 https://github.com/rust-lang/rust/pull/77975 ) shows about 20-30% improvement on debug builds, keeping in mind that what it's gaining from doing less optimizations is being partially offset by giving the linker more to chew on; using Cranelift in conjunction with LLD can give much better results ( https://github.com/bjorn3/rustc_codegen_cranelift/issues/878#issuecomment-599125567 https://github.com/bjorn3/rustc_codegen_cranelift/issues/878... ).

Ar-Curunir 6y ago
I'm very excited for my rust builds to get 2x faster over the next year =D
pjmlp 6y ago
I look forward to when Rust toolchains can compete with Delphi/Eiffel/.NET/Java in what concerns debug builds, I can let the CI/CD take care of release ones. On a positive note, congratulations to everyone involved doing this work.