More scalable pool allocator#50137
Conversation
b01d688 to
369ced8
Compare
|
With all the changes since the beginning, are the benchmarks still the same? |
65a2b4d to
2983c05
Compare
|
On 2983c05:
|
|
that looks pretty good! |
|
Seeing some regressions on this PR on the single-threaded benchmarks. Marking as draft until further investigated. |
|
Benchmarks look fine on the latest commit (the goal of this PR is be performance-neutral on the serial benchmarks and to provide better scalability when there are multiple threads allocating). Serial benchmarks (master)Serial benchmarks (PR)Multithreaded benchmarks (master)Multithreaded benchmarks (PR)Machine information |
4fe05fa to
acb4110
Compare
|
@nanosoldier |
|
Your package evaluation job has completed - possible new issues were detected. |
|
This made the |
|
Yeah it's on my to-do list |
|
Also taking a look at this. |
…ect pool freelist * addresses follow-up comments from #50137, particularly #50137 (comment)
Still very experimental and depends on #49644. Mostly for later comparisons with #48969 (e.g. if concurrent sweeping would perform better on a potentially less contended pool allocator).
Seems to perform better than master on some multithreaded allocation benchmarks (e.g.
tree_mutable.jl), but a lot more benchmarking is needed: