Sort mono items by symbol name

[Kobzol]

Trying to claw back cycles/branch/cache miss losses from #144722.

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[compiler-errors]

@bors2 try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 938563c (938563cd053ec624756cb9f5284a22631f9a413b, parent: 350d0ef0ec0493e6d21cfb265cb8211a0e74d766)

[nnethercote]

Can you clarify how symbol_name puts related things together? The reasoning is not clear to me.

[Kobzol]

So this is just a hunch, it's quite possible that it doesn't have any effect or that the perf. results are just a flake. But my reasoning goes something like this:

• LLVM codegens statics and functions in the order we pass them to it.
• If LLVM codegens things that are related in succession, similar data structures will be accessed repeatedly, because the codegened functions will be similar/related (especially due to monomorphization), and thus memory cache utilization could be better, and the branch predictor will also see similar things "in a row", thus helping branch prediction.

Suppose that we codegen a, c::<u32>, b, c::<i16>, d, c::<bool>. My expectation is that it is beneficial to codegen the three monomorphizations of c right after one another, which should be achieved by sorting by symbol name. I strongly suspect that this sort does put monomorphized things next to one another, but I haven't actually checked whether that wasn't already the case before the sort though (I'll check).

CC @nikic if you have any thoughts about the fact that LLVM codegenning items in a specific order seems to improve runtime perf. statistics (less cycle counts/cache misses/branch misses).

[nnethercote]

Ok. This would be good information for a comment.

[Kobzol]

Or it can be something else entirely, e.g. symbol_name is computed later anyway for the individual mono items, and it helps perf. if we precompute the symbol names at the same time and cache them 🤷‍♂️ I will try to investigate more.

[Kobzol]

Ok I am now more confident that this is indeed what happens. The wins are in LLVM codegen (https://perf.rust-lang.org/detailed-query.html?commit=938563cd053ec624756cb9f5284a22631f9a413b&benchmark=cargo-0.87.1-debug&scenario=full&base_commit=350d0ef0ec0493e6d21cfb265cb8211a0e74d766), and when I tried to print the symbols before and after sort, it's clear that related items are not always next to each other in the original order.

Here is a log of symbols when building cargo, which had the biggest wins in rustc-perf:
cargo.tar.gz

It's clear that the sorting groups related/monomorphized things next to each other, which likely improves LLVM codegen performance.

I will expand the comment.

[rust-timer]

Finished benchmarking commit (938563c): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@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.2%	[0.1%, 0.5%]	35
Regressions ❌ (secondary)	0.3%	[0.1%, 0.5%]	25
Improvements ✅ (primary)	-0.5%	[-0.5%, -0.5%]	1
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	5
All ❌✅ (primary)	0.2%	[-0.5%, 0.5%]	36

Max RSS (memory usage)

Results (primary -2.5%, secondary -1.1%)

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)	1.6%	[1.6%, 1.6%]	1
Improvements ✅ (primary)	-2.5%	[-4.2%, -1.4%]	5
Improvements ✅ (secondary)	-2.4%	[-3.4%, -1.5%]	2
All ❌✅ (primary)	-2.5%	[-4.2%, -1.4%]	5

Cycles

Results (primary -3.4%, secondary -3.6%)

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)	-	-	0
Improvements ✅ (primary)	-3.4%	[-5.8%, -1.9%]	8
Improvements ✅ (secondary)	-3.6%	[-7.9%, -1.5%]	8
All ❌✅ (primary)	-3.4%	[-5.8%, -1.9%]	8

Binary size

Results (primary 0.0%, secondary 0.0%)

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

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	11
Regressions ❌ (secondary)	0.0%	[0.0%, 0.1%]	21
Improvements ✅ (primary)	-0.0%	[-0.0%, -0.0%]	7
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	5
All ❌✅ (primary)	0.0%	[-0.0%, 0.0%]	18

Bootstrap: 468.291s -> 464.071s (-0.90%)
Artifact size: 377.36 MiB -> 377.43 MiB (0.02%)

[SparrowLii]

The increase in instruction count is due to the extra sorting.
This indeed reduces the cycle for most cases, and it also looks fine in terms of wall-time.

[Kobzol]

Added more details to the comment.

[nnethercote]

Can you put the a, c::<u32>, b, c::<i16>, d, c::<bool> example in here? I think that makes it clearer what "similar things" are, which is still a bit vague without the example. Because in the absence of generics alphabetical order would be no better than random, right?

[Kobzol]

I think that even without monomorphizations it sort of makes sense, things that have a similar symbol typically live in a similar module, or they are methods on the same type (unless the symbol is heavily mangled or really random), so they will e.g. reference similar types, call similar functions etc. But the monomorphization example is indeed the best one, I added it.

[nnethercote]

r=me with the comment tweak above.

[Kobzol]

@bors r=nnethercote

[bors]

📌 Commit 6f1c998 has been approved by nnethercote

It is now in the queue for this repository.