GpuOwl 7.x - Page 4

storm5510 · 2020-09-29, 15:35

Quote:

Originally Posted by preda

...2. repeatedly run PRP on this exponent while changing:
- FFT size
- -maxAlloc (e.g. use 3 values: max allowed on the GPU, a very small e.g. 1GB or 800M, and something in between like 3GB or 7GB)
- anything else you feel like changing (-carry long, etc)...

I believe there may be a mix-up here. All the tests in the lists are P-1...

masser · 2020-09-29, 15:43

Quote:

Originally Posted by storm5510

I believe there may be a mix-up here. All the tests in the lists are P-1...

Review the original post in this thread. PRP and P-1 are merged in GpuOwl 7.x; they are run concurrently by the software. Brave new world!

storm5510 · 2020-09-29, 15:51

Quote:

Originally Posted by masser

Review the original post in this thread. PRP and P-1 are merged in GpuOwl 7.x; they are run concurrently by the software. Brave new world!

I am aware of the combination in 7.x. I will continue to use 6.x for some time to come. I will try one as a P-1.

preda · 2020-09-29, 23:06

There is the P-1 calculator on mersenne.ca : https://www.mersenne.ca/prob.php

There are also two implementations of the P-1 calculator in gpuowl in pm1/ folder.

It seems the P-1 wavefront (the smallest exponents that weren't P-1'ed) is a bit above 100M, and those exponents were factored to 76.

In this context, I'm thinking of running with B2=100M (nice round number). For B2=100M, pretty much any B1 between 5M and 10M would be just as good. I would probably go with B1=8M,B2=100M.

Let's see the probabilities (all with B2=100M):
B1=4M: 6.07% (first-stage 2.87%, second-stage 3.20%)
B1=6M: 6.25% (first-stage 3.26%, second-stage 2.99%)
B1=8M: 6.36% (first-stage 3.56%, second-stage 2.80%)
B1=10M: 6.44% (first-stage 3.80%, second-stage 2.64%)

We see that the probability increases a bit as B1 increases from 4M to 10M, so why do I say all those B1 are pretty much the same? -- because as B1 increases, the ratio of the PRP that is saved when a factor is found (in either P1 or P2) decreases (because only the PRP part that is above B1*1.44 is saved). This, in addition to the total effort (P1+P2) being slightly less when running with lower B1 (keeping B2 constant), means that you can choose any B1 in that range.

PS: also, there's no requirement to run with such a high B2=100M. E.g., for B2=50M:

B1=3M: 5.25% (first-stage 2.60%, second-stage 2.65%)
B1=4M: 5.37% (first-stage 2.87%, second-stage 2.50%)
B1=5M: 5.45% (first-stage 3.08%, second-stage 2.37%)

moebius · 2020-10-01, 07:34

- removed LL

I am totally against it, I sometimes do LL-DC because they run very fast on my graphics card. That also makes a bit of Throughput. Let the users choose freely.

M344587487 · 2020-10-01, 08:23

Then freely choose to run an older version of gpuowl. Am I missing something?

moebius · 2020-10-01, 08:46

Quote:

Originally Posted by M344587487

Then freely choose to run an older version of gpuowl. Am I missing something?

I just don't understand why you want to remove a well-functioning feature from a program, in German you would jokingly say "verschlimmbessern" which means in english "worse improve"

M344587487 · 2020-10-01, 09:42

If a feature is removed you're not beholden to fix it when you make a breaking change, it gives you the freedom to make changes to the codebase without having to consider what that change does to the legacy functionality. I don't know why preda removed LL but it's why I would.

moebius · 2020-10-01, 09:57

Well, that's a reason if he otherwise has too much work with it, but it's still a shame, because with the new version you could also confirm the next greatest prime number with LL on an AMD card.

preda · 2020-10-01, 12:31

Quote:

Originally Posted by moebius

I just don't understand why you want to remove a well-functioning feature from a program, in German you would jokingly say "verschlimmbessern" which means in english "worse improve"

As the program evolves, it needs to be refactored ("transformed") to support new functionality. The amount of existing complexity makes the refactoring difficult (similar to inertia: more mass -- harder to change direction). Because IMO LL is a low-priority feature for gpuowl, it was not transferred over in this refactoring step. Note, I also didn't finish the new functionality yet.

preda · 2020-10-01, 12:33

GpuOwl 7.0 is *not ready* yet; please don't use it yet.

Also, I'll be away for a few days, without internet access.

2020-09-29, 23:06	#37
preda "Mihai Preda" Apr 2015 3×457 Posts	Some ideas for B1,B2 bounds There is the P-1 calculator on mersenne.ca : https://www.mersenne.ca/prob.php There are also two implementations of the P-1 calculator in gpuowl in pm1/ folder. It seems the P-1 wavefront (the smallest exponents that weren't P-1'ed) is a bit above 100M, and those exponents were factored to 76. In this context, I'm thinking of running with B2=100M (nice round number). For B2=100M, pretty much any B1 between 5M and 10M would be just as good. I would probably go with B1=8M,B2=100M. Let's see the probabilities (all with B2=100M): B1=4M: 6.07% (first-stage 2.87%, second-stage 3.20%) B1=6M: 6.25% (first-stage 3.26%, second-stage 2.99%) B1=8M: 6.36% (first-stage 3.56%, second-stage 2.80%) B1=10M: 6.44% (first-stage 3.80%, second-stage 2.64%) We see that the probability increases a bit as B1 increases from 4M to 10M, so why do I say all those B1 are pretty much the same? -- because as B1 increases, the ratio of the PRP that is saved when a factor is found (in either P1 or P2) decreases (because only the PRP part that is above B11.44 is saved). This, in addition to the total effort (P1+P2) being slightly less when running with lower B1 (keeping B2 constant), means that you can choose any B1 in that range. PS: also, there's no requirement to run with such a high B2=100M. E.g., for B2=50M: B1=3M: 5.25% (first-stage 2.60%, second-stage 2.65%) B1=4M: 5.37% (first-stage 2.87%, second-stage 2.50%) B1=5M: 5.45% (first-stage 3.08%, second-stage 2.37%) Last fiddled with by preda on 2020-09-29 at 23:44*

2020-10-01, 07:34	#38
moebius Jul 2009 Germany 2×3×101 Posts	- removed LL I am totally against it, I sometimes do LL-DC because they run very fast on my graphics card. That also makes a bit of Throughput. Let the users choose freely. Last fiddled with by moebius on 2020-10-01 at 07:36

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
GpuOwl PRP-Proof changes	preda	GpuOwl	20	2020-10-17 06:51
gpuowl: runtime error	SELROC	GpuOwl	59	2020-10-02 03:56
gpuOWL for Wagstaff	GP2	GpuOwl	22	2020-06-13 16:57
gpuowl tuning	M344587487	GpuOwl	14	2018-12-29 08:11
How to interface gpuOwl with PrimeNet	preda	PrimeNet	2	2017-10-07 21:32

2020-10-01, 08:23	#39
M344587487 "Composite as Heck" Oct 2017 2·11·37 Posts	Then freely choose to run an older version of gpuowl. Am I missing something?

2020-10-01, 09:42	#41
M344587487 "Composite as Heck" Oct 2017 1456₈ Posts	If a feature is removed you're not beholden to fix it when you make a breaking change, it gives you the freedom to make changes to the codebase without having to consider what that change does to the legacy functionality. I don't know why preda removed LL but it's why I would.

2020-10-01, 09:57	#42
moebius Jul 2009 Germany 1136₈ Posts	Well, that's a reason if he otherwise has too much work with it, but it's still a shame, because with the new version you could also confirm the next greatest prime number with LL on an AMD card.

2020-10-01, 12:33	#44
preda "Mihai Preda" Apr 2015 55B₁₆ Posts	GpuOwl 7.0 is not ready yet; please don't use it yet. Also, I'll be away for a few days, without internet access.