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
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.
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.
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!
andldiv!
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!
andldiv!
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
The text was updated successfully, but these errors were encountered: