-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Do not merge yet] Remove alloc_jemalloc, switch the default global allocator to System #52020
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try @Mark-Simulacrum, could you run this on perf.rlo? |
[Do not merge yet] Remove alloc_jemalloc, switch the default global allocator to System Fixes #36963 **Do not merge** yet. This PR by itself is likely to regress rustc performance. The purpose of opening it now is to measure by how much. We’ll likely want to figure out #51038 and land them around the same time.
Please specifically note the versions of the system allocator (presumably glibc) when reporting performance. If possible, it would be nice to have results for both current and older glibc, say Fedora 28 versus RHEL/CentOS 7. If there's a way I can help generate results, let me know -- I don't have hardware to dedicate to this, but I can do manual runs for this evaluation. |
Indeed, results on perf.rust-lang.org are presumably collected on Linux with a single version of glibc. Measuring impact on macOS would be nice too. |
☀️ Test successful - status-travis |
Perf results, once ready, will have been run with Ubuntu GLIBC 2.23-0ubuntu10. |
OK. The most notable change for glibc came in 2.26: For Ubuntu, that would be in artful (17.10) and later. |
We might be able to upgrade the collector -- it seems like a relatively decent idea to have recent software on it, and there is a new LTS of Ubuntu (18.04) so shouldn't be too difficult. |
In this case, getting both sets of results would be interesting. |
So I tried running the benchmarks on a mac and got this:
I assume I also ran it on an Ubuntu 18.04 machine with the
|
Ah, this was the
|
The results on the infra look similar to those on my machine… and I still don’t know what to make of them. CC @rust-lang/wg-compiler-performance, @glandium, @nnethercote |
TL;DR of the numbers: depending on what is being compiled in what mode, compilation wall clock time difference due do disabling jemalloc is between -42.5% (time nearly halved!) and +10.6% |
@SimonSapin oh the perf links you gisted actually were for a pretty wide range of commits, but this comparison URL is just for the jemalloc changes. From that URL some conclusions are:
Overall I think the losses here outweigh the gains (as the gains are all very small and only on small programs) and we probably want to stick with jemalloc on Linux for now. It'd be interesting though to compare with the glibc 2.26 allocator as well though! |
I agree with @alexcrichton. The ones that improved were toy or stress programs; all the more interesting benchmarks regressed :( |
I agree with @alexcrichton and @nnethercote, we should not merge this as is. Thanks a lot for measuring though, @SimonSapin! |
For redis glibc 2.26 can make huge difference It should be revaluated again once perf.rust-lang.org is updated to something more recent. |
Those numbers look great but wouldn't that mean that people on older systems would still experience a noticeable regression? |
Unfortunately that's the case however distributions like Ubuntu, Fedora, openSUSE/SUSE already provide Rust built without jemalloc in their repositories. There is no need to hurry but at some the focus should be shifted for more recent systems. |
Unfortunately that's the case however distributions like Ubuntu, Fedora, openSUSE/SUSE already provide Rust built without jemalloc in their repositories.
This is an interesting point; if we’re basing this situation on “not trying to regress distros”, we may be making a category error. It’s likely they’ve already regressed, in a sense.
IMHO, we should also be taking binary size into some consideration here. It’s a persistent foot gun that people compare C with the system allocator to Rust with jemalloc.
… On Jul 9, 2018, at 7:21 AM, Mateusz Mikuła ***@***.***> wrote:
Unfortunately that's the case however distributions like Ubuntu, Fedora, openSUSE/SUSE already provide Rust built without jemalloc in their repositories.
|
@steveklabnik There are people using rustc packaged by their distro, but also users of various distros with various versions of glibc using our rustc builds through rustup. Re binary size I assume you mean changing default allocator for Rust programs to |
@SimonSapin ah; yes, that was what I was talking about; I got my threads mixed up. Thanks. |
Fixes #36963
Do not merge yet. This PR by itself is likely to regress rustc performance. The purpose of opening it now is to measure by how much. We’ll likely want to figure out #51038 and land them around the same time.