mersenneforum.org Testing new Ranges for Sierpinski/Riesel
 Register FAQ Search Today's Posts Mark Forums Read

2015-08-17, 17:21   #166
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

25·3·101 Posts

Quote:
 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.

Last fiddled with by Batalov on 2015-08-17 at 19:25

 2015-08-18, 00:28 #167 rogue     "Mark" Apr 2003 Between here and the 13·503 Posts Any ideas for having srbsieve auto-compute the sieve depth?
 2015-08-18, 04:24 #168 VBCurtis     "Curtis" Feb 2005 Riverside, CA 142C16 Posts 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? Last fiddled with by VBCurtis on 2015-08-18 at 04:40
2015-08-18, 06:04   #169
paleseptember

Jun 2008
Wollongong, .au

18310 Posts

Quote:
 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!

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

Last fiddled with by paleseptember on 2015-08-18 at 06:06

 2015-08-18, 11:00 #170 pepi37     Dec 2011 After milion nines:) 27238 Posts 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?
2015-08-18, 11:22   #171
lalera

Jul 2003

61410 Posts

Quote:
 Originally Posted by paleseptember Indeed it does! Code: -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

 2015-08-18, 13:04 #172 LaurV Romulan Interpreter     "name field" Jun 2011 Thailand 100110100101102 Posts then use a higher X
2015-08-18, 13:38   #173
lalera

Jul 2003

61410 Posts

Quote:
 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 ?

 2015-08-18, 13:41 #174 rogue     "Mark" Apr 2003 Between here and the 13·503 Posts Code: -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".
2015-08-18, 15:06   #175
rogue

"Mark"
Apr 2003
Between here and the

13×503 Posts

Quote:
 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).

2015-08-18, 15:48   #176
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

22·1,291 Posts

Quote:
 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."

 Similar Threads Thread Thread Starter Forum Replies Last Post robert44444uk Open Projects 587 2016-11-13 15:26 robert44444uk Conjectures 'R Us 139 2007-12-17 05:17 rogue Conjectures 'R Us 11 2007-12-17 05:08 michaf Conjectures 'R Us 2 2007-12-17 05:04 michaf Conjectures 'R Us 49 2007-12-17 05:03

All times are UTC. The time now is 02:43.

Fri Jan 28 02:43:47 UTC 2022 up 188 days, 21:12, 2 users, load averages: 1.81, 1.99, 1.76