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

Add three workflows #37

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

amontoison
Copy link
Member

No description provided.

@codecov
Copy link

codecov bot commented Dec 13, 2022

Codecov Report

Base: 99.06% // Head: 99.13% // Increases project coverage by +0.06% 🎉

Coverage data is based on head (151b1d5) compared to base (869eeda).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #37      +/-   ##
==========================================
+ Coverage   99.06%   99.13%   +0.06%     
==========================================
  Files           6        6              
  Lines         214      231      +17     
==========================================
+ Hits          212      229      +17     
  Misses          2        2              
Impacted Files Coverage Δ
src/struct.jl 100.00% <0.00%> (ø)
src/broadcast.jl 100.00% <0.00%> (ø)
src/linearAlgebra.jl 100.00% <0.00%> (ø)
src/krylov.jl 98.63% <0.00%> (+0.24%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@amontoison
Copy link
Member Author

amontoison commented Dec 13, 2022

@paraynaud You have a lot of ambiguities (Aqua workflow) and invalidations (Invalidations workflow).
If you have invalidations, it means that functions in Base and dependencies must be recompiled because you redefine one of them or you abuse of type-piracy. They are performance killers.

@paraynaud
Copy link
Member

@paraynaud You have a lot of ambiguities (Aqua workflow) and invalidations (Invalidations workflow).

I saw ambiguities, but not the invalidations, where should I look?

If you have invalidations, it means that functions in Base and dependencies must be recompiled because you redefine one of them or you abuse of type-piracy. They are performance killers.

I redefine many Base, LinearAlgebra and Krylov methods, so nothing unexpected ;)
What do you mean by "recompiled"? Where should I recompile something? (e.g. PartitionedVectors.jl side or elsewhere)

What is the result of these workflows on other modules? (or PartitionedVectors.jl is the first one?)

PS: For your information, I will soon release [email protected], it improves a lot the performances.

@amontoison
Copy link
Member Author

I saw ambiguities, but not the invalidations, where should I look?

The workflow Invalidations / evaluate gives the number of invalidations and tests that you don't add new invalidations with new pull request. Because it's the first time we use it here, it can't determine if you added more invalidations.

If you have invalidations, it means that functions in Base and dependencies must be recompiled because you redefine one of them or you abuse of type-piracy. They are performance killers.

I redefine many Base, LinearAlgebra and Krylov methods, so nothing unexpected ;) What do you mean by "recompiled"? Where should I recompile something? (e.g. PartitionedVectors.jl side or elsewhere)

Do you redefine them or extend them for your type?
I think that in some cases you redefined the Base and LinearAlgebra functions, so it means after using PartitionedVectors the routines that you redefined will be used by all other packages and they must be recompiled at runtime because you invalidate what was already (pre)compiled.

What is the result of these workflows on other modules? (or PartitionedVectors.jl is the first one?)

The CompatHelper.yml will open a new PR for you when a dependency has a new version.
The Aqua.yml do a collection a basic checks, it is explained here.
All tests should passed for a Julia package.

About the invalidations, Krylov.jl I has 0 invalidation, DCISolver.jl has 15 invalidations and your package 532.

PS: For your information, I will soon release [email protected], it improves a lot the performances.

Good news! But you will have other improvements if you track and fix some of these invalidations.

@paraynaud
Copy link
Member

Thanks for the explanation.

Do you redefine them or extend them for your type?

For dot, I do:

import LinearAlgebra.dot

dot(pv1::PartitionedVector{T}, pv2::PartitionedVector{T}) where {T}
  some_stuff(pv1,pv2)
end

I think that extends the number of dot methods available, because dot(ones(5), rand(5)) still works,
See Krylov extensions, LinearAlgebra extensions and Base.broadcast extension.

I will try to fix ambiguities and invalidations before [email protected], I opened an issue.

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.

2 participants