Resolver: Parallelize the import resolution loop

[LorrensP-2158466]

View all comments

Follow up of #159440. This pr implements the parallel part of par_for_each_slice. And implements DynSend and DynSync for RefOrMut and CmCell to make the call to par_for_each_slice compile.

This is the bare minimum to make the parallel loop work and is not at all optimized, this will follow :).

r? @petrochenkov

[LorrensP-2158466]

Lets see what CI says.

I have tried to add comments to changes to show my thought process behind them, but i'll make another pass here as well to be sure.

[petrochenkov]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 3df1fed (3df1fed3aaf1081aa59cfe2228eed289a2ef744e)
Base parent: 3c00c96 (3c00c96d3af4d5b5e101e56cc161a608b21366ee)

[rust-bors]

☀️ Try build successful (CI)
Build commit: 7af71a9 (7af71a96afa07b00d71dbdd82c8ef5cb8e075b2d)
Base parent: c188565 (c188565812a9b414ddf02f3c7d89e84f1ba53f7d)

[rust-timer]

Finished benchmarking commit (7af71a9): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.1%, 0.8%]	127
Regressions ❌ (secondary)	0.4%	[0.1%, 1.1%]	56
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.1%, 0.8%]	127

Max RSS (memory usage)

Results (secondary 4.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.2%	[3.4%, 5.0%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (primary 1.6%, secondary 2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 489.502s -> 487.276s (-0.45%)
Artifact size: 387.76 MiB -> 387.80 MiB (0.01%)

[petrochenkov]

@LorrensP-2158466
Could you apply #159452 on top of this so we could benchmark the changes together?

[LorrensP-2158466]

@petrochenkov cherry picked the 3 commits.

[petrochenkov]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: b4cc008 (b4cc008d6abf87b081f7d12fa4bbffce0da89401)
Base parent: ae3bbe7 (ae3bbe78ec2a9bb57a03f10ad6ee0388e12bcefb)

[rust-timer]

Finished benchmarking commit (b4cc008): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.6%]	83
Regressions ❌ (secondary)	0.3%	[0.1%, 0.8%]	55
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.6%, -0.3%]	6
All ❌✅ (primary)	0.3%	[0.1%, 0.6%]	83

Max RSS (memory usage)

Results (primary 2.2%, secondary 3.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.2%	[0.8%, 3.9%]	4
Regressions ❌ (secondary)	4.2%	[1.5%, 5.8%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-1.8%, -1.8%]	1
All ❌✅ (primary)	2.2%	[0.8%, 3.9%]	4

Cycles

Results (primary 3.6%, secondary -4.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 487.635s -> 488.963s (0.27%)
Artifact size: 387.74 MiB -> 387.89 MiB (0.04%)

[petrochenkov]

Nice, the conditional RwLock shows smaller regressions here.

[petrochenkov]

Wait, why does CmRefCell need to use RwLock?
We can only modify its data if we have exclusive access to it (speculative is disabled), that's the whole point.

[LorrensP-2158466]

Wait, why does CmRefCell need to use RwLock?
We can only modify its data if we have exclusive access to it (speculative is disabled), that's the whole point.

I think I already explained why we need this, though I can't find. Basically, in the functions concerned with retrieving a resolution, we use borrow:

fn resolutions(&self, module: Module<'ra>) -> &'ra Resolutions<'ra> {
    if !module.is_local() {
        // as long as 1 thread is building this external table, all other threads will wait
        module.populate_on_access.call_once(|| {
            *module.lazy_resolutions.borrow_mut_unchecked() =
                self.build_reduced_graph_external(module.expect_extern());
        });
    }
    &module.0.0.lazy_resolutions
}

fn resolution(
    &self,
    module: Module<'ra>,
    key: BindingKey,
) -> Option<ReadGuard<'ra, NameResolution<'ra>>> {
    self.resolutions(module).borrow().get(&key).map(|resolution| resolution.0.borrow())
}

These get called during speculative resolution, so the borrow counter needs to be synchronized. We use CmRefCell for both Resolutions of a module and NameResolution:

type Resolutions<'ra> = CmRefCell<FxIndexMap<BindingKey, NameResolutionRef<'ra>>>;


pub(crate) type NameResolutionRef<'ra> = Interned<'ra, CmRefCell<NameResolution<'ra>>>;

[petrochenkov]

I see, it is due to the remaining *_unchecked methods.
I think getting rid of the unchecked methods and the rwlock in cmrefcell is a hard pre-requisite for landing this.

Could you also extract the structures from mod ref_mut to a small crate, together with a minimized resolver (like struct Resolver { speculative: bool, data: CmRefCell<i32> }), and run various scenarios similar to what the real resolver does through miri? (Involving both reborrow and reborrow_ref in particular.)
I should've probably been paying more attention to the unsafe code changes in #159440.

[LorrensP-2158466]

I see, it is due to the remaining *_unchecked methods.
I think getting rid of the unchecked methods and the rwlock in cmrefcell is a hard pre-requisite for landing this.

Yeah, but we still need interior mutability for those 2 structures during speculative resolution, not to mention the other places it is used for ModuleData:

// Not all fields, only relevant.
struct ModuleData<'ra> {
    /// Mapping between names and their (possibly in-progress) resolutions in this module.
    /// Resolutions in modules from other crates are not populated until accessed.
    lazy_resolutions: Resolutions<'ra>,

    /// Macro invocations that can expand into items in this module.
    unexpanded_invocations: CmRefCell<FxHashSet<LocalExpnId>>,

    glob_importers: CmRefCell<Vec<Import<'ra>>>,
    globs: CmRefCell<Vec<Import<'ra>>>,

    /// Used to memoize the traits in this module for faster searches through all traits in scope.
    traits: CmRefCell<
        Option<Box<[(Symbol, Decl<'ra>, Option<Module<'ra>>, bool /* lint ambiguous */)]>>,
    >,

}

So we need some structure that only allows reads during speculative resolution, and somewhow switches to interior mutability when not in speculative resolution.

I think for some of the fields, something like a CondAccess<T> will work. for example: CondAccess<CacheRefCell> which only grants access to the underlying T if Resolver::assert_speculative is false.

[petrochenkov]

we still need interior mutability for those 2 structures during speculative resolution

If something needs mutability during speculative resolution, it doesn't use Cm(Ref)Cell.
The solution is still to split lazy_resolutions into two versions, for local and external modules, they have very different needs for both synchronization and data that they need to keep.

[LorrensP-2158466]

I am sorry, I worded it wrong:

we still need interior mutability for those 2 structures during speculative resolution

If something needs mutability during speculative resolution, it doesn't use Cm(Ref)Cell.

I meant that we need read access during speculative resolution and interior mutability elsewhere for things wrapped in CmRefCell. This is true for almost every field of Module which has interior mutability besides traits:

• globs: we read from it in resolve_ident_in_module_globs_unadjusted
• unexpanded_invocations: to check if there are any macros still unexpanded to determine if a name can be present in the future
• and local resolutions

So:

If something needs mutability during speculative resolution, it doesn't use Cm(Ref)Cell.

While this is true, that is thus only half of it.

So we need to find some very smart datastructure that can be synchronized or not depending the use of it. Which is very unsafe

[petrochenkov]

I meant that we need read access during speculative resolution and interior mutability elsewhere for things wrapped in CmRefCell.

Yes, but it doesn't mean the data in CmRefCell needs to be additionally protected by a mutex or rwlock.
It is already protected by the assert_speculative flag (which needs to be atomic, most likely).
I guess the main question is how to express it in Rust terms, without plaguing the whole resolver with unsafe.