Davieddy's World - Page 9

Aramis Wyler · 2013-04-13, 15:36

Lol! You actually had me going for a second there. James' graph is a curve. The bottom end maps to 1.25, the top end maps to 1.3. Yes, there is a point on the curve where the 1 bitlevel increment maps to 1.26. We can call that the troll point on the graph. Good try.

axn · 2013-04-13, 15:52

Quote:

Originally Posted by chalsall

We should have been going to 75 from 57M onward; we simply didn't have the firepower to do so.

I'm eyeballing that graph. It looks like 75 is warranted for ~65M an above, and 74 at ~54M. Not so?

Quote:

Originally Posted by Aramis Wyler

Lol! You actually had me going for a second there. James' graph is a curve. The bottom end maps to 1.25, the top end maps to 1.3. Yes, there is a point on the curve where the 1 bitlevel increment maps to 1.26. We can call that the troll point on the graph. Good try.

1.26 is a rule-of-thumb. And it is a pretty good ROT. There is a sound mathematical basis for that ROT. I'll take your word that the actual ratio is in the 1.25-1.3 range -- I'd consider that as excellent conformance to the ROT value.

chalsall · 2013-04-13, 16:01

Quote:

Originally Posted by axn

I'm eyeballing that graph. It looks like 75 is warranted for ~65M an above, and 74 at ~54M. Not so?

I oversimplified by rounding. But, to reach a "perfect" cut-off, we'd either do (as an example) 57M to 74.5065 "bits" (which mfaktx could do, but Primenet doesn't handle non-integer bit levels), or else we'd take approximately half the candidates to 74, and the other half to 75.

Aramis Wyler · 2013-04-13, 16:04

Maybe it is a reasonable rule of thumb, but we're not exactly working the numbers out in our heads as we walk down the streets. Why would we dogmatically set a line using a rule of thumb for a site that is doing terraflops of calculations? We have the processing power to work out an actual rule.

Besides, he uses that number to prove we're overfactoring the current range, not to prove that we have in fact underfactored what came before wrt our current firepower or to prove that the bitdepth we're working on should vary according to the firepower we have at any given time.

Prime95 · 2013-04-13, 16:51

Quote:

Originally Posted by chalsall

I oversimplified by rounding. But, to reach a "perfect" cut-off, we'd either do (as an example) 57M to 74.5065 "bits" (which mfaktx could do, but Primenet doesn't handle non-integer bit levels), or else we'd take approximately half the candidates to 74, and the other half to 75.

Perfection is a bit more complicated to obtain than James' graph. Because of P-1, one should TF somewhat less than James' recommendation (because a factor found by TF won't always save 2 LL tests, sometimes it only saves a single P-1 run).

IIRC, James' chart does account for an ~2% LL error rate. Can we also tweak it to account for P-1: ~5% of the time a factor only saves ~3% of an LL test? Attention P-1ers, are the 5% and 3% accurate estimates? Can we add a footnote to James' page explaining the breakeven formula - I know I will eventually forget this conversation :)

davieddy · 2013-04-13, 17:08

Quote:

Originally Posted by Aramis Wyler

Maybe it is a reasonable rule of thumb, but we're not exactly working the numbers out in our heads as we walk down the streets.

Speak for yourself. That is exactly the sort of thing I do, giving me an overall view of the situation that won't be too far from a narrower, short term, unjustifiably precise approach, and easy to grasp.

The ROT arises as follows:
1) the time to TF from 73 to 74 is proportional to 1/expo
2) the time to TF from 73 to 74 is double that for 72 to 73 for a given expo.
3) The time for an LL test is proportional to expo².

If the exponent increases by 2^1/3 (=1.26) the times for TF and LL are both increased by 2^2/3.

I am full of neat tricks like this, which is where I get my confidence that I am right when I make firm assertions.

Another example which seems to be going over people's heads ATM, is that a 10% advance in the wavefronts per year results in one new prime per 4 years on average (as currently observed to be the case) and requires a modest 1.1³ = 4/3 increase in computing per year.

David

Prime95 · 2013-04-13, 17:21

Quote:

Originally Posted by davieddy

3) The time for an LL test is proportional to expo².

Very close:

FFT = n log n
LL = n FFTs = n² log n

Quote:

Another example which seems to be going over people's heads ATM, is that a 10% advance in the wavefronts per year results in one new prime per 4 years on average

This is irrelevant to GIMPS. We don't have a schedule, we find primes at whatever rate our compute power and luck allow.

chalsall · 2013-04-13, 17:23

Quote:

Originally Posted by Prime95

Perfection is a bit more complicated to obtain than James' graph. Because of P-1, one should TF somewhat less than James' recommendation (because a factor found by TF won't always save 2 LL tests, sometimes it only saves a single P-1 run).

Good point (as always).

Quote:

Originally Posted by Prime95

Attention P-1ers, are the 5% and 3% accurate estimates?

I can't speak to the latter, but as to the 5%:

Code:

TF: 72 -- 1,297 / 31,646 == 4.098%
TF: 73 -- 1,415 / 35,945 == 3.937%
TF: 74 --    39 /  1,263 == 3.088% (small sample set currently)

I know James has a much more complete dataset.

Aramis Wyler · 2013-04-13, 17:48

Quote:

Originally Posted by Prime95

Because of P-1, one should TF somewhat less than James' recommendation (because a factor found by TF won't always save 2 LL tests, sometimes it only saves a single P-1 run).

Thank you for weighing in; it's always a help to have the big guns clarify things. :) I'm curious about the statement though - with the graph having one line for first times and a second for DCs, I thought it accounted for the amount saved.

davieddy · 2013-04-13, 17:54

Quote:

Originally Posted by chalsall

Frankly, this is obviously futile. You're now on my "ignore" list.

QUEEN BITCH

chalsall · 2013-04-13, 18:11

Quote:

Originally Posted by Aramis Wyler

I'm curious about the statement though - with the graph having one line for first times and a second for DCs, I thought it accounted for the amount saved.

What George is pointing out is James is not taking into account that something like ~4% of the time finding a factor will not save 2 LLs (for the first-time LL wave), since a following P-1 run (almost always done) will find a factor.

Knowing James, he's take this into account sometime soon -- it will only slightly affect the optimal cross-over point though.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
For davieddy and his music…	Xyzzy	Lounge	88	2014-07-14 02:44
WHY out of the entire university did only Davieddy get banned?!	Stargate38	Forum Feedback	61	2014-07-08 18:54
5 easy pieces for davieddy	NBtarheel_33	PrimeNet	28	2012-07-28 15:26
World Cup Soccer	davieddy	Hobbies	111	2011-05-28 19:21
Change the world!	Xyzzy	Lounge	5	2009-08-31 12:41

2013-04-13, 15:36	#89
Aramis Wyler "Bill Staffen" Jan 2013 Pittsburgh, PA, USA 2³·53 Posts	Lol! You actually had me going for a second there. James' graph is a curve. The bottom end maps to 1.25, the top end maps to 1.3. Yes, there is a point on the curve where the 1 bitlevel increment maps to 1.26. We can call that the troll point on the graph. Good try.

2013-04-13, 16:04	#92
Aramis Wyler "Bill Staffen" Jan 2013 Pittsburgh, PA, USA 2³×53 Posts	Maybe it is a reasonable rule of thumb, but we're not exactly working the numbers out in our heads as we walk down the streets. Why would we dogmatically set a line using a rule of thumb for a site that is doing terraflops of calculations? We have the processing power to work out an actual rule. Besides, he uses that number to prove we're overfactoring the current range, not to prove that we have in fact underfactored what came before wrt our current firepower or to prove that the bitdepth we're working on should vary according to the firepower we have at any given time.