Prime95 30.8 (beta, big P-1 changes, see post #551)

[Prime95]

Originally Posted by kruoli

[Worker #1]
Pminus1=N/A,1,2,22463209,-1,1000000,324000000,75
[Worker #2]
Pminus1=N/A,1,2,21362113,-1,1000000,32400000,75
Pminus1=N/A,1,2,21362903,-1,1000000,32400000,75.

If you are expecting 2 workers to share stage 2 memory in 30.8 you could be in trouble. If worker 1 is in stage 2 and worker 2 wants to enter stage 2 by "taking" some of worker 1's memory, then worker 1 will try to write a save file. Stage 2 save files are currently broken.

[Prime95]

Originally Posted by axn

Build 2 is bad with multithreading:

Build 2 is no different than build 1. I'm pretty sure there is a deadlocking/mutex issue in there that I have not found (I suck at writing good locking code). Your output may provide a clue. Thanks. I suspect restarting build 2 will multithread just fine (until it doesn't).

[kruoli]

Originally Posted by Prime95

If you are expecting 2 workers to share stage 2 memory in 30.8 you could be in trouble. If worker 1 is in stage 2 and worker 2 wants to enter stage 2 by "taking" some of worker 1's memory, then worker 1 will try to write a save file. Stage 2 save files are currently broken.

No, since you strongly recommend having only one worker in stage 2, I had the high memory worker count set to 1 (by not having set it since you said it would have 1 as its default value) and the second worker that tried to enter stage 2 was simply skipping their stage 2 (looking for work that uses less memory) and taking the next assignment since the high memory worker count was reached. This was all as expected.

The problem occurred when stage 2 had finished on worker #1, then reported the factor and crashed. I am not sure if this was because of immediately making up for the skipped stage 2 in worker 2 or not. At least, when I restarted Prime95, it tried to start stage 2 in worker #2 (when there was NO high memory work in worker #1), but then crashed nearly immediately with the details given above.

As an additional data point, the same exponent ran flawlessly on an i7 10700.

[lisanderke]

Bug report on Prime95 v30.8b2, Windows 11, Intel i5 8400 CPU, RTX 2060 SUPER GPU, 32 GB (4x8GB) of 2400 MHz RAM, dual screen setup with 1080p and 2160p (4K) monitors. Prime95 opens on the 4K monitor when retrieved from tray.

Opening Prime95 from tray during stage 2 seems to result in the following behavior:



1. Mfatkc performance drops significantly during Prime95 stage 2
- I've seen drops from ~1900 GHzDs/Day to ~1300 GHzDs/day on 108M exponents from 76 to 77 bits
2. Other GPU tasks (Youtube/Twitch watching) are affected
- Audio and video seem to stutter for a few seconds


Have had this happen on exponents of various sizes, 8M, 10M, 20M... nothing seems out of the ordinary in what Prime95 reports in the worker thread. These drops in performance/the thrashing behavior has been happening for a few days but I only really notice it when I'm watching Youtube/Twitch videos(/VODs). It doesn't happen only on opening of the GUI, sometimes it takes a few seconds before this happens. If I keep the GUI open it will happen occasionally every few minutes without me touching the GUI.

[lycorn]

How much memory have you allocated to Prime95?
With version 30.8, I have noted similar behaviour here. Thrashing, in particular, can be very hard and render the PC really sluggish occasionally. I have 16 GB ram, and I used to allocate 13,5 GB to Prime95; I didn´t notice any trouble while running version 30.7. WIth 30.8 I had to reduce the allocated memory to 12 GB in order to get a decent performance, and still I have a more noticeable impact than I had with 13.5 GB in 30.7. It seems that 30.8 is not using just the allowed memory, which doesn´t make a lot of sense, I know, but the effects are there.
During stage 2, if I put the mouse over the green icon of P95, or check the Task Manager, I get the info that 12 GB are in use, as prescribed in local.txt. Oh well,...
Could it be that 30.7 was not using all the allocated memory, while 30.8 is, and that was just masking the fact that we were actually allocating too much memory? I can´t think of another explanation.

[lisanderke]

I have 22GB allocated to Prime95, stage 2 seems to use all of it (in task manager as well)
Local.txt says; Memory=22528 during 7:30-23:30 else 22528
I could try other RAM allocations and see if it makes a noticeable difference in behavior!

[lycorn]

If you are using 22 out of 32 GB, which I think is the case, there is no reason (as far as memory is concerned) to experience all the symptoms you described. Funny.

[kriesel]

Originally Posted by lycorn

there is no reason (as far as memory is concerned) to experience all the symptoms you described.

Unless there's a memory leak/hog somewhere. Firefox browser can suck up a lot of GB at times, as one example. (My Firefox is currently hogging 6.5GB) Task Manager & sort process list by memory occupied might be informative. Add a game and a few other things, and 10GB occupancy elsewhere is possible. %disk time would be high if it is thrashing pages to the page file. Backing prime95 off by a GB (or 2) sometimes eliminates heavy paging.

[lycorn]

Originally Posted by kriesel

Unless there's a memory leak/hog somewhere. Firefox browser can suck up a lot of GB at times, as one example. (My Firefox is currently hogging 6.5GB) Task Manager & sort process list by memory occupied might be informative. Add a game and a few other things, and 10GB occupancy elsewhere is possible. %disk time would be high if it is thrashing pages to the page file. Backing prime95 off by a GB (or 2) sometimes eliminates heavy paging.

True. I was speaking strictly from P95 point of view. I very often get the impression there are processes not listed in Task Manager, but that are using up significant amounts of memory. For example, as I write this, P95 is running stage 1, so memory usage is really low (< 20 MB). Checking TM, there is the indication that 24% (~4 GB on my machine) of the memory is in use, but if I browse through the sorted (by mem usage) list of processes I can´t see how on earth 4GB are being used. Not even 2, let alone 4! This is a recurrent situation.

[techn1ciaN]

Originally Posted by lycorn

I very often get the impression there are processes not listed in Task Manager, but that are using up significant amounts of memory. For example, as I write this, P95 is running stage 1, so memory usage is really low (< 20 MB). Checking TM, there is the indication that 24% (~4 GB on my machine) of the memory is in use, but if I browse through the sorted (by mem usage) list of processes I can´t see how on earth 4GB are being used. Not even 2, let alone 4!

IIUC, recent versions of Windows (10 and 11 are the ones I have relevant experience with) will start opportunistically caching system files if there is not much RAM being "actively" used. This is not associated with any particular program, so wouldn't show up in Task Manager. The extent of the behavior seems to scale with the amount of RAM installed; I've seen anecdotes of systems with e.g. 128 GB RAM having as much as 10 or 20 GB "used" at system idle.

I have 16 GB of RAM installed in my Windows 11 laptop and at idle with nothing open, 5–6 GB is usually "used." I use this laptop for P-1 and these idle figures would seem to indicate that I could allocate no more than 9 or 10 GB to Prime95 before performance would degrade, but I actually have 13 GB allocated and experience no problems. Windows's caching creeps in during stage 1, but the necessary space is always vacated when stage 2 starts.

I have no idea if older versions of Windows (≤8.1) or any Linux distributions exhibit anything similar.

[nordi]

Originally Posted by techn1ciaN

I have no idea if older versions of Windows (≤8.1) or any Linux distributions exhibit anything similar.

Even MS DOS did this, otherwise the latency of magnetic hard discs would have been unbearable. Linux also does this, and is very transparent about it, which leaves many Linux novices confused why Linux uses so much RAM. The only change might be that Windows has started being more transparent about the RAM used for caching.