I found another bug in srsieve--pentium 4 version.
using --force--base=1440 reduce to
Split 11 base 2 sequences into 12 base 2^1440 subsequences.
Sieve range is 0 to 1007999, using 100 baby steps, 7 giant steps.
(A speed of 300kp/s)

Normally the computer automatically uses base 288. This gives me a speed of 500kp/s

Split 11 base 2 sequences into 11 base 2^288 subsequences.
Sieve range is 288 to 999071, using 204 baby steps, 17 giant steps.

Since the # of steps is less in case 1, shouldn't it be faster? Is this a bug?

:popcorn: :bow:

[QUOTE=axn1]After removing 3 k's for the latest primes, this is what's coming up now:
[B]Split 309 base 5 sequences into 7998 base 5^240 subsequences.[/B]:surprised[/QUOTE]
How does this affect the sieving speed? If it makes it slower than version 1.0.0 then I can make adjustments so that such large bases don't get used. If anyone wants to experiment using srsieve 0.4.1 on the sr5data.txt file, you can use a command like

srsieve -cCvf sr5data.txt --pmin=100e9 --pmax=101e9 --force base X

to get an idea of how fast sr5sieve would be if it used base 5^X. You can also run

srfile -Q X sr5data.txt

to print the estimated amount of work to sieve in base 5^d for certain divisors d of X. Currently sr5sieve uses the same formula with X=720. The current formula is B + GS + 0.5Q + 0.3S where B,G are the number of baby,giant steps and sieving S sequences in base b^Q.

[QUOTE=geoff]How does this affect the sieving speed?[/quote]
Can't say. With 312 k's it was using 5^60 with about 2% speed increase over 1.0.0. When I removed the 3 k's -- with 309 k's -- it jumped to 5^240 with a further speed increase of 2%. Don't know if the 5^240 helped or not. Anyway I am not overly concerned since the overall speed is much improved. Just wanted to note this sudden jump - that's all.

[QUOTE=geoff]If anyone wants to experiment using srsieve 0.4.1 on the sr5data.txt file, you can use a command like

srsieve -cCvf sr5data.txt --pmin=100e9 --pmax=101e9 --force base X

to get an idea of how fast sr5sieve would be if it used base 5^X.[/quote]
I think I'll try that out when I get time.

[QUOTE=geoff]You can also run

srfile -Q X sr5data.txt

to print the estimated amount of work to sieve in base 5^d for certain divisors d of X. Currently sr5sieve uses the same formula with X=720. The current formula is B + GS + 0.5Q + 0.3S where B,G are the number of baby,giant steps and sieving S sequences in base b^Q.[/QUOTE]
Whew! No clue what you just said there:surrender

Result of running "srfile -Q 1440 sr5data.txt"
[code]
Base 5^240: 7998 subsequences (10.8%), work=18851.
Base 5^60: 2337 subsequences (12.6%), work=18854.
Base 5^180: 6078 subsequences (10.9%), work=19103.
Base 5^48: 2102 subsequences (14.2%), work=19479.
Base 5^36: 1590 subsequences (14.3%), work=19556.
Base 5^24: 1191 subsequences (16.1%), work=20314.
Base 5^12: 609 subsequences (16.4%), work=20349.
Base 5^360: 11578 subsequences (10.4%), work=20787.
Base 5^144: 5374 subsequences (12.1%), work=20947.
Base 5^120: 4536 subsequences (12.2%), work=22623.
Base 5^6: 536 subsequences (28.9%), work=26916.
Base 5^4: 366 subsequences (29.6%), work=27176.
Base 5^720: 20371 subsequences (9.2%), work=29620.
Base 5^2: 310 subsequences (50.2%), work=35310.
Base 5^1: 309 subsequences (100.0%), work=47313.
Base 5^1440: 40163 subsequences (9.0%), work=54320.
[/code]
And running srsieve 0.4.1 yielded similar result - 240 was appr. 2% faster than 60.

[QUOTE=axn1]And running srsieve 0.4.1 yielded similar result - 240 was appr. 2% faster than 60.[/QUOTE]
I tried it with the new file on my P3 and it was the other way around, 5^48 and 5^240 were about the same but 5^60 a touch faster, so I adjusted the formula in sr5sieve 1.1.1 to make it favour a lower base. It chooses 5^60 for the current sr5data.txt now, but the difference is probably too small to worry about. There are no other changes, so if 1.1.0 is faster for you then no need to upgrade.

sr5sieve 1.2.0
 

Sr5sieve now checks whether -ck (or -cbk if n is odd) is a quadratic residue with respect to p before adding k*b^n+c to the bsgs list. This means that on average only half the sequences have to be tested for each p, and results in a speedup of about 30% over version 1.1.5.

WOW :)

Thanks a load Geoff... now getting 50.8kp/s!!:bow:

This program is skyrocketing in speed :) :anurag:

everybody upgrade NOW :)

[QUOTE=geoff;86729]Sr5sieve now checks whether -ck (or -cbk if n is odd) is a quadratic residue with respect to p before adding k*b^n+c to the bsgs list. This means that on average only half the sequences have to be tested for each p, and results in a speedup of about 30% over version 1.1.5.[/QUOTE]
I am sure that you've already though of it, but... It handles 151026 properly (being a multiple of 3) right?

[QUOTE=michaf;86754]WOW :)

Thanks a load Geoff... now getting 50.8kp/s!!:bow:

This program is skyrocketing in speed :) :anurag:

everybody upgrade NOW :)[/QUOTE]

Amen! Another 33% speedup!

[QUOTE=axn1;86756]I am sure that you've already though of it, but... It handles 151026 properly (being a multiple of 3) right?[/QUOTE]

Yes 151026*5^n-1 is a special case becase it has both odd and even n. It is currently handled by ignoring it's quadratic residue and unconditionally including it in the bsgs list.

Hopefully someone will find a prime for this pesky sequence soon. :-)

[QUOTE=geoff;86820]Yes 151026*5^n-1 is a special case becase it has both odd and even n. It is currently handled by ignoring it's quadratic residue and unconditionally including it in the bsgs list.

Hopefully someone will find a prime for this pesky sequence soon. :-)[/QUOTE]
Have you tried sieving it separately? Maybe this is one instance where NewPGen might be faster.

[QUOTE=jasong;87033]Have you tried sieving it separately? Maybe this is one instance where NewPGen might be faster.[/QUOTE]

In the worst case 151026*5^n-1 counted as two sequences of similar weight, but that doesn't matter much when there are 300 other sequences in the sieve.

I have made an improvement to the way these sequences are handled in sr5sieve version 1.2.1, so now if the odd terms are QR and the even ones are not then only the odd terms are included in the bsgs iteration.

Finding a prime for this sequence would allow the code to be made a little simpler, but the performance gain would probably be quite minor.