Yoyo had difficulty sieving some bases where there were many k's remaining. Something related to the Legenders tables and getting work credit for removing thousands or millions of factors. Also I know that sr2sieve does not work for extremely large k even with the -x switch. I believe it would all have to be done with srsieve.

Based on past experience I do not recommend Yoyo for sieving R3 or S3.

KEP, I have to decline your offer as you have the frequent tendency to make grandiose announcements about what you are going to do only to back off of them or lose interest. If you want a more detailed explanation I can provide one.

Pepi, even for just a k=1G range, do you realize that this would be a single sieve file with 1000s of k's remaining with thousand and millions of factors to be removed? I'm pretty sure that was a problem for Yoyo before.

If some of you want to start on such an effort, I would suggest attempting to sieve a P=1G range for R3 k=25G-26G. (Should be ~6000 k's.) You can see if Yoyo would be willing to sieve it but I seriously doubt it.

These last few posts are being moved to the R3 thread.

My fault, since I forget fact that only part of S/R 3 can be done with sr2sieve.
So forget what I say :)
Continue sending bases for sieve from recommendation list
Best regards and once more sorry :(

[QUOTE=gd_barnes;506368]Yoyo had difficulty sieving some bases where there were many k's remaining. Something related to the Legenders tables and getting work credit for removing thousands or millions of factors. Also I know that sr2sieve does not work for extremely large k even with the -x switch. I believe it would all have to be done with srsieve.

Based on past experience I do not recommend Yoyo for sieving R3 or S3.

KEP, I have to decline your offer as you have the frequent tendency to make grandiose announcements about what you are going to do only to back off of them or lose interest. If you want a more detailed explanation I can provide one.

Pepi, even for just a k=1G range, do you realize that this would be a single sieve file with 1000s of k's remaining with thousand and millions of factors to be removed? I'm pretty sure that was a problem for Yoyo before.

If some of you want to start on such an effort, I would suggest attempting to sieve a P=1G range for R3 k=25G-26G. (Should be ~6000 k's.) You can see if Yoyo would be willing to sieve it but I seriously doubt it.

These last few posts are being moved to the R3 thread.[/QUOTE]


I also had my doubt about that. ^-^
I will see which pmax value works fine for a 1G range and will do a sieve file for R3 k=25G-26G and n=25K-50K (or just 100K?). I´m pretty sure its going to take some weeks to get this done; since sr2sieve needs pmin > k.
So sieving up to 30e9 with srsieve; than switching to sr2sieve.

[QUOTE=MisterBitcoin;506372]I also had my doubt about that. ^-^
I will see which pmax value works fine for a 1G range and will do a sieve file for R3 k=25G-26G and n=25K-50K (or just 100K?). I´m pretty sure its going to take some weeks to get this done; since sr2sieve needs pmin > k.
So sieving up to 30e9 with srsieve; than switching to sr2sieve.[/QUOTE]

It was my experience that sr2sieve did not work properly for large k even if it was sieved up to the k-value. I was using an older version of sr2sieve at the time but I doubt that it makes a difference. You will likely have to use srsieve to sieve the entire thing.

Be careful about trying to use sr2sieve at any point with the -x switch. With sieve depth > than the k-value, it will appear to work correctly but will actually output incorrect factors. According to the README file k must be < 2^32 (~4.295G) regardless of sieve depth.

Because srsieve is much slower than sr2sieve, efficiency is lost making this an even larger effort.

P=25G-26G was merely a suggestion for people to see how much effort was involved. If you guys decide it is worth the effort, I would suggest working on it in P=5G chunks as in P=25G-30G, 30G-35G, etc.

sr2sieve works for k less than 2^31. That's why 0-2.147G is the part of R3 sieved and tested most deeply; I have 6 cores sieving it, and BOINC tests 50k blocks as they become sieved deeply enough.

For 2.147-63G, it's srsieve or the highway.

I'm running 60G+ in 60-61 and 61-63G chunks; the sieve for 61-63 is unsurprisingly very close to half the speed of 60-61, so one can choose to sieve any multiple of 1G blocks with roughly equal efficiency. Since srsieve is single-threaded only, it makes sense to me to do 1G blocks per core.

I second the suggestion to focus on R3 over S3; it's half the conjectured k, and has quite a bit more work done already so a drive to 50k is less daunting (full disclosure: I only care about Riesel work on any base). I hope people sieve 25-100k, even if we only test to 50k this year.

[QUOTE=VBCurtis;506385]sr2sieve works for k less than 2^31. That's why 0-2.147G is the part of R3 sieved and tested most deeply; I have 6 cores sieving it, and BOINC tests 50k blocks as they become sieved deeply enough.

For 2.147-63G, it's srsieve or the highway.

I'm running 60G+ in 60-61 and 61-63G chunks; the sieve for 61-63 is unsurprisingly very close to half the speed of 60-61, so one can choose to sieve any multiple of 1G blocks with roughly equal efficiency. Since srsieve is single-threaded only, it makes sense to me to do 1G blocks per core.

I second the suggestion to focus on R3 over S3; it's half the conjectured k, and has quite a bit more work done already so a drive to 50k is less daunting (full disclosure: I only care about Riesel work on any base). I hope people sieve 25-100k, even if we only test to 50k this year.[/QUOTE]


I have started a sieve on 25G up to 33G for n=25K up to 50K. I have no idea how long this will need, expecting a few weeks or 2-3 months.

Why only up to n=50K? I will sieve up to n=100K in a 2nd stage; after testing. :P
The removed k´s will give it an nice speed boost, so sieving the next stage should be a bit "faster".

[QUOTE=MisterBitcoin;506407]I have started a sieve on 25G up to 33G for n=25K up to 50K. I have no idea how long this will need, expecting a few weeks or 2-3 months.

Why only up to n=50K? I will sieve up to n=100K in a 2nd stage; after testing. :P
The removed k´s will give it an nice speed boost, so sieving the next stage should be a bit "faster".[/QUOTE]


Since that is a large k-range and there is no efficiency loss by splitting it up, I would suggest sieving several k=1G or 2G ranges each on separate cores. That is the method that Curtis has used with his reservation and he is the resident sieving guru on this forum. :smile: Sieving-wise that will make it easier to manage but most importantly it will be much easier to manage when testing.

I agree with only sieving n=25K-50K at this point. Normally I would say n=25K-100K but base 3 is a far heavier weight base than any other. Somewhere around 40% of k's will be found prime for n=25K-50K. It will make the effort more manageable with smaller files.

If you're going to do 50-100k anyway, you're quite a bit better off doing smaller ranges of k and 25-100k all at once.

Here's the math:
Sieve speed scales with the sqrt of n-range. So, doing 25-100k will take sqrt(3) as long as 25-50k (for a fixed P-value target). Let's round and say 1.73x as long as the 25-50k sieve.

If you do 25-50k and then 50-100k, you'll need sqrt(2) as long for 50-100k, but you'll have 40% fewer k values. srsieve is linear by number of k's, so 0.6 * sqrt(2) = 0.85 (again, rounded). So you'll spend 1.85x the time do sieve this way, but 1.73x if you just run one sieve 25-100k. 1.73/1.85 is around 0.935, so a single large range is about 6.5% faster.

But, that doesn't take into account the sieve speed increase from finding some primes while the sieve is still going. If you're like me and test 25-30k before finishing the sieve, you get much of the speed increase from finding primes on the 50-100k sieve, but with the simplicity of sieving just once. I estimate this improvement as worth at least 10%, so doing one sieve 25-100k is around 15% faster than 25-50 followed by 50-100k.

Now, doing 25-100 is also more efficient in seconds per factor, meaning some of that speed improvement will be spent on sieving a bit deeper; but, once you do you're doing fewer LLR tests too. That's not a huge benefit, but making the long part of the project shorter feels nice! I'd rather sieve more and test less, so long as it's not wasting time overall.

This is why I keep advocating CRUS to sieve *much* larger ranges, as it's a big waste of computrons to do, say, 100-200k and then 200-400k and then yet another sieve. OK, 15% isn't "big waste"..... it's a Small Waste. Anyway, that's why I'm running 100-500k for this project, and then 500k-3M. As n increases, lower-weight k's are left because the heavier ones turn up prime more often, so wider ranges of N make sense.

I'll sieve 58G-63G to n=100000.

Can anyone provide an estimate for sieving depth and how long it would take a 4-core i7 to test a range of 1G?

I'm already well into 60-63G, so I suggest you do 55-60G.
I went to P=9G before pausing to test 25-30k; I don't have a wall-clock-time estimate, but you can extrapolate from a pretty small start.

[QUOTE=VBCurtis;506567]I'm already well into 60-63G, so I suggest you do 55-60G.
I went to P=9G before pausing to test 25-30k; I don't have a wall-clock-time estimate, but you can extrapolate from a pretty small start.[/QUOTE]

Okay. I'll adjust the reservation to 55G-60G.