Quote:
Originally Posted by bur
Now I think it only depends on the prange? In that case my attempt was indeed not good and it also explains the way sr2sieve works with the facotors.txt.
So ideally all physical cores would run one instance of sr2sieve on the same abcd input file but with different pranges. And removing candidates from the abcd file will only be done at the end of the whole process because the number of candidates doesn't really influence sieving speed?
edit: If nrange really has no noticeable impact on sieving speed, what bounds should I use? Lower bound obviously determined by the size of prime I want to find, but upper bound? Largest number I can see myself to LLR in the future? :)
And I used u # to have the instances use their own factors, checkpoint and so on files. However, with c they still all use the same sr2cache.bin, is that intentionally or should I specify different files using C?

The speed of sr2sieve rises theoretically with the square root of nrange; so a 4xlarger range of exponents will cut sieve speed in half (but will find factors twice as fast, since there are 4x as many candidates in the sieve!). In practice, it's not exactly sqrt(nrange); you can experiment, or you can accept that rough guidance as good 'nuff.
When I'm sieving for myself, I select an upper bound a bit higher than the largest exponent I can see myself testing; If I think I might get to 3M, I'll sieve to 4M. You are correct that the number of candidates in the input file has little effect on sieve speed, once the really tiny candidates are taken out. That is, a 50% reduction in candidate pool will improve sieve speed noticeably, but a 5% reduction makes no difference.
I don't know what c and C do, sorry.
If you're sieving a single kvalue, you should be using sr1sieve rather than sr2sieve. sr2 is faster for a file of multiple (more than 2) k's, while 1 or 2 kvalues should be done individually with sr1sieve; in fact, srsieve2 (new software from rogue) may be yet faster and my advice may be stale. sr2sieve expects a file in format usable by LLR (g flag from srfile), not abcd.