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

chalsall · 2013-12-10, 19:05

Quote:

Originally Posted by Mark Rose

So if I find 1 factor per time x of factoring to 72, I should find 3 per (1+2+4)x factoring to 73, or about 57% fewer factors.

Approximately correct. Assuming you're still working from 71.

Aramis Wyler · 2013-12-10, 19:33

I'd like to note with regard to the finding factors rate, that taking 2.5 hours to find a factor between 71 and 74 may appear to be worse that taking 21 minutes to find a factor between 71 to 72, and that certainly is true for as long as we're behind the curve. But when you are (rapidly) finding factors between 71 to 72 for numbers that people aren't on yet (aka, well ahead of the curve) the value is significantly decreased, because what good is it to filter out a number that wasn't being assigned anyway?

You could factor numbers to 72 in the 85M range even more quickly than factoring to 72 in the 67M range because the time to factor a given bitlevel decreases inversely to the size of the exponent. But it would be a long long time before that would help anyone, and in that much time we'll have much better hardware.

I'm not judging here, if you want to simply find more factor I say go for it - we're all volunteers here. But I wanted to post anyway because I know it stings to see a stat you like (in this case, candidate elimination rate) go up more slowly than it could. I just thought that pointing out the greater value of the eliminations close to the front of the curve compared to the value of eliminations far from the curve might help assuage your loss.

garo · 2013-12-10, 21:50

Quote:

Originally Posted by chalsall

Absolutely.

I'm balancing the assignments between the two, to ensure we have 73's ready to release if we need to. It's a bit of a juggling act, since there's latency between when the assignment is issued, and it's returned.

And the situation is made more complicated by the fact that due to P-1 being "over-resourced", we have 69Ms TFed to 71 being given out for P-1. In the last week about 2000+ such exponents have been given out for P-1. This is not terrible as those exponents can get their TF to 74 after the P-1 which is only mildly sub-optimal. But a tangled web we weave....

garo · 2013-12-10, 21:56

Chris, looks like spidey is not letting go of this exponent: 64786237. It was finished about 5 hours ago and reported complete. But it is still assigned to GPU Factoring for Trial Factoring.

chalsall · 2013-12-10, 22:01

Quote:

Originally Posted by garo

Chris, looks like spidey is not letting go of this exponent: 64786237. It was finished about 5 hours ago and reported complete. But it is still assigned to GPU Factoring for Trial Factoring.

Commander. Wait for it....

garo · 2013-12-10, 22:07

Quote:

Originally Posted by chalsall

Commander. Wait for it....

Right! Alerting you just in case it needed a nudge and there were other exponents in the same state.

davieddy · 2013-12-11, 01:08

http://mersenne.org/primenet/

Quote:

Originally Posted by Aramis Wyler

I'd like to note with regard to the finding factors rate, that taking 2.5 hours to find a factor between 71 and 74 may appear to be worse that taking 21 minutes to find a factor between 71 to 72, and that certainly is true for as long as we're behind the curve. But when you are (rapidly) finding factors between 71 to 72 for numbers that people aren't on yet (aka, well ahead of the curve) the value is significantly decreased, because what good is it to filter out a number that wasn't being assigned anyway?

You could factor numbers to 72 in the 85M range even more quickly than factoring to 72 in the 67M range because the time to factor a given bitlevel decreases inversely to the size of the exponent. But it would be a long long time before that would help anyone, and in that much time we'll have much better hardware.

I'm not judging here, if you want to simply find more factor I say go for it - we're all volunteers here. But I wanted to post anyway because I know it stings to see a stat you like (in this case, candidate elimination rate) go up more slowly than it could. I just thought that pointing out the greater value of the eliminations close to the front of the curve compared to the value of eliminations far from the curve might help assuage your loss.

That is a superb post Bill.

Malcolm has returned on the stroke of midnight with a simple suggestion:

Let's give ourselves a bit of breathing space by adjourning all further TF to 74 below 70M, and get all of them up to 73 as quickly as possible.

Oh, and I nearly forgot: release all the expos below 69M for LL testing at 73 bits now and allow those CPUs do some P-1 if they want to. Keep the GPUs on TF. That's what they're good at.

Then we will soon see how fast a freed up assignment front wants to progress when left to its own devices.

David

kracker · 2013-12-11, 01:41

Well, looks like LaurV will pass me in P-1 quite soon

Either I or my computers are traitors!

https://www.gpu72.com/reports/workers/p-1/graph/10-19/

EDIT: Just added a quad haswell to you.

LaurV · 2013-12-11, 03:12

Hehe, that graphic is from the series "My slope is rising higher than your slope"

The first jump was me only, crunching with my cards, then the threshold is where I switched to TF, before the "alien" computers come. The second rising slope (the current one) is since the aliens joined the fray. What can not be really seen on the graphic, is the difference between the two slopes. The actual speed is about double, comparing with the initial speed (the one before the small threshold). The two slopes look about the same, but this is tricky, due to their high inclination. Imagine you have two lines on a chart, both lines cross the (x,y)=(0,0) point, but the first line passes through the point (1,1), and the second line through (1,2), you will see very clear the angle difference between them. But if the first line passes through (0,0) and (1,20) and the second line passes through (0,0) and (1,40), you will not see any angle difference, they will both look like "vertical" lines for you. However, the speed of the second line is still two times the speed of the first. This is the case now.

kladner · 2013-12-11, 04:07

Quote:

Originally Posted by kracker

Well, looks like LaurV will pass me in P-1 quite soon

Either I or my computers are traitors!

https://www.gpu72.com/reports/workers/p-1/graph/10-19/

EDIT: Just added a quad haswell to you.

Be consoled that you can fairly quickly leave me in the dust (on that graph.) In the last couple of days I changed my CPU from P-1 to DC, and I'm unlikely to be a threat to your position there anytime soon.

TheMawn · 2013-12-11, 04:42

From what I understand, chances of finding a factor between 2^x-1 and 2^x are roughly 1/x. For 72, 73 and 74, that doesn't change much and is roughly 1.4% for each. A bit less, but what the hell.

If you look at some Trial Factoring Top x boards, you can see results that indicate just that. It's kind of approximate (also assuming people are working on the suggested GPU72 range, which is fair since it's +/- impossible to get high on the list without a GPU) but at the time of me writing this, "Kevin Jaget" has 106 successful attempts out of 7203. Almost exactly 1 in 72. "gcardona" with 90 of 6155. Etc...

Over a small range of fairly high bit levels, the chances stay approximately the same. The time requirement doubles for each level. So doing 2⁷¹ to 2⁷² takes half the time it takes for 2⁷² to 2⁷³ but has the same chance of finding a factor.

For one "time unit" you can do up to 72 and get one "chance unit" of finding a factor. For 73, it's two "time units" for one "chance unit" and it's four and one respectively for 74. Your estimate of 3 "chance units" for 7 "time units" is therefore correct as far as estimates are concerned.

2013-12-10, 19:33	#68
Aramis Wyler "Bill Staffen" Jan 2013 Pittsburgh, PA, USA 2³×53 Posts	I'd like to note with regard to the finding factors rate, that taking 2.5 hours to find a factor between 71 and 74 may appear to be worse that taking 21 minutes to find a factor between 71 to 72, and that certainly is true for as long as we're behind the curve. But when you are (rapidly) finding factors between 71 to 72 for numbers that people aren't on yet (aka, well ahead of the curve) the value is significantly decreased, because what good is it to filter out a number that wasn't being assigned anyway? You could factor numbers to 72 in the 85M range even more quickly than factoring to 72 in the 67M range because the time to factor a given bitlevel decreases inversely to the size of the exponent. But it would be a long long time before that would help anyone, and in that much time we'll have much better hardware. I'm not judging here, if you want to simply find more factor I say go for it - we're all volunteers here. But I wanted to post anyway because I know it stings to see a stat you like (in this case, candidate elimination rate) go up more slowly than it could. I just thought that pointing out the greater value of the eliminations close to the front of the curve compared to the value of eliminations far from the curve might help assuage your loss. Last fiddled with by Aramis Wyler on 2013-12-10 at 19:34

2013-12-11, 01:41	#74
kracker "Mr. Meeseeks" Jan 2012 California, USA 2³·271 Posts	Well, looks like LaurV will pass me in P-1 quite soon Either I or my computers are traitors! https://www.gpu72.com/reports/workers/p-1/graph/10-19/ EDIT: Just added a quad haswell to you. Last fiddled with by kracker on 2013-12-11 at 01:45

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

2013-12-10, 21:56	#70
garo Aug 2002 Termonfeckin, IE 2²×691 Posts	Chris, looks like spidey is not letting go of this exponent: 64786237. It was finished about 5 hours ago and reported complete. But it is still assigned to GPU Factoring for Trial Factoring.

2013-12-11, 03:12	#75
LaurV Romulan Interpreter Jun 2011 Thailand 25B6₁₆ Posts	Hehe, that graphic is from the series "My slope is rising higher than your slope" The first jump was me only, crunching with my cards, then the threshold is where I switched to TF, before the "alien" computers come. The second rising slope (the current one) is since the aliens joined the fray. What can not be really seen on the graphic, is the difference between the two slopes. The actual speed is about double, comparing with the initial speed (the one before the small threshold). The two slopes look about the same, but this is tricky, due to their high inclination. Imagine you have two lines on a chart, both lines cross the (x,y)=(0,0) point, but the first line passes through the point (1,1), and the second line through (1,2), you will see very clear the angle difference between them. But if the first line passes through (0,0) and (1,20) and the second line passes through (0,0) and (1,40), you will not see any angle difference, they will both look like "vertical" lines for you. However, the speed of the second line is still two times the speed of the first. This is the case now.

2013-12-11, 04:42	#77
TheMawn May 2013 East. Always East. 3277₈ Posts	From what I understand, chances of finding a factor between 2^x-1 and 2^x are roughly 1/x. For 72, 73 and 74, that doesn't change much and is roughly 1.4% for each. A bit less, but what the hell. If you look at some Trial Factoring Top x boards, you can see results that indicate just that. It's kind of approximate (also assuming people are working on the suggested GPU72 range, which is fair since it's +/- impossible to get high on the list without a GPU) but at the time of me writing this, "Kevin Jaget" has 106 successful attempts out of 7203. Almost exactly 1 in 72. "gcardona" with 90 of 6155. Etc... Over a small range of fairly high bit levels, the chances stay approximately the same. The time requirement doubles for each level. So doing 2⁷¹ to 2⁷² takes half the time it takes for 2⁷² to 2⁷³ but has the same chance of finding a factor. For one "time unit" you can do up to 72 and get one "chance unit" of finding a factor. For 73, it's two "time units" for one "chance unit" and it's four and one respectively for 74. Your estimate of 3 "chance units" for 7 "time units" is therefore correct as far as estimates are concerned.