Use mimalloc as the global allocator on x86_64-pc-windows-msvc#138764
Use mimalloc as the global allocator on x86_64-pc-windows-msvc#138764Zoxc wants to merge 1 commit intorust-lang:mainfrom
x86_64-pc-windows-msvc#138764Conversation
|
rustbot has assigned @Mark-Simulacrum. Use |
rustbot
added
A-testsuite
|
Local benchmarks:
We do see the memory use regressions compared to Windows' allocator too. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
just for my interest: does it work for windows-gnu too? |
|
I haven't tested that, but probably. |
|
@bors try |
Use mimalloc as the global allocator on `x86_64-pc-windows-msvc` This adds using mimalloc as the global allocator for the compiler as an option to `bootstrap.toml` and enables it for the `x86_64-pc-windows-msvc` dist builder. try-job: dist-x86_64-msvc
|
These benchmarks also seem pretty small, what's the result on a bigger project like cargo? |
|
☀️ Try build successful - checks-actions |
| #jemalloc = false | ||
|
|
||
| # Use mimalloc as the global allocator for the compiler. Rust code will prefer `mimalloc` over | ||
| # `jemalloc` if that is also enabled. |
There was a problem hiding this comment.
Could we reject setting both? That feels needlessly confusing to me and probably not hugely needed?
There was a problem hiding this comment.
We can probably just remove jemalloc if mimalloc v3 solves all regressions over it.
There was a problem hiding this comment.
Maybe name this field override-allocators in case we'd want to swap allocators in the future?
|
|
||
| #[cfg(feature = "mimalloc")] | ||
| #[global_allocator] | ||
| static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc; |
There was a problem hiding this comment.
Is this just temporary, or the long-term state? As-is this doesn't affect LLVM's malloc calls?
IOW, why is this not changign the rustc/src/main.rs malloc overrides?
There was a problem hiding this comment.
Long term. It's better than the linker hacks in main.rs.
Overriding the C allocator only in main.rs doesn't affect DLLs making it unsound without further work dealing with loadable backends and LLVM plugins.
There was a problem hiding this comment.
But isn't this still a regression for LLVM's allocations? It seems odd to measure perf for a halfway shift like this to mimalloc...
There was a problem hiding this comment.
We'd still want the linker hacks on Linux / macOS for LLVM, using global_allocator just makes Rust allocation overriding less hacky.
As for perf on this PR, LLVM uses Windows' heap allocator both before and after.
|
Nit: if we modify the bootstrap.toml config, I would go for |
|
Is there a noticeable difference with jemalloc on windows? Given, that it already exist but not enabled for windows. |
|
I haven't tried to make jemalloc work on Windows. I focused on mimalloc since it outperformed jemalloc on our Linux tests. |
Mark-Simulacrum
added
S-waiting-on-author
|
mimalloc v3.2.7 release candidate was just released, it should worth a try. |
9 participants
This adds using mimalloc as the global allocator for the compiler as an option to
bootstrap.tomland enables it for thex86_64-pc-windows-msvcdist builder.try-job: dist-x86_64-msvc