Make incremental compilation the default for all profiles. #6564
Conversation
|
Interesting! How does one enable incremental compilation for the release and bench profiles right now? |
|
By setting the |
|
lolbench consumes toolchains via rustup, so as long as that works for you you'll get the data you want. Gosh, I'm a little sad that not having had time for a try feature could now be a part of the geology of EDIT: I think https://github.com/rust-lang/rust-central-station/issues/82#issuecomment-414419239 will be a prereq of try-jobs if someone wants to help me out there. |
|
I'm personally fine with this, but this may want some more buy-in perhaps? Should we pull in the compiler team and/or FCP with a set of folks for this? |
|
We discussed this in the @rust-lang/compiler triage meeting. The team seems to be in favor of enabling this now, in order to collect data via lolbench, and then unconditionally disabling it again at the beginning of the all hands. |
|
@bors: r+ Ok! |
|
📌 Commit 2c40858 has been approved by |
…, r=alexcrichton Make incremental compilation the default for all profiles. This PR makes incremental compilation the default for all profiles, that is, also `release` and `bench`. `rustc` performs ThinLTO by default for incremental release builds for a while now and the [data we've gathered so far](rust-lang/rust#56678) indicates that the generated binaries exhibit roughly the same runtime performance as non-incrementally compiled ones. At the same time, incremental release builds can be 2-5 times as fast as non-incremental ones. Making incremental compilation (temporarily) the default in `cargo` would be a simple way of gathering more data about runtime performance via [lolbench.rs](https://lolbench.rs). If the results look acceptable, we can just leave it on and give a massive compile time reduction to everyone. If not, we can revert the change and think about a plan B. This strategy assumes that lolbench will actually use the nightly `cargo` version. Is that true, @anp? r? @alexcrichton
|
☀️ Test successful - checks-travis, status-appveyor |
…pietroalbini bootstrap: Don't rely on any default settings regarding incr. comp. in Cargo rust-lang/cargo#6564 (temporarily) makes incremental compilation the default for release builds. We don't want this default to apply to building the compiler itself, that is, `bootstrap`'s `incremental` flag should always be respected. Otherwise we'll get incrementally build releases, which we really don't want `:)`. r? @Mark-Simulacrum Anybody else from @rust-lang/release should feel free to r+ this too if they get around to it earlier.
|
I think this change broke release builds for embedded projects. The embedded template used by the community has this in its Cargo.toml: [profile.release]
codegen-units = 1 # better optimizations
debug = true # symbols are nice and they don't increase the size on Flash
lto = true # better optimizationsThese settings produce a the following error: "can't perform LTO when compiling incrementally" with the latest nightly. Adding |
|
@japaric Since we are enabling this just for data collection at the moment and will revert at the end of this week, do think we should do something here now? |
|
@michaelwoerister would it be possible to not enable incremental if |
|
I've gone ahead and posted the revert for this at #6610, and @michaelwoerister we've got a nightly or two now with the incremental bit turned on so I think we're good to go for benchmarking, right? @japaric this is definitely something we'll handle before turning it back on by default for real! @michaelwoerister do you perhaps want to make a tracking issue for turning on incremental by default in release mode? |
|
Which is the first nightly when this was on? (for looking at lolbench) |
|
@Eh2406 nightly-2019-01-28 is the first one. |
|
Sorry for the breakage, @japaric!
Will do. If I understand things correctly #6610 reverts the change in Cargo but the change still takes some time to bubble up to nightlies? I think we have some good numbers already, so I'm OK with ending the experiment. |
Done: rust-lang/rust#57968 |
Lately I've been doing updates around once a week. The last update was 2 days ago, so I would probably do it this coming weekend. Do you feel like this issue is important enough to update now? (Which is totally fine, it's usually not difficult, just depends on how long you want the experiment to last.) |
|
The original plan was to keep it running throughout the week. It depends on how much trouble this creates for the embedded folks. |
Tested with: `rustc 1.34.0-nightly (8ae730a44 2019-02-04)` This commit fixes the compilation error: "can't perform LTO when compiling incrementally" by disabling incremental compilation for the `release` and `bench` profiles. <rust-lang/cargo#6564> enabled incremental compilation by default but it cannot be used at the same time with ThinLTO (hence the compile error). While incremental compilation provides a significant boost to compilation speed, I consider that the runtime performance is the utmost importance for these build types.
This PR makes incremental compilation the default for all profiles, that is, also
releaseandbench.rustcperforms ThinLTO by default for incremental release builds for a while now and the data we've gathered so far indicates that the generated binaries exhibit roughly the same runtime performance as non-incrementally compiled ones. At the same time, incremental release builds can be 2-5 times as fast as non-incremental ones.Making incremental compilation (temporarily) the default in
cargowould be a simple way of gathering more data about runtime performance via lolbench.rs. If the results look acceptable, we can just leave it on and give a massive compile time reduction to everyone. If not, we can revert the change and think about a plan B.This strategy assumes that lolbench will actually use the nightly
cargoversion. Is that true, @anp?r? @alexcrichton