Skip to content
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

Amend matrix * vector specialization for strided arrays #32097

Merged
merged 1 commit into from
May 23, 2019

Conversation

ararslan
Copy link
Member

This method entirely duplicates the one below it with the exception that it also does a convert on one of the inputs with the result of promote_op, which doesn't make a whole lot of sense in some cases. By virtue of calling mul!, strided arrays that go through the abstract array method will still hit the same optimized methods that use BLAS.

Fixes JuliaLang/LinearAlgebra.jl#632.

It would be great if this change could be backported, since it fixes an issue in private code that occurs on every version >= 1.1.0. Help coming up with a minimal test case for this would be much appreciated as well.

@ararslan ararslan added linear algebra Linear algebra needs tests Unit tests are required for this change labels May 20, 2019
@ararslan ararslan requested a review from andreasnoack May 20, 2019 23:15
@ararslan
Copy link
Member Author

@nanosoldier runbenchmarks("linalg", vs=":master")

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - no performance regressions were detected. A full report can be found here. cc @ararslan

@ararslan ararslan added the triage This should be discussed on a triage call label May 21, 2019
@ararslan
Copy link
Member Author

Marking for triage because I'd like to know:

  • Can this make it into 1.2?
  • Can this be backported to 1.0 and/or 1.1?
  • Can anyone help me come up with a good test? 😬

@mbauman
Copy link
Member

mbauman commented May 21, 2019

strided arrays that go through the abstract array method will still hit the same optimized methods that use BLAS

I don't think that's the case. For example, given rand(5, 5) * rand(1:10, 5), we previously would allocate a Float64 result, convert the vector to Float64s, and then call mul!(::Vector{Float64}, ::Matrix{Float64}, ::Vector{Float64}), which dispatches to gemv!.

Without this method, we just allocate a Float64 result and then call mul!(::Vector{Float64}, ::Matrix{Float64}, ::Vector{Int})... which dispatches to generic_matvecmul!.

This conversion is there for a reason. Now, there's probably a better way to do what it's trying to do, but I don't think this is it.

@ararslan
Copy link
Member Author

ararslan commented May 21, 2019

Can we restrict the input vector eltype to Real then, perhaps? That would fix my use case, at least.

@mbauman
Copy link
Member

mbauman commented May 21, 2019

Or how about only doing the conversion if Base.isconcretetype(TS)? If it's abstract, we're definitely not going to be hitting BLAS. That should also fix your case and probably gains us a bit more generality (there could be Reals like yours, too).

Edit: or both?

This restricts the element type of the input vector to be `<:Real` and
only converts in case the promoted type is concrete.

Fixes #32092.
@ararslan ararslan force-pushed the aa/no-convert-promote_op branch from 2ca4c5b to 545d9f5 Compare May 22, 2019 02:16
@ararslan
Copy link
Member Author

Implemented that. Still needs tests though.

@ararslan ararslan changed the title Remove matrix * vector specialization for strided arrays Amend matrix * vector specialization for strided arrays May 22, 2019
@JeffBezanson
Copy link
Member

Triage: seems safe to backport.

@JeffBezanson JeffBezanson added backport 1.0 and removed triage This should be discussed on a triage call labels May 23, 2019
@JeffBezanson JeffBezanson merged commit 587cb82 into master May 23, 2019
@JeffBezanson JeffBezanson deleted the aa/no-convert-promote_op branch May 23, 2019 18:38
@ararslan
Copy link
Member Author

I was going to add a test before this was merged, but ¯\_(ツ)_/¯

@mbauman
Copy link
Member

mbauman commented May 23, 2019

Would still be nice to do separately.

@ararslan
Copy link
Member Author

The test should probably be backported with the fix itself, I would think. But yeah, can do.

@ararslan
Copy link
Member Author

Test added in #32124.

@ararslan ararslan removed the needs tests Unit tests are required for this change label May 23, 2019
KristofferC pushed a commit that referenced this pull request May 23, 2019
This restricts the element type of the input vector to be `<:Real` and
only converts in case the promoted type is concrete.

Fixes #32092.

(cherry picked from commit 587cb82)
@KristofferC KristofferC mentioned this pull request May 23, 2019
58 tasks
KristofferC pushed a commit that referenced this pull request Aug 26, 2019
This restricts the element type of the input vector to be `<:Real` and
only converts in case the promoted type is concrete.

Fixes #32092.

(cherry picked from commit 587cb82)
@KristofferC KristofferC mentioned this pull request Aug 26, 2019
55 tasks
KristofferC pushed a commit that referenced this pull request Aug 26, 2019
This restricts the element type of the input vector to be `<:Real` and
only converts in case the promoted type is concrete.

Fixes #32092.

(cherry picked from commit 587cb82)
@KristofferC KristofferC added the bugfix This change fixes an existing bug label Sep 9, 2019
KristofferC pushed a commit that referenced this pull request Feb 20, 2020
This restricts the element type of the input vector to be `<:Real` and
only converts in case the promoted type is concrete.

Fixes #32092.

(cherry picked from commit 587cb82)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix This change fixes an existing bug linear algebra Linear algebra
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Matrix * Vector uses convert with promote_op, causes issues on 1.1+
5 participants