Prime95 v25.3

[Prime95]

Originally Posted by rayrob

Any chance of a Windows x64 build to try?

Ask and ye shall receive: ftp://mersenne.org/gimps/p64v253.zip

[Knappo]

If started crunching a number with the new version. First the things I like (press FF on your mouse if you want to :-)

a) Seperating the threads gives you a very good overview over the things happening

Now the things I would prefer to be changed...

a) If you close one of the thread windows there is no chance to show it again (Or I haven't found it)

b) Communication is done in plain, so everybody can see your pass (Ok, this is also done by the "old" Prime95). Why not use at least a MD5 hash as passwort or (better but more complicated) using OpenSSL for the entire connection

c) Worst of all is, that your pass is shown in the programm (in the com-window). Why is it masked in the options but appears every time your computer talks to the server?


I haven't noticed a speed difference to the old version (in P-1) yet, but I will stay tuned.

[Knappo]

Another glitch I've just seen:

The title of the worker states always the last message of the thread. How ever, after finishing P-1 stage 1 there is no new title.
My log currently states the following:
[Jul 19 10:29] ... stage 1 is 98.69% complete. Time: 393.230 sec.
[Jul 19 10:36] ... stage 1 is 99.46% complete. Time: 401.040 sec.
[Jul 19 10:41] ... stage 1 complete. 127080 transforms. Time: 5402.264 sec.
[Jul 19 10:41] Starting stage 1 GCD - please be patient.
[Jul 19 10:45] Stage 1 GCD complete. Time: 226.122 sec.
[Jul 19 10:45] Using 495MB of memory. Processing 25 relative primes (0 of 480 already processed).

But the title of the window says:
Worker thread #1 - 99.46% of .... P-1 stage 1

Shouldn't there be a newer message?

Update: The tooltip of the systra icon states also the old message:
"Prime 95 - 99.46% of .... P-1 stage 1"

[monst]

a) If you close one of the thread windows there is no chance to show it again (Or I haven't found it)

>> stopping and continuing will restore the worker thread windows.

[Prime95]

Originally Posted by Knappo

a) If you close one of the thread windows there is no chance to show it again

I've thought about disabling the "close window" menu choice. I'll have to research how to do that. Do you think we need a method to stop individual worker threads? Right now your only option is stop them all.

b) Communication is done in plain, so everybody can see your password.

The new server does not use a password on the client side. The only problem I see is that someone can add their computer to your user id without your permission.

There is a password required to edit your user information on the web pages.


Thanks for the feedback.

[Prime95]

Originally Posted by Knappo

But the title of the window says:
Worker thread #1 - 99.46% of .... P-1 stage 1
Shouldn't there be a newer message?

I'll fix that.

[chappjc]

Originally Posted by Prime95

I've added links to the Linux, Linux 64-bit, and Intel Mac OS X versions. These are not well tested. Please report any bugs, though it is unlikely I'll be able to address them until I return around July 4th.

Linux specific tests and questions include:
1) load average option - I probably broke it.
2) Is the -B option needed anymore.
3) Should the check for another running version of mprime be changed or eliminated?

I have mprime 25.3 for linux 64-bit running on Ubuntu x86_64 7.04. The machine has two (2) dual core Xeons with 32GB RAM. So, that's 4 physical computational cores on 2 chips.

So I configured 4 worker threads and started mprime running using "whatever makes the most sense." Stage one seems to have completed over night, running in the background, but the program was stalled with 0% CPU when I checked this morning. So I killed the process (had to use -1 because -15 wouldn't do the job). When I restarted with ./mprime -d, I saw the four worker threads trying to start stage 2, but the first worker thread to start always claimed too much of the memory.

I don't remember the exact messages, but I think the other workers would say something like "another worker is using a lot of memory". I'll post the exact message later.

If I increased the day/night memory, the first thread would always claim an increasingly huge portion of the memory and the rest would not be able to start properly. I have tried 2048/2048 and still problems, but maybe 2 threads start now... not sure. Messages would continually flood the terminal because they never quite gave up trying to start. Again, I will post these messages later too.

[monst]

George, I definitely vote for having the ability to stop individual threads. In the future as we move to more threads, this would be even more useful.

[Prime95]

Originally Posted by chappjc

I have mprime 25.3 for linux 64-bit running on 4 physical computational cores on 2 chips.

I don't remember the exact messages, but I think the other workers would say something like "another worker is using a lot of memory". I'll post the exact message later.

Thanks, you do not need to post more info. I've reproduced the trouble. I'll work on a fix.

The way it is supposed to work is one worker grabs the memory and does stage 2. The other three workers having insufficient memory to run stage 2 should start their LL test. They will do stage 2 when the first worker completes stage 2.

[chappjc]

I am naïve to the whole process of prime testing so bear with me here. Two questions:

1. Why don't the four workers each take 1/4 of the memory for their stage 2? Stage 2 can apparently work with just about any amount of memory I give it.
2. What is the optimal memory in terms of performance? As far as I can recall, an older v24 mprime asked for a value between 8 and 23 MB for some reason.

Thanks!

[chappjc]

Originally Posted by Prime95

The other three workers having insufficient memory to run stage 2 should start their LL test. They will do stage 2 when the first worker completes stage 2.

To get around this in the meantime, I changed the number of workers to 1 and the number of threads per worker to 4. It plowed through stage 2 very quickly.

Could there be a separate option for "threads per stage 2 worker"? Alternatively, the stage 2 worker could always be run with an extra thread to finish faster. I'm not exactly sure what the point of that would be, however I observed that stage 2 P-1 seemed to benefit quite a bit from extra threads. Two gives the greatest boost, while a third and fourth added very little. (With four cores and mprime set to use 4 threads per worker, it only uses 260% of 400% max CPU usage.)