-
-
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
Darwin/ARM64: Julia freezes on @threads loops #45626
Comments
I can't reproduce it all 🤔 |
thank you @gbaraldi. I ran into this issue multiple times over the last 48 hours and was able to consistently reproduce it in the REPL in julia 1.7.2 as well as in julia 1.8.0-beta3 and julia 1.8.0-rc1 and thought this was happening all the time. After reading your post, I tried to rerun what I did earlier and it seemingly disappeared which confused me a lot. However, there's something new and even more interesting I found out now thanks to your post: this is not happening every time I run this script. I have to run the script over and over again and it only sometimes freezes (requires quite a lot of tries). Right now I have two different terminals opened on my Mac in which I ran the above posted codes and they are frozen at i = 8 and i = 11 respectively. |
something more I found out by now: this is even more likely to happen when using 2 terminal sessions executing the above codes at the same time, but running two sessions is not necessary to produce the freeze on my system. Also, I'm using 8 threads but this should be apparent from my versioninfo() I posted above. |
I've been trying to reproduce this with:
but I can't. I can even run up to 8 terminals running this same code, all on 6 threads, without issue. I repeated multiple times, but cannot get it to freeze. So either it's specific to 1.8, or there is some weird trigger hidden… |
thanks for your effort @fxcoudert. I recorded my screen when doing this with two open terminal sessions because I'm so puzzled as to why this would only happen on my machine. I really don't know what the trigger is, but if I do something wrong in the terminal session please tell me. The function foo.jl that I run in these terminal sessions is exactly what I posted above... threads_freeze.mov |
I was able to reproduce #41820 very easily back when it was a problem, but #43418 fixed it for me. I tried to run the code above multiple times, it never froze:
@ssagl can you check CPU usage in Activity Monitor? When #41820 was an issue it used to drop to 0 for me, indicating a deadlock situation. I agree with @fxcoudert that there may be something else going on causing the issue for you. |
thanks @giordano. I checked and when it freezes it seems like CPU usage is not going to zero but goes down from initially around 400 % to 100%. Screenshot from the Activity Monitor when it freezes below. Doesn't seem like a deadlock like you experienced previously. |
Is there a way on Mac OS to see which cores it got scheduled on? Maybe it's something with the efficiency cores? |
@vchuravy yes there is, thanks! I attach a snapshot of my CPU usage history when running the codes. Right when it starts to freeze, performance cores 6, 7, 8, 9, and 10 seem to not do anything anymore. Performance core 6 seems to come back at some time but not sure what that all means. |
Can reproduce with two concurrent sessions (i.e. two terminals with the I will let @vchuravy take it from here... but do note the behavior of the
|
Okay, I can now also reproduce with one process only, with One is not guaranteed to get the performance cores by simply staying below the total number of performance cores fwiw. One is likely going to get assigned efficiency cores anyway if they are asking for all or most of them, even on a 8-to-2 split like here. Stuff printed after ^C below.
|
@ngam thanks a ton, finally somebody who can reproduce this issue! I already thought this problem is just specific to my machine. Concerning that you can only reproduce with two concurrent sessions: I think it happens extremely infrequently with just one session (but that's still how I even noted this problem). I can also confirm that with |
But I suspect the line of reasoning of vchuravy above is key to figuring this out. |
oh we apparently posted this at the same time. great to hear you can reproduce everything now @ngam. |
My observation playing with this is that it is significantly more likely to happen if you use efficiency cores. You can notice the degradation very early on with much slower printing of the index. But anyway, this is a totally non-scientific stat below of three consecutive runs with
edit: foo.jl below function foo()
Threads.@threads for i in 1:10
rand()
end
end
for i in 1:1000
println(i)
for j in 1:10000
foo()
end
end |
Closes JuliaLang#45626, hopefully.
Closes JuliaLang#45626, hopefully.
I'm encountering a previously documented issue when running @threads loops on the arm64 native 1.8.0-rc1 version of julia. Apparently, this has been a known issue before but marked as closed (link to issue). The bug still seems to exist and is causing troubles for me. I'll quote a minimal example from the thread that initially documented this issue (Originally posted by @gbaraldi in #41820 (comment)):
This freezes for me somewhere in i = 11 on my Mac with the current 1.8.0-rc1 version of julia.
Below I attach the exact output of versioninfo():
The text was updated successfully, but these errors were encountered: