[perf] Test mimalloc 2.0.6

[lqd]

Last time we tried mimalloc:

• we were comparing to a different release of jemalloc
• the 1.x version of mimalloc had interesting performance characteristics but max-rss regressions, that were supposed to be fixed in 2.x, which was apparently in beta at the time.

We'd like to have more up-to-date numbers for comparison. (My expectations: some perf improvements, but similar max-rss regressions as last time)

[rustbot]

r? @cjgillot

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

[lqd]

(sorry for the ping camille, I hit Ctrl+Enter while typing the description and it opened the PR before I finished 😓 )

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 485b976a0f9e01e3de7f4d339df1d7c2f0c13276 with merge 9b394c599b060e5e45fe2903e1f8e21f770c934e...

[bors]

💔 Test failed - checks-actions

[lqd]

@bors try

[bors]

⌛ Trying commit 549803c with merge 3730639d7f06cd606b6fd0cda3eeef8e107f63e1...

[bors]

☀️ Try build successful - checks-actions
Build commit: 3730639d7f06cd606b6fd0cda3eeef8e107f63e1 (3730639d7f06cd606b6fd0cda3eeef8e107f63e1)

[rust-timer]

Queued 3730639d7f06cd606b6fd0cda3eeef8e107f63e1 with parent 15d7556, future comparison URL.

[rust-timer]

Finished benchmarking commit (3730639d7f06cd606b6fd0cda3eeef8e107f63e1): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.7%	[0.8%, 2.3%]	3
Improvements ✅ (primary)	-4.1%	[-24.0%, -1.0%]	241
Improvements ✅ (secondary)	-3.9%	[-9.4%, -0.4%]	243
All ❌✅ (primary)	-4.1%	[-24.0%, -1.0%]	241

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)	8.2%	[0.9%, 33.2%]	128
Regressions ❌ (secondary)	9.8%	[1.8%, 34.5%]	95
Improvements ✅ (primary)	-2.7%	[-5.6%, -0.7%]	7
Improvements ✅ (secondary)	-7.6%	[-10.7%, -2.2%]	4
All ❌✅ (primary)	7.6%	[-5.6%, 33.2%]	135

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)	-	-	0
Improvements ✅ (primary)	-2.3%	[-12.6%, -1.1%]	123
Improvements ✅ (secondary)	-3.2%	[-6.8%, -1.0%]	149
All ❌✅ (primary)	-2.3%	[-12.6%, -1.1%]	123

[lqd]

(no, no 🎉 , look at the max-rss results 😄 )

No need to keep this open, we should have all the data we need.

[Noratrieb]

oh, those aren't great yeah..

[aganea]

Hello @lqd ! Have you tried https://github.com/mjansson/rpmalloc ? I did quite a lot of testing on LLVM & building real-size projects at Ubisoft, and it seemed it was the best compromise, see discussion in mjansson/rpmalloc#150. It would really nice if rustc+rust-lld would come with a lockfree allocator on Windows, this has a big impact there, please see: https://reviews.llvm.org/D71786
We were thinking in vendoring rpmalloc inside the LLVM tree, for licencing reasons, not sure if that would help.

[aganea]

@lqd Sorry for the spam I don't have your email. I came here from https://www.memorysafety.org/blog/remy-rakic-compile-times/
One thing I've been working on in the past was, embedding the compiler and linker in a single process, along with the build system. In essence it's a bit as if cargo, rustc and rust-lld were living inside the same process, and shared the same thread pool. This has a big impact on Windows, but I suspect on Linux as well, as the OS context switching between processes should be more expensive than just a single active process with many running threads. Also, launching and shutting down the processes on Windows is very expensive. See https://reviews.llvm.org/D69825 and https://reviews.llvm.org/D86351 - overall switching to this model of pools of threads instead of pool of process used to save about 60% on the build times on a large project at Ubisoft (and said project already used to aggregate .CPP files into blobs/unity files)
Right now I'm working on making LLD usable as a lib: https://reviews.llvm.org/D119049 -- then would follow multi-threaded usage inside the same process, at least for the LLD COFF driver.
One other alternative to llvm-buildozer prototype above would be long-living compile/link processes that accept some kind of jobserver-like protocol with build commands, and then dispatch internally, multi-threaded.

[Kobzol]

FWIW, here are rpmalloc results from Linux.