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

pkgimage: use faster flags to jl_matching_methods #48841

Merged
merged 2 commits into from
Mar 4, 2023
Merged

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Mar 1, 2023

This does a better job of filtering out duplicates, which can both save a lot of time and avoid spurious invalidations.

For example, this is an example I had been shown recently:

julia> @time Base._methods_by_ftype(Tuple{typeof(eltype), Type{A} where A<:(NamedTuple{names, T} where T<:Tuple where names)}, -1, Base.get_world_counter());
  0.365237 seconds (625.08 k allocations: 27.142 MiB)
# returns 86 and increasing matches

julia> @time Base._methods_by_ftype(Tuple{typeof(eltype), Type{A} where A<:(NamedTuple{names, T} where T<:Tuple where names)}, 10, Base.get_world_counter());
  0.380524 seconds (709.15 k allocations: 32.155 MiB)
# returns 2 matches, always

This does a better job of filtering out duplicates, which can both save
a lot of time and avoid spurious invalidations.

For example, this is an example I had been shown recently:
```
julia> @time Base._methods_by_ftype(Tuple{typeof(eltype), Type{A} where A<:(NamedTuple{names, T} where T<:Tuple where names)}, -1, Base.get_world_counter());
  5.200027 seconds (651.79 k allocations: 28.765 MiB, 93.73% gc time)

julia> @time Base._methods_by_ftype(Tuple{typeof(eltype), Type{A} where A<:(NamedTuple{names, T} where T<:Tuple where names)}, 10, Base.get_world_counter());
  0.403162 seconds (647.60 k allocations: 28.124 MiB, 20.61% gc time)
```
@vtjnash vtjnash requested a review from topolarity March 1, 2023 13:52
@topolarity
Copy link
Member

Should we do some benchmarking with this, e.g. on a PkgEval run? Or do we expect this to be uniformly faster for algorithmic reasons?

@vtjnash
Copy link
Member Author

vtjnash commented Mar 1, 2023

Er, no, we know this is algorithmically slower in general itself. It is faster because it can help avoid invalidations. (I fixed the numbers in the example above)

Copy link
Member

@topolarity topolarity left a comment

Choose a reason for hiding this comment

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

OK that aligns with my initial understanding that lim == -1 is generally the fast-path, if you're getting all matches.

Sounds like an important change. I didn't realize that we are marking extra invalidations due to imprecise method matching. That's probably worth the extra perf cost to fix, but given the performance variation we've been seeing lately (e.g. #48811) I do think we'll want a good benchmark for these kinds of hairy improvements in general

Not that we need to gate the PR on that necessarily, but is there a quick MWE that this is known to improve?

@vtjnash
Copy link
Member Author

vtjnash commented Mar 1, 2023

It seems more impactful when #48846 is included too, since that seems much better at avoiding work.

@vtjnash vtjnash added the merge me PR is reviewed. Merge when all tests are passing label Mar 3, 2023
@vtjnash vtjnash merged commit eb36cb9 into master Mar 4, 2023
@vtjnash vtjnash deleted the jn/pkgimg-fast-edges branch March 4, 2023 18:30
@oscardssmith oscardssmith removed the merge me PR is reviewed. Merge when all tests are passing label Mar 4, 2023
@vtjnash vtjnash added the backport 1.9 Change should be backported to release-1.9 label Mar 6, 2023
KristofferC pushed a commit that referenced this pull request Mar 7, 2023
This does a better job of filtering out duplicates, which can both save
a lot of time and avoid spurious invalidations.

(cherry picked from commit eb36cb9)
@KristofferC KristofferC mentioned this pull request Mar 7, 2023
52 tasks
@KristofferC
Copy link
Member

I had to drop this from 1.9 since a straight up backport caused errors in the precompile tests.

@KristofferC KristofferC removed the backport 1.9 Change should be backported to release-1.9 label Mar 8, 2023
@@ -936,7 +936,7 @@ precompile_test_harness("code caching") do dir
j = findfirst(==(tagbad), invalidations)
@test invalidations[j-1] == "insert_backedges_callee"
@test isa(invalidations[j-2], Type)
@test isa(invalidations[j+1], Vector{Any}) # [nbits(::UInt8)]
@test invalidations[j+1] === nothing || isa(invalidations[j+1], Vector{Any}) # [nbits(::UInt8)]
Copy link
Member

Choose a reason for hiding this comment

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

The whole point of this test was to ensure that we could identify the cause of the invalidation.

Copy link
Member Author

Choose a reason for hiding this comment

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

It can be very costly to decide, which is why we don't here on deserialization, cutting off the search as soon as we show that there is more than one reason, without knowing what they are.

Copy link
Member

Choose a reason for hiding this comment

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

We need to be able to find the source of invalidations, otherwise how can we fix them? But #48982 may provide a solution.

@timholy
Copy link
Member

timholy commented Mar 11, 2023

I think this needs to be reverted.

timholy added a commit that referenced this pull request Mar 11, 2023
timholy added a commit that referenced this pull request Mar 12, 2023
This modifies #48841 to restore the required logging data.  When
logging is on, it recalculates the method-match as needed, casting a
wider net to ensure that we identify the trigger of the invalidation.
timholy added a commit that referenced this pull request Mar 15, 2023
This modifies #48841 to restore the required logging data.
By collecting at least one additional match, we retain the possibility
of identifying at least one trigger of invalidation.
oscardssmith pushed a commit that referenced this pull request Mar 17, 2023
* Ensure accurate invalidation logging data

This modifies #48841 to restore the required logging data.
By collecting at least one additional match, we retain the possibility
of identifying at least one trigger of invalidation.

* Bump number of invalidation causes

* Update src/staticdata_utils.c

Co-authored-by: Jameson Nash <[email protected]>

---------

Co-authored-by: Jameson Nash <[email protected]>
oscardssmith pushed a commit to oscardssmith/julia that referenced this pull request Mar 20, 2023
* Ensure accurate invalidation logging data

This modifies JuliaLang#48841 to restore the required logging data.
By collecting at least one additional match, we retain the possibility
of identifying at least one trigger of invalidation.

* Bump number of invalidation causes

* Update src/staticdata_utils.c

Co-authored-by: Jameson Nash <[email protected]>

---------

Co-authored-by: Jameson Nash <[email protected]>
Xnartharax pushed a commit to Xnartharax/julia that referenced this pull request Apr 19, 2023
* Ensure accurate invalidation logging data

This modifies JuliaLang#48841 to restore the required logging data.
By collecting at least one additional match, we retain the possibility
of identifying at least one trigger of invalidation.

* Bump number of invalidation causes

* Update src/staticdata_utils.c

Co-authored-by: Jameson Nash <[email protected]>

---------

Co-authored-by: Jameson Nash <[email protected]>
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.

5 participants