Registration

[gdalle]

Would you be open to registering the package? Even if it has to change a lot and release breaking versions often while in the prototyping phase

[albertomercurio]

Yes it would be fine.

I'm also open to move it into an organization. I don't guarantee to give much time to it, so perhaps it is better to have different maintainers with the right permissions. What do you think?

[gdalle]

Actually judging by the discussion I just had on slack with @kshyatt, the package name may not be super appropriate since technically those are host sparse arrays?

Before registration it might be worth pondering whether this functionality belongs in GPUArrays.jl or not, given its new sparse matrix support

[albertomercurio]

I see.

Actually the concept of this package can go beyond the use of GPU arrays. They can be even CPU arrays, like DistributedArrays, FixedSizeArrays and more. So I don't know how to align with that.

[gdalle]

That's a good point. Would KernelAbstractions be sufficient to tackle all the types you have in mind? For instance it doesn't natively handle distributed computations I think, unless you raise the kernel to Reactant first?

[albertomercurio]

KernelAbstractions supports Reactant, and so it should support sharding in principle. For any other general array, it should dispatch to the array-specific method.

For example, I'm planning to use SparseArrays.jl methods if the array is the base one, without having the overhead of KernelAbstractions.

[gdalle]

Sounds good! I guess there is no harm in registering then

[albertomercurio]

Should we renamed it in another way then? Any suggestions? BackendSparseArrays.jl?

[gdalle]

GenericSparseArrays? ParallelSparseArrays?