sp00n
Prime95 AVX512 "auto runtime" stuck in loop
At some point it seems like the "automatic" runtime to finish "ALL" FFTs for AVX512 for every single core seem to get stuck in some loop and repeat the same FFTs.
It seems that the "All passed FFTs" fill up and eventually there's duplicates and the "number of FFT sizes already tested:" doesn't progress.
I am not sure why or how though, surely this is not meant to take 12+ hours per core? Log provided. Used version: 0.11.0.0alpha3
CoreCycler_2025-05-12_01-22-44_PRIME95_AVX512.log
Prime95 begins to randomize the order and repeat already tested FFT sizes, but I have only observed this after a full cycle has been completed.
I have to use a predefined list of FFT sizes to determine if all sizes have been tested though, and I don't have a processor that can do AVX512, so that list may simply be incorrect for AVX512.
Can you also attach the Prime95 logfile for that run?
In this case, it was stuck on Core 0 and I was getting a bit suspicious. Expected it to take longer per core compared to AVX2 but not this long :)
I can't remember anymore where I took the current values for AVX512 from.
I've adjusted the FFT sizes to those found in your run on the 9950X3D, and I just hope that it will also work for other CPUs that support AVX512.
The current version in the repository (alpha5) does have this new array, you can try to see if it works. According to your log file, one core should now take between 1:26h and 2:22h, depending on how random Prime95 chooses to be.
If you want more consistent run times per core, you could set restartTestProgramForEachCore = 1 so that Prime95 starts fresh for each core.
Similar problem: It got to 149, stopped for a bit, then got to 156 FFTs tested and got stuck there:
CoreCycler_2025-05-13_00-13-44_PRIME95_AVX512.log
Prime95_2025-05-13_00-13-44_AVX512_ALL_FFT_4K-65536K.log
It looks like the two threads have gone too far out of sync here.
The script currently looks up to 6 lines upwards to find a matching FFT size "pair" that would indicate that an FFT size has been completed by both threads, but one thread seems to run substantially faster (resp. slower) than the other here, which over time leads to a too large gap between the log entries.
You could search for the $maxRowsToCheck = 6 entry inside script-corecycler.ps1 and change it to something else, maybe 10 or even higher, to see if that changes anything for you.
Setting the value too high might produce unexpected results, maybe double countings, I'm not sure right now.
It also might be a good idea to additionally set restartTestProgramForEachCore = 1 so that the discrepancy doesn't get even larger over timer.
I did use RestartTestProgram for the 2nd run, but it never switched core so it wouldn't matter.
I'll test increasing maxRows and see if there's changes anything. I will also increase the priority, but i don't think this is an issue; I've ran the tests over night so there shouldn't be anything else taking CPU time.
I increased rows to check, $maxRowsToCheck = 12; are these logs proper?
I ran it with restartTestProgramForEachCore = 1 as well, each core seemed to take 1½ hours which seemed kind of fast so I'm wondering if it went through all. The logs seems to suggest so.
Logs are also split up into two "sessions" because I ran it under two different nights.
CoreCycler_2025-05-24_02-40-19_PRIME95_AVX512.log Prime95_2025-05-24_02-40-19_AVX512_ALL_FFT_4K-65536K.log CoreCycler_2025-05-22_00-20-52_PRIME95_AVX512.log Prime95_2025-05-22_00-20-52_AVX512_ALL_FFT_4K-65536K.log
Also, in addition to this, let me know if there's some other AVX512 things that needs to be tested more thoroughly for corecycler.