Open alanderos91 opened 1 year ago
Sorry, probably my fault. At least the answer seems correct.
For matrix X
, I only tested A*X
where A
is SnpLinAlg and X
is dense matrix. Not sure why it fails when X
is another SnpLinAlg or SparseMatrixCSC, would need some time to figure this out
I don't think it's anybody's fault, Ben. It's just that we have not designed a kernel for this specific operation. LoopVectorization
is not really a good solution for SparseMatrixCSC. For SnpLinAlg x SnpLinAlg, the quick and dirty workaround is indeed transforming one of them into a numeric matrix. If it is large enough, I think it might still be faster than numeric matrix x numeric matrix due to having slightly better cache efficiency.
Thank you both for the quick reply. I only used SnpLinAlg
x SnpLinAlg
as an example since it throws the same warning and is incredibly slow, for me at least.
In the short-term, I think it would be reasonable to restrict this and this to DenseMatrix{T}
instead of AbstractMatrix{T}
. Multiplication with a generic AbstractMatrix{T}
should either throw an error, as it is technically not supported, or give a warning, since the current kernel is not suitable for that case.
In the long-term it would be nice to round out support for matrix-matrix multiplication. I can probably implement something for SnpLinAlg
times SparseMatrixCSC
for my problem and contribute it as a starting point. Can't promise it will be the best, though.
Reproducing the issue:
This results in the following message:
This happens when I start Julia with 10 threads on a 10 core machine. Here's some additional information:
Note: The issue came up trying to compute
A*B
whereA
isSnpLinAlg
andB
isSparseMatrixCSC
. So other operations seem to run into the issue.