diff options
| author | bors <bors@rust-lang.org> | 2025-02-04 23:47:45 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2025-02-04 23:47:45 +0000 |
| commit | e5f11af042ad099102efd572743138df60764a4e (patch) | |
| tree | ceeb5544e9d09be5fde29bea094000587b87d564 /compiler/rustc_const_eval/src | |
| parent | bef3c3b01f690de16738b1c9f36470fbfc6ac623 (diff) | |
| parent | 7f1231c986c26dcd1b519b81b78371a750db797a (diff) | |
| download | rust-e5f11af042ad099102efd572743138df60764a4e.tar.gz rust-e5f11af042ad099102efd572743138df60764a4e.zip | |
Auto merge of #136115 - Mark-Simulacrum:shard-alloc-id, r=RalfJung
Shard AllocMap Lock This improves performance on many-seed parallel (-Zthreads=32) miri executions from managing to use ~8 cores to using 27-28 cores, which is about the same as what I see with the data structure proposed in https://github.com/rust-lang/rust/pull/136105 - I haven't analyzed but I suspect the sharding might actually work out better if we commonly insert "densely" since sharding would split the cache lines and the OnceVec packs locks close together. Of course, we could do something similar with the bitset lock too. Either way, this seems like a very reasonable starting point that solves the problem ~equally well on what I can test locally. r? `@RalfJung`
Diffstat (limited to 'compiler/rustc_const_eval/src')
0 files changed, 0 insertions, 0 deletions