Prime95 version 29.5b5

[kladner]

More than once, P95v29.5b5 has paused for needed benchmarks, and failed to complete. I can't say exactly where it stopped, but after at least ten trials, it hangs without completing the line. I was uncertain at first because I forced it to quit previously. Last night, I left it alone (0% CPU), and it was still stuck 7 hours later. It resisted quitting, requiring Task Manager to kick it out.

I don't remember a report of this behavior, though I could have missed it.

[Prime95]

Does it occur at the same FFT size & implementation each time? Can you email results.txt? Maybe a little info on the number of cores/workers?

In the mean time use AutoBench=0 (see undoc.txt)

[ATH]

Can we get an AutoBench=2 feature that forces an automatic benchmark next time you start Prime95/mprime?

[kladner]

Originally Posted by Prime95

Does it occur at the same FFT size & implementation each time? Can you email results.txt? Maybe a little info on the number of cores/workers?

In the mean time use AutoBench=0 (see undoc.txt)

System: -i7 6700K, 16 G RAM, 4 cores, 1 worker. CPU@4300mhz, RAM@3200mhz
[Fri Dec 21 23:34:09 2018] -auto bench
EDIT: To answer more completely, I think auto-bench was only running 2560K, 4 threads, 1 worker, for best setting. I reran the same bench successfully. This lockup happened once before, 2 or 3 months ago, but I didn't really pay attention. I would rate it as "fairly rare." I have gone looking for the previous event in results.txt. The auto-bench first appears on [Fri Nov 30 05:12:52 2018]. Subsequent A-Bs are split between 2560 and 2400.

[kriesel]

In prime95 v29.4b8, the worker title bar indicates progress and exponent for a primality test but does not indicate which primality test is running, LL (or LL/Jacobi) or PRP (or PRP/GC). It can be a bit of a nuisance to go click Test, Status, and then wait for it to spin through the possibilities for a stack of lengthy P-1 assignments before displaying, the second worker is running LL now, hasn't switched to PRP yet per the setting of work preference.

It would be good if prime95 V29.5 when released indicated LL or PRP in the worker title bar. Does it include that now? See the red arrow in the attached screen shot of prime95 v29.4b8.

[kriesel]

Originally Posted by kladner

More than once, P95v29.5b5 has paused for needed benchmarks, and failed to complete. I can't say exactly where it stopped, but after at least ten trials, it hangs without completing the line. I was uncertain at first because I forced it to quit previously. Last night, I left it alone (0% CPU), and it was still stuck 7 hours later. It resisted quitting, requiring Task Manager to kick it out.

I don't remember a report of this behavior, though I could have missed it.

I tried 29.5b5 briefly on an i7-8750H (6 cores, HT available) Win 10 x64 laptop. A manually initiated benchmark for 1-3 and 6 workers stopped early and it just sat there. Attempts to launch new benchmarks manually to finish the job accomplished nothing more than irritation. There was also a crash and some Task Manager-necessary stop and restart of the application. I reverted to 29.4b8.

[kriesel]

I note that in prime95 V29.4b8, Test, Stop does not work while a Jacobi check is in progress. Apparently the Jacobi check must complete before the stop occurs. This is so, even if all the workers had been stopped, and then continue was accidentally clicked, or the user changes his mind about making a run, while workers are still starting. The Jacobi check takes minutes on some of my machines. The staggered starts of multiple workers may add more time during which the app may be unresponsive.
It would be good if Jacobi checks could be terminated early, or did not launch, when they accomplish nothing.
So, a request for the behavior of 29.5b7?

[Prime95]

The Jacobi check is done by the GMP library. Once I've made that call it cannot be interrupted.

[pepi37]

I noticed this info in latest Prime95 version, but dont know how it calculate probability.

If I have more tasks in worktodo, then probability is lower. If I have smaller number of tasks then probability is higher ( as you can see)
Anyway I do PRP on CRUs bases, so this is irrelevant , but as I say I noticed :)

[Mysticial]

Originally Posted by kriesel

I note that in prime95 V29.4b8, Test, Stop does not work while a Jacobi check is in progress. Apparently the Jacobi check must complete before the stop occurs. This is so, even if all the workers had been stopped, and then continue was accidentally clicked, or the user changes his mind about making a run, while workers are still starting. The Jacobi check takes minutes on some of my machines. The staggered starts of multiple workers may add more time during which the app may be unresponsive.
It would be good if Jacobi checks could be terminated early, or did not launch, when they accomplish nothing.
So, a request for the behavior of 29.5b7?

Cancelling is a basic yet one of the most annoying features to implement for any non-trivial application.

Some Thoughts:

I suppose if the issue is the UI lagging, then the Jacobi check could be moved to a different thread to let it run out.

AFAIK, GMP doesn't do proper exception/signal handling. So you can't use a signal to force it to break out. And if you do, it won't do the proper cleanup - thus leading to potential memory leaks.

I *think* the only resource that GMP uses is memory allocation. It doesn't spawn threads or create open file handles or anything. If there is a way to subvert the memory allocator that GMP uses, you can replace it with your own pool. Now you can terminate the entire thread that GMP is working on without leaking resources.

Another possibility is to move the Jacobi check to a different process. Then you can kill it without consequences.

[Prime95]

Originally Posted by pepi37

I noticed this info in latest Prime95 version, but dont know how it calculate probability.

If I have more tasks in worktodo, then probability is lower. If I have smaller number of tasks then probability is higher ( as you can see)
Anyway I do PRP on CRUs bases, so this is irrelevant , but as I say I noticed :)

Hmmm, don't count on that number. I just modified the code to better handle non-Mersennes.