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

reduce allocation in a few linalg functions while removing full calls #24137

Merged
merged 2 commits into from
Oct 19, 2017

Conversation

Sacha0
Copy link
Member

@Sacha0 Sacha0 commented Oct 14, 2017

This pull request reduces allocation in a few linalg functions by replacing (allocating) full calls with (non-allocating) alternatives. Serves as another small step towards deprecation of full. Ref. #12153, #12251, #18850, and linked threads. Best!

@Sacha0 Sacha0 added domain:linear algebra Linear algebra performance Must go faster labels Oct 14, 2017
@Sacha0 Sacha0 added this to the 1.0 milestone Oct 14, 2017
@andreasnoack
Copy link
Member

What about having a generic function for this operation?

@Sacha0
Copy link
Member Author

Sacha0 commented Oct 14, 2017

What about having a generic function for this operation?

As in the present full!? I thought of extending full! from the triangular types to Symmetric/Hermitian and deploying it here, but hesitated for a few reasons:

Foremost I wanted to ponder full!'s semantics (to make certain I was not replacing one poorly defined operation with another). But full!'s semantics seem well defined: Make the parent match the child's contents and return the parent.

Next I was curious how frequently full! sees use, and whether in those cases some better approach exists. (My experience in eliminating full has been that usually a better approach exists, as e.g. in this pull request.) Outside the potential uses in this pull request, full! has only three uses (exclusively in two-argument A_mul_B[c]! methods), and one of those uses is redundant. But in those cases full!'s semantics do seem right, and as this pull request demonstrates full!'s semantics are useful beyond the existing uses.

So given the above I favor your proposition, i.e. I lean towards extending full! to Symmetric/Hermitian and deploying it here. But simultaneously I would rename full! to reflect its semantics. Some ideas: fillparent!, fixparent!, matchparent!, conformparent!, completeparent!.

In any case playing with full! seemed like something for a followup pull request, so I left off.

Thoughts? Thanks! :)

@Sacha0 Sacha0 force-pushed the repfullopts branch 2 times, most recently from 43ce5a5 to c81411a Compare October 14, 2017 19:19
@Sacha0 Sacha0 mentioned this pull request Oct 14, 2017
@Sacha0 Sacha0 force-pushed the repfullopts branch 6 times, most recently from 18dc3e8 to 30879bd Compare October 17, 2017 18:24
@Sacha0
Copy link
Member Author

Sacha0 commented Oct 17, 2017

Rebased and extended to the full calls introduced in #23679. Assuming CI signs off and absent objections or requests for time, I plan to merge these changes this evening or tomorrow morning and carry through the plan outlined in #24137 (comment) in a followup pull request. Best!

@fredrikekre
Copy link
Member

linalg/dense: Test Failed
  Expression: all((z->begin
            -π < imag(z) < π && real(z) > 0 || (0 <= imag(z) < π && abs(real(z)) < abstol || abs(imag(z) - π) < abstol && real(z) >= 0)
        end), (eigfact(acosh(A)))[:values])

@Sacha0
Copy link
Member Author

Sacha0 commented Oct 17, 2017

(The CI failure should be fixed. Thanks @fredrikekre! :) )

@Sacha0 Sacha0 merged commit 4ae0155 into JuliaLang:master Oct 19, 2017
@Sacha0 Sacha0 deleted the repfullopts branch October 19, 2017 01:24
@Sacha0
Copy link
Member Author

Sacha0 commented Oct 19, 2017

Thanks all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:linear algebra Linear algebra performance Must go faster
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants