Update PRP (on the web interface)
 

Hi, a small list of things to do to bring PRP to parity with LL on the web interface:

1. manual testing assignments: add PRP-first-time and PRP-double-check as work types.

2. Reports: add "Top-producers / first PRP", and maybe PRP-DC.

3. To "Top-producers / Totals overall" add columns for PRP and PRP-DC.

4. To "Current progress / Recent Cleared" add PRP.

[QUOTE=preda;474200]Hi, a small list of things to do to bring PRP to parity with LL on the web interface:

1. manual testing assignments: add PRP-first-time and PRP-double-check as work types.

2. Reports: add "Top-producers / first PRP", and maybe PRP-DC.

3. To "Top-producers / Totals overall" add columns for PRP and PRP-DC.

4. To "Current progress / Recent Cleared" add PRP.[/QUOTE]

You just said it :smile:
I was becoming nervous doing PRP without knowing how far my "antagonists" are...

[QUOTE=preda;474200]2. Reports: add "Top-producers / first PRP", and maybe PRP-DC.[/QUOTE]

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 availible only by manipulating GET-parameters.

[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 availible only by manipulating GET-parameters.[/QUOTE]

:smile:

If we're talking about adding it to the publicly-visible portion of the website...

Job #1 is going to be explaining to the world what the PRP test is and how it works and why it should be part of GIMPS.

It's not clear to me that PRP is ever going to move into the spotlight - in much the same way that the whole GPU factoring effort goes on behind the scenes. Pages like [url]https://www.mersenne.org/manual_gpu_assignment/[/url] exist and aren't hidden behind a password, but are not linked to any of the public-facing pages.

Heck, I am not sure *I* understand how PRP fits into the bigger picture, despite trying to keep tabs on this forum.

[QUOTE=Siegmund;474404]Heck, I am not sure *I* understand how PRP fits into the bigger picture, despite trying to keep tabs on this forum.[/QUOTE]

Basically "R. Gerbicz" came up with an ingenious way to error check PRP tests, see this thread and even more in the other linked thread in the GPU forum:
[url]http://mersenneforum.org/showthread.php?t=22510[/url]

So instead of LL test we might as well run PRP tests since even though they will not prove a number prime they *will* prove a number composite which is what happens >99.99% of the time.

If a number is shown to be a PRP then we need to run 2+ actual LL tests, but many LL tests are always run anyway whenever we have a positive result.

The chance/risk that a >20M digit Mersenne number should be an actual 3-PRP without being prime is so infinitesimal small that a positive PRP test is probably more likely to be prime than a positive LL test due to the better error checking.

can you summarize PRP?

If you do a PRP and discover something, are you the discoverer or is the LL'er?

Does PRP take less resources?

[QUOTE=aurashift;474442]can you summarize PRP?

If you do a PRP and discover something, are you the discoverer or is the LL'er?

Does PRP take less resources?[/QUOTE]

[QUOTE]Basically "R. Gerbicz" came up with an ingenious way to error check PRP tests, see this thread and even more in the other linked thread in the GPU forum:
[url]http://mersenneforum.org/showthread.php?t=22510[/url][/QUOTE]

The PRP'er is the finder and gets credit for finding a new Mersenne prime -- after the LL proofs have been performed.

PRP takes a few minutes more to do but is amazingly error free! :smile:

my h/w is already more error free than usual (ecc & server grade h/w), so is this not worth doing for me?

[QUOTE=aurashift;474445]my h/w is already more error free than usual (ecc & server grade h/w), so is this not worth doing for me?[/QUOTE]

PRP goes beyond what is possible with ECC RAM. For peace of mind, I would run PRP if I were using your hardware.

So once everybody upgrades their software will the (new) PRP test be the standard for checking primality of mersenne candidates (instead of LL?). Or will they coexist?

[QUOTE=VictordeHolland;474450]So once everybody upgrades their software will the (new) PRP test be the standard for checking primality of mersenne candidates (instead of LL?).[/quote]

Undecided.

[quote] Or will they coexist?[/QUOTE]

Definitely coexist. Upgrading takes a long, long time. There are still decade old installs of version 24 reporting in.

[QUOTE=Prime95;474456]Undecided.
[/QUOTE]

Why undecided? is there some advantage of LL over PRP, or some drawback of PRP?

[QUOTE=preda;474602]Why undecided? is there some advantage of LL over PRP, or some drawback of PRP?[/QUOTE]

No good reason, haven't even thought about it (other than recommending those doing 100M digit tests do PRP).

I'll wait a good long while to see how well the server handles managing PRP and LL assignments before I ponder changing the default behavior to PRP. It will take a good long while for a significant percentage of clients to upgrade to version 29.4 or later.

The good news is that if and when we make the decision to change to PRP, then it is a simple server side change for all v29.4 and later clients to start PRPing with their next assignment.

George, are you going to get enough double-checked PRP results in the next few months to constitute a statistically meaningful sample for comparing final-result error rates between the following 3 options?

1. LL only
2. LL with Jacobi check
3. PRP with Gerbicz check

If that is not being done already, I suggest organizing a bunch of 1st-time-test PRP work accompanied by early PRP-based DCing. The error rate is the key metric as to whether switching to [3] is desirable going forward.

[QUOTE=ewmayer;474627]George, are you going to get enough double-checked PRP results in the next few months to constitute a statistically meaningful sample for comparing final-result error rates between the following 3 options?

1. LL only
2. LL with Jacobi check
3. PRP with Gerbicz check

If that is not being done already, I suggest organizing a bunch of 1st-time-test PRP work accompanied by early PRP-based DCing. The error rate is the key metric as to whether switching to [3] is desirable going forward.[/QUOTE]

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.

"Manual assignments" web page now has a full set of PRP choice. (thanks!)

[QUOTE=preda;476340]"Manual assignments" web page now has a full set of PRP choice. (thanks!)[/QUOTE]

Now waiting for this: [url]https://www.mersenne.org/report_top_500_custom/[/url] :rolleyes:

[QUOTE=ET_;476362]Now waiting for this: [url]https://www.mersenne.org/report_top_500_custom/[/url] :rolleyes:[/QUOTE]

Ugh... that page is so hard to work with.

By the way, I do have a mocked up version of that page that uses an HTML table instead of the funky pre-formatted text (that never seems to line up quite right):
[URL="https://www.mersenne.org/report_top_500_custom/default.mock.php"]https://www.mersenne.org/report_top_500_custom/default.mock.php[/URL]

At least with that, if I add PRP info it's just another table column and doesn't involve a much more complicated (by far) dive into how it generates that preformatted text.

[QUOTE=Madpoo;476404]Ugh... that page is so hard to work with.

By the way, I do have a mocked up version of that page that uses an HTML table instead of the funky pre-formatted text (that never seems to line up quite right):
[URL="https://www.mersenne.org/report_top_500_custom/default.mock.php"]https://www.mersenne.org/report_top_500_custom/default.mock.php[/URL]

At least with that, if I add PRP info it's just another table column and doesn't involve a much more complicated (by far) dive into how it generates that preformatted text.[/QUOTE]

That would work fine for me, if the width of the table are suffices...
I would live without it, but as you are reworking the project... :smile:

[QUOTE=Siegmund;474404]If we're talking about adding it to the publicly-visible portion of the website...

Job #1 is going to be explaining to the world what the PRP test is and how it works and why it should be part of GIMPS.

It's not clear to me that PRP is ever going to move into the spotlight - in much the same way that the whole GPU factoring effort goes on behind the scenes. Pages like [URL]https://www.mersenne.org/manual_gpu_assignment/[/URL] exist and aren't hidden behind a password, but are not linked to any of the public-facing pages.

Heck, I am not sure *I* understand how PRP fits into the bigger picture, despite trying to keep tabs on this forum.[/QUOTE]

GPU assignment page returns
Error code: 40 Error text: No assignment available for GPU trial factoring

cpu yes, but consider gpu
 

[QUOTE=Prime95;474616]No good reason, haven't even thought about it (other than recommending those doing 100M digit tests do PRP).

I'll wait a good long while to see how well the server handles managing PRP and LL assignments before I ponder changing the default behavior to PRP. It will take a good long while for a significant percentage of clients to upgrade to version 29.4 or later.

The good news is that if and when we make the decision to change to PRP, then it is a simple server side change for all v29.4 and later clients to start PRPing with their next assignment.[/QUOTE]

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=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.

Shouldn't the distinction between PRP an LL checks be abolished ?
Multiplying categories is not really useful.

Also the default for the newest versions should be PRP => no more LL for first time checks.

(Of course double checks should be using the same method as the first time checks for any exponent.)

Jacob

[QUOTE=S485122;500247]Shouldn't the distinction between PRP an LL checks be abolished ?
Multiplying categories is not really useful.

Also the default for the newest versions should be PRP => no more LL for first time checks.

(Of course double checks should be using the same method as the first time checks for any exponent.)

Jacob[/QUOTE]
Thanks for your comments.

There are reasons to not discard or conceal information.

Default assignment for mprime/prime95 managed by primenet API is one thing. GPU computing is quite another. There is no application supporting PRP on NVIDIA gpus currently. There's also no primenet integration in gpu applications currently. GPUs are run via manual assignment and manual reporting or separate client management tool (which are apparently application-specific). see [URL]http://www.mersenneforum.org/showpost.php?p=488292&postcount=3[/URL] There is currently no released separate client management tool supporting PRP assignment or reporting (or P-1). Manual assignments are likely to remain up to the requester to select type, subject to what assignments are available.

These may be answered somewhere before but are PRP tests preferred to LL?
I read that PRP may require only 1 test and no double testing for certainty? Has it been established yet?

Also what is the command to put in worktodo file to start PRP test?


I expect PRP to only be available for prime95 not cudalucas?

PRP is better (if no LL tests has already been done on the exponent) because of the improved error checks. We are still doing PRP double checks though to be completely safe by comparing residues.

You should just add to prime.txt for PRP tests:
WorkPreference=150

and for PRP double checks:
WorkPreference=151

then the server will hand out exponents, and yes it will not work on CUDALucas, only Prime95 and mprime.

[QUOTE=ATH;504017]and yes it will not work on CUDALucas, only Prime95 and mprime.[/QUOTE]

That would be CUDAPrp ?
Gpuowl (from Preda) is also using Prp, and correct me if not, but that is faster than CUDALucas.
Btw there should be no problem in switching to (error checked) Prp, the only difficulty could be that if you have "only" squaremod, and not general mulmod what is needed in our case. The easy workaround (with some overhead) is:
x*y=((x+y)^2-(x-y)^2)/4.

[QUOTE=R. Gerbicz;504030]That would be CUDAPrp ?
Gpuowl (from Preda) is also using Prp, and correct me if not, but that is faster than CUDALucas.
Btw there should be no problem in switching to (error checked) Prp, the only difficulty could be that if you have "only" squaremod, and not general mulmod what is needed in our case. The easy workaround (with some overhead) is:
x*y=((x+y)^2-(x-y)^2)/4.[/QUOTE]
Re CUDA mulmod, perhaps that could be borrowed / adapted from the CUDAPm1 code.

GpuOwL is for PRP (+ optionally P-1) with GC via OpenCl on AMD gpus;
CUDALucas is for LL (no Jacobi check) via CUDA on NVIDIA gpus.
clLucas for LL (no Jacobi check) via OpenCl on AMD gpus is noticeably lower performance than gpuOwL on the same hardware.
There is currently no PRP or GC or Jacobi check implemented for Mersenne hunting on NVIDIA gpus to my knowledge, after searching for relevant software and tracking developments for nearly two years.

CUDALucas implements fft lengths at all 7-smooth multiples of 2[SUP]10[/SUP] up to 2[SUP]27[/SUP] (128M, the NVIDIA fft library limit).
clLucas implements fft lengths at all 7-smooth multiples of 2[SUP]10[/SUP] up to at least 2[SUP]26[/SUP]. clLucas seems to derive less benefit from the non-power-of-two lengths than CUDALucas does. As I recall Preda also saw less benefit during extension of the set of fft lengths gpuowl supports. GpuOwL implements a subset of the 5-smooth multiples of 2[SUP]10[/SUP], from 128K up to 144M.

Comparing CUDALucas on a GTX1060 or 1070 to gpuOwL on an RX480, gpus with comparable benchmark figures at James Heinrichs' site, on primality test iteration times,
[FONT=Fixedsys][SIZE=3][CODE]gpu exponent fft length msec/it(m) TFGhzD/day LL GhD/d(L) m*L
GTX1060 3gb 74101927 4096K 7.25 428 28.7 208.
RX480 74207281 4096K 3.18 535 41.5 [B]132[/B].
GTX1070 74170739 4096K 5.18 714 47.8 248.[/CODE][/SIZE][/FONT]It does appear that gpuowl is more efficient than CUDALucas on comparable hardware. It is not simply a case of the benchmarks being off due to cllucas or other factors, since the TF figures from mfakt* are independent comparisons. For equally efficient code, and perfect benchmarks, the product mL would be about constant for the same fftlength. ML is an indication of how much throughput is consumed per iteration accomplished, so lower is better.

(A reference pdf for some available mersenne hunting software is attached at [URL]https://www.mersenneforum.org/showpost.php?p=488291&postcount=2[/URL] and periodically updated in place. It's part of the reference threads I've created at [URL]https://www.mersenneforum.org/forumdisplay.php?f=154[/URL].)

Something is wrong with that table. The product ms/iter times ghd/d [U]must[/U] be constant, for the same exponent (range) and the same FFT length, one is the reverse of the other, times a constant. As you need more time per iteration, your output is less iterations per day, and therefore less GHzDays per day. For a given exponent (/range), with a chosen FFT size, each iteration is a fix number of GHzDays. So, in the table, the line for 1070 is a bit inflated, and the line for 480 is highly deflated.

[QUOTE=kriesel;504035]Comparing CUDALucas on a GTX1060 or 1070 to gpuOwL on an RX480, gpus with comparable benchmark figures at James Heinrichs' site, on primality test iteration times,
[FONT=Fixedsys][SIZE=3][CODE]gpu exponent fft length msec/it(m) TFGhzD/day LL GhD/d(L) m*L
GTX1060 3gb 74101927 4096K 7.25 428 28.7 208.
RX480 74207281 4096K 3.18 535 41.5 [B]132[/B].
GTX1070 74170739 4096K 5.18 714 47.8 248.[/CODE][/SIZE][/FONT]It does appear that gpuowl is more efficient than CUDALucas on comparable hardware. It is not simply a case of the benchmarks being off due to cllucas or other factors, since the TF figures from mfakt* are independent comparisons. For equally efficient code, and perfect benchmarks, the product mL would be about constant for the same fftlength. ML is an indication of how much throughput is consumed per iteration accomplished, so lower is better.[/QUOTE]
Poor methodology results in invalid results (GIGO).
1. RX480 has 16:1 SP:DP. GTX 10 has 32:1. So using mfakt* performance as yardstick for LL performance is fatally flawed.
2. The figure of 41.5 GHz d/d for RX480 is derived using clLucas (cudalucas doesn't run on non-nvidia things). So you're comparing efficiency of clLucas to gpuowl (but you don't realise it).
3. m*L should be a constant (for a given FFT) (because, the latter is derived from the former). If it is not, you can't make any conclusions from it. Instead you should send the benchmarks to James to updated the numbers in his table. Here you're using his tables as some kind of authority on how much GHz d/d a card should produce -- it is not. It is calculated based on benchmarks submitted by others. If he'd used gpuowl for his RX480 numbers, you wouldn't be able to tell the difference, because then the GH D/d on his table wold be higher, exactly compensating for the lower iteration time. That's why basically you're comparing clLucas vs gpuOwl, and not cudalucas vs gpuowl.

Beat you to it this time :razz:
Just to state it right, he does not involve the TF result in any way, it is just there in the table, as additional measurement ("independent" as he says). But the LL stuff is wrong. However, he may be into something there, the method of computing the GHzDays/Day of one of those programs may be buggy. I will try to recalculate if I have some time during the lunch break later (at job, and quite busy! grrrr).

Ha! replying to myself again...

I just realized what Ken did, he got the 3.xx ms from the owl's output, but the ghd from James' site. That is indeed, not correct, as said already by axn. I was assuming that the numbers are outputs of the program, I didn't know gpuOwl does not output the ghd, because I am not using it since it switched to PRP testing (sorry, I can't keep up with everything, I am getting order...)

[QUOTE=LaurV;504074]I didn't know gpuOwl does not output the ghd, because I am not using it since it switched to PRP testing (sorry, I can't keep up with everything, I am getting order...)[/QUOTE]

That's fine. But switching between LL and PRP is rather trivial. And, now that we have the Gerbicz Error Check, doing LL on a *GPU* at 80+M exponents is asking for trouble with no plus side.

[QUOTE=preda;504104]That's fine. But switching between LL and PRP is rather trivial. And, now that we have the Gerbicz Error Check, doing LL on a *GPU* at 80+M exponents is asking for trouble with no plus side.[/QUOTE]That was no complaint. Keep up the good work! We keep you at high esteem for it and we can tell to our friends "hey this guy is Romanian" :razz:

It is just the fact that we own a lot of cuda-aware stuff, and only one single 7970 or so "owl"-aware card. And for what we own, cudaLucas is our friend.

We could enumerate few of the LL advantages versus PRP (one being the speed, especially when you run two cards in parallel, you exclude the possibility of mismatch, don't need any error check beside of matching residues, iterations are a bit faster, and you save a lot of time by avoiding taking the test to the end), but we don't want to argue too much here. People should do what they want with their hardware.

And we wanted to say that we are getting "older", not "order". We have no idea where the hack our fingers were at that time. :redface:

[QUOTE=LaurV;504117]That was no complaint. Keep up the good work! We keep you at high esteem for it and we can tell to our friends "hey this guy is Romanian" :razz:

It is just the fact that we own a lot of cuda-aware stuff, and only one single 7970 or so "owl"-aware card. And for what we own, cudaLucas is our friend.

We could enumerate few of the LL advantages versus PRP, but we don't want to argue here. People should do what they want with their hardware.

And we wanted to say that we are getting "older", not "order". We have no idea where the hack our fingers were at that time. :redface:[/QUOTE]

OK, thanks! I completely agree with people using the hardware as they see fit, no argument there. And I also hope somebody will pick up the task of implementing PRP on CUDA (with the check).

One advantage of LL is that it's considered "verification" for a new MP, while PRP isn't. As I see the rate of discovery of new primes accelerating rapidly, this may become significant :)

[QUOTE=R. Gerbicz;504030]That would be CUDAPrp ?
Gpuowl (from Preda) is also using Prp, and correct me if not, but that is faster than CUDALucas.[/QUOTE]
Correction: you are wrong. :razz: Making the same mistake Ken did. GpuOwl is OpenCL/GL/Whatever implementation, it is faster than [U]clLucas[/U] on identical AMD cards due to the fact that openCL FFT library (used in clLucas) sucks, and Mihai implemented his own for the Owl. But on fast nVidia cuda cards comparable at flops cudaLucas is faster, by far.

My two top cards, [COLOR=Gray](which are NOT last Volta architecture, and are NOT Tesla cards with 1/2 DP/SP, and which currently run cudaLucas and do LL for M666666667 at ~25-29ms/iter, depending of ambient temperature and overclocking)[/COLOR], do 2.2 to 2.4ms/iter where Ken's table has 3.18 for the RX card.

Now, the thing is that cudaLucas also uses cuFFT libraries from nVidia, and we wonder what could happen if a guy like you or Mihai, or Ernst, etc, put his nose into it and try to implement it "properly".

I'm glad you had some fun with my GTX/RX comparison post attempting to estimate relative efficiency of different code. I realized after I had posted the GTX / RX comparison and gone off running errands while some of you were having so much fun poking holes in my post, another flaw in the comparison is that both the GTX cards ms/iter numbers are while they are thermally throttled somewhat, while I've not seen an indication of thermal throttling on the RX480. I think the thermal throttling penalty is somewhere between 15 and 30% against CUDALucas on these two GTX gpus in my systems. (Trying swapping out the existing fans for windier noisier models on the HP Z600s housing them is on the todo list.)

It would be good to have an efficient CUDA implementation of PRP, or any really, so the comparisons could be a bit more apples to apples. (Hint hint, nudge nudge, coding wizards.)

I used the data I could readily lay my hands on, recognizing there are limitations. I suppose I could add a column for the manufacturers' DP TFlops claims or some independent source. Constructive suggestions?

LL on CUDA is pretty reliable, even without Jacobi check. PRP with GC is _extremely_ reliable. PRP/GC if it was available on CUDA would make parallel crosscheck LL runs even on the largest exponents a 50% waste of gpu time. PRP/GC in prime95 on a flaky AMD pc was seemingly bulletproof.
[CODE]Of my runs: LL verified all sources 339; manual (gpu) 152, 187 cpu
bad all sources 6; prime95 bad 3; gpu bad 3
% bad cpu 3/187= 1.60%
% bad gpu 3/152= 1.97%
note small-sample uncertainty is significant on both percentages[/CODE]The 3 bad prime95 residues came from 3 different systems, 2 of which have failed. The other system is doing another LLDC, and will be reassigned or decommission if that is bad.

2 of the 3 bad gpu residues came from one gpu which has been decommissioned.
The other gpu that produced a bad LL residue was switched to trial factoring. There have been no bad LL residues from my gpus in the past 16 months.