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
Wouldn't it make sense from an organizational point of view to merge SparseMatricesCSR.jl into this library?
Being able to work with CSR matrices is beneficial, because matvec product with CSR matrix is easier paralellizable than with a CSC matrix. Having a designated CSR implementation here would help interoperability with other libraries. For example, MKLSparse.jl could add hooks for the CSR functions in the MKL library. CUDA.jl has its CuSparseMatrixCSR type, and it would be good to add a constructor from a CSR matrix on CPU.
The major opposing argument is simply to use a lazy transpose over CSC matrix. However, benchmarks in this post show that it can work slower.
More importantly, it puts an unnecessary mental overhead on the user by making him construct a transpose of the matrix instead of the matrix itself, which could be prone to mistakes.
The text was updated successfully, but these errors were encountered:
I don't think we should merge it in here. It will slow down development and ability to ship (which will get tied to the Julia release schedule). What we want to do is remove SparseArrays from the Julia stdlibs so that it can be a regular package - at which point it would make sense to consolidate capabilities.
Wouldn't it make sense from an organizational point of view to merge SparseMatricesCSR.jl into this library?
Being able to work with CSR matrices is beneficial, because matvec product with CSR matrix is easier paralellizable than with a CSC matrix. Having a designated CSR implementation here would help interoperability with other libraries. For example, MKLSparse.jl could add hooks for the CSR functions in the MKL library. CUDA.jl has its CuSparseMatrixCSR type, and it would be good to add a constructor from a CSR matrix on CPU.
The major opposing argument is simply to use a lazy transpose over CSC matrix. However, benchmarks in this post show that it can work slower.
More importantly, it puts an unnecessary mental overhead on the user by making him construct a transpose of the matrix instead of the matrix itself, which could be prone to mistakes.
The text was updated successfully, but these errors were encountered: