-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make all alt builders produce parallel-enabled compilers #64722
Conversation
We're not quite ready to ship parallel compilers by default, but the alt builders are not used too much (in theory), so we believe that shipping a possibly-broken compiler there is not too problematic.
Going to nominate for infra and compiler teams as I'd like to check that the claims I've made are true:
|
Discussed in T-compiler meeting. We ourselves don't see any problem with doing this as described here. In particular, @nikomatsakis wanted to stress that we do plan to keep LLVM assertions enabled for these builds. This will mean that these builds help flush out parallel bugs, but they will not be a good basis for comparative benchmarking. |
(leaving nominated tag on, but at this point that is directed at T-infra, not T-compiler.) |
I believe we discussed this in the infra meeting and there weren't any major objections -- could you just make sure this is doing what it's intended and such and approve if you think we're good to go here? |
Would it be possible to configure these compilers to be built with |
I think that's "just" |
Ah ok, great! In that case actually, I think it'd be best to default to |
Alright, I pushed up another commit that makes the default for query parallelism 1, instead of num_cpus as before. This does not affect the codegen parallelism. |
src/librustc/session/config.rs
Outdated
@@ -1259,7 +1259,7 @@ options! {DebuggingOptions, DebuggingSetter, basic_debugging_options, | |||
"prints the LLVM optimization passes being run"), | |||
ast_json: bool = (false, parse_bool, [UNTRACKED], | |||
"print the AST as JSON and halt"), | |||
threads: Option<usize> = (None, parse_opt_uint, [UNTRACKED], | |||
threads: Option<usize> = (Some(1), parse_opt_uint, [UNTRACKED], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems a bit odd to have this be Option<usize>
when the default isn't None
, could this instead change threads_from_count
, and a comment could be included why it's defaulted to one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, yeah.
550df4d
to
f271c15
Compare
This changes the default parallelism for parallel compilers to one, instead of the previous default, which was "num cpus". This is likely not an optimal default long-term, but it is a good default for testing whether parallel compilers are not a significant regression over a sequential compiler. Notably, this in theory makes a parallel-enabled compiler behave exactly like a sequential compiler with respect to the jobserver.
@bors: r+ |
📌 Commit f271c155f02c8a5fd7e079d1d7f21d188ee1f8f9 has been approved by |
f271c15
to
1a1067d
Compare
Was a bit overeager pushing, there's a new commit up (no significant differences) |
@bors: r+ |
📌 Commit 1a1067d has been approved by |
…xcrichton Make all alt builders produce parallel-enabled compilers We're not quite ready to ship parallel compilers by default, but the alt builders are not used too much (in theory), so we believe that shipping a possibly-broken compiler there is not too problematic. r? @nikomatsakis
…xcrichton Make all alt builders produce parallel-enabled compilers We're not quite ready to ship parallel compilers by default, but the alt builders are not used too much (in theory), so we believe that shipping a possibly-broken compiler there is not too problematic. r? @nikomatsakis
…xcrichton Make all alt builders produce parallel-enabled compilers We're not quite ready to ship parallel compilers by default, but the alt builders are not used too much (in theory), so we believe that shipping a possibly-broken compiler there is not too problematic. r? @nikomatsakis
…xcrichton Make all alt builders produce parallel-enabled compilers We're not quite ready to ship parallel compilers by default, but the alt builders are not used too much (in theory), so we believe that shipping a possibly-broken compiler there is not too problematic. r? @nikomatsakis
Rollup of 11 pull requests Successful merges: - #64649 (Avoid ICE on return outside of fn with literal array) - #64722 (Make all alt builders produce parallel-enabled compilers) - #64801 (Avoid `chain()` in `find_constraint_paths_between_regions()`.) - #64805 (Still more `ObligationForest` improvements.) - #64840 (SelfProfiler API refactoring and part one of event review) - #64885 (use try_fold instead of try_for_each to reduce compile time) - #64942 (Fix clippy warnings) - #64952 (Update cargo.) - #64974 (Fix zebra-striping in generic dataflow visualization) - #64978 (Fully clear `HandlerInner` in `Handler::reset_err_count`) - #64979 (Update books) Failed merges: - #64959 (syntax: improve parameter without type suggestions) r? @ghost
We're not quite ready to ship parallel compilers by default, but the alt
builders are not used too much (in theory), so we believe that shipping
a possibly-broken compiler there is not too problematic.
r? @nikomatsakis