A multiple k/c sieve for Sierpinski/Riesel problems

[michaf]

Around 12% faster on an athlon 64-x2 too :)

Everyone upgrade now!

[geoff]

There was a major bug introduced in sr5sieve version 1.2.4 that probably causes about 75% of factors to be missed by the k8 and ppc64 builds. (It doesn't affect 64-bit hardware running the linux32 or mingw32 binaries in compatibility mode).

I Hope to have a fix tomorrow. Sorry for the trouble.

[michaf]

As seen from the factor-reports, everyone reports just about as much factors as expected, so I don't think you'll have to worry too much.

[michaf]

Geoff, can you make it happen, in a future release,
that sr5sieve will also accept work of the form:
3000-3050

instead of only
3000,3050
?

Cheers, Micha
(Who happend to have made this 'typo' more then once already :> )

[geoff]

This version fixes a major problem in the bitmap code for 64-bit builds. If you are using the 32 bit mingw32 or linux32 builds then there is no need to upgrade.

Originally Posted by michaf

Geoff, can you make it happen, in a future release,
that sr5sieve will also accept work of the form:
3000-3050

I'll do this in the next version.

[Xentar]

Ehm, sorry for this question, but can someone please explain the difference of 586 and 686 to me?
I always used the 686 version. Now i tried the 586 just for fun, and I see, that it is almost as fast as the 686 - so what´s the difference?
Is 686 for 64bit processors, or something like this?

Running WinXP 32 Bit, on a Core2 Duo.

[axn]

Originally Posted by geoff

I'll do this in the next version.

Geoff, I have a feature request. Could you make it so that the Legendre table lookup can be written to a file once and load from it next time onwards (instead of recomputing everytime)? Obviously "sr5sieve -d" option has to remove the lookup info also. [It should probably have some checksum logic to avoid unwittingly using a corrupt lookup file]

PS:- All this is assuming that it is faster to load a file than compute the lookup.

[axn]

Originally Posted by Xentar

Ehm, sorry for this question, but can someone please explain the difference of 586 and 686 to me?

586 is for plain Pentium and Pentium MMX. 686 is for PPro, PII, PIII.

For modern processors, it doesn't really matter. But going with the higher one is better. If only it was SSE2 optimized...

[geoff]

Originally Posted by Xentar

I always used the 686 version. Now i tried the 586 just for fun, and I see, that it is almost as fast as the 686 - so what´s the difference?

Originally Posted by axn1

586 is for plain Pentium and Pentium MMX. 686 is for PPro, PII, PIII.

For modern processors, it doesn't really matter. But going with the higher one is better. If only it was SSE2 optimized...

In sr5sieve the critical code is in the mulmod64() function. Prior to version 1.4.0 this function could run about 5% faster by using a conditional move instruction (only available for i686) to replace a branch instruction. With the new mulmod code in version 1.4.x, using a conditional move works out slower than a branch, so there is now little difference between the i586 and i686 builds.

(I think the reason for this is that the branch that was replaced in the old version had about a 50% chance of being taken. In the new version the branch is not usually taken, so the CPU branch prediction algorithm works better and a conditional move is not worthwhile).

I have been trying to write a SSE2 version of mulmod64(), but I have come to the conclusion that it is not worthwhile for 32-bit machines. The basic problem is that it doesn't seem possible to load a 64-bit integer into a double-precision SSE register without first going through the FPU. (64-bit machines do have such an instruction).

Simply compiling for SSE2 with GCC (flags -march=pentium4 -msse2 -fpmath=sse) results in code that runs slower on a P4 than when compiled without SSE2.

[Citrix]

I was trying to sieve

myfile.txt
1665624349782373*2^n-1
10075614324682349*2^n-1
12782924755172441*2^n-1
15335906269828439*2^n-1
23009979551311559*2^n-1
30729699810869707*2^n-1
41360993926068041*2^n-1
49050506465852977*2^n-1
49791527843569597*2^n-1
50670759245200691*2^n-1
72292129717621199*2^n-1

from the 15 k low weight project from 1-2 million, the srsieve for windows just freezes, it does not start working for 15 mins or so, no factor output etc. Is this a bug?

(cmd prompt: srsieve --nmax 2000000 myfile.txt --pmax 100000000 --factors --verbose)

Thanks

[geoff]

Originally Posted by axn1

Could you make it so that the Legendre table lookup can be written to a file once and load from it next time onwards (instead of recomputing everytime)? Obviously "sr5sieve -d" option has to remove the lookup info also. [It should probably have some checksum logic to avoid unwittingly using a corrupt lookup file]

michaf requested this feature earlier. The file will be large, about 20MB, but it should be faster to load than recomputing the tables each time.

If I can't find a way to speed up the table creation then I'll implement this.