mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2008-12-14, 23:26   #1
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2×3×5×241 Posts
Exclamation Prime95 version 25.8

Version 25.8 is now available. See latest client software thread for download links.

This is primarily a bug fix release. If you are using version 25.7 and are not experiencing any problems, there is little reason to upgrade to version 25.8.

From the included whatsnew.txt file:

1) Bug fixed in smart affinity on hyperthreaded CPUs.
2) Bug fixed in setting a thread priority other than 1.
3) Off-by-one-bit bug fixed in the benchmarking of trial factoring.
4) In rare case an infinite loop could occur when the computer ID in the spool file did not match the current computer ID.
5) The "days between checkin" value now has a range of 1 to 7 days. In version 24, the range was 1 to 60 days with a default of 28 days.
6) Fixed bug where switching users on a Windows machine caused computer GUIDs to be erroneously regenerated. You may need to suffer through one more regenerated GUID before the fix takes effect.
7) A bug where some low memory situations on a multi-core machine resulted in one or more worker threads sat idle has been fixed.
8) A crash bug doing 61 and 62 bit trial factoring on Pentium CPUs that do not support the CMOV instruction was fixed.
Prime95 is offline   Reply With Quote
Old 2008-12-14, 23:27   #2
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2×3×5×241 Posts
Default

Known bugs and fixes:

1) Factoring bug in old Pentiums fixed. See http://www.mersenneforum.org/showpos...59&postcount=7. Fixed in build 5 - available for Windows only.

2) 64-bit versions cannot handle a setting of more than 4GB available memory. See http://www.mersenneforum.org/showpos...7&postcount=10. Working on fix for 25.9.

3) Duron erroneously reported as a dual processor (see http://www.mersenneforum.org/showpos...3&postcount=20). Working on fix in 25.9. Set NumCPUS=1 in local.txt in the meantime.

4) Linux battery state. I think the last fix I attempted will not work. A better fix will be available in 25.9.

5) P-1 percent complete goes over 100%. See http://www.mersenneforum.org/showpos...0&postcount=40. This bug is not fixed in 25.9, but it will no longer cause problems in range/status and sending expected completion dates to the server.

6) On 64-bit linux, the checksum code (the 12345678 in "...Wd8: 12345678") occasionally prints more than 8 hex digits. Fixed in 25.9. In the meantime, if you using the manual results web form, delete all but the last 8 hex digits.

7) P-1 crashes during attempted error recovery from a roundoff error. Will be fixed in 25.9.

8) It is impossible to select more than 1600MB of memory for torture testing. Will be fixed in 25.9 build 3.

9) PRP tests do not launch optimal P-1 factoring. Will be fixed in 25.9 build 4.

10) 32-bit executables did not find factor 81079117666989161 of M40969891. Fixed in 25.9 build 4.

11) Mprime users could not stop and start individual worker threads. Fixed in 25.9 build 4.

12) When stopping because of battery power, if AC power was restored before an LL test finished writing its save file then the worker would not resume. Fixed in 25.9 build 4.

13) Although it is a purely subjective evaluation, consensus was TF-LMH was sending intermediate bit level results to the server too frequently. 25.9 build 4 will not send as much intermediate TF information.

14) AMD L3 cache not recognized. Fixed, but not tested, in 25.9 build 4.

15) Two backup files option did not work for exponents over 100M. Two backup files option did not work for TF, ECM, and P-1. Fixed in 25.9 build 4.

16) Exiting in mprime sometimes took 50 seconds. Fixed in 25.9 build 4.

17) When ECMing the same number in different workers, each worker would use the same save file name. Fixed in 25.9 build 4.

18) When different workers were PRPing k*b^n+c with the same n value but different k or c, then the save file names would conflict. Fixed in build 25.9 build 4.

Last fiddled with by Prime95 on 2009-03-15 at 03:13
Prime95 is offline   Reply With Quote
Old 2008-12-15, 01:32   #3
jasong
 
jasong's Avatar
 
"Jason Goatcher"
Mar 2005

5×701 Posts
Default

Is there a way to force a more specific type of work than the options available? It'd be great if my quad-core could be forced to only do ecm on F14 when I max out the RAM to 8GB. :)
jasong is offline   Reply With Quote
Old 2008-12-15, 01:38   #4
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

2·1,601 Posts
Default

Just reporting in that v25.8.4 64-bit version is playing nice so far on Vista64 with 3000MB allocated to P-1 (v25.8.4 32-bit also works fine with 3000MB allocated).
James Heinrich is offline   Reply With Quote
Old 2008-12-15, 04:35   #5
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2×3×5×241 Posts
Default

Quote:
Originally Posted by jasong View Post
Is there a way to force a more specific type of work than the options available? It'd be great if my quad-core could be forced to only do ecm on F14 when I max out the RAM to 8GB. :)
No. You'll need to manually add the work to worktodo.txt and then let the program contact the server to register the work.
Prime95 is offline   Reply With Quote
Old 2008-12-15, 04:37   #6
WraithX
 
WraithX's Avatar
 
Mar 2006

23·59 Posts
Default

Is there a way (in a future version perhaps) to make "Days of Work to queue up" a per worker option, instead of a global option? ie, To move it from "Options->Preferences" to "Test->Worker Windows"?
WraithX is offline   Reply With Quote
Old 2008-12-15, 13:39   #7
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

2×1,601 Posts
Default

I'll repeat some of my feature requests, just to keep them in one place:

a) multithreaded TF. It's admittedly doable, I just need to convince you (George) that it should be done

b) unified pool of work and smart assignment selection: Don't have [worker #x] sections in worktodo.txt, simply have one pool of assignments. Prime95 should go through a process like:
- look at each worker:
-- is lots of RAM available? If so, look for first assignment in pool that needs a lot of RAM (P-1, ECM, etc)
-- else, if worker is multithreaded then select assignment type that can use multiple threads (everything but TF... if request (a) is implemented then this line goes away :)
-- finally, if there is really no work available for this worker then find the worker thread that is doing multithreadable work that has the fewest number of helper threads and (temporarily) reassign the idle thread to the worker that needs it the most.
I would suggest this unified work approach would be useful in avoiding idle cores, although you should probably keep the current system as an option for those that like to have full control of what's going where (even at the expense of maximum throughput).

c) desired TF range: rather than simply "low" (TF-LMH) or "high" (TF), let the user specify a desired TF range (per computer), e.g. between 2^67 and 2^72, and where possible have PrimeNet assign the most useful TF work in that range, falling back to the closest-available range if nothing available. If nothing specified, it would default to whatever is most needed (probably upper-range TF just ahead of the LL leading edge, per the current "TF" assignment type).

d) ETA in "Test|Status..." of subtasks. For example, I am currently assigned LL testing of M332203901, and it says I should be done on 08-Dec-2011. What I would like to see is a breakdown of that showing that I'll be done P-1_stage2 on 28-Dec-2008, TF to 2^76 on 13-Jan-2009, TF to 2^77 on 07-Feb-2009, and LL on 08-Dec-2011.

e) PauseWhileRunning pause X threads, not workers

f) allow benchmark submission even for non-PrimeNet-users

g1) Show " (using 1234MB)" at the end of worker window titles for ECM_stage2, like it does for P-1_stage2
g2) devise abbreviated worker window naming to handle tooltips for 8+ threads

h) Temporary force-low-memory-mode tray icon option

i) Three pause-while-running issues

x) the rest of my old requests
James Heinrich is offline   Reply With Quote
Old 2008-12-15, 17:47   #8
S485122
 
S485122's Avatar
 
Sep 2006
Brussels, Belgium

163110 Posts
Default Estimated Time to Completion is off

I am under the impression that on multicore machines the rolling average is computed based on the last worker. When you have for instance core 0, 1 and 3 doing LL tests and core 2 doing TF, the rolling average based on core 3 is very optimitic for cores 0 and 1. (Core 3 has a much better access to memory, while core 0 and 1 are competing for memory throughput.) This means that to compute a reliable ETA there should be a rolling average per core (or per worker). Another solution would be a rolling average based on all cores...

Jacob

Last fiddled with by S485122 on 2008-12-15 at 17:49 Reason: punctuation
S485122 is offline   Reply With Quote
Old 2008-12-15, 18:31   #9
petrw1
1976 Toyota Corona years forever!
 
petrw1's Avatar
 
"Wayne"
Nov 2006
Saskatchewan, Canada

32×7×71 Posts
Default

Quote:
Originally Posted by S485122 View Post
I am under the impression that on multicore machines the rolling average is computed based on the last worker. When you have for instance core 0, 1 and 3 doing LL tests and core 2 doing TF, the rolling average based on core 3 is very optimitic for cores 0 and 1. (Core 3 has a much better access to memory, while core 0 and 1 are competing for memory throughput.) This means that to compute a reliable ETA there should be a rolling average per core (or per worker). Another solution would be a rolling average based on all cores...

Jacob

On my core-DUO the estimated times are almost half of what they should be; almost like it is assuming both cores are working on the same test (they are NOT).

However, on my Quad the estimates are much more accurate for each core even though they are not all doing the same thing: I've done some LL, DC, TF and PM-1 and in all cases the estimated are close.

I think it might be related to the P4-Equivalent numbers on my CPU reports. The DUO is (in my opinion) double reported at 7.319 while the Quad is reported at 3.952 (more reasonable).
petrw1 is offline   Reply With Quote
Old 2008-12-17, 02:56   #10
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

2×1,601 Posts
Default

Is Prime95 64-bit [v25.8.4] limited to 3GB RAM? I've been churning through P-1 on M332203901, first with 2500MB allocated (the minimum that would give decent bounds, IMHO), where it could process 10 relative primes; I then increased the allocation to 3000MB and it could do 13 relative primes. Just for fun I let it use 3400MB, but it refused:
Quote:
[Dec 16 21:41] Stopping worker at user request.
[Dec 16 21:41] Resuming worker at user request.
[Dec 16 21:41] Optimal P-1 factoring of M332203901 using up to 3400MB of memory.
[Dec 16 21:41] Assuming no factors below 2^75 and 2 primality tests saved if a factor is found.
[Dec 16 21:41] Optimal bounds are B1=3320000, B2=99600000
[Dec 16 21:41] Chance of finding a factor is an estimated 6.99%
[Dec 16 21:41] Setting affinity to run helper thread 1 on any logical CPU.
[Dec 16 21:41] Using FFT length 20M, 3 threads
[Dec 16 21:41] Setting affinity to run helper thread 2 on any logical CPU.
[Dec 16 21:41] Ignoring suggested B2 value, using B2=91560000 from the save file
[Dec 16 21:41] Available memory is 2998MB.
[Dec 16 21:41] Using 2957MB of memory. Processing 13 relative primes (237 of 480 already processed).
[Dec 16 21:43] M332203901 stage 2 is 50.65% complete.
It acknowledged my desire to use 3400MB, but acted as if it can't see more than 2998MB... is this part of your compiling with /3GB?

Last fiddled with by James Heinrich on 2008-12-17 at 02:57
James Heinrich is offline   Reply With Quote
Old 2008-12-17, 03:22   #11
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

1C3E16 Posts
Default

I see some internal limits of 4GB. I'll fix them and let you try it.
Prime95 is offline   Reply With Quote
Reply

Thread Tools


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

All times are UTC. The time now is 12:25.

Sat Dec 5 12:25:18 UTC 2020 up 2 days, 8:36, 0 users, load averages: 1.15, 1.36, 1.55

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.