Prime95 version 26.4

[Prime95]

Version 26.4 is ready for testing. This version fixes some bugs that were reported for 26.3.

I added debug output in prime.log for the spurious unreserve bug. If you run into this bug using this version, please email me the prime.log, prime.txt, local.txt, and worktodo.txt files.

Download links:
Windows: ftp://mersenne.org/gimps/p95v264.zip
Windows 64-bit: ftp://mersenne.org/gimps/p64v264.zip
Linux: ftp://mersenne.org/gimps/mprime264.tar.gz
Linux 64-bit: ftp://mersenne.org/gimps/mprime264-linux64.tar.gz
Mac OS X: ftp://mersenne.org/gimps/Prime95-MacOSX-264.zip
FreeBSD: ftp://mersenne.org/gimps/mprime264-FreeBSD.tar.gz
FreeBSD 64-bit: ftp://mersenne.org/gimps/mprime264-FreeBSD64.tar.gz
Windows NT service: ftp://mersenne.org/gimps/winnt264.zip
Windows NT service 64-bit: ftp://mersenne.org/gimps/win64nt264.zip
Source: ftp://mersenne.org/gimps/source264.zip

Bug fixes are described here: http://www.mersenneforum.org/showpos...81&postcount=2

[Prime95]

1) Pentium 4s and Celerons with L2 cache size of 256K or less choose a length 4M FFT when they could use an FFT between 1600K and 4M in size. Fixed in next release.
2) The on screen message reporting that errors have occurred during the LL test was wrong. The counts for "SUM(INPUTS) != SUM(OUTPUTS)" and "ROUNDOFF > 0.4" were reversed. Fixed in next release.
3) Dual-boot users running a 32-bit and 64-bit executable on the same exponent may experience "Unable to initialize FFT" message. This happens when prime95 writes an FFT size to worktodo.txt and that FFT size is only supported by just one of the two executables. For example, the 2240K FFT length is supported for 64-bit Core 2 but not 32-bit Core 2. Fixed, somewhat inelegantly, in 26.5 -- unimplemented FFT lengths are ignored when worktodo.txt is read.
4) Prime95 will sometimes inexplicably unreserve exponents. I think this happens when prime95 incorrectly calculates the CPU speed. Version 26.5 will only use a new slower CPU speed measurement after several slower CPU measurements. Hopefully, this will resolve the unreserve problem caused by a single erroneous CPU speed measurement.
5) Prime95 would lose the how_far_factored and tests_saved information on PRP= lines in worktodo.txt. Fixed in 26.5.
5) Prime95 did not offer an option to delete P-1 save files when a work unit completes. Fixed in 26.5.
6) Prime95 did not fully understand Sandy Bridge CPUID output. Fixed in 26.5.
7) Prime95 did not accurately report the CPU speed. Fixed in 26.5.
8) At startup, the workers threads do not start up properly until communication with the server completes. If you have a large worktodo.txt file, this will result in wasted CPU time and many "use count" error messages. Fixed in 26.5.
9) Time estimates for trial factoring to 2^79 and above were incorrect. Fixed in 26.5.

[harlee]

I want to bring something to your attention but I don't know if this is really a problem or not. I'm doing P-1 testing on small exponents (5M range) and the CPU is normally running at 50%, which is fine as I'm only running 1 worker on my P4 HT system. What I've noticed is that while the software is returning the exponent to the server, the CPU usage jumps to 100% unit the server returns the "CPU credit" line and the software is "Done communicationg with server.", then it returns to 50%. Also, noticed that the more exponents that I have reserved, the longer this process takes. This has been going on for several versons now but I'm just now looking into the matter more closely. Would appreciate any insights that you might have. Regards.

[Prime95]

Originally Posted by harlee

while the software is returning the exponent to the server, the CPU usage jumps to 100%

That sounds right. The OS is scheduling the P-1 work on one hyperthread and the communicate-with-the-server on the other hyperthread. Thus, the OS is keeping 100% of the logical processors busy.

[James Heinrich]

I'm mildly confused by the massive increase in executable size since I last upgraded; v25.x was around 5MB, this is 24MB. What special goodies inside account for the bloat?

[ixfd64]

I think version 26.x contains a lot more optimization code.

[harlee]

Originally Posted by Prime95

That sounds right. The OS is scheduling the P-1 work on one hyperthread and the communicate-with-the-server on the other hyperthread. Thus, the OS is keeping 100% of the logical processors busy.

Thanks for the answer. My fault for not including everything. I took a closer look and when Prime95 returns a P-1 result, it shows the Credit received line, the CPU sits at 100% for a few seconds until it receives the "Done communicationg with server." Another factor which I failed to include is when the software does a "Send new expected completion dates to server", the CPU is only showing between 60-65% usage. Verified this by doing a Manual update on 577 P-1 exponents and watching the CPU graph. Guess my question is why does returning a result uses a lot more CPU while talking with the Server than doing time updates?

[James Heinrich]

Originally Posted by harlee

why does returning a result uses a lot more CPU while talking with the Server than doing time updates?

I suspect it's more an issue of how well hyperthreading can multitask the workload. If you had a true dual-core you'd probably see (close to) full 100% in both situations. But since you have a "fake" dual-core, you see 100% where the two workloads are different (P-1 and talking to server) because hyperthreading can juggle them well; but you see poor hyperthreaded performance when it's trying to do two similar workloads (P-1, and calculating P-1 estimated time).

[TimSorbet]

Originally Posted by James Heinrich

I'm mildly confused by the massive increase in executable size since I last upgraded; v25.x was around 5MB, this is 24MB. What special goodies inside account for the bloat?

Originally Posted by ixfd64

I think version 26.x contains a lot more optimization code.

More specifically, I believe there are several different ways to do FFT built in now, which are more efficient for different CPU architectures, which allows Prime95 to be faster for many CPUs (instead of the usual method of "make it faster for new ones and a little slower for old ones").

[harlee]

Originally Posted by James Heinrich

I suspect it's more an issue of how well hyperthreading can multitask the workload. <snip> you see poor hyperthreaded performance when it's trying to do two similar workloads (P-1, and calculating P-1 estimated time).

I stopped all workers (actually only running one), watched the CPU goto 0% and then did a "Send new expected completion dates to server". The CPU mostly stayed under 10% with a few spikes up to 15%. The usage is in line with my earlier statement about doing a P-1 with reporting the expected completion dates - 50% + 10-15% = 60-65%. Still doesn't explain why reporting a result takes up so much CPU. If anything I would expect sending expected completion dates to use more CPU as it has to calculate the times and report them to the server.

[Commaster]

harlee, could you please look at the Processes pane? I suspect some background programs eating your CPU. (Maybe)