Prime95 version 29.4

[Prime95]

Prime95 version 29.4 build 7 is available.

From whatsnew.txt:

1)  GIMPS has a new sub-project -- finding (probable) prime Mersenne cofactors.
    This sub-project has two parts:  1) Running PRP tests, and 2) Finding
    additional factors.  To support this new sub-project there are three
    new work preferences:  PRP on Mersenne cofactors, PRP double-checking on
    Mersenne cofactors, ECM on Mersenne cofactors.
2)  Like LL tests, PRP tests now support shift counts to aid in running double-checks.
    Shift counts are only supported for Mersenne numbers and Mersenne cofactors.
3)  PRP tests now support a type of low overhead error checking that almost guarantees
    correct results even on flaky hardware.  We call this Gerbicz error-checking after
    it was proposed by Robert Gerbicz at mersenneforum.org.  This error-check only
    works for base-2 numbers.
4)  Because PRP tests are highly reliable, we now offer the option to do PRP tests
    instead of Lucas-Lehmer primality tests.  There are 4 new work preferences
    similar to LL work preferences:  first-time PRP tests, world record PRP tests,
    PRP tests on 100 million digit numbers, and PRP double-checking.
    If you are looking for a 100 million digit prime, PRP testing is recommended
    rather than LL testing.
5)  For non-base-2 PRP tests, there is a new option to run each iteration twice and
    rollback if a mismatch occurs.  Useful only on flaky hardware due to the obvious
    high overhead.
6)  Minor performance tweaks were made to stage 1 of P-1.  Save files are incompatible
    in stage 1.  Wait for your P-1 test to reach stage 2 before upgrading.

This version is not heavily tested - but I don't expect many problems. A few users have been testing the new PRP code for a while. If you are doing any PRP work you should upgrade to this version.

Also, some bugs were fixed: http://www.mersenneforum.org/showpos...65&postcount=2 If you have a flaky machine, please upgrade so that you don't lose a lot of work when an LL error occurs and a rollback to the .bu3 or .bu4 file is required.


Download links:
Windows 64-bit: ftp://mersenne.org/gimps/p95v294b7.win64.zip
Linux 64-bit: ftp://mersenne.org/gimps/p95v294b7.linux64.tar.gz
Mac OS X: ftp://mersenne.org/gimps/p95v294b7.MacOSX.zip
Windows 32-bit: ftp://mersenne.org/gimps/p95v294b7.win32.zip
Linux 32-bit: ftp://mersenne.org/gimps/p95v294b7.linux32.tar.gz
FreeBSD11 64-bit: ftp://mersenne.org/gimps/p95v294b7.FreeBSD11-64.tar.gz
Source: ftp://mersenne.org/gimps/p95v294b7.source.zip
Windows 64-bit service: ftp://mersenne.org/gimps/p95v294b7.win64.service.zip
Windows 32-bit service: ftp://mersenne.org/gimps/p95v294b7.win32.service.zip

[Prime95]

1) Linux mprime menu rejects work preferences above 150. Workaround is to manually edit prime.txt. Fixed in 29.4 build 4.
2) A bug in caused extraneous (and stale) data to be output to the screen and results.txt. Fixed in 29.4 build 4.
3) A bug in allocating cores in low-worker throughput benchmarks on Xeon (and Threadripper?) caused too many cores to be allocated for some workers and thus affinity assignment errors. Fixed in 29.4 build 4.
4) Many Mac users do not know how or where to install libgmp. Prime95 now references a libgmp contained within the bundle. Fixed in build 6.

[GP2]

It might be useful to post SHA256 sums.

I get:

Get-FileHash ~\Downloads\p95v294b3.win64.zip

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          AD0576CA2E63BB433A2A2D0974EF3D481ACAEA300E7C52466D5DE882D7C82B17

sha256sum p95v294b3.linux64.tar.gz
efc2b3edb47b5625be446101f14b832dd0d13fcd3b51b738d1aac24c36585108  p95v294b3.linux64.tar.gz

[Dubslow]

For those of us who've only been partially lurking, does this indicate a mass shift for GIMPS away from LL tests? That is, how much effort does PRP take on a given exponent (say the current LL or DC wavefronts) relative to the LL? If the PRP takes only a few percent more effort in exchange for being nearly 100% reliable (as opposed to the current 96% LL reliability), should that not mean that GIMPS should primarily use PRP tests over the LL?

[Prime95]

Originally Posted by Dubslow

For those of us who've only been partially lurking, does this indicate a mass shift for GIMPS away from LL tests? That is, how much effort does PRP take on a given exponent (say the current LL or DC wavefronts) relative to the LL? If the PRP takes only a few percent more effort in exchange for being nearly 100% reliable (as opposed to the current 96% LL reliability), should that not mean that GIMPS should primarily use PRP tests over the LL?

I have not done any comparisons - Gerbicz adds only 0.2% runtime. LL's Jacobi testing adds about 0.1% overhead. So the runtimes should be very, very close.

The biggest problem with PRP instead of LL is that the server is not ready. Yes, we've shoe-horned in support, but it is not ready for everyone to convert. Maybe we'll start a thread here where people can be volunteer to do first-time PRP testing and double-checking to work out the inevitable issues.

[Mark Rose]

I've switched my flaky machine to this version and PRP-D.

I've eliminated the memory channels and memory sticks as issues and power supply is next.

[Dubslow]

Originally Posted by Prime95

I have not done any comparisons - Gerbicz adds only 0.2% runtime. LL's Jacobi testing adds about 0.1% overhead. So the runtimes should be very, very close.

The biggest problem with PRP instead of LL is that the server is not ready. Yes, we've shoe-horned in support, but it is not ready for everyone to convert. Maybe we'll start a thread here where people can be volunteer to do first-time PRP testing and double-checking to work out the inevitable issues.

So PRP-Gerbicz and LL-Jacobi error variants are within less than a percent of each other in total runtime? What's the relative reliability then? The 96% I cited is of course without the Jacobi error check.

[axn]

Originally Posted by Dubslow

So PRP-Gerbicz and LL-Jacobi error variants are within less than a percent of each other in total runtime? What's the relative reliability then? The 96% I cited is of course without the Jacobi error check.

Jacobi error check will catch 50% of the errors. I guess, that makes the reliability about 98%.

[Prime95]

Originally Posted by Mark Rose

I've switched my flaky machine to this version and PRP-D.

I've eliminated the memory channels and memory sticks as issues and power supply is next.

There are very few PRP-D assignments available. If you run out of assignments, you can switch to first-time PRP.

[Dubslow]

Originally Posted by axn

Jacobi error check will catch 50% of the errors. I guess, that makes the reliability about 98%.

That's still substantially less than the PRP-gerbicz reliability though, correct?

That suggests that GIMPS should mostly eliminate LL, though I suppose the benefits are marginal.

[srow7]

Originally Posted by Prime95

Placeholder for reported bugs and fixes.

mprime menu 2 type of work
menu will not let me enter 160 or 161 PRP on m cofactors
says
please enter a value between 0 and 150

I can manually edit prime.txt, server then gives me expected assignments.