[quote=monst;119467]
2.) the -z and -Z command line options to adjust priority (with the default set to Don't adjust priority, I find myself going to the task manager to switch to low priority after every time I restart the sieve)

Let me know if I am missing something in build 0.6.7, if that functionality is already there.

Thanks,

-- monst[/quote]

Good request! When I do sieving with srsieve on 300-500 k's at once for some of my double-check efforts, I have the same issue. sr1sieve and sr2sieve default to low priority but srsieve defaults to medium priority and I have to go in to the task manager to adjust it to low.

Personally I wouldn't even need the -z or -Z options. If srsieve just defaulted to low priority, that would work for me but I'm sure others may want the option to adjust it at the command line.


Gary

[quote=gd_barnes;119473]
Personally I wouldn't even need the -z or -Z options. If srsieve just defaulted to low priority, that would work for me but I'm sure others may want the option to adjust it at the command line.
Gary[/quote]


That implementation, defaulting to low priority (or idle priority), would be fine with me too.

[QUOTE=monst;119297]Hello geoff,

I am interested in performing multiple k sieves at once. I understand that sr2sieve would be the best choice of program.

What are the practical limits on the number of k's in a single sieve file, from a performance standpoint? I would like to have as many k's as possible -- each k would have approximately 10 to 100 n values associated with it. How does the performance scale as I increase the number of k's?
[/QUOTE]

In principle, for a sieve with many (hundreds) of k and very large range (10 of millions) of n, the speed should be proportional to sqrt(number of k * range of n). But when there are many more k and only a few n this will not apply, and in this case you might be better off with a trial factoring algorithm.

sr2sieve is optimised for data sets of about the size of the main distributed projects it is being currently being used for, i.e. SR5 (200-300 k, 2 million n range), RS (66 k, 20 million n range), PSP (17 k, 50 million n range). srsieve might be faster than sr2sieve when the range of n is smaller.

If you are thinking of trying to use sr2sieve as a replacement for a (multiple) fixed-n sieve, don't bother, it will be slow.

[QUOTE=monst;119467]When working with srsieve and sr2sieve, there are two pieces of functionality that sr2sieve has that would really help me in srsieve.
1.) x86-64 functionality for Windows (I don't see a download available for this on your site)
2.) the -z and -Z command line options to adjust priority (with the default set to Don't adjust priority, I find myself going to the task manager to switch to low priority after every time I restart the sieve)
[/QUOTE]

I have uploaded srsieve 0.6.8 which has the -z and -Z switches, which work the same as in sr2sieve.

Building a x86-64 Windows executable is on my TODO list, but it will take some time as a lot of assembly code needs to be translated to WIN64 calling conventions, it is not just a matter of changing compiler options.

All new development happens in sr2sieve. A lot of it gets into sr1sieve fairly quickly because most of the important code is shared between sr1sieve and sr2sieve. However there is now very little common code between srsieve and sr2sieve, and so updating srsieve is becoming difficult.

More questions about sr(n)sieve...
 

Hello Geoff,

Thanks for the new build of srsieve. I have downloaded it and have it running.

I will stay with NewPGen and perform multiple fixed-n sieving when the range of n is small.

I have several projects that have extended n-ranges and would be more suited to srsieve, sr1sieve, or sr2sieve. However, each sequence has a different base b. Do you recommend (performance-wise) running multiple sequences when the bases are different? (I noticed that on the prime pages, it stated that sr2sieve is for base 2, but I read a post that you enhanced it and lifted this restriction.) If so, would you run srsieve or sr2sieve? If not, I'll stay with sr1sieve.

With regards to 64-bits, I appreciate your comments on the different code bases: sr(n)sieve vs. srsieve. How much does 64-bit improve sieving performance on Windows? (I know with Prime95, there is a huge benefit when trial factoring, but not as much when LL testing.) This could sway me to move to sr2sieve with fewer sequences since it already has an x86-64 version.

Finally, where is multi-threading on your TODO list? -- Just curious...

Thanks, in advance.

[QUOTE=monst;119788]Do you recommend (performance-wise) running multiple sequences when the bases are different?[/quote]
sr2sieve doesn't support multiple bases in a single run, so you'll have to split your runs based on the bases. Also, initial sieving should be performed by srsieve (the details are explained in the README file coming with sr2sieve). Other than that, go nuts!

[QUOTE=monst;119788]How much does 64-bit improve sieving performance on Windows?[/quote]
I've seen people posting nearly 2x speed compared to 32-bit client (actually almost 80% improvement). YMMV.

[QUOTE=monst;119788]Finally, where is multi-threading on your TODO list?[/QUOTE]
I'll leave this one up to geoff :smile:

Thanks. I've got sr1sieve running in batch mode and I'll move it to a 64-bit machine tomorrow.

monst
 

If it's not a secret, what kind of projects are you working on?

I'm not sure we can give you the best advice based on sparse information you provided so far.