i just tried the sr1sieve application:

it give a good boost

4.6 million to 6.2 million p/sec on the amd x2 4200
(was 2.6 million with sr5sieve "nonp4")

problem with sr1sieve:

there is no checkpoint file so that we can restart at the last tested factor ...

sr5sieve 1.4.19
 

There are some very minor optimisations in this version, and a couple of minor bug fixes. Some new powmod code for the K8 build hasn't been fully tested.

[QUOTE=tnerual;97654]problem with sr1sieve:

there is no checkpoint file so that we can restart at the last tested factor ...[/QUOTE]

Just use the -o switch to save a copy of the whole sieve file instead of a checkpoint. If the output file and the input file are the same then the input will be overwritten.

sr5sieve/sr2sieve 1.4.20
 

This version uses an addition ladder idea that worked in sr1sieve. This benefits sieves with few or lightweight sequences most. (Faster for SoB.dat, no gain for riesel.dat or sr5data.txt).

The number of baby/giant steps is now chosen from a precomputed table of all possibilities, instead of being estimated. This needs a larger hashtable to pay off, and so probably benefits machines with large L1 and/or fast L2 cache most. (Faster on my P4 and Coppermine P3, no gain for P2 or Katmai P3).

The second change has messed up the parameter selection code a bit, so some manual tweaking may be needed to get best performance on some machines. For those who want to do this there are some command line switches you can use to improve the automatic selection:

-l X Set L1 data cache size to X kilobytes
-L X Set L2 data cache size to X kilobytes

The next two allow some automatic selections to be overridden:

-H X Force use of X kilobyte hashtable (X=1,2,4,8,16,32,64)
-Q X Force use of b^X for subsequence base (X=120,240,360,720)

Run with the -v switch to see which parameters were actually used.

If anyone finds a combination of hashtable size and subsequence base that works better than the defaults on their machines, post here along with the machine type, L1/L2 cache sizes, and sieve file used. This will help make the automatic selections better in future versions.

sr5sieve 1.4.21
 

This version uses mmap() to load the Legendre symbol cache file on systems that have it [not mingw32 unfortunately]. This allows multiple sr5sieve processes to share the memory used by the Legendre symbol tables.

It also regognises sequences that consist of Generalised Fermat numbers A^2^y+1, for which only primes of the form x*2^(y+1)+1 are considered as candidates.

sr5sieve/sr2sieve 1.4.23
 

I have extended the power residue tests to 9th powers in this version. The code has been made more flexible so it is now much easier to extend these tests further, however 9th powers seem to be close to the limit of usefulness. Gain is about 4% for Sob.dat, 2% for riesel.dat, < 1% for sr5data.txt.

Some of the gain is lost on SSE2 machines because some SSE2-specific assembler can no longer be used.

I am no longer able to sieve some k using 1.4.23 version of win32.i686 binary. I get the following error: [code]ERROR: 736320585*2^n-1: Square-free part of k is too large.[/code]It was possible with 1.4.20 version of the same executable...

[QUOTE=Cruelty;98701]I am no longer able to sieve some k using 1.4.23 version of win32.i686 binary. I get the following error: [code]ERROR: 736320585*2^n-1: Square-free part of k is too large.[/code]It was possible with 1.4.20 version of the same executable...[/QUOTE]

There was a case in earlier versions where some k values could be accepted even though the squarefree part was over the limit. I fixed this, but in doing so may have caused some legitimate k values to be excluded.

Your k is borderline, I will have to work through the arithmetic and see whether it passes. If it doesn't then earlier versions may have missed factors for this k, sorry. (sr1sieve or srsieve will handle this k OK).

OK. Thanks, just let me know of your findings :smile:
BTW: In the same sieve I also have k=864316301 - is it also a "borderline" case?

sr5sieve/sr2sieve 1.4.24
 

[QUOTE=Cruelty;98803]OK. Thanks, just let me know of your findings :smile:
BTW: In the same sieve I also have k=864316301 - is it also a "borderline" case?[/QUOTE]

Sorry, false alarm: no factors were missed for k=736320585. In version
1.4.21 I had incorrectly lowered the limit on the squarefree part of k,
in this version 1.4.24 I have restored it to the previous higher level.

For sr2sieve, the squarefree part of k can be up to 2^30. In general for
k*b^n+c, c*core(b)*core(k) must fit in a signed 32-bit integer.

Thanks! :bow: