Prime95 version 25.6

Prime95 · 2007-12-22, 14:39

THIS IS A PRE-BETA VERSION - NOT FOR EVERYDAY USE

The Windows version of 25.6 is now available. If you are running version 25.5 you can install the new version on top of the old version.

Steps to install version 25.6
---------------------------

1) DO NOT INSTALL OVER VERSION 24. If you have problems, you want to be able to revert to testing using version 24. There will be outages on the new server so you'll want to let version 24 run at lower priority to soak up those available CPU cycles.
2) Create a new directory, download version 25.6 from the link below, unzip into this new directory.
3) PM or email to get the secret line to add to prime.txt so that this version contacts the new server.
4) Run version 25.6. Follow the link in the dialog box to create a userid. Choose a work preference of either "Trial factoring to low limits" or "ECM on small Mersenne numbers".
5) Find problems. Report them to me.

Known bugs
-----------

1) Time= option in prime.txt does not work.

Links to 25.6 versions
---------------------
Windows 32-bit - ftp://mersenne.org/gimps/p95v256.zip
Linux - ftp://mersenne.org/gimps/mprime256.tar.gz
Linux 64-bit - ftp://mersenne.org/gimps/mprime256-linux64.tar.gz
Windows 64-bit - ftp://mersenne.org/gimps/p64v256.zip
Mac OS X - ftp://mersenne.org/gimps/mprime256-MacOSX.tar.gz

Prime95 · 2007-12-22, 14:45

What's new compared to version 25.5? Not much. Several small bug fixes and a few important ones:

1) Bug in SSE2 trial factoring above 2^64 fixed.
2) Client-server getting out-of-sync in exchanging program options fixed.
3) Endless communication loop on Error 40 fixed.

The main reason for the release is it hard for me to debug version 25.5. I didn't put the sources under source control so I'm not exactly sure what bug fixes and changes are in 25.5. 25.6 is under RCS so I'll know exactly what source code you are reporting bugs on.

James Heinrich · 2007-12-22, 19:10

I await your Windows64 25.6 build

But I'll try the Win32 version on my Q6600 and see if the endless fight for stage2 RAM still exists.

James Heinrich · 2007-12-22, 20:02

Of 3 threads fighting for P-1 stage2 RAM, 1 now gets ~496MB (of 1024MB available) and the other 2 spend all their time fighting over the remaining ~500MB, perpetually restarting:

Code:

[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Available memory is 499MB.
[Work thread Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (13 of 480 already processed).
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Other worker threads are using lots of memory now.
[Work thread Dec 22 14:33] Looking for work that uses less memory.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Available memory is 499MB.
[Work thread Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (13 of 480 already processed).
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Other worker threads are using lots of memory now.
[Work thread Dec 22 14:33] Looking for work that uses less memory.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Available memory is 499MB.
[Work thread Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (13 of 480 already processed).
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Other worker threads are using lots of memory now.
[Work thread Dec 22 14:33] Looking for work that uses less memory.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Available memory is 499MB.
[Work thread Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (13 of 480 already processed).
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Other worker threads are using lots of memory now.
[Work thread Dec 22 14:33] Looking for work that uses less memory.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Using FFT length 2560K
[Work thread Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:33] Available memory is 499MB.
[Work thread Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (13 of 480 already processed).
[Work thread Dec 22 14:33] Restarting thread with new memory settings.
[Work thread Dec 22 14:33] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:34] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:34] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:34] Using FFT length 2560K
[Work thread Dec 22 14:34] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:34] Other worker threads are using lots of memory now.
[Work thread Dec 22 14:34] Looking for work that uses less memory.
[Work thread Dec 22 14:34] Optimal P-1 factoring of M46000949 using up to 1024MB of memory.
[Work thread Dec 22 14:34] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Work thread Dec 22 14:34] Optimal bounds are B1=560000, B2=16100000
[Work thread Dec 22 14:34] Chance of finding a factor is an estimated 6.5%
[Work thread Dec 22 14:34] Restarting thread with new memory settings.
[Work thread Dec 22 14:34] Using FFT length 2560K
[Work thread Dec 22 14:34] Ignoring suggested B1 value, using B1=555000 from the save file
[Work thread Dec 22 14:34] Available memory is 499MB.
[Work thread Dec 22 14:34] Using 496MB of memory.  Processing 19 relative primes (13 of 480 already processed).

Code:

[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:33] Available memory is 503MB.
[Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (10 of 480 already processed).
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:33] Other worker threads are using lots of memory now.
[Dec 22 14:33] Looking for work that uses less memory.
[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:33] Available memory is 503MB.
[Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (10 of 480 already processed).
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:33] Other worker threads are using lots of memory now.
[Dec 22 14:33] Looking for work that uses less memory.
[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:33] Available memory is 503MB.
[Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (10 of 480 already processed).
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:33] Other worker threads are using lots of memory now.
[Dec 22 14:33] Looking for work that uses less memory.
[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:33] Available memory is 503MB.
[Dec 22 14:33] Using 496MB of memory.  Processing 19 relative primes (10 of 480 already processed).
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:33] Other worker threads are using lots of memory now.
[Dec 22 14:33] Looking for work that uses less memory.
[Dec 22 14:33] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:33] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:33] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:33] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:33] Using FFT length 2560K
[Dec 22 14:33] Restarting thread with new memory settings.
[Dec 22 14:34] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:34] Available memory is 503MB.
[Dec 22 14:34] Using 496MB of memory.  Processing 19 relative primes (10 of 480 already processed).
[Dec 22 14:34] Restarting thread with new memory settings.
[Dec 22 14:34] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:34] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:34] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:34] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:34] Using FFT length 2560K
[Dec 22 14:34] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:34] Other worker threads are using lots of memory now.
[Dec 22 14:34] Looking for work that uses less memory.
[Dec 22 14:34] Optimal P-1 factoring of M46000987 using up to 1024MB of memory.
[Dec 22 14:34] Assuming no factors below 2^68 and 2 primality tests saved if a factor is found.
[Dec 22 14:34] Optimal bounds are B1=560000, B2=16100000
[Dec 22 14:34] Chance of finding a factor is an estimated 6.5%
[Dec 22 14:34] Using FFT length 2560K
[Dec 22 14:34] Restarting thread with new memory settings.
[Dec 22 14:34] Ignoring suggested B1 value, using B1=555000 from the save file
[Dec 22 14:34] Available memory is 503MB.
[Dec 22 14:34] Using 496MB of memory.  Processing 19 relative primes (10 of 480 already processed).

James Heinrich · 2007-12-22, 20:09

Quote:

Originally Posted by Prime95

1) Bug in SSE2 trial factoring above 2^64 fixed.

If you haven't already, you should dump all TF results from v25.5 above 2^64 since they may have missed factors. If possible, also avoid assigning or accepting TF results >2^64 for <25.4.

harlee · 2007-12-22, 22:26

Prime95,

Sorry for bringing this back up, but the server is still giving less credit for finding a factor in the 61-bit range than not finding a factor from 2^0 to 2^60 bits.

P4_2600_v256 221752123 NF 2007-12-22 22:19 0.2 no factor to 2^60 0.0007
P4_2600_v256 221750929 NF 2007-12-22 21:27 0.2 no factor to 2^61 0.0014
P4_2600_v256 221750927 F 2007-12-22 21:25 0.2 2264553794801324393 0.0006
P4_2600_v256 221747791 F 2007-12-22 19:35 0.1 1734156108967545617 0.0001

The bit size is from James Heinrich's web site.

2264553794801324393 = 60.97 bits
1734156108967545617 = 60.59 bits

James Heinrich · 2007-12-22, 23:32

I've gone through the v25.5 thread and dug up all my old bugs and feature requests and compiled them here for easy reference

bug: If communication & worker windows are merged, when the communication thread goes inactive the child window icon goes red and it looks like the worker thread is inactive (but it's still working).
I'd like to see an (additional) option to merge Main and Communication threads into one window and leave the worker threads each in their own window.
When doing multi-threaded ECM it shows "Using FFT length 20K, 2 threads", but for single-threaded it just says "Using FFT length 20K". Can you make it explicity say "Using FFT length 20K, 1 thread", please?
tooltip on system tray currently shows status of worker #1; can it please show one line per thread?
right-click in system tray and set Prime95 to "low-memory mode" to limit it to worktypes that don't use a lot of memory (TF, LL, P-1 stage1, etc) so that the user can (temporarily) limit the memory usage if they're about to do something that uses at lot of RAM during a scheduled period when Prime95 is usually allocated a lot of RAM (e.g. 3am Photoshop or gaming sessions).
LowMemWhileRunning setting (similar to PauseWhileRunning) to automatically kick Prime95 into low-memory-using worktypes when a memory-hogging program is launched, so the user doesn't have to manually set low-memory mode every time they launch Photoshop or Battlefield etc.
PauseWhileRunning ability to pause only X number of threads (e.g. pause 1 of 4 threads while notepad.exe is running, to allow a full core available to that program, while the others threads continue to work on Prime95)
# more complex scheduling for RAM usage: the ability to schedule multiple periods during the day when RAM usage can be high/low, different schedules for different days of the week. For example, I would set mine to high memory use most of the time, except (M-F,0600-0900;M-F,1800-2200;S-S,0800-2200).
ability to specify more than one type of worktype preference; for example I'd choose to any of TF, ECM or P-1. Ideally you could set a percentage distribution between the worktypes (e.g. spend 50% of time on TF, 30% on ECM and 20% on P-1) or have a "whatever-makes-most-sense" checkbox to auto-distribute the work among the selected types.
ability to merge main+comm threads
If one thread is idle because it has run out of work to do that doesn't require a lot of RAM, see if it can borrow or steal a worktodo entry from another thread. For example, if thread #1 is doing P-1 work, but it's done all the stage1 work it can for now but needs to wait until more memory is available, it should be able to look at the queued work for other threads and steal (or borrow) low memory work (TF, P-1 stage 1, LL, etc) to do while it waits for more memory to be available.
Have a worktype of "TF up to ___ bits" -- this would be basically a modification of the "TF to low limits", perhaps if you restrict the range of values entered (to something between 2^56 and 2^64?, perhaps defaulted to a sensible value based on general machine speed (e.g. 2^64 on a modern CPU but 2^56 for a 486, etc)) it would replace both the "TF to low limits" worktype, and the manual TF work that LMH does.
Prime95 should check not only if "other worker threads are using lots of memory now", but also whether the amount of memory left is enough to do something useful in. For example, right now I have 3072MB allocated to Prime95, and thread #2 is using (only) 1340MB for ECM-stage-2 (presumably it doesn't need any more than that for the work it's doing). Thread #1 isn't letting itself do any stage2 work because "other worker threads are using lots of memory now". But it should be able to do some of the Stage2 work it has queued up that wouldn't use more than the still-available 1700MB of memory anyways.
edit1: Times when lots of memory is available should be considered precious and if two (or more) "high-memory" tasks can co-exist, they probably should. For example, the next ECM-stage-2 work that Thread #2 has just moved on to is using only 279MB, leaving ~2793MB available to thread #1, but it still won't consider that it can try doing any Stage2 work.
edit2: Perhaps it would be best to prioritize queued lots-of-memory work in descending order of RAM requirements, such that when a lot of memory is available the worker thread would look at the available memory and work first on the queued exponent that requires the most memory, and move on to lower-memory tasks if the requisite amount of RAM isn't available. This would extend naturally into doing "no-memory" tasks last (such as P-1/ECM stage 1, TF, LL, etc) if there are no P-1/ECM Stage2 tasks queued that can fit in the available memory.
When you have a lot of work queued up in more than 1 worker thread, it will take up almost all of the vertical space in the "Status..." dialog showing you the work queued for Thread #1 like this:
Code:
```
<worktodo1>, <eta1>
<worktodo2>, <eta2>
<worktodo3>, <eta3>
<worktodo4>, <eta4>
.etc.
<worktodoN>, <etaN>
More...
[Worker thread #2]
More...
```
that is, it lists as much of Worker #1's work as it can, but then just shows that Worker #2 has something to do, but you can't even see the first line. It would (I think) be more useful to allocate 1/<workers> of the available lines to each worker thread, such that I can see the next 16 assignments for each of my 2 worker threads, rather than the next 32 assignments for Thread#1 and 0 for Thread#2.
Can you please put the bitversion (32-bit, 64-bit) as part of the "About" box in the Prime95 client, it's hard to tell them apart when testing
modified PauseWhileRunning to be able to specify how many threads to pause while said program is running. Default is to pause all threads, but quite possibly pausing 1 thread from a quadcore would be enough to allow said program to run smoothly. I'm not sure if this could/should be specified per item (e.g. "notepad[1],wmplayer[2],crysis[ * ]", where [x] is the number of threads to pause and * means all threads) or globally where (for example) 1 thread is paused for each instance of a running program that's in the list, so per the above example if both notepad and wmplayer are running then (up to) 3 threads should be paused.
I have 1 thread doing ECM on small Mersenne numbers, and another thread working on an LL test, but currently doing the initial P-1 factoring. Now Prime95 has gone through and done all the stage1 for the ECM work it has queued up, while the P-1 thread is still churning away on its stage2, which will take another day or so to complete. When I start Prime95 the ECM thread usually gets to the check-how-much-RAM-it-can-claim stage first, and allocates anywhere from 250-750MB for itself. If I have high RAM settings (say 2GB for Prime95) there's plenty left over for the P-1 thread to do something useful with, and it does. However, once the ECM thread finishes its stage2, the P-1 thread restarts with new settings and grabs all available RAM for itself and then the ECM thread sits idle (in this case for several days) because there is no RAM available to do stage2 work. I realize that (in many cases) using a lot of RAM is more efficient at processing than using less RAM; however you can see from this example my system would get far more work done using (for example) 250MB for ECM and 750MB for P-1 rather than 1GB for P-1 and the ECM thread sitting idle for 2 days. My request/suggestion is that Prime95 scans through the worktodo for all threads before allocating memory so that it could detect situations like this, where allocating less-than-max memory for one thread would result in greater overall throughput.
What might be workable, however, is specifying both a minimum RAM-per-thread a global max RAM setting. Global max works as it does now. Minimum RAM-per-thread means that a thread can always get that amount of RAM if it asks for it (assuming min_per_thread is forced to be <= global_max / threads). So if I have 1024MB allocated as global_maximum, and 256MB min_per_thread, then my first thread will start off and use the whole 1024MB for itself if no other threads need it, but when thread #2 comes along and asks for RAM, thread #2 will get its 256MB and thread #1 has to make do with only 768MB (it gets more RAM because it was there first).
On a related note, one observation:
I had 1 thread doing small-ECM-stage2, another doing P-1-stage2. ECM didn't ask for a lot of RAM (anywhere from 125MB to 450MB), while P-1 got the rest of the allocated 2.5GB. However, the ECM stage2 often takes a very short amount of time (30 seconds to a few minutes) and the P-1 thread spent all its time trying to initialize its 2GB of RAM, then halfway through that restart with new memory settings, only to repeat a few minutes later. I'm not sure if there's an easy solution. My above-proposed automatic intelligent memory allocation would probably be able to solve it, at least if combined with a mechanism that would calculate the "new" memory settings for all running threads and prevent a thread from restarting if its going to get allocated the same amount of RAM as it had before (and probably bias the allocation of RAM such that that happens if it doesn't impact efficiency much).
When starting stage2 could Prime95 print a message to the effect of "max efficiency needs <1234>MB of RAM; <768>MB available; using <620>MB"
Prime95's communication thread could use a better timeout system. It's been waiting for an acknowledgement for the last result it sent 1h45m ago. Of note: this attempted communication happened right on the hour (19:00h EST) so perhaps there are still issues where on-the-hour cron jobs cause problems elsewhere? In any case, if Prime95 doesn't get a valid response to a communication attempt within <30> seconds it should abort and try again later. It's not doing that.
I'd like to see all worktodo automagically assigned to available CPUs (unless the user has explicitly requested that certain cores only do certain work). There's no reason for core[1] to be idle when workdoto[2] has work waiting.
An extension to the above: If one (or more) cores are idle, and another core is working on something that can reasonably exploit more multithreading, respawn the other work with the appropriate number of threads to fully utilize the CPU. I'm currently doing a hack version of this: I have a dual-core CPU running TF-LMH on one core and LL on the other. Problem is that every now and then the server goes down and I can't get any work for the TF thread to do. Normally that would mean one core idle for hours (or days), but I have the LL set to run in 2 threads. Perhaps it's not ideal when TF has work (I'm not sure the of exact inefficiency ratio) but overall my throughput is definitely higher due to capturing all the otherwise-idle time on the TF core.

Prime95 · 2007-12-23, 02:37

Quote:

Originally Posted by harlee

Sorry for bringing this back up, but the server is still giving less credit for finding a factor in the 61-bit range than not finding a factor from 2^0 to 2^60 bits.

Fix #2 in place. Let me know if its better.

harlee · 2007-12-23, 12:50

Quote:

Originally Posted by Prime95

Fix #2 in place. Let me know if its better.

Just find another 61-bit factor, more credit but still less then no factor to 2^60 bits.

[Dec 23 07:42] Trial factoring of M222909889 to 2^61 is 0.01% complete.
[Dec 23 07:43] M222909889 has a factor: 1647118574100374201

P4_2600_v256 222909889 F 2007-12-23 12:43 0.0 1647118574100374201 0.0002

I consider this to be a low priority, just something I noticed and wanted to report. FYI, I've changed the worktodo.txt file to TF the next 20 exponents to 2^64 bits. Will see what happens.

harlee · 2007-12-23, 13:04

This is just an FYI to show credit for the higher bit levels.

P4_2600_v256 222909959 NF 2007-12-23 13:02 0.0 no factor from 2^63 to 2^64 0.0084
P4_2600_v256 222909959 NF 2007-12-23 12:52 0.0 no factor from 2^62 to 2^63 0.0044
P4_2600_v256 222909959 NF 2007-12-23 12:47 0.0 no factor from 2^61 to 2^62 0.0022
P4_2600_v256 222909959 NF 2007-12-23 12:45 0.0 no factor to 2^61 0.0014

Prime95 · 2007-12-23, 22:01

Quote:

Originally Posted by harlee

This is just an FYI to show credit for the higher bit levels.

Fix #3 in place. A stubborn bug. This time its a client problem. You'll see the fix next time I upload a new version.

2007-12-22, 23:32	#7
James Heinrich "James Heinrich" May 2004 ex-Northern Ontario 4081₁₀ Posts	I've gone through the v25.5 thread and dug up all my old bugs and feature requests and compiled them here for easy reference bug: If communication & worker windows are merged, when the communication thread goes inactive the child window icon goes red and it looks like the worker thread is inactive (but it's still working). I'd like to see an (additional) option to merge Main and Communication threads into one window and leave the worker threads each in their own window. When doing multi-threaded ECM it shows "Using FFT length 20K, 2 threads", but for single-threaded it just says "Using FFT length 20K". Can you make it explicity say "Using FFT length 20K, 1 thread", please? tooltip on system tray currently shows status of worker #1; can it please show one line per thread? right-click in system tray and set Prime95 to "low-memory mode" to limit it to worktypes that don't use a lot of memory (TF, LL, P-1 stage1, etc) so that the user can (temporarily) limit the memory usage if they're about to do something that uses at lot of RAM during a scheduled period when Prime95 is usually allocated a lot of RAM (e.g. 3am Photoshop or gaming sessions). LowMemWhileRunning setting (similar to PauseWhileRunning) to automatically kick Prime95 into low-memory-using worktypes when a memory-hogging program is launched, so the user doesn't have to manually set low-memory mode every time they launch Photoshop or Battlefield etc. PauseWhileRunning ability to pause only X number of threads (e.g. pause 1 of 4 threads while notepad.exe is running, to allow a full core available to that program, while the others threads continue to work on Prime95) # more complex scheduling for RAM usage: the ability to schedule multiple periods during the day when RAM usage can be high/low, different schedules for different days of the week. For example, I would set mine to high memory use most of the time, except (M-F,0600-0900;M-F,1800-2200;S-S,0800-2200). ability to specify more than one type of worktype preference; for example I'd choose to any of TF, ECM or P-1. Ideally you could set a percentage distribution between the worktypes (e.g. spend 50% of time on TF, 30% on ECM and 20% on P-1) or have a "whatever-makes-most-sense" checkbox to auto-distribute the work among the selected types. ability to merge main+comm threads If one thread is idle because it has run out of work to do that doesn't require a lot of RAM, see if it can borrow or steal a worktodo entry from another thread. For example, if thread #1 is doing P-1 work, but it's done all the stage1 work it can for now but needs to wait until more memory is available, it should be able to look at the queued work for other threads and steal (or borrow) low memory work (TF, P-1 stage 1, LL, etc) to do while it waits for more memory to be available. Have a worktype of "TF up to ___ bits" -- this would be basically a modification of the "TF to low limits", perhaps if you restrict the range of values entered (to something between 2^56 and 2^64?, perhaps defaulted to a sensible value based on general machine speed (e.g. 2^64 on a modern CPU but 2^56 for a 486, etc)) it would replace both the "TF to low limits" worktype, and the manual TF work that LMH does. Prime95 should check not only if "other worker threads are using lots of memory now", but also whether the amount of memory left is enough to do something useful in. For example, right now I have 3072MB allocated to Prime95, and thread #2 is using (only) 1340MB for ECM-stage-2 (presumably it doesn't need any more than that for the work it's doing). Thread #1 isn't letting itself do any stage2 work because "other worker threads are using lots of memory now". But it should be able to do some of the Stage2 work it has queued up that wouldn't use more than the still-available 1700MB of memory anyways. edit1: Times when lots of memory is available should be considered precious and if two (or more) "high-memory" tasks can co-exist, they probably should. For example, the next ECM-stage-2 work that Thread #2 has just moved on to is using only 279MB, leaving ~2793MB available to thread #1, but it still won't consider that it can try doing any Stage2 work. edit2: Perhaps it would be best to prioritize queued lots-of-memory work in descending order of RAM requirements, such that when a lot of memory is available the worker thread would look at the available memory and work first on the queued exponent that requires the most memory, and move on to lower-memory tasks if the requisite amount of RAM isn't available. This would extend naturally into doing "no-memory" tasks last (such as P-1/ECM stage 1, TF, LL, etc) if there are no P-1/ECM Stage2 tasks queued that can fit in the available memory. When you have a lot of work queued up in more than 1 worker thread, it will take up almost all of the vertical space in the "Status..." dialog showing you the work queued for Thread #1 like this: Code: <worktodo1>, <eta1> <worktodo2>, <eta2> <worktodo3>, <eta3> <worktodo4>, <eta4> .etc. <worktodoN>, <etaN> More... [Worker thread #2] More... that is, it lists as much of Worker #1's work as it can, but then just shows that Worker #2 has something to do, but you can't even see the first line. It would (I think) be more useful to allocate 1/<workers> of the available lines to each worker thread, such that I can see the next 16 assignments for each of my 2 worker threads, rather than the next 32 assignments for Thread#1 and 0 for Thread#2. Can you please put the bitversion (32-bit, 64-bit) as part of the "About" box in the Prime95 client, it's hard to tell them apart when testing modified PauseWhileRunning to be able to specify how many threads to pause while said program is running. Default is to pause all threads, but quite possibly pausing 1 thread from a quadcore would be enough to allow said program to run smoothly. I'm not sure if this could/should be specified per item (e.g. "notepad[1],wmplayer[2],crysis[ * ]", where [x] is the number of threads to pause and * means all threads) or globally where (for example) 1 thread is paused for each instance of a running program that's in the list, so per the above example if both notepad and wmplayer are running then (up to) 3 threads should be paused. I have 1 thread doing ECM on small Mersenne numbers, and another thread working on an LL test, but currently doing the initial P-1 factoring. Now Prime95 has gone through and done all the stage1 for the ECM work it has queued up, while the P-1 thread is still churning away on its stage2, which will take another day or so to complete. When I start Prime95 the ECM thread usually gets to the check-how-much-RAM-it-can-claim stage first, and allocates anywhere from 250-750MB for itself. If I have high RAM settings (say 2GB for Prime95) there's plenty left over for the P-1 thread to do something useful with, and it does. However, once the ECM thread finishes its stage2, the P-1 thread restarts with new settings and grabs all available RAM for itself and then the ECM thread sits idle (in this case for several days) because there is no RAM available to do stage2 work. I realize that (in many cases) using a lot of RAM is more efficient at processing than using less RAM; however you can see from this example my system would get far more work done using (for example) 250MB for ECM and 750MB for P-1 rather than 1GB for P-1 and the ECM thread sitting idle for 2 days. My request/suggestion is that Prime95 scans through the worktodo for all threads before allocating memory so that it could detect situations like this, where allocating less-than-max memory for one thread would result in greater overall throughput. What might be workable, however, is specifying both a minimum RAM-per-thread a global max RAM setting. Global max works as it does now. Minimum RAM-per-thread means that a thread can always get that amount of RAM if it asks for it (assuming min_per_thread is forced to be <= global_max / threads). So if I have 1024MB allocated as global_maximum, and 256MB min_per_thread, then my first thread will start off and use the whole 1024MB for itself if no other threads need it, but when thread #2 comes along and asks for RAM, thread #2 will get its 256MB and thread #1 has to make do with only 768MB (it gets more RAM because it was there first). On a related note, one observation: I had 1 thread doing small-ECM-stage2, another doing P-1-stage2. ECM didn't ask for a lot of RAM (anywhere from 125MB to 450MB), while P-1 got the rest of the allocated 2.5GB. However, the ECM stage2 often takes a very short amount of time (30 seconds to a few minutes) and the P-1 thread spent all its time trying to initialize its 2GB of RAM, then halfway through that restart with new memory settings, only to repeat a few minutes later. I'm not sure if there's an easy solution. My above-proposed automatic intelligent memory allocation would probably be able to solve it, at least if combined with a mechanism that would calculate the "new" memory settings for all running threads and prevent a thread from restarting if its going to get allocated the same amount of RAM as it had before (and probably bias the allocation of RAM such that that happens if it doesn't impact efficiency much). When starting stage2 could Prime95 print a message to the effect of "max efficiency needs <1234>MB of RAM; <768>MB available; using <620>MB" Prime95's communication thread could use a better timeout system. It's been waiting for an acknowledgement for the last result it sent 1h45m ago. Of note: this attempted communication happened right on the hour (19:00h EST) so perhaps there are still issues where on-the-hour cron jobs cause problems elsewhere? In any case, if Prime95 doesn't get a valid response to a communication attempt within <30> seconds it should abort and try again later. It's not doing that. I'd like to see all worktodo automagically assigned to available CPUs (unless the user has explicitly requested that certain cores only do certain work). There's no reason for core[1] to be idle when workdoto[2] has work waiting. An extension to the above: If one (or more) cores are idle, and another core is working on something that can reasonably exploit more multithreading, respawn the other work with the appropriate number of threads to fully utilize the CPU. I'm currently doing a hack version of this: I have a dual-core CPU running TF-LMH on one core and LL on the other. Problem is that every now and then the server goes down and I can't get any work for the TF thread to do. Normally that would mean one core idle for hours (or days), but I have the LL set to run in 2 threads. Perhaps it's not ideal when TF has work (I'm not sure the of exact inefficiency ratio) but overall my throughput is definitely higher due to capturing all the otherwise-idle time on the TF core.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Prime95 version 27.3	Prime95	Software	148	2012-03-18 19:24
Prime95 version 26.3	Prime95	Software	76	2010-12-11 00:11
Prime95 version 25.5	Prime95	PrimeNet	369	2008-02-26 05:21
Prime95 version 25.4	Prime95	PrimeNet	143	2007-09-24 21:01
When the next prime95 version ?	pacionet	Software	74	2006-12-07 20:30

2007-12-22, 14:39	#1
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 1111111011110₂ Posts	Prime95 version 25.6 THIS IS A PRE-BETA VERSION - NOT FOR EVERYDAY USE The Windows version of 25.6 is now available. If you are running version 25.5 you can install the new version on top of the old version. Steps to install version 25.6 --------------------------- 1) DO NOT INSTALL OVER VERSION 24. If you have problems, you want to be able to revert to testing using version 24. There will be outages on the new server so you'll want to let version 24 run at lower priority to soak up those available CPU cycles. 2) Create a new directory, download version 25.6 from the link below, unzip into this new directory. 3) PM or email to get the secret line to add to prime.txt so that this version contacts the new server. 4) Run version 25.6. Follow the link in the dialog box to create a userid. Choose a work preference of either "Trial factoring to low limits" or "ECM on small Mersenne numbers". 5) Find problems. Report them to me. Known bugs ----------- 1) Time= option in prime.txt does not work. Links to 25.6 versions --------------------- Windows 32-bit - ftp://mersenne.org/gimps/p95v256.zip Linux - ftp://mersenne.org/gimps/mprime256.tar.gz Linux 64-bit - ftp://mersenne.org/gimps/mprime256-linux64.tar.gz Windows 64-bit - ftp://mersenne.org/gimps/p64v256.zip Mac OS X - ftp://mersenne.org/gimps/mprime256-MacOSX.tar.gz Last fiddled with by Prime95 on 2008-08-06 at 13:08 Reason: Patched links

2007-12-22, 14:45	#2
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 1111111011110₂ Posts	What's new compared to version 25.5? Not much. Several small bug fixes and a few important ones: 1) Bug in SSE2 trial factoring above 2^64 fixed. 2) Client-server getting out-of-sync in exchanging program options fixed. 3) Endless communication loop on Error 40 fixed. The main reason for the release is it hard for me to debug version 25.5. I didn't put the sources under source control so I'm not exactly sure what bug fixes and changes are in 25.5. 25.6 is under RCS so I'll know exactly what source code you are reporting bugs on.

2007-12-22, 19:10	#3
James Heinrich "James Heinrich" May 2004 ex-Northern Ontario 7·11·53 Posts	I await your Windows64 25.6 build But I'll try the Win32 version on my Q6600 and see if the endless fight for stage2 RAM still exists. Last fiddled with by James Heinrich on 2007-12-22 at 19:11

2007-12-22, 22:26	#6
harlee Sep 2006 Odenton, MD, USA 191 Posts	Prime95, Sorry for bringing this back up, but the server is still giving less credit for finding a factor in the 61-bit range than not finding a factor from 2^0 to 2^60 bits. P4_2600_v256 221752123 NF 2007-12-22 22:19 0.2 no factor to 2^60 0.0007 P4_2600_v256 221750929 NF 2007-12-22 21:27 0.2 no factor to 2^61 0.0014 P4_2600_v256 221750927 F 2007-12-22 21:25 0.2 2264553794801324393 0.0006 P4_2600_v256 221747791 F 2007-12-22 19:35 0.1 1734156108967545617 0.0001 The bit size is from James Heinrich's web site. 2264553794801324393 = 60.97 bits 1734156108967545617 = 60.59 bits

2007-12-23, 13:04	#10
harlee Sep 2006 Odenton, MD, USA 191 Posts	This is just an FYI to show credit for the higher bit levels. P4_2600_v256 222909959 NF 2007-12-23 13:02 0.0 no factor from 2^63 to 2^64 0.0084 P4_2600_v256 222909959 NF 2007-12-23 12:52 0.0 no factor from 2^62 to 2^63 0.0044 P4_2600_v256 222909959 NF 2007-12-23 12:47 0.0 no factor from 2^61 to 2^62 0.0022 P4_2600_v256 222909959 NF 2007-12-23 12:45 0.0 no factor to 2^61 0.0014