Skip to content
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

Merged
merged 2 commits into from
Oct 2, 2019

Conversation

Mark-Simulacrum
Copy link
Member

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

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.
@Mark-Simulacrum Mark-Simulacrum added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 23, 2019
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 23, 2019
@Mark-Simulacrum
Copy link
Member Author

Going to nominate for infra and compiler teams as I'd like to check that the claims I've made are true:

  • usage is minimal, mostly to deal with LLVM-related regressions (-Zthreads=1 is probably enough to sidestep any bugs in parallel that could impact this)
  • we are comfortable altering them in such a "big" way.

@Mark-Simulacrum Mark-Simulacrum added I-nominated S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 23, 2019
@pnkfelix
Copy link
Member

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.

@pnkfelix
Copy link
Member

(leaving nominated tag on, but at this point that is directed at T-infra, not T-compiler.)

@Mark-Simulacrum
Copy link
Member Author

r? @alexcrichton

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?

@alexcrichton
Copy link
Member

Would it be possible to configure these compilers to be built with -j1 for everything except the codegen backend? I'm basically curious if we can just enable parallelism but not use it.

@Mark-Simulacrum
Copy link
Member Author

I think that's "just" -Zthreads=1 at runtime but I can take a look to both verify that theory and, if so, hard code that as the default (perhaps via a cfg flag or something).

@alexcrichton
Copy link
Member

Ah ok, great! In that case actually, I think it'd be best to default to -Zthreads=1 by default? Basically leave everything as-is, but just producing "parallel capable" compilers here.

@Mark-Simulacrum
Copy link
Member Author

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.

@@ -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],
Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, yeah.

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.
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Sep 30, 2019

📌 Commit f271c155f02c8a5fd7e079d1d7f21d188ee1f8f9 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Sep 30, 2019
@Mark-Simulacrum
Copy link
Member Author

Was a bit overeager pushing, there's a new commit up (no significant differences)

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed I-nominated S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 30, 2019
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Sep 30, 2019

📌 Commit 1a1067d has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 30, 2019
Centril added a commit to Centril/rust that referenced this pull request Oct 1, 2019
…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
tmandry added a commit to tmandry/rust that referenced this pull request Oct 1, 2019
…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
tmandry added a commit to tmandry/rust that referenced this pull request Oct 1, 2019
…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
tmandry added a commit to tmandry/rust that referenced this pull request Oct 2, 2019
…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
bors added a commit that referenced this pull request Oct 2, 2019
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
@bors bors merged commit 1a1067d into rust-lang:master Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants