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

array::from_fn should be fully inlined #108765

Closed
HadrienG2 opened this issue Mar 5, 2023 · 2 comments
Closed

array::from_fn should be fully inlined #108765

HadrienG2 opened this issue Mar 5, 2023 · 2 comments
Labels
A-array Area: `[T; N]` A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@HadrienG2
Copy link

HadrienG2 commented Mar 5, 2023

It regularly happens to me that I need to create an array not because that's the end product of my computation, but because that's a useful intermediate object when going from dynamic-sized entities like iterators, slices, or arbitrary generator functions, to static-sized entities like SIMD types or loops that must be unrolled.

In this scenario, I tend to use array::from_fn in the hope that the intermediary array will be optimized out. And if everything gets inlined correctly, that works out as expected. But unfortunately, while array::from_fn itself is marked #[inline], its implementation is based on <[(); N]>::map, which is not marked #[inline]. And since the code of that latter function is mildly complex before optimization, the part of rustc that splits crates into multiple codegen-units has an unpleasant tendency to outline it into a separate codegen unit, resulting in a performance disaster.

To avoid this, either array::map should be marked inline, or the implementation of array::from_fn should be changed not to rely on it but only on other inline functions.

You can find further discussion of this and a simple reproducer of array::from_fn failing to inline at #102202 (comment) .

@workingjubilee workingjubilee added A-codegen Area: Code generation I-heavy Issue: Problems and improvements with respect to binary size of generated code. T-libs Relevant to the library team, which will review and decide on the PR/issue. A-array Area: `[T; N]` I-slow Issue: Problems and improvements with respect to performance of generated code. and removed I-heavy Issue: Problems and improvements with respect to binary size of generated code. labels Mar 6, 2023
@gmorenz
Copy link

gmorenz commented Mar 10, 2023

I think this was already fixed in #107634, array::from_fn no longer users array::map and appears to only rely on inline functions. Have you reproduced this on a recent nightly?

@HadrienG2
Copy link
Author

HadrienG2 commented Mar 11, 2023

Indeed, with current nightlies, the codegen became reasonable. Thanks for the pointer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-array Area: `[T; N]` A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants