Delete the cfg(not(parallel)) serial compiler - #132282
Conversation
|
cc @davidtwco, @compiler-errors, @TaKO8Ki This PR modifies If appropriate, please update |
fae56ab to
2e9696f
Compare
|
cc @davidtwco, @compiler-errors, @TaKO8Ki This PR modifies If appropriate, please update |
This comment has been minimized.
This comment has been minimized.
2e9696f to
9c4a078
Compare
9c4a078 to
2c453de
Compare
|
This PR modifies If appropriate, please update |
|
☔ The latest upstream changes (presumably #132513) made this pull request unmergeable. Please resolve the merge conflicts. |
2c453de to
09d2f62
Compare
|
@bors p=1 many changes |
cjgillot
left a comment
There was a problem hiding this comment.
I trust you cleaned-up the cfgs correctly.
Some cases of missed formatting for macros there and there, if you don't mind fixing them.
Does this need some kind of heads-up to the team?
r=me if doesn't.
|
From the discussion I think we can land this. @Noratrieb Could you help doing the format work as @cjgillot suggested? |
|
Yes, I will do it, but it may take me a few days. Feel free to push the fix to my branch and approve it if you want to. |
Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead. But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now. Stable and beta have still been on the serial compiler, because they can't use `-Zthreads` anyways. But this is quite suboptimal: - the maintenance burden still sucks - we're not testing the serial compiler in nightly Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now. Let the knight slay one head of the two-headed dragon!
09d2f62 to
505b8e1
Compare
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (6503543): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -1.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 2.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 787.726s -> 784.558s (-0.40%) |
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of rust-lang#132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( rust-lang#113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of rust-lang#132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( rust-lang#113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of rust-lang/rust#132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( rust-lang/rust#113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of rust-lang/rust#132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( rust-lang/rust#113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of rust-lang/rust#132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( rust-lang/rust#113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of rust-lang/rust#132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( rust-lang/rust#113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
A few cleanups after the removal of `cfg(not(parallel))` I noticed a few small things that are no longer needed after the removal of `cfg(not(parallel))` in rust-lang#132282. One of the later changes adjusts several imports, so viewing the changes individually is recommended. r? SparrowLii (or reroll)
Rollup merge of rust-lang#137922 - Zalathar:sharded, r=SparrowLii A few cleanups after the removal of `cfg(not(parallel))` I noticed a few small things that are no longer needed after the removal of `cfg(not(parallel))` in rust-lang#132282. One of the later changes adjusts several imports, so viewing the changes individually is recommended. r? SparrowLii (or reroll)
…l-queries, r=Mark-Simulacrum,onur-ozkan Remove `RUN_CHECK_WITH_PARALLEL_QUERIES` After rust-lang#132282, I'm pretty sure that this is simply useless? It just runs check with an empty config, lol. CC `@onur-ozkan` r? `@Noratrieb`
…lel-queries, r=Mark-Simulacrum,onur-ozkan Remove `RUN_CHECK_WITH_PARALLEL_QUERIES` After rust-lang#132282, I'm pretty sure that this is simply useless? It just runs check with an empty config, lol. CC `@onur-ozkan` r? `@Noratrieb`
Rollup merge of rust-lang#138452 - Kobzol:remove-run-check-with-parallel-queries, r=Mark-Simulacrum,onur-ozkan Remove `RUN_CHECK_WITH_PARALLEL_QUERIES` After rust-lang#132282, I'm pretty sure that this is simply useless? It just runs check with an empty config, lol. CC `@onur-ozkan` r? `@Noratrieb`
Rust crates are compiled in a serial chain on the critical path - core, bindings, kernel crates and then the drivers - each a rustc invocation. With CONFIG_RUST set and every rust driver enabled, the entire chain takes around 25 seconds on a 128-thread machine, with the associated C code taking 24 seconds. Each time a change is made to any of the bindings, it triggers a rebuild. Use the -Zthreads option to have rustc perform builds in parallel. This has been available since rust 1.84 (rust-lang/rust#132282), and the kernel requires rust 1.85 or above. A future -j/--jobs option is planned for rustc:(rust-lang/compiler-team#1005), so check to see if this available and if so use it. If the user's rustc supports neither, then it falls back gracefully and neither are used. The threads are taken from make's jobserver, so a parallel build is not oversubscribed. It was found that benefits level off at 8 threads (16 was found to be around the same, and 32 slower). Generated output was confirmed byte-for-byte identical. Observed build time changes (using rustc 1.98, clang): before after core.o 7.7s 4.9s bindings.o 4.3s 3.1s kernel.o 2.0s 1.4s clean build 39.3s 34.6s touch rust/kernel/lib.rs 12.9s 12.1s touch rust/bindings/bindings_helper.h 19.5s 17.5s Whole build, 128-thread Threadripper 9980X, best of N runs: before after delta ------------------------------- x86 defconfig+RUST, clean 41.0s 36.4s -4.6s (-11%) x86 defconfig+RUST, touch lib.rs 8.3s 7.7s -0.56s (-7%) Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead.
But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now.
Stable and beta have still been on the serial compiler, because they can't use
-Zthreadsanyways.But this is quite suboptimal:
Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now.
Let the knight slay one head of the two-headed dragon!
#113349
Note that the default is still 1 thread, as more than 1 thread is still fairly broken.
cc @onur-ozkan to see if i did the bootstrap field removal correctly, @SparrowLii on the sync parts