new sieving software

[VBCurtis]

Sorry, geoff-- I was unclear. I should have said "speedup due to 1.05 upgrade from 1.04" instead of "speedup from 1.05". I have not tried 1.06 yet.

[Flatlander]

Originally Posted by geoff

It is normal to update the screen status line every minute, but is it really saving the output file every minute too?

Yes.

Also, if a give a command such as:

"C:\Searches\3045>sr1sieve-i686.exe -i 3045d.txt -o 3045e.txt -p 802465263461 -P 2000000000000 -v --save 5"

the factored candidates are saved to a file called '5' and '3045e.txt' is only saved every hour.

Am I using it correctly?

For your reference the output is:

"sr1sieve 1.0.6 -- A sieve for one sequence k*b^n+/-1.
Read 24861 terms for 3045*2^n-1 from NewPGen format file `3045d.txt'.
Split 1 base 2 sequence into 85 base 2^120 subsequences.
Used 2 Kb for Legendre lookup table.
Using 4 Kb for the baby-steps giant-steps hashtable, maximum density 0.23.
Using a 48 rung odd addition ladder, density 0.40.
Using a 86 rung odd and even addition ladder, density 0.72.
Using a 43 rung even addition ladder, density 0.36.
Using 128 Kb for the sieve of Eratosthenes bitmap.
Expecting to find about 801 factors in this range.
sr1sieve started: 312177 <= n <= 599989, 802465263461 <= p <= 2000000000000"

Then it starts sieving.
btw It runs about 30% faster than NewPGen with these settings. (Athlon XP 3200+.)

[geoff]

Originally Posted by Flatlander

"C:\Searches\3045>sr1sieve-i686.exe -i 3045d.txt -o 3045e.txt -p 802465263461 -P 2000000000000 -v --save 5"

the factored candidates are saved to a file called '5' and '3045e.txt' is only saved every hour.

You are right, this is a bug. The interpretation of the '-f' and '-s' command-line switches are mixed up. I will fix it in version 1.0.7, until then it is probably best not to use the '-s' or '--save' switches, just let it use the default 1 hour save period instead.

[VBCurtis]

I am experimenting with srsieve or sr2sieve shortly. Since I am only sieving RPS files, should I convert to riesel.dat format to take advantage of sr2's additional speed over sr?
Kosmaj's explanation of the riesel format makes me think it is not horrible to convert by hand.

I would be sieving 4 to 6 sequences together if I build this file. I plan to add one sequence at a time, measuring the speed and reporting how speed scales with additional sequences. I suppose the specific k of the sequence being added will play a large role in overall sieve speed, but I'm sure we'll still learn something from it.

Is sr2 enough faster that I should only try this for sr2-style formatting, and not bother with srsieve?
-curtis

[VBCurtis]

I tried srsieve on 3 sequences after truncating them to have the same range. I converted speeds to time taken to sieve 1B, so I could directly compare.
Time for srsieve to sieve each sequence 1B individually: 975 sec.
Time for srsieve to sieve all 3 at once 1B: 735 sec.
Time for sr1sieve to sieve each 1B individually: 558 sec.

I'll wait for some encouragement before converting to riesel.dat by hand to try sr2. sr2 only has to be 30% faster than sr to make it worth doing 3-at-once rather than individual sieves; certainly it's more efficient as one adds more k-values.
-Curtis

[geoff]

http://www.geocitis.com/g_w_reynolds/sr1sieve/

This version fixes the bug reported by Flatlander that caused the -f FILE and -s TIME command-line switches to be mixed up when used together.

There is also a new command-line switch: -c FILE will cause the Legendre symbol tables to be written to cache FILE (if FILE doesn't exist), or loaded from cache FILE (if FILE exists and contains a valid symbol table).

For systems that support mmap() [Not mingw32 unfortunately], multiple sr1sieve processes will share the same copy of the cache file in memory. To make use of this, run sr1sieve once to create the Legendre symbol tables, then stop and restart it so that the tables are mmap()'d from the cache. Start all other processes using the same cache file (don't make copies of the file). The different sr1sieve processes may have different command-line options, including different sieve input file, as long as they are sieving the same sequence k*b^n+/-1.

Note that the cache file format is architecture-specific, so for example the 32-bit sr1sieve executable will refuse to load symbol tables from a cache file created by a 64-bit executable. The sr1sieve format is also not compatible with the cache file used by sr2sieve.

There are some other command-line switches that you may be able to use to tweak performance for your own machine: -l -L to set L1 L2 cache size, and -H -Q to override hashtable size and subsequence base. I expect these will have only very minor effect, unless you are sieving a very large range of n, or are sieving a very deep p range where large L2 cache may be useful.

Originally Posted by VBCurtis

I am experimenting with srsieve or sr2sieve shortly. Since I am only sieving RPS files, should I convert to riesel.dat format to take advantage of sr2's additional speed over sr?
Kosmaj's explanation of the riesel format makes me think it is not horrible to convert by hand.

It is not too hard to convert from NewPGen to riesel.dat format, but sr2sieve also understands ABCD format, it will try to load the sieve from a file sr2data.txt if you don't specifiy either of the -r or -s switches.

To convert to ABCD format you can use the srfile utility that comes with srsieve. If all your NewPGen files end in .npg then run `srfile -A *.npg' and rename the .abcd output file to sr2data.txt.

[VBCurtis]

I have run the same tests on sr2 as I did on sr; I noticed sr's natural output was essentially the same as riesel.dat, so converting was simple.
I ran all 3 pairs of sequences; each case was a 5-7% improvement in speed versus running two separate sr1 sieves. Thus, even sieving 2 k-values is faster than running two individual sieves when ranges are the same.

sr2 sieving all 3 together for 1B: 447 sec
sr1 sieving each of the 3 individually 1B: 558 sec.
sr2 is 25% faster on just 3 sequences!

Based on this, I suggest any of you currently sieving three or more sequences to merge them, even if the ranges are not precisely the same. When I added the fastest sequence as a third k-value, the sieve speed only dropped 12% (2540 kp/sec to 2240 kp/sec). This could give new life to some low-weight sequences that happen to be easy to sieve.
-Curtis

[Cruelty]

VBCurtis, which executables are you using?

[VBCurtis]

I believe all were done on linux-64 (k8) builds, on a Conroe.
-Curtis

[Cruelty]

I have just compared sr2sieve and srsieve using win32.i686 executables on P3-1000 laptop for the following sieve:

25*2^n-1
101*2^n-1
137*2^n-1
617*2^n-1
1515*2^n-1
12345*2^n-1
151515*2^n-1
736320585*2^n-1
864316301*2^n-1

srsieve = ~140000 p/sec
sr2sieve = ~220000 p/sec

57% improvement????

[Flatlander]

Guys, help me out here!
I have flu and not much is making sense. What is the quickest way of sieving 6 k and the same time ie.

uuuu , vvvv , wwww , xxxx , yyyy , zzzz from, say, 270,000 < n < 500,000.
Athlon XP, verbose, save every 10 mins, cache sizes of 128 and 512.
Then feeding the output into LLR.

btw All k have core() <16.