[QUOTE=kriesel;481121]I wonder what the cpu-gpu throughput mix is for the GIMPS project overall.[/QUOTE]

That depends on how you measure throughput. If you look at FLOPS, GPUs may in fact dominate, even if almost all of the FLOPS are "wasted" by unsuccessful trial factoring. If you look at LL throughput, I bet it's almost all CPUs.

[QUOTE=kriesel;481121]On the gpu side, changing from LL to PRP means a different application with a different way of doing things.

I'm expecting gpuOwLPRP to replace cllLucas LL for AMD gpu primality testing. My admittedly limited testing thus far indicates a sizable speed advantage; ETA <11 days for 78M PRP on gpuOwL V1.9, vs. over 13.5 days for a 62.8M DC with clLucas 1.04, which scales to about 2:1 speed advantage, on the same GPU model.

I wonder what the cpu-gpu throughput mix is for the GIMPS project overall.

If Mihai were to port GpuOwL to CUDA, I'd like to be among the first to test it.[/QUOTE]




One dual-core hyperthreaded cpu at 3.60 GHz will compute 80M LL within 15 days, the GPU computes the same exponent in 6 days approximately.

[QUOTE=preda;476339]There are a few double-checked PRP results already. I think the reliability so far is perfect (no errors). But the problem with PRP is not accidental errors, but intentional false results, and a statistical analysis is not very helpful there.[/QUOTE]

Now at a few hundred. How are the stats?

A few more suggestions:

1. Ability to exclude PRP test results from team results.

2. If a PRP test shows a number to be composite, then the exponent should be marked with something like "PRP-C" rather than "PRP." Otherwise, it's a bit misleading.

3. The LL results only contain the residue while PRP results begin with "M######## is not prime." We should pick one format for both for the sake of consistency.

4. In some cases, PRP cofactors are incorrectly marked as "factored" (example: [url]https://mersenne.org/M20521[/url]). This should be fixed.

5. For PRP cofactors, the residue should be marked as "1" or "PRP." "PRP_PRP_PRP_PRP_" looks a bit messy in my opinion.

I implemented 1 & 2. Maybe madpoo will implement some of the pretty-print ideas.

The new changes look good. I also noticed that the "Recent Cleared" list now includes cofactors!

On second thought, I wonder if it would be slightly better to use "C-PRP" rather than "PRP-C" for consistency's sake because factoring results use "F" or "NF" followed by the type. But this probably isn't too important unless we're planning to add other primality tests in the future.

Found a new issue: some cofactors with different numbers of known factors are shown as having the same PRP residue. Either that or the number of known factors is wrong in some cases.

Example: [url]https://mersenne.org/report_exponent/?exp_lo=25153&full=1[/url]

I think that is expected for Type 5 PRP tests, so for every new factor you only need 1 more type 5 PRP test to verify the residue (except if it is PRP after the new factor).

I do not remember the explanation why it is the same residue.

[QUOTE=ixfd64;491550]Found a new issue: some cofactors with different numbers of known factors are shown as having the same PRP residue. Either that or the number of known factors is wrong in some cases.[/QUOTE]

Type 5 residues for PRP-cofactor testing remain the same even as new factors are discovered. Unless, presumably, the cofactor is actually probably-prime.

Here is the [URL="http://www.mersenneforum.org/showthread.php?p=468378&highlight=type+residue#post468378"]original post describing the types of residue[/URL].

Ah, that makes sense. Thanks for the explanation.

PRP reports, and expiration
 

[QUOTE=kruoli;474229]PRP:
[URL]https://www.mersenne.org/report_top_500_custom/?type=1007[/URL]

PRP-D:
[URL]https://www.mersenne.org/report_top_500_custom/?type=1008[/URL]

PRP-CF:
[URL]https://www.mersenne.org/report_top_500_custom/?type=1009[/URL]

PRP-CF-D:
[URL]https://www.mersenne.org/report_top_500_custom/?type=1010[/URL]

For now, they seem to be available only by manipulating GET-parameters.[/QUOTE]
1) Please add at least PRP and PRP-DC to the dropdown menu at [URL]https://www.mersenne.org/report_top_500/[/URL]

2) Also please add PRP and PRP-DC under Detailed Reports. Meanwhile, they can be reached via [URL]https://www.mersenne.org/report_prp/[/URL]

I note in [URL]https://www.mersenne.org/assignments/?exp_lo=81097309&exp_hi=82000000&execm=1&exp1=1&extf=1&exdchk=1[/URL] that the exponents that have gone longest without an update (all going silent within a week of assignment, and now over a month overdue for completion) are all PRP assignments to anonymous users. I've taken the liberty of queuing them on a gpuowl instance that should knock them all out sequentially in about 2 weeks, so they don't hold up a minor milestone.

PRP assignments do not expire, displaying a blank entry in the expiration date column.

3) Perhaps PRP and PRP-DC expiration should be introduced, to apply something approximating the LL and LL-DC expiration rules to PRP and PRP-DC, at least for the run of the mill primenet connected mprime/prime95 instances. I'm happy to have gpu manual PRP not expire, since there is no interim updating capability on gpu applications.