Testing new Ranges for Sierpinski/Riesel

[mdettweiler]

Originally Posted by rogue

You will need to find the header that has a #define for that then modify the code to include it in main.cpp. I suggest searching /usr/include for that string.

FWIW...I encountered a similar issue when compiling PRPnet on the noprimeleftbehind.net server (which has a very old gcc). It seems the C standard formatting macros are included by default by some compilers, but not (apparently) some versions of gcc.

The header is, in fact, being included already, but the desired macros are "turned off" when __STDC_FORMAT_MACROS is not defined.

The fix is to add "-D__STDC_FORMAT_MACROS" to CPPFLAGS in the Makefile. This sets the compiler flag that turns on the format macros. In my case, for compiling PRPnet, CPPFLAGS ended up looking like this:

Before:
CPPFLAGS=-c -g -m64 -Wall
After:
CPPFLAGS=-c -g -m64 -D__STDC_FORMAT_MACROS -Wall

The actual line might be different for sr*sieve (I haven't ever tried compiling them myself so I wouldn't know), but a similar change should do the trick.

A while back when I asked Lennart about this, he said that this modification is always necessary when building with gcc, so it may not just be limited to the really old version I'm using. Since pepi37 was able to fix his issue by upgrading to a newer gcc, perhaps the behavior has since been changed; though it seems versions with the older behavior are still quite prevalent.

If it doesn't interfere with other (non-gcc) compilers, it might be helpful to include the -D__STDC_FORMAT_MACROS flag in the official source code (both for the sr*sieve projects, and for PRPnet, which also has this issue).

[KEP]

Originally Posted by lalera

haswell - https://en.wikipedia.org/wiki/Haswel...rchitecture%29

4670 at 3.4 GHz

[VBCurtis]

Originally Posted by KEP

4670 at 3.4 GHz

Now, if you'd just learn to spell "haswell", we'd all be in agreement.

[KEP]

Originally Posted by VBCurtis

Now, if you'd just learn to spell "haswell", we'd all be in agreement.

Okay it is a Haswell I5-4670 @ 3.4GHz

[KEP]

If anyone would like to start up some base 3 work, please use the attached srbsieve.ini file.

Remember to change following:

mink=
maxk=

and set c= accordingly to the side you are searching (1 for sierpinski side and -1 for the riesel side)

I do recommend, for base 3 that you sieve with NewPGen* to these n:

From n=1 to n=28 if you sieve and test a range of 1G
From n=1 to n=30 if you sieve and test a range of 2G
From n=1 to n=32 if you sieve and test a range of 4G

* REMEMBER TO SIEVE EACH n, from p=1 until NewPGen TERMINATES BY ITSELF else you will have composites in your primelist.

If you sieve to only n=28, remove following lines from the srbsieve.ini file:

npgfile=29,29_.log
npgfile=30,30_.log
npgfile=31,31_.log
npgfile=32,32_.log

If you sieve to only n=30, remove following lines from the srbsieve.ini file:

npgfile=31,31_.log
npgfile=32,32_.log

If you sieve to n=32, after having changed what you are noticed to change in the beginning of this post, leave everything else untouched.

Now if we could get 16 cores with the equivalent force of an I5-4670 @ 3.4GHz running base 3, we should be able to have the entire base 3 tested to n=25K before the end of this year, as long as people use the optimized ini file, attached to this post.

Anyone care to join the effort and help getting base 3 completely started? PuzzlePeter would you?

[MyDogBuster]

I may as well jump in here.
I'm trying S3 from 1G to 1.1G

Got my newpgen files to n=23

Have latest pfgw 3.7.10
Have srsieve
Have srbsieve dated 8/15/15

SRBsieve started and removed from all 23 files
I then got the message

Started recovery at Phase 0 with 4247788 terms
ERROR m 1e10: argument out of range

My ini file looks like:

base=3
mink=1000000001
maxk=1100000000
c=1
npgfile=1,n1.log
npgfile=2,n2.log
npgfile=3,n3.log
npgfile=4,n4.log
npgfile=5,n5.log
npgfile=6,n6.log
npgfile=7,n7.log
npgfile=8,n8.log
npgfile=9,n9.log
npgfile=10,n10.log
npgfile=11,n11.log
npgfile=12,n12.log
npgfile=13,n13.log
npgfile=14,n14.log
npgfile=15,n15.log
npgfile=16,n16.log
npgfile=17,n17.log
npgfile=18,n18.log
npgfile=19,n19.log
npgfile=20,n20.log
npgfile=21,n21.log
npgfile=22,n22.log
npgfile=23,n23.log
phase=100,33000,70000
phase=335,33000,140000
phase=674,33000,315000
phase=898,33000,552500
phase=1120,33000,425000
phase=1792,33000,977500
phase=2240,33000,595000
phase=2636,33000,1080000
phase=3512,33000,2790000
phase=4364,33000,4410000
phase=5205,33000,4950000
phase=6948,33000,10620000
phase=8624,33000,18000000
phase=10288,33000,31410000
phase=13703,20000,91800000
phase=17027,15000,154800000
phase=20310,15000,190224368
phase=25000,10000,360000000

???

[wombatman]

Random question, but shouldn't

kBitMap = (uint8_t *) malloc((size_t) 1 + (maxK - minK + 1 / 8));

be

kBitMap = (uint8_t *) malloc((size_t) 1 + ((maxK - minK + 1) / 8));

It hasn't caused any issues so far that I've seen, so maybe it doesn't matter, but I just wanted to make sure.

[KEP]

Originally Posted by MyDogBuster

I may as well jump in here.
I'm trying S3 from 1G to 1.1G

Got my newpgen files to n=23

Have latest pfgw 3.7.10
Have srsieve
Have srbsieve dated 8/15/15

SRBsieve started and removed from all 23 files
I then got the message

Started recovery at Phase 0 with 4247788 terms
ERROR m 1e10: argument out of range

My ini file looks like:

base=3
mink=1000000001
maxk=1100000000
c=1
npgfile=1,n1.log
npgfile=2,n2.log
npgfile=3,n3.log
npgfile=4,n4.log
npgfile=5,n5.log
npgfile=6,n6.log
npgfile=7,n7.log
npgfile=8,n8.log
npgfile=9,n9.log
npgfile=10,n10.log
npgfile=11,n11.log
npgfile=12,n12.log
npgfile=13,n13.log
npgfile=14,n14.log
npgfile=15,n15.log
npgfile=16,n16.log
npgfile=17,n17.log
npgfile=18,n18.log
npgfile=19,n19.log
npgfile=20,n20.log
npgfile=21,n21.log
npgfile=22,n22.log
npgfile=23,n23.log
phase=100,33000,70000
phase=335,33000,140000
phase=674,33000,315000
phase=898,33000,552500
phase=1120,33000,425000
phase=1792,33000,977500
phase=2240,33000,595000
phase=2636,33000,1080000
phase=3512,33000,2790000
phase=4364,33000,4410000
phase=5205,33000,4950000
phase=6948,33000,10620000
phase=8624,33000,18000000
phase=10288,33000,31410000
phase=13703,20000,91800000
phase=17027,15000,154800000
phase=20310,15000,190224368
phase=25000,10000,360000000

???

I'm using PFGW 3.7.9
srbsieve dated 15 august 2015 (latest version)

and this is how my ini looks:

base=3
mink=1000000001
maxk=1100000000
c=1
npgfile=1,1_.log
npgfile=2,2_.log
npgfile=3,3_.log
npgfile=4,4_.log
npgfile=5,5_.log
npgfile=6,6_.log
npgfile=7,7_.log
npgfile=8,8_.log
npgfile=9,9_.log
npgfile=10,10_.log
npgfile=11,11_.log
npgfile=12,12_.log
npgfile=13,13_.log
npgfile=14,14_.log
npgfile=15,15_.log
npgfile=16,16_.log
npgfile=17,17_.log
npgfile=18,18_.log
npgfile=19,19_.log
npgfile=20,20_.log
npgfile=21,21_.log
npgfile=22,22_.log
npgfile=23,23_.log
phase=100,33000,70000
phase=335,33000,140000
phase=674,33000,315000
phase=898,33000,552500
phase=1120,33000,425000
phase=1792,33000,977500
phase=2240,33000,595000
phase=2636,33000,1080000
phase=3512,33000,2790000
phase=4364,33000,4410000
phase=5205,33000,4950000
phase=6948,33000,10620000
phase=8624,33000,18000000
phase=10288,33000,31410000
phase=13703,20000,91800000
phase=17027,15000,154800000
phase=20310,15000,190224368
phase=25000,10000,360000000

I doesn't get the message that you get MyDogBuster. However you also has more candidates in your recovery count, than should excist after n=23 is removed. Did you stop srbsieve?

After having removed from n=1 to n=23, I have 3998517 candidates remaining and srbsieve starts processing those without problems.

Could you try and run the range with my .ini settings and see if it does make a difference?

Could you try and run it in a new folder where srbsieve and pfgw aswell srsieve has full rights and see if that makes a difference?

[MyDogBuster]

After having removed from n=1 to n=23, I have 3998517 candidates remaining and srbsieve starts processing those without problems.

Could you try and run the range with my .ini settings and see if it does make a difference?
After having removed from n=1 to n=23, I have 3998517 candidates remaining and srbsieve starts processing those without problems.

Could you try and run the range with my .ini settings and see if it does make a difference?

Could you try and run it in a new folder where srbsieve and pfgw aswell srsieve has full rights and see if that makes a difference?

I too had 3998517 candidates remaining. (read the wrong number)

Ran with your ini and got the same error

All programs have full rights.

I'm not familiar with pfgw. Does it need an ini file?

[KEP]

Originally Posted by MyDogBuster

I'm not familiar with pfgw. Does it need an ini file?

This is weird. I'm all out of ideas. PFGW64 (I recon that you use 64 bit) should not need an ini file (created by you) to run, srbsieve should handle all the settings, according to your srbsieve.ini file.

I just completed the same test, using PFGW 3.7.10 and still no errors. What puzzles me is that srbsieve seems to write a checkpoint file before fininshing removing n=21, n=22 and n=23 from the NewPGen files.

Maybe it is a good idea to post your srbsieve.ckpt file, it may mean something to Rogue

[MyDogBuster]

Maybe it is a good idea to post your srbsieve.ckpt file, it may mean something to Rogue

chpt file looks like this

phase=1
completedStep=3
completedMaxK=1001653986
completedKCount=33000
inProgressKCount=33000