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

Discussing avoiding array allocation for moving to equal index set #26011

Open
mppf opened this issue Sep 27, 2024 · 2 comments
Open

Discussing avoiding array allocation for moving to equal index set #26011

mppf opened this issue Sep 27, 2024 · 2 comments

Comments

@mppf
Copy link
Member

mppf commented Sep 27, 2024

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.

@mppf
Copy link
Member Author

mppf commented Sep 27, 2024

@benharsh @bradcray - I'm curious if you have any thoughts on the questions & ideas here.

@mppf 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
@bradcray
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants