mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   GpuOwl (https://www.mersenneforum.org/forumdisplay.php?f=171)
-   -   gpuOwL: an OpenCL program for Mersenne primality testing (https://www.mersenneforum.org/showthread.php?t=22204)

Prime95 2019-05-06 19:13

[QUOTE=SELROC;515950]
To do P-1, do I have to get a different assignment type ?[/QUOTE]

No, but prime95's worktodo.txt would be:

Pfactor=exponent,how_far_factored

I would not change your workflow until preda weighs in

kriesel 2019-05-06 19:14

[QUOTE=SELROC;515950]
To do P-1, do I have to get a different assignment type ?[/QUOTE]
It works on primenet to perform P-1 without an assignment, while you hold a primality test assignment. Manually submitting such a P-1 result will generate a message that there was an assignment type mismatch for the exponent, but the result is accepted, computing credit isgiven, and the existing primality test assignment for the same exponent is unaffected.

Similarly, if assigned P-1, some additional manual TF for the same exponent can be performed and reported before the assigned P-1 is. I've had success doing so and altering the bits-factored-to field of the P-1 worktodo entry to match, which CUDAPm1 uses to determine optimal bounds.

It's bad form to do a different primality test type than assigned.

SELROC 2019-05-06 19:20

[QUOTE=kriesel;515952]It works on primenet to perform P-1 without an assignment, while you hold a primality test assignment. Manually submitting such a P-1 result will generate a message that there was an assignment type mismatch for the exponent, but the result is accepted, computing credit isgiven, and the existing primality test assignment for the same exponent is unaffected.

Similarly, if assigned P-1, some additional manual TF for the same exponent can be performed and reported before the assigned P-1 is. I've had success doing so and altering the bits-factored-to field of the P-1 worktodo entry to match, which CUDAPm1 uses to determine optimal bounds.

It's bad form to do a different primality test type than assigned.[/QUOTE]


Thanks.
However, may I ask (@Preda) why P-1 on GpuOwl involved the CPU (which becomes hot) at some point near the end?

kriesel 2019-05-06 19:42

[QUOTE=SELROC;515953]Thanks.
However, may I ask (@Preda) why P-1 on GpuOwl involved the CPU (which becomes hot) at some point near the end?[/QUOTE]
If I recall correctly, neither CUDAPm1 nor gpuowl do the required gcd on the gpu, using instead the cpu for that portion via gmp.

That Preda is so efficient, he answered your question months before you asked.
[URL]https://www.mersenneforum.org/showpost.php?p=506749&postcount=946[/URL]
[QUOTE]It needs GMP (for the GCD done on the CPU, as was before with PRP-1)[/QUOTE]

preda 2019-05-06 21:33

[QUOTE=Prime95;515949]Yes, P-1 is highly recommended.

It's a question of "relative" performance. That is, if on your machine GpuOwl is 5x faster than prime95 at PRP but only 2x faster at P-1, then GpuOwl should be doing PRP 100% of the time. Use prime95 on your CPU to do all your P-1 work prior to having the the GPU do the PRP.

Your P-1 bounds are "suspicious" in that when prime95 is used to double-check your result years down the road, I think prime95 will want to redo the P-1 to higher bounds.

IIUC, Preda has a somewhat different view on optimal P-1 bounds in that he believes Gerbicz error checking in the initial PRP test means double-checking is not necessary.

For reference, prime95 would use these bounds (assuming 1.8GB of memory).
Saving 1 LL/PRP test: B1=1,115,000 B2=14,495,000
Saving 2 LL/PRP tests: B1=2,395,000 B2=35,326,000[/QUOTE]

GpuOwl can do P-1 now, and it's rather efficient at it -- especially stage2 on high-RAM GPUs such as R7 with 16GB. Two GCD per test are offloaded to the CPU (one after each stage).

OTOH GpuOwl doesn't do "preliminary P-1" ahead of a PRP test by its own initiative. One reason being that the already-done P-1 information is not included in the assignment line for a P-1 test (unlike the already-done TF information, which is included), thus GpuOwl could not know whether P-1 is needed or not ahead of PRP.

The solution, for a 100M exponent, is for the user to manually do "preliminary P-1" if desired, before the PRP. Either by getting a manual P-1 assignment for the exponent, or by creating the worktodo line simply without AID (without assignment from the server) and still submit the result at the end.

Prime95 2019-05-06 22:16

[QUOTE=preda;515970]GpuOwl can do P-1 now, and it's rather efficient at it -- especially stage2 on high-RAM GPUs .[/QUOTE]

How were the 100M P-1 bounds calculated? They were vastly smaller than prime95's optimal P-1 bounds.

Prime95 2019-05-06 22:20

[QUOTE=preda;515970]
OTOH GpuOwl doesn't do "preliminary P-1" ahead of a PRP test by its own initiative. One reason being that the already-done P-1 information is not included in the assignment line for a P-1 test (unlike the already-done TF information, which is included), thus GpuOwl could not know whether P-1 is needed or not ahead of PRP.[/QUOTE]

A PRP worktodo line looks like this:
PRP=k,b,n,c[,how_far_factored,tests_saved[,base,residue_type]][,known_factors]

If tests_saved is zero then P-1 has been done. If one, then this is a PRP double-check with no P-1 done yet. If two then this is a first-time PRP with no P-1 done yet.

I have not validated that the server is sending this data properly to prime95 (or formatting them properly in the manual reservations web page).

kriesel 2019-05-06 23:08

[QUOTE=Prime95;515974]A PRP worktodo line looks like this:
PRP=k,b,n,c[,how_far_factored,tests_saved[,base,residue_type]][,known_factors]

If tests_saved is zero then P-1 has been done. If one, then this is a PRP double-check with no P-1 done yet. If two then this is a first-time PRP with no P-1 done yet.

I have not validated that the server is sending this data properly to prime95 (or formatting them properly in the manual reservations web page).[/QUOTE]
prime95 via primenet: PRP=(aid redacted),1,2,79335979,-1,75,0,3,1
fresh from manual assign now: PRP=(aid redacted),1,2,85128553,-1,76,0

SELROC 2019-05-07 03:57

[QUOTE=kriesel;515952]It works on primenet to perform P-1 without an assignment, while you hold a primality test assignment. Manually submitting such a P-1 result will generate a message that there was an assignment type mismatch for the exponent, but the result is accepted, computing credit isgiven, and the existing primality test assignment for the same exponent is unaffected.

Similarly, if assigned P-1, some additional manual TF for the same exponent can be performed and reported before the assigned P-1 is. I've had success doing so and altering the bits-factored-to field of the P-1 worktodo entry to match, which CUDAPm1 uses to determine optimal bounds.

It's bad form to do a different primality test type than assigned.[/QUOTE]


This all requires manual intervention, which I am moving away from. I have other projects to follow and I need GIMPS to work on his own.


It could be easier if the server can assign PRP with P-1, even better, if GpuOwl could do P-1 before PRP.

preda 2019-05-07 08:30

[QUOTE=Prime95;515973]How were the 100M P-1 bounds calculated? They were vastly smaller than prime95's optimal P-1 bounds.[/QUOTE]

Which ones? (for which exponent, user)

GpuOwl always takes P-1 bounds from the user. They can be configured per-exponent or globally (per run). The user must configure (specify) at least B1. By default B2==30*B1, but this is also configurable either as a ratio (relative to B1) or absolute B2.

For exponents around 95M (the P-1 wavefront), I would consider normal bounds (assuming no previous P-1 done) anything with B1 between 500K and 2M, and rB2 between 10 and 25.

For exponents at 100M-digits, which might have lower TF, I would probably use B1 around 1M-3M and rB2 20 to 30.

Right now I'm not doing P-1 because the exponents at 85M where I PRP are fully P-1'ed. If I'd do 100M-digits exponents, probably I would allocate.. up to about 4% of the the test time (about half-a-day on R7?) for additional P-1 and TF before starting the PRP.

preda 2019-05-07 10:18

[QUOTE=Prime95;515974]A PRP worktodo line looks like this:
PRP=k,b,n,c[,how_far_factored,tests_saved[,base,residue_type]][,known_factors]

If tests_saved is zero then P-1 has been done. If one, then this is a PRP double-check with no P-1 done yet. If two then this is a first-time PRP with no P-1 done yet.

I have not validated that the server is sending this data properly to prime95 (or formatting them properly in the manual reservations web page).[/QUOTE]

Thank you, so the boolean information on whether any P-1 has been done is there in the assignment in the form of "tests_saved".

Note though that in this particular case (
[url]https://www.mersenne.org/report_exponent/?exp_lo=332252533&full=1[/url] ), P-1 has been done before the PRP although to insufficient bounds (not by GpuOwl).

I can change GpuOwl to auto-trigger P-1 for a PRP without any P-1; but I still can't handle the case of P-1 done with insufficient bounds.


All times are UTC. The time now is 23:14.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.