You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the work done on lolbench there was a perf regression on
rayon_1_0_0::sort::demo_merge_sort_descending and rayon_1_0_0::sort::par_sort_descending between nightly 2018-11-03 and 2018-11-04.
The benchmarks grew 100%, and close to 200 % in branch_instructions / iteration.
Commit range is 8b09631...04fdb44, which notably includes the jemalloc removal. Most likely this is just an allocator regression and can be recovered by explicitly enabling jemalloc.
Okay so I think that confirms the hypothesis from @nikic
You can see from the description on PR #55238 that switching from jemalloc to glibc alloc was expected to cause regressions. That included the note that you would get that performance back (and then some) by switching to jemalloc-sys from crates.io. The Rust stdlib don't do it by default, but as far as I can tell it is what we are recommending as the path for clients who want to maximize performance on this axis?
(I think there isn't much more to investigate here with respect to the scope of the regression nor its source. Downgrading from P-high to P-medium, and nominating for discussion at next compiler meeting with inclination to close as "not-a-bug"/"wont-fix")
Activity
pnkfelix commentedon Nov 29, 2018
tagging as P-high for the initial investigation of the scope of the performance regression.
nikic commentedon Nov 29, 2018
Commit range is 8b09631...04fdb44, which notably includes the jemalloc removal. Most likely this is just an allocator regression and can be recovered by explicitly enabling jemalloc.
pnkfelix commentedon Dec 3, 2018
I can observe the ~2.0x slowdown regression on my Linux desktop.
My mac does not exhibit it nearly as cleanly.
I'm going to see if switching on jemallocator manually (by adding it as a
#[global_allocator]to rayon-demo'smain.rs) eliminates the regression.#[global_allocator] static ALLOC: jemallocator::Jemalloc = jemallocator::Jemalloc;eliminates the regression.pnkfelix commentedon Dec 3, 2018
Okay so I think that confirms the hypothesis from @nikic
You can see from the description on PR #55238 that switching from jemalloc to glibc alloc was expected to cause regressions. That included the note that you would get that performance back (and then some) by switching to
jemalloc-sysfrom crates.io. The Rust stdlib don't do it by default, but as far as I can tell it is what we are recommending as the path for clients who want to maximize performance on this axis?pnkfelix commentedon Dec 3, 2018
In any case my personal recommendation is that Rayon should consider turning on jemalloc for its demo code.
Here is the necessary diff:
pnkfelix commentedon Dec 3, 2018
(I think there isn't much more to investigate here with respect to the scope of the regression nor its source. Downgrading from P-high to P-medium, and nominating for discussion at next compiler meeting with inclination to close as "not-a-bug"/"wont-fix")
anp commentedon Dec 3, 2018
FWIW I hope to support measuring against multiple different allocators in lolbench in the future, just not there yet.
pnkfelix commentedon Dec 6, 2018
closing as wontfix.