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

Binary size reduction after overriding default allocator to system allocator (nightly) #55910

Open
osa1 opened this Issue Nov 13, 2018 · 7 comments

Comments

Projects
None yet
7 participants
@osa1
Contributor

osa1 commented Nov 13, 2018

Tried with rustc 1.32.0-nightly (65204a9 2018-11-12).

To reproduce:

  • Clone https://github.com/osa1/tiny
  • cargo build --release && ls -lha target/release/tiny. You'll see a 2.4M binary.
  • Apply this diff
      diff --git a/src/lib.rs b/src/lib.rs
      index 8a41e51..9cae724 100644
      --- a/src/lib.rs
      +++ b/src/lib.rs
      @@ -5,9 +5,6 @@
       #![feature(nll)]
       #![feature(ptr_offset_from)]
    
      -#[global_allocator]
      -static ALLOC: std::alloc::System = std::alloc::System;
      -
       #[cfg(test)]
       extern crate quickcheck;
    
  • Repeat the same command. The binary size is now 2.5M.

Originally reported on /r/rust thread.

The reason why I think this is a bug is because the default allocator should already be the system allocator, so overriding the allocator to system allocator should have no effect.

@Mark-Simulacrum

This comment has been minimized.

Member

Mark-Simulacrum commented Nov 13, 2018

@eddyb

This comment has been minimized.

Member

eddyb commented Nov 13, 2018

@gnzlbg

This comment has been minimized.

Contributor

gnzlbg commented Nov 13, 2018

This should not happen. Hmm, can you strip symbols of both versions and see if then they become equal?

@mati865

This comment has been minimized.

Contributor

mati865 commented Nov 13, 2018

@osa1 which system are you using?

I cannot reproduce it on Arch Linux.

@osa1

This comment has been minimized.

Contributor

osa1 commented Nov 14, 2018

This should not happen. Hmm, can you strip symbols of both versions and see if then they become equal?

Nope, 1195288 vs 1199384 bytes after stripping. Still not equal.

@osa1 which system are you using?

Ubuntu 18.04.

@tormol

This comment has been minimized.

Contributor

tormol commented Nov 14, 2018

I also run Ubuntu 18.04 and can reproduce the results before stripping, but not after:

2509744 default_unstripped
2491976 explicit_unstripped
1150232 default_stripped
1150232 explicit_stripped

The stripped binaries differ, but the output of nm contains too much noise for the diffs to be useful.

Versions:

$ rustc --version --verbose
rustc 1.32.0-nightly (6e9b84296 2018-11-10)
binary: rustc
commit-hash: 6e9b84296223126a0a59bde63a0f97011bb7b0f5
commit-date: 2018-11-10
host: x86_64-unknown-linux-gnu
release: 1.32.0-nightly
LLVM version: 8.0
$ strip --version
GNU strip (GNU Binutils for Ubuntu) 2.30
<snip>
@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Nov 14, 2018

I think this is not really a bug nor an issue and would be in favor of closing it. The way the default is injected is every-so-subtly different than using #[global_allocator], they're not byte-for-byte equal (and we don't really have much reason to make them so). The binary sizes don't really matter so much as the stripped binary sizes (no debug info), and if those are close enough to one another then there's not really much to do here.

If there's a large discrepancy then there may be a bug, otherwise this is probably just that libstd can inline better than #[global_alloctor], which LTO can paper over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment