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

Invalidations caused by lock(io::IOCustom) #1607

Closed
sumiya11 opened this issue Feb 14, 2024 · 2 comments
Closed

Invalidations caused by lock(io::IOCustom) #1607

sumiya11 opened this issue Feb 14, 2024 · 2 comments

Comments

@sumiya11
Copy link
Contributor

It seems that lock(io::IOCustom) in combination with Groebner.jl wins the first prize for the number of method invalidations.

Running

# from https://sciml.ai/news/2022/09/21/compile_time/
using SnoopCompile

invalidations = @snoopr begin
    using AbstractAlgebra
    R, (x,y) = polynomial_ring(QQ, ["x","y"], ordering=:degrevlex)
    using Groebner
    groebner([x^2 - y^2, x*y^2 + x])
end

trees = SnoopCompile.invalidation_trees(invalidations);

@show length(SnoopCompile.uinvalidated(invalidations)) # show total invalidations (1102)

show(trees[end]) # show the most invalidated method

I get

inserting lock(io::AbstractAlgebra.PrettyPrinting.IOCustom) @ AbstractAlgebra.PrettyPrinting C:\data\projects\AbstractAlgebra.jl\src\PrettyPrinting.jl:1840 invalidated:
   backedges: 1: superseding lock(::IO) @ Base io.jl:26 with MethodInstance for lock(::IO) (621 children)
              2: superseding lock(::IO) @ Base io.jl:26 with MethodInstance for lock(::IO) (4 children)

This is more than half of the total number of invalidated methods. I use AbstractAlgebra.jl from the master branch, but the issue seems to be present also for older versions.

At the moment, I am not sure why this happens, or how to fix this. Looks related: JuliaLang/julia#46878

@fingolfin
Copy link
Member

You don't really need the "Groebner" package, just do

invalidations = @snoopr using AbstractAlgebra

and it already reports a few hundred invalidations.

However, there is nothing wrong with our lock method as far as I can tell - the culprit is most likely the code calling lock. E.g. it may not be fully type stable. You can do

ascend(trees[end].backedges[1])

to find out more. Here is a screenshot to retain the colors:

Screen Shot 2024-02-15 at 10 28 44

As you can see, println is the "culprit" here. It is defined like this:

println(xs...) = println(stdout, xs...)

but stdout is a non-constant global, so this code is not type stable.

So I really don't see what we could do about it; as you already found out it is really an issue in Julia itself, as you found out.

@fingolfin fingolfin closed this as not planned Won't fix, can't repro, duplicate, stale Feb 16, 2024
@sumiya11
Copy link
Contributor Author

Thanks for your comment and the explanation !

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