Sieving for CRUS

[MisterBitcoin]

Originally Posted by VBCurtis

For a single k, use sr1sieve?

Yes. sr2sieve is build to deal more k´s.

[Batalov]

Originally Posted by MisterBitcoin

Taking R867 to nmax=1M. Using the "old" srsieve to avoid any problems.

Originally Posted by VBCurtis

For a single k, use sr1sieve?

Originally Posted by MisterBitcoin

Yes. sr2sieve is build to deal more k´s.

That's not what VBCurtis meant.
He meant "Are you trying to sieve with (old or whatnot) srsieve, not knowing that you should only sieve low n values with srsieve and then switch to sr1sieve which is many times faster?"

In fact one should sieve like follows (pay attention to the middle step which removes 25% of candidates and makes next step faster):

srsieve -g -n200000 -N1000000 -P1e6 "8*867^n-1"
# optional:
# awk 'NF==2 {print $2%3}' t17_b867_k8.npg | sort | uniq -c
#      and observe

awk 'NF!=2 || $2%3!=0' t17_b867_k8.npg > t17_b867_k8.A.npg

sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg
sr1sieve -t 4 -P 1e13 -i t17_b867_k8.1e11.npg -o t17_b867_k8.1e13.npg

# even more optimal is to sieve ranges on 1 CPU each, then combine... 
# ... but you have to know how/what you are doing

[MisterBitcoin]

Originally Posted by Batalov

That's not what VBCurtis meant.
He meant "Are you trying to sieve with (old or whatnot) srsieve, not knowing that you should only sieve low n values with srsieve and then switch to sr1sieve which is many times faster?"

In fact one should sieve like follows (pay attention to the middle step which removes 25% of candidates and makes next step faster):

srsieve -g -n200000 -N1000000 -P1e6 "8*867^n-1"
# optional:
# awk 'NF==2 {print $2%3}' t17_b867_k8.npg | sort | uniq -c
#      and observe

awk 'NF!=2 || $2%3!=0' t17_b867_k8.npg > t17_b867_k8.A.npg

sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg
sr1sieve -t 4 -P 1e13 -i t17_b867_k8.1e11.npg -o t17_b867_k8.1e13.npg

# even more optimal is to sieve ranges on 1 CPU each, then combine... 
# ... but you have to know how/what you are doing

I always sieve to 50M using srsieve, not deeper. After sieving to this value sr1sieve catches the factors.

[Its not my first sieve I´m doing. I probably misunderstood Curtis.]

[VBCurtis]

Originally Posted by MisterBitcoin

I always sieve to 50M using srsieve, not deeper. After sieving to this value sr1sieve catches the factors.

[Its not my first sieve I´m doing. I probably misunderstood Curtis.]

neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.

[rogue]

Originally Posted by VBCurtis

neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.

Once the kinks are worked out of the newest srsieve, it will eliminate those terms.

[MisterBitcoin]

Originally Posted by VBCurtis

neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.

Oh, your talking about algebraic factors...............I´ll check with the script.
Your reply was so confusing, just say what you want.
Sry that I falsely understand it, I should stop sieving until all problem solved.

[pepi37]

Originally Posted by Batalov

sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg

When you use -t 4 what is slowdown comparing to t 1 * 4 instances?

[VBCurtis]

For me on R3, -t 4 is just a bit faster than 3 instances of single-threaded. So, about 20% wasted for convenience. But that's on a hyperthreaded machine; ubuntu doesn't schedule awesomely, so even with 6 tasks running it sometimes doubles up tasks on a single core whilst leaving another core idle.

[pepi37]

That info is same for me- one instance gives me 53Mp/s but t 4 gives me 169 Mp/s

[MisterBitcoin]

R867 finished to p=50T. File attached.

As I stated there are a lot of under sieved files for single-k Bases.
Reserving S406 (1k) from n=200K to N=1M. planned pmax=50T

[pepi37]

Originally Posted by MisterBitcoin

R867 finished to p=50T. File attached.

1157 algebraic factors removed
corrected sieve file attached