[DO NOT MERGE] Enable parallel compiler by default

[bjorn3]

This is a rebase of #75651.

#78201 may have reduced the overhead of parallel rustc.

[rust-highfive]

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 6053526 with merge df18da5db6c9c66898610a29a2401e762c860f0a...

[bjorn3]

failures:
    [ui] ui/privacy/privacy2.rs
    [ui] ui/privacy/privacy3.rs
    [ui] ui/type_length_limit.rs

There are a few cases where the exact error changes.

[bors]

☀️ Try build successful - checks-actions
Build commit: df18da5db6c9c66898610a29a2401e762c860f0a (df18da5db6c9c66898610a29a2401e762c860f0a)

[rust-timer]

Queued df18da5db6c9c66898610a29a2401e762c860f0a with parent 2218520, future comparison URL.

[rust-timer]

Finished benchmarking try commit (df18da5db6c9c66898610a29a2401e762c860f0a): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

[est31]

In the unit test benchmarks, there are sometimes really heavy regressions, but the wall clock time improvement for bigger crates is just beautiful:

---

[bjorn3]

Instruction count difference seems to have gotten a bit worse since the last perf test, however wall time difference seems to have gotten a bit more positive than it already was.

[bjorn3]

Going to do another perf run with only a single thread to see if the overhead in this case has been reduced.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit dec8166 with merge 7cd4a2ec5195e5df4cb2f7292aa53fa3d870cd9f...

[Mark-Simulacrum]

The bootstrap times are actually really interesting, because perf runs that build under -j1 - which should mean that we get zero parallelism opportunity. I guess that means that either our -j1 isn't quite working or something else interesting is going on (e.g., we get better scheduling under parallel mode). Either way I'm not sure I'd trust these numbers given that...

Overall though other than that confusing element these do indeed look pretty good. We can't trust the instruction counts I think pretty much at all for this kind of assessment.

[bors]

☀️ Try build successful - checks-actions
Build commit: 7cd4a2ec5195e5df4cb2f7292aa53fa3d870cd9f (7cd4a2ec5195e5df4cb2f7292aa53fa3d870cd9f)

[rust-timer]

Queued 7cd4a2ec5195e5df4cb2f7292aa53fa3d870cd9f with parent 2218520, future comparison URL.

[rust-timer]

Finished benchmarking try commit (7cd4a2ec5195e5df4cb2f7292aa53fa3d870cd9f): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

[est31]

Now it's way less red in the instruction counts (single digit regressions), but there are regressions for the bootstrap timings.