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

Use conditional synchronization for Lock #111713

Merged
merged 2 commits into from
Aug 30, 2023
Merged

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented May 18, 2023

This changes Lock to use synchronization only if mode::is_dyn_thread_safe could be true. This reduces overhead for the parallel compiler running with 1 thread.

The emitters are changed to use DynSend instead of Send so they can still use Lock.

A Rayon thread pool is not used with 1 thread anymore, as session globals contains Locks which are no longer Sync.

Performance improvement with 1 thread and cfg(parallel_compiler):

BenchmarkBeforeAfter
TimeTime%
🟣 clap:check1.7665s1.7336s💚 -1.86%
🟣 hyper:check0.2780s0.2736s💚 -1.61%
🟣 regex:check0.9994s0.9824s💚 -1.70%
🟣 syn:check1.5875s1.5656s💚 -1.38%
🟣 syntex_syntax:check6.0682s5.9532s💚 -1.90%
Total10.6997s10.5083s💚 -1.79%
Summary1.0000s0.9831s💚 -1.69%

cc @SparrowLii

@rustbot
Copy link
Collaborator

rustbot commented May 18, 2023

r? @davidtwco

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels May 18, 2023
@rustbot
Copy link
Collaborator

rustbot commented May 18, 2023

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

@rust-log-analyzer

This comment has been minimized.

compiler/rustc_data_structures/src/sync/lock.rs Outdated Show resolved Hide resolved
Cargo.lock Outdated Show resolved Hide resolved
@SparrowLii
Copy link
Member

It looks good to me. cc @cjgillot @nnethercote

Copy link
Member

@davidtwco davidtwco left a comment

Choose a reason for hiding this comment

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

Apologies for the delay in reviewing this - looks good to me, but I'll re-assign to someone involved in compiler performance/parallel compiler to double check.

@davidtwco
Copy link
Member

r? @nnethercote

@rustbot rustbot assigned nnethercote and unassigned davidtwco Jun 27, 2023
Copy link
Contributor

@nnethercote nnethercote left a comment

Choose a reason for hiding this comment

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

I'm starting to get really uncomfortable with the amount of extra complexity being added for the whole single-thread vs multi-threaded split for the parallel front-end.

More specifically, for this PR, there is an entirely new file, lock.rs, which is 242 lines, implementing a critical low-level type, involving UnsafeCell and a bunch of unsafe blocks, and it has just one two-line comment. That's not enough. Without additional documentation I can't understand the code well enough to review it and give an r+ in good conscience.

I suggest adding:

  • A top-level comment to lock.rs explaining at a high-level what is going on.
  • Comments on more of the types, like LockRawUnion and LockRaw.
  • Comments on and/or within some of the more complex functions.
  • Comments on unsafe blocks, explaining why they're safe.
  • Any other comments above and beyond these would also be fine.

@@ -1,4 +1,4 @@
use crate::sync::Lock;
use parking_lot::Mutex;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why the Lock to Mutex changes in this file? Is this code not used in the serial front-end?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not used in the serial compiler and it's quite cold.

type Target = T;
#[inline]
fn deref(&self) -> &T {
unsafe { &*self.lock.data.get() }
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this unsafe?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The get method on UnsafeCell is not safe.

@nnethercote nnethercote added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 28, 2023
@bors
Copy link
Contributor

bors commented Jul 20, 2023

☔ The latest upstream changes (presumably #108714) made this pull request unmergeable. Please resolve the merge conflicts.

@Dylan-DPC
Copy link
Member

@Zoxc any updates on this?

@Zoxc
Copy link
Contributor Author

Zoxc commented Aug 14, 2023

I've added some documentation to this now.

@bors
Copy link
Contributor

bors commented Aug 30, 2023

⌛ Testing commit 16eae91781eef660e19400d451ce1bab3a1dacf7 with merge e507b3d655f189b6382af2000caf319468f847b4...

@bors
Copy link
Contributor

bors commented Aug 30, 2023

☀️ Test successful - checks-actions
Approved by: nnethercote
Pushing e507b3d655f189b6382af2000caf319468f847b4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 30, 2023
@bors
Copy link
Contributor

bors commented Aug 30, 2023

👀 Test was successful, but fast-forwarding failed: 422 Update is not a fast forward

@Zoxc
Copy link
Contributor Author

Zoxc commented Aug 30, 2023

@bors retry

2 similar comments
@SparrowLii
Copy link
Member

@bors retry

@nnethercote
Copy link
Contributor

@bors retry

@nnethercote
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Aug 30, 2023

📌 Commit d35179f has been approved by nnethercote

It is now in the queue for this repository.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (e507b3d655f189b6382af2000caf319468f847b4): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

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.

mean range count
Regressions ❌
(primary)
0.5% [0.5%, 0.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.5% [0.5%, 0.5%] 1

Cycles

Results

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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.1% [1.6%, 4.0%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 630.625s -> 631.483s (0.14%)
Artifact size: 315.99 MiB -> 316.06 MiB (0.02%)

@bors
Copy link
Contributor

bors commented Aug 30, 2023

⌛ Testing commit d35179f with merge 61efe9d...

@bors
Copy link
Contributor

bors commented Aug 30, 2023

☀️ Test successful - checks-actions
Approved by: nnethercote
Pushing 61efe9d to master...

@bors bors merged commit 61efe9d into rust-lang:master Aug 30, 2023
11 checks passed
@rustbot rustbot added this to the 1.74.0 milestone Aug 30, 2023
@Zoxc Zoxc deleted the lock-switch branch August 30, 2023 16:09
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (61efe9d): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Warning ⚠: The following benchmark(s) failed to build:

  • syn-1.0.89
  • exa-0.10.1

cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.3% [2.3%, 2.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.3% [2.3%, 2.3%] 1

Max RSS (memory usage)

Results

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.

mean range count
Regressions ❌
(primary)
2.5% [0.5%, 4.9%] 3
Regressions ❌
(secondary)
2.5% [1.0%, 4.5%] 4
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.5% [0.5%, 4.9%] 3

Cycles

Results

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.

mean range count
Regressions ❌
(primary)
2.2% [2.2%, 2.2%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.2% [2.2%, 2.2%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 630.791s -> 632.146s (0.21%)
Artifact size: 316.62 MiB -> 316.62 MiB (0.00%)

@rustbot rustbot added the perf-regression Performance regression. label Aug 31, 2023
@nnethercote
Copy link
Contributor

We have possible infinite loops for two rustc-perf benchmarks: exa-0.10.1 and syn-1.0.89. If they persist this PR will have to be backed out.

@SparrowLii
Copy link
Member

@nnethercote How can we re-product this error?

@Zoxc
Copy link
Contributor Author

Zoxc commented Aug 31, 2023

The changes are quite small without cfg(parallel_compiler) and it passed perf just before merging. It doesn't seem likely that this PR is the cause.

@lqd
Copy link
Member

lqd commented Aug 31, 2023

The latest results have 13 benchmarks for syn, while this PR has 11, so it seems like whatever happened was a transient issue maybe?

@pnkfelix
Copy link
Member

pnkfelix commented Sep 5, 2023

The instruction-count regression(s) here appear spurious from what I can see.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Sep 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.