What do the different types of work each mean?

[Prime95]

Originally Posted by storm5510

Disadvantage: It takes a long time to do a PRP on a large exponent. Sometimes longer than LL, in my experience.

The extra error-checking in PRP adds 0.2% overhead. There are options available to reduce that further.

PRP disadvantages: Larger save files (does anyone care?). Uses twice as much memory (irrelevant with today's multi-GB machines).

PRP advantages: When you get a computation error (you probably will), prime95 will recover and produce a good result.

Note: the 0.2% overhead is far less than the cost of the occasional double-check I would do to make sure my machine was OK.

Originally Posted by storm5510

Disadvantage: It takes a long time to do a PRP on a large exponent. Sometimes longer than LL, in my experience.

Computing large exponents is good to achieve a world record of patience :-)

[storm5510]

Originally Posted by Prime95

The extra error-checking in PRP adds 0.2% overhead. There are options available to reduce that further.

PRP disadvantages: Larger save files (does anyone care?). Uses twice as much memory (irrelevant with today's multi-GB machines).

PRP advantages: When you get a computation error (you probably will), prime95 will recover and produce a good result.

Note: the 0.2% overhead is far less than the cost of the occasional double-check I would do to make sure my machine was OK.

Thank you George.

My i7 system can, on rare occasions, be a bit 'flaky' with ECM tests. Everything else runs fine. I decided to simply stop running them. I have it running PRP's on cofactors now. No problems whatsoever.

I will ask a question here: Is running a PRP preferable to running a LL test on occasion?

[preda]

Originally Posted by Prime95

[...]
PRP disadvantages: Larger save files (does anyone care?). Uses twice as much memory (irrelevant with today's multi-GB machines).

But this is not necessarily the case: as implemented in GpuOwl, it is possible to save only the "check bits" instead of "check + data bits"; this because the "data" can be derived from "check" easily with a few iterations.

With this trick, the PRP save-file becomes just as large as for LL.

[ATH]

Originally Posted by storm5510

My i7 system can, on rare occasions, be a bit 'flaky' with ECM tests. Everything else runs fine. I decided to simply stop running them. I have it running PRP's on cofactors now. No problems whatsoever.

I will ask a question here: Is running a PRP preferable to running a LL test on occasion?

PRP on cofactors is a "side project" to find completely factored exponents, not part of the main project of finding Mersenne Primes.

PRP is preferable since the error checking assures that the tests have a smaller error rate, and the extra megabytes of hard disk space and few hundreds extra megabytes of RAM used will not be noticed on modern computers.

The exception is exponents that already have 1 LL test, do not run PRP test on those, since they do not double check each other, and a 3rd test would be needed.

[Prime95]

Originally Posted by preda

But this is not necessarily the case: as implemented in GpuOwl, it is possible to save only the "check bits" instead of "check + data bits"; this because the "data" can be derived from "check" easily with a few iterations.

Does this introduce an increased chance of a hardware error going undetected? If there is an error reading the save file or an error in recreating the "data" bits from the "check" bits, will that error get detected?

Originally Posted by Prime95

Does this introduce an increased chance of a hardware error going undetected? If there is an error reading the save file or an error in recreating the "data" bits from the "check" bits, will that error get detected?

One possible solution is to compare data bits size with check bits size, and see if in case of doubling check bits for redundancy still produces some gain. Check+check versus data+check.

Originally Posted by Prime95

Does this introduce an increased chance of a hardware error going undetected? If there is an error reading the save file or an error in recreating the "data" bits from the "check" bits, will that error get detected?

Originally Posted by SELROC

One possible solution is to compare data bits size with check bits size, and see if in case of doubling check bits for redundancy still produces some gain. Check+check versus data+check.

If savefile size becomes a problem it is possible to compress, may be with this library


https://github.com/RoaringBitmap/CRoaring

[dragonbud20]

Originally Posted by Prime95

[snipped]

PRP advantages: When you get a computation error (you probably will), prime95 will recover and produce a good result.

Note: the 0.2% overhead is far less than the cost of the occasional double-check I would do to make sure my machine was OK.

is there a reason that whatever makes the most sense assigns LL work then? would it not make more sense to just do PRP by default?

[Prime95]

Originally Posted by dragonbud20

would it not make more sense to just do PRP by default?

Probably.