Parallel frontend compiler support (perf backend only)

[heinwol]

Supersedes #2421, but only backend (profiler/bencher/database). As said in parent pr, parallel frontend support is implemented as additional dimension with corresponding row added to the database

[Kobzol]

Thanks for the PR! Let's revert the last commit; the CI failure shows why we need to have a custom environment variable, so that it will also work with a stable Rust compiler.

[heinwol]

I'm not sure I quite like a separate environment variable for that; don't we have a better mechanism? Also, maybe a collector run shouldn't silently revert to single-threaded scenario in an unsupported version, which it currently does, for my understanding? However, it seems like it's a common behavior in collector/src/lib.rs::async fn bench_published_artifact:

// ...
    let profiles = if collector::version_supports_doc(&toolchain.id) {
        vec![Profile::Check, Profile::Debug, Profile::Doc, Profile::Opt]
    } else {
        vec![Profile::Check, Profile::Debug, Profile::Opt]
    };
    let scenarios = if collector::version_supports_incremental(&toolchain.id) {
        Scenario::all()
    } else {
        Scenario::all_non_incr()
    };
    let frontend_threads_counts = if collector::version_supports_parallel_frontend(&toolchain.id) {
        FrontendThreads::default_opts()
    } else {
        vec![FrontendThreads(1)]
    };
// ...

So it might be i'm looking too hard into it...

[Kobzol]

bench_published_artifact is only used for benchmarking stable versions of the compiler, which is ~never done locally, and we need to keep compatibility with Rust going all the way back to 1.26.0, so I wouldn't worry about that.

[Kobzol]

Thanks for separating the PR! Did a first review pass. Adding a new benchmark axis is always cumbersome, as it requires changing many places, and this one is also tricky, because it doesn't have a closed set of values, but is just a number. But in general it looks good, just

Please revert all the site changes, the integration with the frontend and also the job queuing system should be done in a follow-up PR. For now everything on production will just assume frontend count 1.

[Kobzol]

Let's remove the par_n function, it contains a hardcoded string prefix that is then used in several places. That shouldn't belong in the database module.

[Kobzol]

Hmm, this is tricky, because for the old version that doesn't support the flag, we would either:

• Not pass the RUSTC_THREAD_COUNT at all (which happens now). That works for the old compiler, but if we change the default thread count in the future, then setting --frontend-threads=1 will actually use the default number of threads, which is misleading.
• Still try to pass -Zthreads=1. That will ensure that we are using the right number of threads, but it will break benchmarking on Rust <1.33.0.

I would suggest changing this to always pass the flag. It is better to break benchmarking on Rust <1.33.0, which likely won't be needed in the near future, than to use an unexpected thread count by mistake.

[Kobzol]

Suggested change

	if self.frontend_threads.0 != 1 {
	cmd.env("RUSTC_THREAD_COUNT", self.frontend_threads.0.to_string());
	}
	cmd.env("RUSTC_THREAD_COUNT", self.frontend_threads.0.to_string());

[heinwol]

Thanks for the fast yet sizable review! I'm sorry for calling out for you so early; i'm not sure this pr is quite review-ready. I'll try to resolve what you commented for now and then dive more into how this works! As until now all i did is brainless-ish renaming, lol

[Kobzol]

To be fair, adding a new benchmark axis mostly involves a lot of brainless-ish renaming :) I think that the PR is mostly good to go, though it will require a couple of follow-up PRs to:

1. Add integration in the website backend and frontend
2. Modify the job queue to be able to distinguish that different jobs can have different frontend thread counts

[heinwol]

The dumb part is more or less done, now i'll be dealing with threads argument propagation and fallback legacy paths

EDIT: oh, and the par_n one