Skip to content
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

Experiment with sharing monomorphized code between crates #47317

Closed
michaelwoerister opened this issue Jan 10, 2018 · 3 comments
Closed

Experiment with sharing monomorphized code between crates #47317

michaelwoerister opened this issue Jan 10, 2018 · 3 comments
Labels
A-codegen Area: Code generation C-feature-request Category: A feature request, i.e: not implemented / a PR. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-compiler-performance Working group: Compiler Performance

Comments

@michaelwoerister
Copy link
Member

At the moment the compiler will re-instantiate generic code in every crate that uses it. That sounds like a lot of duplicated work. However, we don't have any actual numbers on how much duplicated work. There are a few things we could do:

  • Instrument the compiler to count how many duplicated functions we have
  • Prototype sharing of generic code and see how it affects compile times and binary sizes
  • Wait for MIR-only RLIBs to solve the problem naturally.

This could potentially be a big win for compile times but we won't know until we've collected some data.

Side node: Sharing monomorphized instances could negatively affect runtime performance when compiling without any form of LTO or when compiling with ThinLTO just for the current crate (as opposed to doing ThinLTO over the whole crate graph).

@michaelwoerister michaelwoerister added A-codegen Area: Code generation I-compiletime Issue: Problems and improvements with respect to compile times. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. labels Jan 10, 2018
@XAMPPRocky XAMPPRocky added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-compiler-performance Working group: Compiler Performance labels Apr 10, 2018
@brson
Copy link
Contributor

brson commented Apr 1, 2019

#47660 indicates a check box next to this task, but it is still open and doesn't indicate progress. Is this done?

@michaelwoerister
Copy link
Member Author

This has been implemented in #48779 and is enabled by default for optimization levels <= 2:

pub fn share_generics(&self) -> bool {
match self.debugging_opts.share_generics {
Some(setting) => setting,
None => {
match self.optimize {
OptLevel::No |
OptLevel::Less |
OptLevel::Size |
OptLevel::SizeMin => true,
OptLevel::Default |
OptLevel::Aggressive => false,
}
}
}
}

#50861 tested enabling it for optimized builds showed mixed results:
https://perf.rust-lang.org/compare.html?start=fd18d2537ddcffb24b3739393b085ed28dfc340e&end=b60bd5703773a04cd853519fdc2465dc9d45603d&stat=instructions%3Au

@brson
Copy link
Contributor

brson commented Dec 25, 2019

Thanks @michaelwoerister

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation C-feature-request Category: A feature request, i.e: not implemented / a PR. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-compiler-performance Working group: Compiler Performance
Projects
None yet
Development

No branches or pull requests

3 participants