-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Make jl_cumulative_compile_time_ns
global (and reentrant).
#41733
Make jl_cumulative_compile_time_ns
global (and reentrant).
#41733
Conversation
Also: julia> function process_cumulative_compile_time_ns()
out = fill(UInt(0), Threads.nthreads())
Threads.@threads for i in 1:Threads.nthreads()
out[i] = Base.cumulative_compile_time_ns()
end
return sum(out)
end
process_cumulative_compile_time_ns (generic function with 1 method)
julia> process_cumulative_compile_time_ns() / 1e9
0.367209021 Which is maybe nice? :) I'm not sure if that's worth adding to the stdlib, or users should do that themselves? I guess I'll add it too - why not! |
Cool, that seems to work too! :) julia> @test Base.process_cumulative_compile_time_ns() >= Base.cumulative_compile_time_ns()
Test Passed
Expression: Base.process_cumulative_compile_time_ns() >= Base.cumulative_compile_time_ns()
Evaluated: 0x00000000008d47ed >= 0x00000000008d47ed
julia> Threads.@spawn @eval @time @eval 2+2
Task (runnable) @0x000000010fb907f0
0.004653 seconds (53 allocations: 2.703 KiB, 92.94% compilation time)
julia> @test Base.process_cumulative_compile_time_ns() >= Base.cumulative_compile_time_ns()
Test Passed
Expression: Base.process_cumulative_compile_time_ns() >= Base.cumulative_compile_time_ns()
Evaluated: 0x0000000000cf466f >= 0x00000000008d47ed |
ccfcc4f
to
4eece51
Compare
jl_cumulative_compile_time_ns
_reentrant_.jl_cumulative_compile_time_ns
global (and reentrant).
Okay this is now ready for review again! :) Thanks Valentin. 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you squash your commits?
I would like you have @vtjnash eyes on this once, but it looks good toe.
926f1a3
to
4dfc9a7
Compare
Thanks Valentin. Squashed!
Haha thanks for the review :) |
I just looked at the diff. There's a lot changed here that doesn't seem relevant. Did something go wrong in the squash? |
Oh thanks, it might've. I didn't check. Out to dinner now, will have a look
later :)
…On Sat, Jul 31, 2021, 4:23 PM Ian Butterworth ***@***.***> wrote:
I just looked at the diff. There's a lot changed here that doesn't seem
relevant. Did something go wrong in the squash?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#41733 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMCIEJS6OTLBEZRQNNJCWLT2RLUFANCNFSM5BHTOLFA>
.
|
4dfc9a7
to
5567f5f
Compare
Thanks @IanButterworth - fixed the squash. It looks right now. Thanks for catching that! :) |
@vtjnash - i think this PR is waiting for your review as well, whenever you get the chance. Thanks! |
I would also like to draw attention to my PR that tackles somewhat different aspect of this problem: #41762 (ability to turn the compilation tracking permanently which is going to be useful for long-running processes where we are okay with paying the overhead) |
@NHDaly friendly bump |
35939fe
to
213b590
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks Nathan! :)
(From an offline conversation: the exception-throwing-disabling-timing conundrum is to be addressed downstream.)
Thanks for the review @Sacha0! 😊 And yeah, thanks - i was just about to write up a message about the exception handling thing. Hokay, this PR is ready to go. It fixes the following problems:
It does not the following problem:
EDIT: I've opened #41923 to discuss fixing the exception problem above. |
d6c330e
to
619dec8
Compare
I think the remaining build failures are all unrelated:
Seem reasonable to merge now? |
Now, multiple tasks (on the same or different Threads) can start and stop compilation time measurement, without interrupting each other. * Makes jl_cumulative_compile_time_ns into a global, atomic variable. Instead of keeping per-task compilation time, this change keeps a global counter of compilation time, protected with atomic mutations. Fixes JuliaLang#41739 ```julia julia> include("./compilation-task-migration-17-example.jl") start thread: 2 end thread: 2 5.185706 seconds (3.53 M allocations: 2.570 GiB, 7.34% gc time, 15.57% compilation time) julia> include("./compilation-task-migration-17-example.jl") start thread: 3 WARNING: replacing module M. end thread: 1 4.110316 seconds (18.23 k allocations: 2.391 GiB, 5.67% gc time, 0.24% compilation time) ``` Compilation time measurement originally added in: JuliaLang#38885 Problems addressed: - This fixes JuliaLang#41739, meaning it fixes compilation time reporting in 1.7 after task migration was enabled. - It also fixes the race condition that existed previously, even on 1.6, where multiple Tasks on the thread measuring `@time` could break the measurement, as identified in (JuliaLang#41271 (comment)). - It fixes reentrant `@time` by making the `enable` flag a _counter,_ instead of a boolean. - It fixes `@time` called from multiple threads by making that flag thread-safe (via atomics).
4ad884f
to
b4ca196
Compare
Thanks Valentin |
Now, multiple tasks (on the same or different Threads) can start and stop compilation
time measurement, without interrupting each other.
Compilation time measurement originally added in: #38885
Problems addressed:
This allows users to enable global monitoring of compilation time, by enabling it withBase.cumulative_compile_time_ns_before()
, and then regularly callingBase.cumulative_compile_time_ns()
to track the metric, and finally optionally disabling it withBase.cumulative_compile_time_ns_after()
when they're done.@time
could break the measurement, as identified in (jl_cumulative_compile_time_ns_before
tracks compilation time per thread rather than per task #41271 (comment)).Here's a very simple example that shows the fixed "reentrant" behavior:
v1.6 - the inner
@time
disables compilation measurement, so the outer@time
misses it:this PR:
And here's the fixed examples from #41739: