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

AbstractWrappedArray, or another approach for wrapped array identification #51910

Open
maleadt opened this issue Oct 28, 2023 · 1 comment
Open
Labels
arrays [a, r, r, a, y, s] feature Indicates new feature / enhancement requests gpu Affects running Julia on a GPU

Comments

@maleadt
Copy link
Member

maleadt commented Oct 28, 2023

Opening an issue to track #31563 again. Summary below.

The problem

In #31563, a proposal was made to introduce AbstractWrappedArray, a new entry in the type hierarchy of array wrappers. This would make it easier for packages like GPUArrays.jl or CUDA.jl to identify, say, whether a wrapped array contains a GPU array, and thus need to be passed to a GPU kernel. It avoids having to define many methods, one for each possible combination of wrapped arrays (which often leads to expensive and highly ambiguous methods) in order to avoid the AbstractArray fallback.

Current solution

The issue was closed by @vtjnash, referencing @dkarrasch's recent work on reworking the mul! and ldiv! functionality implemented in Base. That work basically made it so that Base unpeels the wrappers, and defines an interface to override that only takes the base array. That fixes the problem, but only for a handful of operations. #48861 is something similar, in that it reimplements said methods using traits that are easier to override.

Why that isn't sufficient

The fact that mul! and ldiv! now works better is great, but I we still need a principled approach to this problem that covers other operations and other array wrappers. We frequently get complaints/issues by users of GPU packages how some random array operation that we've implemented in CUDA.jl or so all of a sudden triggers the AbstractArray fallback when invoked using some random array wrapper.

cc @KlausC

@maleadt maleadt added arrays [a, r, r, a, y, s] gpu Affects running Julia on a GPU feature Indicates new feature / enhancement requests labels Oct 28, 2023
@maleadt
Copy link
Member Author

maleadt commented Dec 12, 2023

Another case where this may be useful: BroadcastStyle. For GPU arrays, we need the broadcast style of a wrapped array to be the broadcast style of the parent, i.e., we cannot rely on the DefaultBroadcastStyle that the BroadcastStyle(::Type{<:AbstractArray}) falls back to. However, lacking a parent function for types, it's not easy to do so, and GPUArrays does some nasty things to get close to what we need.

With the proposal from #31563, IIUC, it should be possible to define something like BroadcastStyle(::Type{<:AbstractWrappedArray{<:Any,<:Any,P}}) = BroadcastStyle(P).

I guess the alternative is to rework BroadcastStyle so that it unpeels the wrappers much like the mul! changes, but that's just another stopgap measure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arrays [a, r, r, a, y, s] feature Indicates new feature / enhancement requests gpu Affects running Julia on a GPU
Projects
None yet
Development

No branches or pull requests

1 participant