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

Different name for partial-update functions? #2

Open
tkelman opened this issue May 17, 2017 · 4 comments
Open

Different name for partial-update functions? #2

tkelman opened this issue May 17, 2017 · 4 comments

Comments

@tkelman
Copy link
Contributor

tkelman commented May 17, 2017

The signatures of A_mul_B! and scale! and similar here that take start indices that don't match the signatures used by those functions in base don't really need to use the same name here, do they? It might be clearer to distinguish them by more than just the number of inputs, since Base is never going to lower to or call these signatures.

@MikaelSlevinsky
Copy link
Member

I guess I could re-name to A_mul_B_with_indices_and_increments!, though with the importing it's technically harmless. I'm also open to suggestions.

The reason for their existence is that hierarchical matrices are defined block-wise and so for a Julia implementation to be on par with C or Fortran, I needed methods that implement (BLAS'ed) arithmetic on input vectors that don't start at the first index, and output to vectors that don't start at the first index either.

@tkelman
Copy link
Contributor Author

tkelman commented May 17, 2017

_partial ?

you might be incurring a bit of splatting penalty with the local fallback to the base methods

@MikaelSlevinsky
Copy link
Member

bit of splatting penalty with the local fallback to the base methods

Can you explain this a little more slowly? Do you mean that there may be an extra latency due to finding the right methods in Base's already large hash table for A_mul_B!?

@tkelman
Copy link
Contributor Author

tkelman commented May 17, 2017

splatting can have a non negligible performance cost in some situations, so

    for op in (:A_mul_B!, :At_mul_B!, :Ac_mul_B!, :scale!)
        @eval begin
            $op(args...) = Base.$op(args...)
        end
    end

might not be zero cost, depending on whether or not the compiler is happy with you.

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

No branches or pull requests

2 participants