Polyester causes significant TTFX due to dependency on CPUSummary.num_threads()

[Krastanov]

The pkgimages support was merged into julia today: JuliaLang/julia#47184

Even with that improvement, libraries that depend on Polyester see significant TTFX unless they run with julia -tauto. For instance consider the following library that depends on Polyester:

@time @eval QuantumClifford._precompile_() # a typical task used as a precompile directive

#with -tauto
0.037428 seconds (40.73 k allocations: ...)

#with Threads.nthreads() != Sys.CPU_THREADS
3.068928 seconds (4.78 M allocations: ...)

The reason for this seems to be that CPUSummary redefines num_threads in its __init__ call as discussed in these issues:

• Attribution for "insert_backedges" invalidations JuliaLang/julia#41913
• continued in Invalidations CPUSummary.jl#3
• an example of a fix in TriangularSolve reduce invalidations by not using CPUSummary.num_threads() TriangularSolve.jl#24
• maybe related fix in LoopVectorization JuliaSIMD/LoopVectorization.jl@def5ad1

My question is What is a reasonable path forward for improving this in Polyester? Is one of the following reasonable:

Is not using CPUSummary in Polyester an option? I suspect the goal is to have compile-time constants when deciding on number of threads, but I do not know whether that is possible without CPUSummary.

Is it possible to improve CPUSummary to avoid this issue?

[chriselrod]

Yeah, I suggest switching to Threads.nthreads instead.
PRs welcome. :)

[chriselrod]

CPUSummary.num_threads should be deprecated.

[Krastanov]

A first attempt at such a pull request is submitted (links above in this thread)