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
PR #25896 avoids array allocation when moving to a different domain with the same index set, but only for DefaultRectangular arrays. That PR uses the approach of adding an optional method that array implementations can provide to support stealing a buffer from another array.
It occurs to me that there might be a simpler, more widely applicable strategy, that can work in more cases.
It also occurs to me that the optimization in PR #25896 could change the locale on which array elements are allocated.
This issue is a place to discuss these & future work in this area.
A more general strategy
The way I see it is that the reason that arrays care about which domain (vs which index set) is that the domain might be resized, and in that case, only those arrays declared over that domain specifically should be resized.
That brings up an idea. If an array is declared over a const or anonymous domain, it can't ever be resized through the domain. So:
When moving an array value, let's call it A, to a different type T, if T's domain is declared const or was an anonymous domain, then moving from A to T can be implemented by returning A without changing anything.
This would not be true if there are other operations (beyond domain assignment / array resizing) that depend on domain identity. Are there?
(For example, if we provided a way to return an array's domain, and check if it had the same identity as another array's domain).
Changing Locale
I don't think we normally allow "move"s across locales right now, but I think it's possible to get them with some pragmas. It might be that, with some data structures (e.g. list) we can get such "move"s by using them, due to pragmas in their implementation.
Anyway, if that happens, it might be the case that the old re-allocate behavior before PR #25896 would cause a new array to exist on a different locale.
I'm not sure if this is possible to write today or not. However I'd bet that we could check that the array values's domain and the destination type's domain are on the same locale in the code that tries to optimize away the allocation.
The text was updated successfully, but these errors were encountered:
@benharsh@bradcray - I'm curious if you have any thoughts on the questions & ideas here.
mppf
changed the title
Another way to avoid array allocation for moving to equal domain
Discussing avoiding array allocation for moving to equal index set
Sep 27, 2024
This would not be true if there are other operations (beyond domain assignment / array resizing) that depend on domain identity. Are there?
I can't think of any user-facing operations offhand, and tend to agree that resizing is the main link between an array and its domain. There may be some internal optimizations we do that check domain identity for fast paths—that's the only other thing that occurs to me, and I'm not certain whether those would be innocuous or beneficial here, or problematic.
Not directly related to this, but I'm not sure where else to mention it: I think we also discussed that this optimization ought to be able to be applied in cases where the domains don't have matching index sets, but matching shape (where, if they don't have matching shape, the initialization is probably illegal).
PR #25896 avoids array allocation when moving to a different domain with the same index set, but only for DefaultRectangular arrays. That PR uses the approach of adding an optional method that array implementations can provide to support stealing a buffer from another array.
It occurs to me that there might be a simpler, more widely applicable strategy, that can work in more cases.
It also occurs to me that the optimization in PR #25896 could change the locale on which array elements are allocated.
This issue is a place to discuss these & future work in this area.
A more general strategy
The way I see it is that the reason that arrays care about which domain (vs which index set) is that the domain might be resized, and in that case, only those arrays declared over that domain specifically should be resized.
That brings up an idea. If an array is declared over a
const
or anonymous domain, it can't ever be resized through the domain. So:When moving an array value, let's call it
A
, to a different typeT
, ifT
's domain is declaredconst
or was an anonymous domain, then moving fromA
toT
can be implemented by returningA
without changing anything.This would not be true if there are other operations (beyond domain assignment / array resizing) that depend on domain identity. Are there?
(For example, if we provided a way to return an array's domain, and check if it had the same identity as another array's domain).
Changing Locale
I don't think we normally allow "move"s across locales right now, but I think it's possible to get them with some pragmas. It might be that, with some data structures (e.g.
list
) we can get such "move"s by using them, due to pragmas in their implementation.Anyway, if that happens, it might be the case that the old re-allocate behavior before PR #25896 would cause a new array to exist on a different locale.
I'm not sure if this is possible to write today or not. However I'd bet that we could check that the array values's domain and the destination type's domain are on the same locale in the code that tries to optimize away the allocation.
The text was updated successfully, but these errors were encountered: