make mk_attr_id part of ParseSess

[SparrowLii]

Updates #48685

The current mk_attr_id uses the AtomicU32 type, which is not very efficient and adds a lot of lock contention in a parallel environment.

This PR refers to the task list in #48685, uses mk_attr_id as a method of the AttrIdGenerator struct, and adds a new field attr_id_generator to ParseSess.

AttrIdGenerator uses the WorkerLocal, which has two advantages: 1. Cell is more efficient than AtomicU32, and does not increase any lock contention. 2. We put the index of the work thread in the first few bits of the generated AttrId, so that the AttrId generated in different threads can be easily guaranteed to be unique.

cc @cjgillot

[rust-highfive]

r? @fee1-dead

(rust-highfive has picked a reviewer for you, use r? to override)

[fee1-dead]

I am not familiar with parallel compiler code, but is there a cap as to how many threads can be used for parallel rustc? If there are too many then the actual usable bits would be decreased.

[SparrowLii]

Yes it is a cap. AFAIK, the number of threads is usually no more than 64. Besides, as the number of threads increases, the number of AttrIds that need to be assigned per thread will decreases relatively, so I don't think this is a problem.

[cjgillot]

I understand that the main motivation is performance in parallel environment. Do you have a measurement of the perf improvement?

[SparrowLii]

I understand that the main motivation is performance in parallel environment. Do you have a measurement of the perf improvement?

I haven't learned about a good benchmark for measuring the efficiency of parallel compilation, which is also in my follow-up implementation plan. I guess for now we just need to guarantee that there is no negative impact on the efficiency in non-parallel mode. So I think we can run rustc perf directly.

[SparrowLii]

There are already some issues about parallel compilation' benchmarks, such as #59667 and #92596, I think we will solve them in subsequent implementations.

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit f9234777e44bde1b27786e9f4300b0ee3323c5f9 with merge 7e04d9038009c47e6b24a62aab7fa9d31c71706a...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7e04d9038009c47e6b24a62aab7fa9d31c71706a (7e04d9038009c47e6b24a62aab7fa9d31c71706a)

[rust-timer]

Queued 7e04d9038009c47e6b24a62aab7fa9d31c71706a with parent 5b4bd15, future comparison URL.

[rust-timer]

Finished benchmarking commit (7e04d9038009c47e6b24a62aab7fa9d31c71706a): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

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

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-1.2%, -0.3%]	13
Improvements ✅ (secondary)	-1.2%	[-1.7%, -0.8%]	8
All ❌✅ (primary)	-0.7%	[-1.2%, -0.3%]	13

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.

	mean1	range	count2
Regressions ❌ (primary)	1.6%	[0.8%, 2.3%]	2
Regressions ❌ (secondary)	2.3%	[1.4%, 3.7%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-2.3%, -2.3%]	1
All ❌✅ (primary)	1.6%	[0.8%, 2.3%]	2

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.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-2.8%, -2.8%]	1
All ❌✅ (primary)	-	-	0

Footnotes

1. the arithmetic mean of the percent change↩↩²↩³

2. number of relevant changes↩↩²↩³

[cjgillot]

From the perf report, this PR looks like a great idea to improve perf.
However, I'm a bit afraid of Heisenbugs in parallel-compiler due to silent collisions of AttrId because they overflow the allocated 27 bits or so.
Could you add a debug-assertion that this does not happen?
Then r=me

[SparrowLii]

Sure, I added the corresponding modifications.

[SparrowLii]

@bors r=cjgillot

[bors]

@SparrowLii: 🔑 Insufficient privileges: Not in reviewers

[SparrowLii]

@cjgillot It looks like I don't have the privilege to r=

[bors]

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

[cjgillot]

@bors r+

[bors]

📌 Commit bfc4f2e has been approved by cjgillot

It is now in the queue for this repository.

[bors]

⌛ Testing commit bfc4f2e with merge 750bd1a...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 750bd1a to master...

[rust-timer]

Finished benchmarking commit (750bd1a): 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)

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

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.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-4.5%	[-4.9%, -4.1%]	2
Improvements ✅ (secondary)	-3.2%	[-3.3%, -3.1%]	2
All ❌✅ (primary)	-4.5%	[-4.9%, -4.1%]	2

Footnotes

1. the arithmetic mean of the percent change↩

2. number of relevant changes↩

[Zoxc]

It's possible that WorkerLocal is slower than fetch_add since the latter is quite fast already. I don't think mk_attr_id is hot enough for it to matter, but to actually measure the overhead I'd recommend measuring check builds using a single thread on a CPU with its frequency locked using my benchmark tool.

[SparrowLii]

Thanks, your suggestion is very valuable! In fact, we don't have good tools for measuring the performance of compilers in parallel environments at current. I will try this tool then!

[Zoxc]

This happened to break the parallel compiler due to WorkerLocal being created outside the Rayon thread pool.

[SparrowLii]

You mean WorlerLocal can not get the index correctly? If so then WorkerLocal really shouldn't be used. It might be reasonable to use thread_local.

Or we should add this WorkerLocal to TyCtxt so it doesn't exceed Rayon thread pool

[Zoxc]

I think it just ends up spawning the global Rayon thread pool. I kind of have a workaround in #107782, but it's not particularly clean.