Well, 25 P4s should be quite a help to find your first prime :shock:

I found out that Newpgen is much faster with fixed n than with fixed k. On fixed n I get speeds around 0.1 billion per second.

[QUOTE=nuggetprime;100883]On k=19217385 NewPGen is a litte bit faster than sr1sieve!
sr1sieve rate ~ 1500k per sec.
NewPGen rate ~ 2000k per sec.

I'm running windows and I have a 3.2 GHZ P4.
I'm running sr1sieve for P4.
[/QUOTE]

It is always a good idea to test all the options before spending a lot of CPU time sieving. sr1sieve uses a different algorithm to NewPGen and there will be cases when one is faster then the other.

However I timed your sequence over the range 100,000 < n < 3,000,000, 20000e8 < p < 20001e8 on a 2.8GHz P4/Celeron (Linux) and got these results:
NewPGen 2.82: 231 sec.
sr1sieve-intel 1.0.15: 165 sec.

Can you tell me what range of n you were sieving, and at what p? If p is too small and there are many factors being found per second, then sr1sieve often spends more time checking the factors and printing them to the screen than it spends actually finding them.

[QUOTE=geoff;101104]If p is too small and there are many factors being found per second, then sr1sieve often spends more time checking the factors and printing them to the screen than it spends actually finding them.[/QUOTE]I don't know if it would be of any use but maybe "verbose=0" switch could be implemented, especially for benchmarking? Also I would welcome a Windows (2000/XP) service :bow:

[QUOTE=Cruelty;101183]I don't know if it would be of any use but maybe "verbose=0" switch could be implemented, especially for benchmarking?
[/quote]
I may add a --quiet switch to a future version. For benchmarking the best approach is simply to use a high value for --pmin. If you expect to sieve to about p=X, then benchmarking at about p=X/2 should be ideal.

It is still necessary to sieve enough of the small factors out (so that the character of the sequence shows up in the terms left in the sieve) before starting benchmarking, but sieving to p=10 million or so should be sufficient in most cases, this usually only takes a minute with NewPGen or srsieve.

[quote] Also I would welcome a Windows (2000/XP) service :bow:[/QUOTE]

I guess a Windows service is like a daemon in unix? I compile the windows binaries using the mingw32 cross-compiler from Linux, it only has a small subset of the normal library functions to work with, signal handling in particular is almost non-existent. It might be possible using cygwin, but I am still looking for a cygwin cross-compiler.

p from 200 billion to 500 billion,
n = 300k-500k

[QUOTE=nuggetprime;101537]p from 200 billion to 500 billion,
n = 300k-500k[/QUOTE]

You are right, NewPGen is faster over that range. I think it is mainly the short range of n that makes the difference, more than the particular value for k.

practical limits on number of k's in sieve file
 

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?

Thank you, in advance,

-- monst

I think once you get enough k's in the sieve file, srsieve becomes more efficient than sr2sieve.

Of course, if you're starting the sieving from scratch, you're going to need to use srsieve or NewPGen to start it out anyway (since sr2sieve won't sieve below a certain level of p, not to mention that it can't create a new sieve file, only sieve existing ones).

sieving suggestions...
 

Monst,

Below are cut-and-pastes of some relevant parts of some posts from another thread that explain quite a bit in detail. Bottom line:
1. For 1-2 k's, use sr1sieve. Running it twice is still usually faster than running any other program once with 2 k's.
2. For 3 to about 50 k's, use sr2sieve.
3. For about 50 k's to (I think) upwards of 100,000 k's, use srsieve.
4. For fixed-n searches and other kinds of 'specialty' searches like for twins, Sophie-Germains, Cunningham Chains, etc., use NewPGen.

In other words, the limit is very high on the # of k's that you can sieve at once.

For the use of sr1sieve and sr2sieve, you'll have to use srsieve first to sieve to the limit required by those programs (generally the largest k that you are sieving) but I recommend that you sieve to at least P=100M first.

All of these programs smoke NewPgen on speed for fixed-k searches. NewPgen was more designed for fixed-n searches.



[quote=gd_barnes;113391]Just to clarify to make sure I understand you correctly...Sometime late on Monday, you will have completed searching the range of 100K < k < 200K for n < 7000. Is that correct?

Suggestion...Having searched across large ranges of k quite a bit myself, I have found srsieve to be much faster than sr2sieve for a very large # of k's like you are doing here. You might run both over the same range of p for a small test and see which one is faster on your machine. I think srsieve will be much faster for the 50,000 k's that you're doing here (assuming that I understand you correctly).

My experience...when doing the double-checking for k <= 1001 up to n=50K, srsieve was faster in all cases, even when I reduced the range of k to just 300 < k < 1001. But when I did my 'large heavy-weight' k sieve for only 12 k's from k=19437 up to k=3428677395 from n=200K to 400K, sr2sieve was always faster. It probably has to do with actual factor removal as the program progresses on srsieve vs. just writing factors out and removing them later on sr2sieve. I think a large # of k's makes immediate removal by the program much faster vs. removing them at a few points along the way or all at the end using srfile.


Gary[/quote]

[quote=gd_barnes;114091]Anon,
Based on my experience, here are my suggestions for sieving software in different situations:

1. 1 to 2 k's of the form k*2^n+/-1: use sr1sieve. It's fast enough that running it twice is usually faster than running anything else once with 2 k's.

2. 3 to about 50 k's: use sr2sieve.

3. About 50 k's or more: use srsieve.

4. Very specific types of searches like SG's or twins: use NewPGen.

The 50 k's is a very rough estimate. If you have anywhere between about 20 and 100 k's you want to sieve, I'd suggest testing both programs and see which is faster. If about the same, use srsieve because it doesn't require as many steps and so is a little easier to use.

Once you get used to the srsieve series of programs, you'll rarely go back to NewPGen for standard searches.

If you haven't used sr2sieve, it takes a little getting used to. There are a few hoops to jump though on it. Curtis is the best resource for getting all of the ins and outs of it.


Gary[/quote]

requests for additional functionality in srsieve
 

Gary,

Thank you for the advice. I have srsieve working on about 2400 sequences -- from your input it seems that srsieve is a better choice than sr2sieve.

Geoff,

I like srsieve a lot! I converted hundreds of NewPGen fixed-n sieve files with thousands of k's in them to work with srsieve and my boxes are humming along.

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)

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

Thanks,

-- monst