The "(W)TF Depth Debate" state of the bunion - Page 8

LaurV · 2013-12-11, 05:39

You got it right. That is why we need to stop doing TF at some level, where it would be faster to eliminate exponents by P-1 and/or directly LL. Going higher will be non-profitable anymore, as it will waste more time to eliminate the exponents than "pure" LLDC them).

The best example is DC, where we had endless talk (and you can see my about-500

posts about this), where it would take, say 20 hours to run a LL test on some xxx card (and get rid of the exponent, if a match is found), or with the same card, in the same time, you can TF about ~120 exponents to 70 bit and find "~1.2" factor (due to the P-1 done in the area, you will not find a factor for every 70 expos in average, you will only find less factors) or run ~60 exponents to 71 and find "~0.9" (or less) factors. (this is only an example, and the real numbers depend on the exponent, range, how much P-1 done, your card computing abilities, etc).

The "endless discussions" are related to the fact that you don't always get a DC match (we have "empirical data" only), and some people consider it funny to find factors, therefore the "bar" was rose to 71, or 72 bits (depending on range). It is clear that going beyond that is not profitable, with the current tools (hardware and software).

Another example is actual LL front, where we are TF-ing to 74. We had discussions if it worth or not, or (more interestingly) if we should only go to 72, or 73 first, then do P-1, then continue to 74. I was for the last version, and what follows after showed that I was right: the most efficient solution is to TF to 72 or 73, then do P-1, then do TF to 74.

Practical example: since Chris and Kracker put their computers together to push me up in the P-1 top, they found 11 P-1 factors together, eliminating those exponents, and me, TF-ind from 72 to 74, I did 8 times more GHDays, but found only 4 factors. Of course, I understand the probabilistic distribution (just to avoid RDS jumping on my head

), but yet...

In all this time we are talking about, running the same hardware, I would be able to do 4 LL tests, which would mean only 2 exponents cleared (here we have to do DC too).

Certainly, again, going higher with TF will become non-profitable, with the current tools (hardware and software): the exponents will be eliminated faster by directly LL.

Of course, these limits are tools-dependent. They may change in the future, same way as the GPU changed the limits by adding few more bits to the PrimeNet's TF limits in the past.

Short (TL:DR) version: Assuming your GPU can do a LL test in 100 hours, and you have to do two LL tests to clear one exponent, which is 200 hours. Assuming no P-1 was done in the range. If it takes less than 200/70= 2 hours and 50 minutes to TF one exponent to 70 bits, it is worth to do it. You will clear that range faster by doing TF. If it takes more, you better do LL.

TheMawn · 2013-12-11, 05:56

This is where the interesting discussions occur.

Every time I go through the exact reasoning LaurV posted, I think:

"Wait. Shouldn't we just factor as far as we can while keeping factoring on par with LL?"

In essence, that is what we're doing, because GHz-Days aren't GHz-Days anymore. Because different hardware is more or less efficient at either task, it's harder to balance mathematically.

Completely gibberish random-ass numbers alert!!!

CPU does one LL in 14 days. Can factor up to 70 in one fifth of a day => factor to 70 is optimal.

GPU does one LL in 20 hours, can factor to 72 in 16.7 minutes (whatever this GPU is I want three) => factor to 72 is optimal.

Which bit level is optimal?

EDIT:

Going a bit further yet, we see that the CPU could LL and the GPU could factor. CPU does one LL in 14 days, GPU can factor to 76 in 265 minutes. Tests have the same amount of determinate tests per unit time.

More confusion!

LaurV · 2013-12-11, 07:17

Welcome to the real world, hehe. This is how the things work here around since ages, with more or less arguments and hair pulling. Your confusion shows that you begun to understand how the things work

That is why we have graphs like this one, which is card-dependent (click on your card, to see its curves, i.e. to put real numbers into the "random gibberish alert" in your post), read carefully the text on the top of the page, that comes with the graph. (edit: also, if you hover the mouse over the card names, you should see tooltips about TF/LL crossovers for each card - but the real numbers for your card, you still have to tune)

kracker · 2013-12-11, 15:25

Welcome to the actual world...

SCREW GHz days credit, it doesn't work always well and who cares about credit except for LaurV?

Frankly I'm not into the "credit" thing.

kracker · 2013-12-11, 22:08

https://www.gpu72.com/reports/worker...447de91ca35a6/

A quick look at this shows roughly how we are doing...if the graph is correct, and if we are doing 8-1 TF-P-1, you are behind

LaurV · 2013-12-12, 10:30

Yes, I am behind

(about 800GHzDays), but there is no way you could see this from the graphics, because the slope there is contributed about 45-50% by Chris, about 25-30% by you, and the rest of about 20-30% by my computers (CPUs) which remained on the barricades, after I moved the two GPUs away. What you see, is not only what you and Chris "contribute".

I wanted to add a third card yesterday evening, but delayed after Jerry announced that he is back online. I will continue to do TF, as a tribute to you an Chris

, even if you stop doing P-1 for me, and most probably I will add another 500GhD/D of mfakto tonight, but I am not really sure about, see how the mining goes.

A "bad" thing I did last night, I took a bunch of exponents from the 65M pool, 71 to 72 bits, manually requested from GPU72, "wasting" few hours on them (with 430GHzD/D/card instead of 465GHzD/D/card as it would be the "normal" night-time production). I did this because I got really frustrated about not finding factors, I thought my cards went nuts. I added the exponents to the worktodo file, the cards went through them fast, and found few factors, false alarm, returned to normal work. But I lost some of "to 74" factoring time, and few GHzDays, as the productivity is a bit lower for shorter assignments.

TheMawn · 2013-12-13, 02:44

Write up a worktodo.txt with a bunch of exponents with known factors.

Check that it finds all factors. Check that it didn't find any extras.

LaurV · 2013-12-13, 06:00

Beautiful find last night by one of kracker's computers:

Code:

k-i3-3220-1     68942509   F-PM1    2013-12-12      01:15    0.0    75695661338176919566126395000703079     2.5393

(ridiculously low credit for such a high beauty

unfortunately is very smooth... hehe)

Code:

gp > #binary(a=75695661338176919566126395000703079)
%2 = 116
gp > factorint(a-1)
%3 =
[2 1]
[7 2]
[17 1]
[61 1]
[1907 1]
[20479 1]
[20959 1]
[29027 1]
[454723 1]
[68942509 1]
gp >

LaurV · 2013-12-13, 06:04

Quote:

Originally Posted by TheMawn

Write up a worktodo.txt with a bunch of exponents with known factors.

Check that it finds all factors. Check that it didn't find any extras.

Doing this regularly, thanks

, but the "randomness" is missing here, we like "randomness" and we feel better producing (arguably) "useful" work.

kjaget · 2013-12-13, 14:59

Quote:

Originally Posted by TheMawn

at the time of me writing this, "Kevin Jaget" has 106 successful attempts out of 7203. Almost exactly 1 in 72.

I do my best to be unremarkable at everything I attempt.

kracker · 2013-12-13, 16:08

Quote:

Originally Posted by LaurV

Beautiful find last night by one of kracker's computers:

Code:

k-i3-3220-1     68942509   F-PM1    2013-12-12      01:15    0.0    75695661338176919566126395000703079     2.5393

(ridiculously low credit for such a high beauty

unfortunately is very smooth... hehe)

Code:

gp > #binary(a=75695661338176919566126395000703079)
%2 = 116
gp > factorint(a-1)
%3 =
[2 1]
[7 2]
[17 1]
[61 1]
[1907 1]
[20479 1]
[20959 1]
[29027 1]
[454723 1]
[68942509 1]
gp >

Holy crap... that would have been my second largest factor.

And LaurV had to take it

2013-12-11, 05:39	#78
LaurV Romulan Interpreter Jun 2011 Thailand 10010110110101₂ Posts	You got it right. That is why we need to stop doing TF at some level, where it would be faster to eliminate exponents by P-1 and/or directly LL. Going higher will be non-profitable anymore, as it will waste more time to eliminate the exponents than "pure" LLDC them). The best example is DC, where we had endless talk (and you can see my about-500 posts about this), where it would take, say 20 hours to run a LL test on some xxx card (and get rid of the exponent, if a match is found), or with the same card, in the same time, you can TF about ~120 exponents to 70 bit and find "~1.2" factor (due to the P-1 done in the area, you will not find a factor for every 70 expos in average, you will only find less factors) or run ~60 exponents to 71 and find "~0.9" (or less) factors. (this is only an example, and the real numbers depend on the exponent, range, how much P-1 done, your card computing abilities, etc). The "endless discussions" are related to the fact that you don't always get a DC match (we have "empirical data" only), and some people consider it funny to find factors, therefore the "bar" was rose to 71, or 72 bits (depending on range). It is clear that going beyond that is not profitable, with the current tools (hardware and software). Another example is actual LL front, where we are TF-ing to 74. We had discussions if it worth or not, or (more interestingly) if we should only go to 72, or 73 first, then do P-1, then continue to 74. I was for the last version, and what follows after showed that I was right: the most efficient solution is to TF to 72 or 73, then do P-1, then do TF to 74. Practical example: since Chris and Kracker put their computers together to push me up in the P-1 top, they found 11 P-1 factors together, eliminating those exponents, and me, TF-ind from 72 to 74, I did 8 times more GHDays, but found only 4 factors. Of course, I understand the probabilistic distribution (just to avoid RDS jumping on my head ), but yet... In all this time we are talking about, running the same hardware, I would be able to do 4 LL tests, which would mean only 2 exponents cleared (here we have to do DC too). Certainly, again, going higher with TF will become non-profitable, with the current tools (hardware and software): the exponents will be eliminated faster by directly LL. Of course, these limits are tools-dependent. They may change in the future, same way as the GPU changed the limits by adding few more bits to the PrimeNet's TF limits in the past. Short (TL:DR) version: Assuming your GPU can do a LL test in 100 hours, and you have to do two LL tests to clear one exponent, which is 200 hours. Assuming no P-1 was done in the range. If it takes less than 200/70= 2 hours and 50 minutes to TF one exponent to 70 bits, it is worth to do it. You will clear that range faster by doing TF. If it takes more, you better do LL. Last fiddled with by LaurV on 2013-12-11 at 05:49

2013-12-11, 05:56	#79
TheMawn May 2013 East. Always East. 11·157 Posts	This is where the interesting discussions occur. Every time I go through the exact reasoning LaurV posted, I think: "Wait. Shouldn't we just factor as far as we can while keeping factoring on par with LL?" In essence, that is what we're doing, because GHz-Days aren't GHz-Days anymore. Because different hardware is more or less efficient at either task, it's harder to balance mathematically. Completely gibberish random-ass numbers alert!!! CPU does one LL in 14 days. Can factor up to 70 in one fifth of a day => factor to 70 is optimal. GPU does one LL in 20 hours, can factor to 72 in 16.7 minutes (whatever this GPU is I want three) => factor to 72 is optimal. Which bit level is optimal? EDIT: Going a bit further yet, we see that the CPU could LL and the GPU could factor. CPU does one LL in 14 days, GPU can factor to 76 in 265 minutes. Tests have the same amount of determinate tests per unit time. More confusion! Last fiddled with by TheMawn on 2013-12-11 at 06:01

2013-12-11, 07:17	#80
LaurV Romulan Interpreter Jun 2011 Thailand 7²·197 Posts	Welcome to the real world, hehe. This is how the things work here around since ages, with more or less arguments and hair pulling. Your confusion shows that you begun to understand how the things work That is why we have graphs like this one, which is card-dependent (click on your card, to see its curves, i.e. to put real numbers into the "random gibberish alert" in your post), read carefully the text on the top of the page, that comes with the graph. (edit: also, if you hover the mouse over the card names, you should see tooltips about TF/LL crossovers for each card - but the real numbers for your card, you still have to tune) Last fiddled with by LaurV on 2013-12-11 at 07:22

2013-12-11, 15:25	#81
kracker "Mr. Meeseeks" Jan 2012 California, USA 2³·271 Posts	Welcome to the actual world... SCREW GHz days credit, it doesn't work always well and who cares about credit except for LaurV? Frankly I'm not into the "credit" thing. Last fiddled with by kracker on 2013-12-11 at 15:26

2013-12-12, 10:30	#83
LaurV Romulan Interpreter Jun 2011 Thailand 7²·197 Posts	Yes, I am behind (about 800GHzDays), but there is no way you could see this from the graphics, because the slope there is contributed about 45-50% by Chris, about 25-30% by you, and the rest of about 20-30% by my computers (CPUs) which remained on the barricades, after I moved the two GPUs away. What you see, is not only what you and Chris "contribute". I wanted to add a third card yesterday evening, but delayed after Jerry announced that he is back online. I will continue to do TF, as a tribute to you an Chris , even if you stop doing P-1 for me, and most probably I will add another 500GhD/D of mfakto tonight, but I am not really sure about, see how the mining goes. A "bad" thing I did last night, I took a bunch of exponents from the 65M pool, 71 to 72 bits, manually requested from GPU72, "wasting" few hours on them (with 430GHzD/D/card instead of 465GHzD/D/card as it would be the "normal" night-time production). I did this because I got really frustrated about not finding factors, I thought my cards went nuts. I added the exponents to the worktodo file, the cards went through them fast, and found few factors, false alarm, returned to normal work. But I lost some of "to 74" factoring time, and few GHzDays, as the productivity is a bit lower for shorter assignments. Last fiddled with by LaurV on 2013-12-12 at 10:31

2013-12-11, 22:08	#82
kracker "Mr. Meeseeks" Jan 2012 California, USA 2168₁₀ Posts	https://www.gpu72.com/reports/worker...447de91ca35a6/ A quick look at this shows roughly how we are doing...if the graph is correct, and if we are doing 8-1 TF-P-1, you are behind

2013-12-13, 02:44	#84
TheMawn May 2013 East. Always East. 11·157 Posts	Write up a worktodo.txt with a bunch of exponents with known factors. Check that it finds all factors. Check that it didn't find any extras.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Stockfish game: "Move 8 poll", not "move 3.14159 discussion"	MooMoo2	Other Chess Games	5	2016-10-22 01:55
Aouessare-El Haddouchi-Essaaidi "test": "if Mp has no factor, it is prime!"	wildrabbitt	Miscellaneous Math	11	2015-03-06 08:17
Specifing TF factor depth in "Manual Assignments"?	kracker	PrimeNet	2	2012-07-22 17:49
Would Minimizing "iterations between results file" may reveal "is not prime" earlier?	nitai1999	Software	7	2004-08-26 18:12