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 reusing monomorphized instances across crates #1980

Closed
marijnh opened this issue Mar 15, 2012 · 11 comments
Closed

Experiment with reusing monomorphized instances across crates #1980

marijnh opened this issue Mar 15, 2012 · 11 comments
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code. P-low Low priority

Comments

@marijnh
Copy link
Contributor

marijnh commented Mar 15, 2012

Currently, crates generate their own versions of all generic functions they use. They could write info about the generated functions to the metadata, and crates compiling against them could check that first, and simply link the already existing instance when possible. This is bound to reduce code output size, and thus compilation time.

@graydon
Copy link
Contributor

graydon commented Mar 21, 2012

Yeah, this is worth doing. It'd also plausibly be worth pre-specializing a variety of generics in libstd and libcore and such. Maybe some kind of #[pre_specialize(int, str)] attribute or something.

@catamorphism
Copy link
Contributor

Cleared assignee.

@thestinger
Copy link
Contributor

@graydon: I think being able to pre-specialize is a good solution. C++11 supports this by letting you declare template instantiations as extern in the header and providing them in some translation unit and they came to that solution after many failed alternatives.

@thestinger
Copy link
Contributor

LLVM supports this with externally_available combined with linkonce_odr.

@catamorphism
Copy link
Contributor

Also see #9222 (though that doesn't solve the cross-crate issue).

@catamorphism
Copy link
Contributor

P-low, not 1.0

@emberian
Copy link
Member

Visiting for triage. Hasn't been done yet.

@steveklabnik
Copy link
Member

Triage: no updates

@alexcrichton
Copy link
Member

cc @brson, do you feel your work in this area is enough to close this? It sounded like experiments were done, conclusions were reached, and we probably don't want to land it in the compiler at this time?

Plus you get to close a pre-2k bug :)

@brson
Copy link
Contributor

brson commented Aug 31, 2015

My report.

After a few weeks of on-and-off work I could not find a simple heuristic that would produce reliable wins. Switching large amounts of functions from internal to some form of external linkage causes the compilation profile to change in large but subtle ways, and I couldn't find a scenario where the changes were consistently in favor of better compile times.

I haven't given up hope though. I think this technique still has clear applications to profile-based (de)optimization and pre-instantiation of std library functions.

I do think it's not worth keeping this open. If somebody has a breakthrough someday it'll happen. If not, nbd.

@brson brson closed this as completed Aug 31, 2015
@brson
Copy link
Contributor

brson commented Aug 31, 2015

My big headline number for this effort was that I reduced total servo debug build times by 8%. The tradeoff though was that some crates took significantly longer to build, punishing smaller projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code. P-low Low priority
Projects
None yet
Development

No branches or pull requests

8 participants