You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HadrienG2 opened this issue
Mar 5, 2023
· 2 comments
Labels
A-arrayArea: `[T; N]`A-codegenArea: Code generationI-slowIssue: Problems and improvements with respect to performance of generated code.T-libsRelevant to the library team, which will review and decide on the PR/issue.
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) .
The text was updated successfully, but these errors were encountered:
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
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?
A-arrayArea: `[T; N]`A-codegenArea: Code generationI-slowIssue: Problems and improvements with respect to performance of generated code.T-libsRelevant to the library team, which will review and decide on the PR/issue.
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, whilearray::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 ofarray::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) .The text was updated successfully, but these errors were encountered: