A multiple k/c sieve for Sierpinski/Riesel problems

[geoff]

I build some 64-bit Windows executables for sr[125]sieve, but have no way to test them. If someone familliar with the 32-bit binaries could test them that would be great. Even just running `sr2sieve -h' to see whether the executable is valid would be helpful :-)

(The 64-bit executables are in the *-windows-x86-64.zip archives).

[S485122]

sr2sieve.exe -h has no problems under (over ?) Windows XP 64. If you PM me some input files I could really try the program out for a SHORT time.

Jacob

[geoff]

Originally Posted by S485122

sr2sieve.exe -h has no problems under (over ?) Windows XP 64. If you PM me some input files I could really try the program out for a SHORT time.

Jacob

Thanks Jacob. No-one has reported any problems yet.

This archive contains a very small test sieve and instructions, it can be used with both sr2sieve and sr5sieve:

http://www.geocities.com/g_w_reynold...r5check.tar.gz

[S485122]

No problem encountered, I had to increase the priority of the process since it took less than one % of one of the cores processor time.

09/28/07 10:47:05 sr2sieve started: 7 <= n <= 1999999, 100000000 <= p <= 150000000
09/28/07 10:55:27 sr2sieve stopped: at p=150000000 because range is complete.
09/28/07 10:55:27 Found factors for 10533 terms in 32.234 cpu sec. (expected about 10697.12)

Jacob

[geoff]

There is one difference between the 64-bit Linux and Windows builds: Windows uses 32-bit bitmap code, and so the cache file sr2cache.bin created by the Windows executable is incompatible with the one created by the Linux executable on 64-bit systems.

If you try to use the same cache file in Windows and Linux then sr[125]sieve will complain about it being the wrong width. The solution is just to delete it and create a new one.

I don't think this will have much effect on performance. It is a consequence of the `uint_fast32_t' type only being 32-bits wide on 64-bit Windows, but 64-bits wide on Linux.

[Cruelty]

Geoff, I have a question about srfile utility.
I have sieved a large number of "k" (50000) using srsieve and received a result file in srsieve format (~33M candidates). Right now I'm trying to convert it to PRP format, however it already lasts 12 hours. There was no such problem with converting to ABCD format which takes less than 5 minutes on the same machine. I have tried it on both win32 and linux64 latest versions of srfile.

[geoff]

Originally Posted by Cruelty

Geoff, I have a question about srfile utility.
I have sieved a large number of "k" (50000) using srsieve and received a result file in srsieve format (~33M candidates). Right now I'm trying to convert it to PRP format, however it already lasts 12 hours. There was no such problem with converting to ABCD format which takes less than 5 minutes on the same machine. I have tried it on both win32 and linux64 latest versions of srfile.

The PRP format is sorted, but the sort routine is not efficient :-(

You could try converting into NewPGen format (i.e. 50,000 individual *.npg files!) and then from the Linux shell run:

$ cat t16*.npg | grep -v ":" | sort -k2,2 > plus.txt
$ cat t17*.npg | grep -v ":" | sort -k2,2 > minus.txt

Then edit plus.txt and minus.txt to add an appropriate header taken from one of the t16*.npg and t17*.npg files respectively. (This is from memory, try `man sort' if not sure).

[geoff]

New command line switches available in all builds:
-e --elapsed-time Use elapsed instead of CPU time for status line reports.
-f --factors FILE Append found factors to FILE instead of factors.txt.
-D --duplicates FILE Append duplicate factors to FILE.
-S --save TIME Write checkpoint every TIME seconds. (default 300).

The sr2sieve-amd and sr2sieve-intel executables have been merged, there is now one 32-bit sr2sieve executable with three seperate critical code paths:
Intel code path: Optimised for Pentium 2 or Pentium 3
AMD code path: Optimised for Athlon/Duron.
SSE2 code path: Optimised for Pentium 4.

The correct code path should be selected automatically but can be overridden with command-line switches:
`sr2sieve --amd' is equivalent to running the old sr2sieve-amd executable,
`sr2sieve --intel' is equivalent to running the sr2sieve-intel executable.

Both --amd and --intel will use the SSE2 code path if the hardware supports it, unless the --no-sse2 switch is also used. The `-v --verbose' switch will report which code path was selected.

The AMD code path requires the CMOV instruction set, so the Intel code path will be selected for early AMD chips (K6 and earlier). There is not a big difference between the AMD and Intel code paths yet, they were just compiled with different CFLAGS.

[Cruelty]

Originally Posted by geoff

The PRP format is sorted, but the sort routine is not efficient :-(

It took me ~20 hours but I've managed it

[geoff]

This version has some minor changes to the x86-64 assembly that might make it a little faster on Windows. Previous versions had to translate from the Win64 calling convention into the Linux convention for some functions.

The changes in version 1.6.4 seem to benefit the Athlon 64, but as usual what is fast on one machine is slow on everything else, so the Core 2 may have lost some ground. If that happened you could try using the -Bgen/8 command line switch to see if that gets the speed back on the Core 2. I may have to split the 64-bit code into AMD and Intel specific paths in future versions.

[geoff]

The 64-bit Windows build now uses the correct hashtable optimisations, and so should hopefully run close to the speed of the Linux build. I have also added this fix to version 1.5.21.

The gen/6 mulmod method added in version 1.6.4 caused a slowdown on Core 2, so now it will only be considered for use when running on AMD. It can still be selected manually with the -B and -G switches, e.g. -Bgen/6.