-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Simplify mul!
dispatch
#49806
Simplify mul!
dispatch
#49806
Conversation
@nanosoldier @nanosoldier |
@nanosoldier |
Your benchmark job has completed - no performance regressions were detected. A full report can be found here. |
Your package evaluation job has completed - possible new issues were detected. |
Many tests were skipped because of PkgEval issue; let's try again: @nanosoldier |
Aha, okay, out of the tested packages that failed I couldn't find a single related one. But some strange errors like undefined variables. Is that related to the issue you mentioned? |
Your package evaluation job has completed - possible new issues were detected. |
There seem to be no related issues. |
No, just the skipped packages with |
I wonder if this will help packages already, just because the I applied the same dispatch move to matvec multiplication, so to be safe, let's run pkgeval once more, and then merge. BTW, one can do something similar to @nanosoldier |
Your package evaluation job has completed - possible new issues were detected. |
Guys, I saw the light, while I was struck by a thunder. Look what we can do! Let a generic
mul!
strip off potentialAdjOrTrans
wrappers, and peel off the actually data-storing array. With this design, it is crystal-clear what SparseArrays.jl, GPUArrays.jl and its surounding ecosystem need to overload. Not tons ofmul!
, butgeneric_matmatmul!
with all three matrix arguments of their own(ed) kind: SparseMatrixCSC, CuArray, MtlArray etc. In this PR, we have 4(!) methods as follows:That should be really helpful in terms of package load times.