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

Use 5-arg mul! for matrices #68

Merged
merged 10 commits into from
Sep 26, 2019
Merged

Use 5-arg mul! for matrices #68

merged 10 commits into from
Sep 26, 2019

Conversation

dkarrasch
Copy link
Member

@dkarrasch dkarrasch commented Sep 2, 2019

Closes #56.

  • introduce MatrixMap{T} <: WrappedMap{T}
  • direct 5-arg mul! for MatrixMaps to LinearAlgebra's 5-arg mul!
  • make MatrixMap invariant under adjoint/transpose
  • use this, if possible, in linear combinations

@dkarrasch
Copy link
Member Author

I tested this on a BlockMap, in which subsequent matvec-mul results are added to previous results. The only allocations are due to views, in contrast to earlier Julia/LinearMaps versions.

@coveralls
Copy link

coveralls commented Sep 2, 2019

Coverage Status

Coverage decreased (-1.7%) to 94.684% when pulling b22a8b8 on going-5argmul into 3d2e53f on master.

@codecov
Copy link

codecov bot commented Sep 2, 2019

Codecov Report

Merging #68 into master will decrease coverage by 3.72%.
The diff coverage is 93.33%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master     #68      +/-   ##
=========================================
- Coverage   98.62%   94.9%   -3.73%     
=========================================
  Files           8       8              
  Lines         435     451      +16     
=========================================
- Hits          429     428       -1     
- Misses          6      23      +17
Impacted Files Coverage Δ
src/wrappedmap.jl 100% <100%> (ø) ⬆️
src/linearcombination.jl 95.34% <90.9%> (-4.66%) ⬇️
src/transpose.jl 44.44% <0%> (-55.56%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c435822...639037d. Read the comment docs.

@codecov
Copy link

codecov bot commented Sep 2, 2019

Codecov Report

Merging #68 into master will decrease coverage by 0.94%.
The diff coverage is 97.29%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #68      +/-   ##
==========================================
- Coverage   98.62%   97.67%   -0.95%     
==========================================
  Files           8        8              
  Lines         435      473      +38     
==========================================
+ Hits          429      462      +33     
- Misses          6       11       +5
Impacted Files Coverage Δ
src/LinearMaps.jl 100% <ø> (ø) ⬆️
src/wrappedmap.jl 100% <100%> (ø) ⬆️
src/linearcombination.jl 96.92% <96.96%> (-3.08%) ⬇️
src/transpose.jl 88.88% <0%> (-11.12%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3d2e53f...b22a8b8. Read the comment docs.

@dkarrasch
Copy link
Member Author

Alright, this is tested really hard for zero allocations, for the case when the map is a wrapped map of some AbstractMatrix (called MatrixMap, not a type, just an abbreviation), a wrapped map of a uniformscaling object (called UniformScalingMap, which is going to be exported after #61 is merged), BTW these are joined as FreeMaps, and linear combinations of FreeMaps. In BlockMaps, any block can be the aforementioned FreeMap or LinearCombination of FreeMaps, and the only allocations are a few bytes for the views. Check out the newly added tests to get a flavor of what is allocation-free now.

@chriscoey Does this cover most of your applications? If not, I'd be interested to learn about the uncovered ones.

@dkarrasch dkarrasch requested a review from Jutho September 3, 2019 13:34
@chriscoey
Copy link

@dkarrasch thank you, you're brilliant! I'll let you know in the next couple months as we run benchmarks of our as-yet-unreleased optimization solver that calls methods from IterativeSolvers

@chriscoey
Copy link

Is this one ready for merge?

@dkarrasch
Copy link
Member Author

I think it is, but I would love to have @Jutho's eyes on it, just in case.

@Jutho
Copy link
Collaborator

Jutho commented Sep 25, 2019

My apologies for the delay, I'll try to review before the end of the week.

Copy link
Collaborator

@Jutho Jutho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great and ready to merge (or almost if you consider my small comments).

One final question, because I have lost track a bit: Are we at this point still using one(T) and zero(T) as default values of alpha and beta in the other 5-arg mul methods, or did we switch to true and false everywhere?

An = A.maps[n]
if An isa FreeMap
mul!(y, An, x, true, true)
else
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One trick I learned recently is to add, in the body of a loop, a statement like

if !(@isdefined z)
     z = similar(y)
end

which would then only allocate z once the first map which is not a FreeMap is encountered, and thus not allocate at all if all the maps are FreeMap

src/linearcombination.jl Outdated Show resolved Hide resolved
src/wrappedmap.jl Outdated Show resolved Hide resolved
@dkarrasch
Copy link
Member Author

Thanks, @Jutho! Things are a bit spread over the place, but the idea is to have true and false as defaults for alpha and beta everywhere. As for the other mul! methods, this is done in #66 (I hope, but will make sure).

@Jutho
Copy link
Collaborator

Jutho commented Sep 26, 2019

Yes indeed; I should have remembered. Anyway, I think this is good to merge, aside from maybe the == method for MatrixMap. And please remind me of any open PRs which are ready for review (and feel free to keep reminding me if there is no reaction), because I have not followed closely.

@dkarrasch dkarrasch merged commit 98cc86a into master Sep 26, 2019
@dkarrasch dkarrasch deleted the going-5argmul branch September 26, 2019 09:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

use LinearAlgebra's new generic in-place 5-arg mul! (requires Julia 1.3)?
4 participants