Testing new Ranges for Sierpinski/Riesel

[Batalov]

Originally Posted by lalera

hi,
i did R708 to n=5000 as a test with srbsieve
828 k´s remaining

I can DC this data.
For starters, 10000, 20000, 30000 are listed twice; CK=41121 is listed as "remain"ing k. So it is already 827, not 828.
There are also some differences of squares, cubes and seventh powers.

P.S. 9216*708^n-1 = (96*708^h-1)*(96*708^h+1), with h=n/2, for even n; and divisible by 709 for odd n.

[rogue]

Any ideas for having srbsieve auto-compute the sieve depth?

[VBCurtis]

The time spent sieving should be in the vicinity of 5% of the time it will take to test the entire file for primality. At very low exponents, this might be better set to 10%.

If there's a way to estimate how long it would take the PFGW the whole file (perhaps number of entries in the sieve multiplied by the time it takes to PFGW a candidate at the midpoint of the exponents), multiplying that by 10% and stopping srsieve at that time (rather than depth) should work. Of course, sieving reduces the number of tests in the sieve, and I have no idea what the right way to compensate for that is. Perhaps sieve to 100*maxn^2 (pulled from my &^%*), count the number of items in the sieve, then do this calculation?

That won't be ideal for bases like R3 that lose a bunch of k's to primes, as those sieve files have most of their tests run well below the midpoint of the exponent range. But, it still prevents cases like my first couple tries at using srbsieve, where I ended up having it sieve for longer than it took the resulting file to PFGW completely. If one wanted to allow tinkering, one could make the 10% a setting in the .ini, so users can adjust the relative time spent in sieve; this allows stuff like R3 to run at 7%, or even lower, to compensate for the high frequency of primed k's.

Edit- much simpler is to find time to test a midpoint-exponent candidate, and sieve until time per factor equals that time. I think srsieve has that option as a flag?

[paleseptember]

Originally Posted by VBCurtis

Edit- much simpler is to find time to test a midpoint-exponent candidate, and sieve until time per factor equals that time. I think srsieve has that option as a flag?

Indeed it does!

-S --stop-rate X  Stop when it takes X seconds to eliminate a candidate.

[pepi37]

And let someone who knows how Linux works help that Rogue compile srbsieve for Linux ( 64 bit)
I got testing S 810. On one machine it will be done at aprox ten days: on three will be done in 3.3 days :)
So anyone?

[lalera]

Originally Posted by paleseptember

Indeed it does!

-S --stop-rate X  Stop when it takes X seconds to eliminate a candidate.

good idea - but if there are many concurrent tasks (more than physical cores)
it would stop too soon

[LaurV]

then use a higher X

[lalera]

Originally Posted by LaurV

then use a higher X

do you know the real load of the machine ?
(an example: if the load is high you need to set -S 30 and
if the load is low to medium you need to set -S 10 or so ...)
p=xxx? would be better but who knows how to set it correct for each base and
exponent ?

[rogue]

-S --stop-rate X  Stop when it takes X seconds to eliminate a candidate.

That works fine for higher n, but for low n it doesn't because you want a removal rate of "x per second" instead of "seconds per x".

[rogue]

Originally Posted by pepi37

And let someone who knows how Linux works help that Rogue compile srbsieve for Linux ( 64 bit)
I got testing S 810. On one machine it will be done at aprox ten days: on three will be done in 3.3 days :)
So anyone?

I cannot compile for linux as I do not have a linux machine. I have already explained earlier in this thread how to compile for linux. All you should need is the GNU Compiler Chain (gcc).

[VBCurtis]

Originally Posted by lalera

good idea - but if there are many concurrent tasks (more than physical cores)
it would stop too soon

If the target time were found on the same machine with the same load, it would not matter how many tasks were running, as the result would still be "sieve until PFGW is faster on an avg candidate."