mersenneforum.org Help needed for doublecheck sieving!
 Register FAQ Search Today's Posts Mark Forums Read

2008-02-18, 22:50   #34
em99010pepe

Sep 2004

B0E16 Posts

Quote:
 Originally Posted by gd_barnes My bad here. Now I need to go back and look at how far I should have sieved 400
I think you should sieve.

2008-02-18, 23:18   #35
gd_barnes

May 2007
Kansas; USA

5·2,017 Posts

Quote:
 Originally Posted by em99010pepe I think you should sieve.
In this effort or on the n=400K-600K range?

2008-02-18, 23:20   #36
em99010pepe

Sep 2004

2·5·283 Posts

Quote:
 Originally Posted by gd_barnes In this effort or on the n=400K-600K range?
On the n=400K-600K range, LLRnet is already with work until 370k.

2008-02-18, 23:23   #37
mdettweiler
A Sunny Moo

Aug 2007
USA (GMT-5)

3×2,083 Posts

Quote:
 Originally Posted by em99010pepe On the n=400K-600K range, LLRnet is already with work until 370k.
The only problem is...last I heard, all of Gary's machines are busy sieving 300<k<400. So he would have to get some power from elsewhere, or steal it from 300<k<400, if he was going to sieve n=400K-600K further.

We could, as an alternative, make it a public sieve effort, like this one.

2008-02-19, 08:08   #38
gd_barnes

May 2007
Kansas; USA

276516 Posts

Quote:
 Originally Posted by Anonymous The only problem is...last I heard, all of Gary's machines are busy sieving 300
I'll do some analysis on removal rate for the narrower n=400K-600K range using sr2sieve during the day Tues.

I think it would have been worth it for for n=260K-600K but I'm not so sure for n=400K-600K. Once the LLR time has been expended for a large portion of a range, it becomes less beneficial to sieve the remaining range. I'll let you know.

Done in by improving software... lol

Gary

 2008-02-19, 18:17 #39 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 141518 Posts 120G-130G complete.
2008-02-19, 19:59   #40
gd_barnes

May 2007
Kansas; USA

5·2,017 Posts
Sieve depth analysis on n=260K-600K / 400K-600K

Quote:
 Originally Posted by em99010pepe On the n=400K-600K range, LLRnet is already with work until 370k.
I redid some analysis I did back when I was sieving 400<k<=1001 for n=260K-600K using sr2sieve:

Machine used for both LLR and sieving test: 1.66 Ghz Dell core duo
(about equally good at sieving and LLRing)

70% n-range = 498K
Candidate chosen for LLR test:
693*2^498000-1
Time per iteration: .835 ms
Iterations: 498K
Total LLRing time: 416 secs.

Sieving test on n=260K-600K for 400<k<=1001:

Way back when, srsieve was faster. I was getting P=67K/sec. and confirmed that with a recent test.

I just now ran a test using the new version of sr2sieve. It was at P=88K/sec. :surprised Yep, it's faster now. (Previously ~P=50K/sec. if I remember right.)

Analysis sieve: P=5000G-5010G:
Expected factors found: 271 (much more accurate than actual found)
P-rate/sec. using srsieve: 67K/sec.
Est. seconds to process P=10G: 10G / 67K = 149254
Est secs. per factor found: 149254 / 271 = 551

The 551 sec. removal rate vs. 416 sec. LLR time confirms that I initially over-sieved the range. My original analysis showed an optimal depth of P=4.25T-4.5T but I wanted it to be 10-15% over-sieved since most everyone else would be LLRing.

Now, going back and using sr2sieve instead on the entire range:

Analysis sieve: P=5000G-5010G:
Expected factors found: 271
P-rate/sec. using srsieve: 88K/sec.
Seconds to process P=10G: 10G / 88K = 113636
Secs. per factor found: 113636 / 271 = 419

surprised:surprised

Now, how LUCKY is that? Had I used sr2sieve originally, P=5T is almost exactly the right depth for the range: 419 secs. removal rate vs. 416 secs. LLR rate.

Therefore sieving the smaller range of n=400K-600K would be foolish. With only 200K/340K (58.8%) of the n-range, the removal rate would be 419 secs. / .588 = 712 secs. A 70% n-range candidate of n=540K wouldn't take nearly that long to LLR.

Conclusion: No additional sieving needed for 400<k<=1001.

Future: Thanks to sr2sieve, I'm sieving 300<k<400 to P=6T, which will save additional LLRing time.

Thanks to Geoff for the nice increase in sr2sieve sieving speed!

Gary

Last fiddled with by gd_barnes on 2008-02-19 at 20:00

 2008-02-19, 22:37 #41 Flatlander I quite division it     "Chris" Feb 2005 England 31·67 Posts 80G-120G complete.
 2008-02-19, 22:58 #42 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 3×2,083 Posts New sieve file released, sieved to p=130G.
 2008-02-22, 04:40 #43 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 3×2,083 Posts Hi all, We've decided to include k<300 (for the same n-range, 100K-260K) in this doublecheck sieving, since it's currently doublechecked up to n=100K, just like the 300
2008-02-22, 06:06   #44
gd_barnes

May 2007
Kansas; USA

5·2,017 Posts

Quote:
 Originally Posted by Anonymous Hi all, We've decided to include k<300 (for the same n-range, 100K-260K) in this doublecheck sieving, since it's currently doublechecked up to n=100K, just like the 300
In theory, since the rate of sieving varies by the square root of the # of k's, it should sieve sqrt (500/351)-1 = ~19.4% slower. But it will find more factors / P-range.

With the efficiency of more k's, sieve depth should increase slightly. After I said it, 1T seemed a little high but it might be real close with 500 vs. 351 k's. It's very unusual to sieve to 1T for a non-top 5000 range but then again, it's very unusual to sieve 500 k's at once too!

G

 Similar Threads Thread Thread Starter Forum Replies Last Post jasong jasong 4 2012-03-25 19:11 ATH PrimeNet 11 2010-06-03 06:38 masser Sierpinski/Riesel Base 5 44 2006-09-24 17:19 Unregistered PrimeNet 9 2006-03-26 05:48 TheJudger Data 4 2005-04-04 08:54

All times are UTC. The time now is 10:19.

Tue Mar 31 10:19:24 UTC 2020 up 6 days, 7:52, 0 users, load averages: 1.14, 1.02, 1.08

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.