Question about sieving

[bur]

Thanks, I managed to use both srsieve and sr2sieve. Once you know what to do it's really easy to transfer work from one to the other.


However, I couldn't figure out how to continue sieving with sr2sieve at a later time with higher pmax. srsieve notes in the abcd file up to which value sieving was performed, so when I specify that file as input pmin is automatically adjusted. As far as I can see, sr2sieve does no such thing.

Originally Posted by rogue

If using sr2sieve with a k in that range, make sure that you generate the Legendre tables. That should give it a nice speed boost.

Does the -c switch do that?


Also I noticed the --threads option is not supported in my version 1.8.11, is that normal? It only runs on one core now...

[VBCurtis]

-p tells sr2sieve where to start sieving, -P where to end. The input file is untouched, so you could also edit the top line manually to update pmin.

-t is used for threads, only up to 8. I'm not sure what happens when you specify more than 8.

[bur]

Ok, manually updating the abcd file is what I do now. I thought is was a neat feature of srsieve to include this info in the abcd file, why doesn't sr2sieve?


The -t option isn't accepted. I just get the message: "unknown option -- t".

[VBCurtis]

Originally Posted by bur

Ok, manually updating the abcd file is what I do now. I thought is was a neat feature of srsieve to include this info in the abcd file, why doesn't sr2sieve?
The -t option isn't accepted. I just get the message: "unknown option -- t".

Again, sr2sieve is designed to work over multiple machines and some sneakernet. If you have machine #1 sieve 10T to 30T, and machine #2 sieve 30T to 50T, machine #2 would be mistaken to mark the input file as sieved to 50T for two reasons:
1. The factors haven't been removed yet
2. The factors from 10-30T aren't on machine #2.

It is more consistent and leads to fewer mistakes in software usage for sr2sieve to not change the input file at all.

Edit: I think threads only works on linux. If you're using windows, pretty sure you're out of luck. You could try the linux shell within win10?

[rogue]

Correct -t is not enabled on Windows.

Use -h to find the option to use Legendre lookups.

[bur]

VBCurtis, you're right, makes sense not to change the abcd file when it's the input file. But after sieving, when I convert the sr2sieve output with srfile, then it would be helpful if that information would be written in the abcd output file.


rogue, ok, so best way for fixed k is to split the n-range and run several sr2sieve simultaneously?

Use -h to find the option to use Legendre lookups.

That's where I got -c from, but I'm not sure if that's all that's required. It only says "save symbols" while -C says "load/save".

[rogue]

Originally Posted by bur

VBCurtis, you're right, makes sense not to change the abcd file when it's the input file. But after sieving, when I convert the sr2sieve output with srfile, then it would be helpful if that information would be written in the abcd output file.


rogue, ok, so best way for fixed k is to split the n-range and run several sr2sieve simultaneously?


That's where I got -c from, but I'm not sure if that's all that's required. It only says "save symbols" while -C says "load/save".

Do not split the range of n. That will not speed things up.

By default it will generate the tables. -x disables that. Using -c/-C will save you time when you start up as you can generate the tables once then re-use them.

[VBCurtis]

Originally Posted by bur

rogue, ok, so best way for fixed k is to split the n-range and run several sr2sieve simultaneously?.

Like I said a few posts ago, sr2sieve is designed to split over many clients, each with its own range of p to sieve. Give each client (or core) its own -p and -P. If you run them from the same folder, I suggest also giving each one its own -f factorfilename.

Or, get linux working in a virtual machine; that's how many of us got started in the conversion out of windows.

[bur]

Do not split the range of n. That will not speed things up

I realized it's apparently not like that... (My intention was to utilize all four physical cores since the -t option doesn't work under Windows. Won't it speed up overall progress (not progress on that specific n-range) if I run another instance of sr2sieve on one of the idle cores? I'm not really splitting the n-range but rather extending it.)

Like I said a few posts ago, sr2sieve is designed to split over many clients, each with its own range of p to sieve.

I thought about that and apparently I don't really get how sieving works. I thought that BOTH the size of p-range and n-range determine the speed. If that was the case, then it would make sense to work in small increments of -P to gradually decrease the n-range.


Now I think it only depends on the p-range? 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 p-ranges. 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 n-range 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?

[VBCurtis]

Originally Posted by bur

Now I think it only depends on the p-range? 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 p-ranges. 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 n-range 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 n-range; so a 4x-larger 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(n-range); 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 k-value, 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 k-values 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.

[rogue]

You can use the same cache for each instance of sr2sieve that is sieving the same k, b, c, and n range, but different p range.