[QUOTE=jmblazek;93412]
TPS…correct me if I’m wrong but it seems impractical to be LLRing right now when sieving can remove 8 k’s to LLR’s 1 k.
[/QUOTE]
Actually, the practical figure is closer to 3k's for LLR's 1 k. This is because (assuming average luck) we should find a twin after ~11G. If the range was 1-11G instead of the current 1-25G, sieving would only be eliminating 3k's each time LLR tests 1k. The only reason why I wanted the range to be so big in the first place was to have almost a 100% guarantee that we'll find a twin in this range. If I chose 1-11G, we would have to start sieving all over from 0, for higher k values (11G-50G, for example) if there was no twin for n=195000. Choosing 1-25G minimizes the chance of this happening.

P.S. My condolences, Rytis.

Rytis I've reserved 1400-1700M for PrimeGrid. The pre-sieved file is here:

[url]http://www.twinprimesearch.org/presieved/1400e6-1700e6_195000.txt[/url]

[QUOTE=biwema;92779]I will post more accurate information later.[/QUOTE]

Hi twinprimesearchers,

Some time ago I promised more detailed information regarding the work, that is necessary to find a twin.

I took a closer look at these candidates:
172500, 195000, 250000, 333333, 500000, 1000000, 3330000, 33300000

Computer: P4 3.6 GHz (from benchmark page)

How long does it take to sieve?
The sieving speed does not depend on the size of the range. Nevertheless, the size of the array is limited by the memory. The increasing size could make it difficult to merge over the web.
This list shows the sieving time (sieving speed 100 Million/ second) and the number of twin candidates per G.

bits | candidates | sieving time
40 545700 3 hours
45 431170 3.7 days
50 349248 3.8 months
55 288634 10 years
60 242533 320 years
65 206655 10 K years
70 178187 330 K years
75 155221 10 million y
80 136425 320 million years
85 120847 10 billion years

LLR/Proth test effort.

172500
FFT size: 16K
Time 1 test: 51.75 s
Optimal sieve bits: 51
Tests per twin: 3.73M
Twin every G: 10.69
90% chance after G: 24.6
CPU years per twin: 5.9

195000
FFT size: 20K
Time 1 test: 72.15 s
Optimal sieve bits: 52
Tests per twin: 4.41M
Twin every G: 13.6
90% chance after G: 31.4
CPU years per twin: 10.1

250000
FFT size: 24K
Time 1 test: 115 s
Optimal sieve bits: 53
Tests per twin: 7M
Twin every G: 22.45
90% chance after G: 51.7
CPU years per twin: 25.4

333333
FFT size: 32K
Time 1 test: 200 s
Optimal sieve bits: 55
Tests per twin: 11.5M
Twin every G: 39.9
90% chance after G: 91.9
CPU years per twin: 73

500000
FFT size: 48K
Time 1 test: 500 s
Optimal sieve bits: 57.5
Tests per twin: 23.7M
Twin every G: 90
90% chance after G: 207
CPU years per twin: 376

1000000
FFT size: 112K
Time 1 test: 2800 s
Optimal sieve bits: 62
Tests per twin: 82M
Twin every G: 359
90% chance after G: 827
CPU years per twin: 7243

3330000
FFT size: 384K
Time 1 test: 30303
Optimal sieve bits: 69
Tests per twin: 730M
Twin every G: 3983
90% chance after G: 9170
CPU years per twin: 702000

33300000
FFT size: 3584K
Time 1 test: 3506490
Optimal sieve bits: 82
Tests per twin: 51.7G
Twin every G: 398300
90% chance after G: 917000
CPU years per twin: 5750 M

Conclusions:

- Optimal sieving goes deeper than expected.
- Sieving 1Mdigit twins requires 32G Ram (At the beginning more)
- Time complexity: 10 times more digits requires more than 10000 times more processing time.
- Sieving memory complexity: 10 times more digits requires 100 times more space.

Any feedback / questions?

biwema

[QUOTE=biwema;93717]
Conclusions:

- Optimal sieving goes deeper than expected.
[/QUOTE]

How was the optimal sieve depth calculated? Is it "time per factor = testing time of one k"? If so, did you use the full sieve range (which yields 90% guarantee)? How will this change if you assume that you are sieve only a range sufficient for 50% guarantee? The reason is that you may not have to test an entire range to find a twin prime, therefore the [B]expected[/B] amount of CPU years spent on primality testing will be lesser.

Also, how much additional CPU years will be required if the optimal sieving depth is reduced by 1 bit, 2 bits, 3 bits, etc...?

[QUOTE=axn1;93719]How was the optimal sieve depth calculated? Is it "time per factor = testing time of one k"? If so, did you use the full sieve range (which yields 90% guarantee)? How will this change if you assume that you are sieve only a range sufficient for 50% guarantee? The reason is that you may not have to test an entire range to find a twin prime, therefore the [B]expected[/B] amount of CPU years spent on primality testing will be lesser.[/QUOTE]

I took the range which contains one expected prime (Twin every G). Taht means that the chance of finding a twin is 1-e^-1 or 63.2%. Then I rounded down to the next bit.
Of course, when we start on such a range, we should sieve on a at leas 90% safe range. Sieve twice means double work. Therefore I sieve a 100 G range, that is almost 92%.

One bit less makes not so much difference: One bits less makes not so much difference. I just see on the table, that my estimated optimal sieving depth is maybe 1 bit too deep. We always can see while sieving when the optimal limit is reached. That will be earlier for P4 users than for the AMD people.

I want to highlight also in this thread that range 1330-1395 is still AVAILABLE.

When this AVAILABLE range will be less than 50M we'll release 1700-1800.

@Rytis: when PrimeGrid is near to finish 1400-1700 tell us the size of next range you want (300M again ? )

I will need new work in about 36 hours. Is that "near finish"? :)

300 will be fine.

[QUOTE=Rytis;94034]I will need new work in about 36 hours. Is that "near finish"? :)

300 will be fine.[/QUOTE]


Yes , it is. I ask Gribozavr the next range.

Gribozavr I don't know if you saw the PM or the email, please send the range 1700-2000M (in one file for PrimeGrid)

Gribozavr has not sent the new range yet.
I hope he 'll send it within tomorrow morning ( UTC ).

[QUOTE=pacionet;94081]Gribozavr has not sent the new range yet.
I hope he 'll send it within tomorrow morning ( UTC ).[/QUOTE]

Don't worry my friend, maybe if the barely 18,000 WU left is crunched before gribozavr sends you the new range, PrimeGrid should just crunch the missing range (1335-1395?)... but let's all see how it all turns out :)