srsieve/sr2sieve enhancements

[rogue]

Originally Posted by Gelly

Did what you suggested. Still no dice for srsieve2cl. It seems like most of the other cl sievers work just fine with OpenCL, though I did not make a decimal file for pixsievecl to test with.

Here's another example where I start sieving on a random sequence, leading me to believe it's not a sequence problem, neither:

../srsieve2cl -G 1 -P 1e13 -n 1000 -N 1500 -s "2564*2345^n+1"
srsieve2cl v1.5.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with generic logic for p >= 3
Creating CPU worker to use until p >= 1000000
GPU primes per worker is 56320
Sieve started: 3 < p < 1e13 with 501 terms (1000 < n < 1500, k*2345^n+c) (expecting 482 factors)
Sieving one sequence where abs(c) = 1 for p >= 2564
Split 1 base 2345 sequence into 11 base 2345^30 sequences.
552614 bytes used for congruence tables
376119 bytes used for Legendre tables
Creating CPU worker to use until p >= 1000000
*** buffer overflow detected ***: terminated
Aborted (core dumped)

Are you able to debug? Getting a stack trace might help me track down the issue.

[Gelly]

Originally Posted by rogue

Are you able to debug? Getting a stack trace might help me track down the issue.

(gdb) run
Starting program: /home/gelly/Math/mtsieve/mtsieve-svn/srsieve2cl -P 5e13 -o candy.cand -i candy2.cand -f A -W 4 -G 1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffde917640 (LWP 206402)]
[New Thread 0x7fffde116640 (LWP 206403)]
[New Thread 0x7fffdd915640 (LWP 206404)]
[New Thread 0x7fffdd114640 (LWP 206405)]
[New Thread 0x7fffdc913640 (LWP 206406)]
[New Thread 0x7fffd1fff640 (LWP 206407)]
[New Thread 0x7fffd17fe640 (LWP 206408)]
srsieve2cl v1.5.2, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving one sequence where abs(c) = 1 for p >= 31162066292659
Split 1 base 13 sequence into 19 base 13^120 sequences.
551218 bytes used for congruence tables
351 bytes used for Legendre tables
[New Thread 0x7fffd0ffd640 (LWP 206409)]
[New Thread 0x7fffd07fc640 (LWP 206410)]
[New Thread 0x7fffcfffb640 (LWP 206411)]
[New Thread 0x7fffcf7fa640 (LWP 206412)]
[New Thread 0x7fffceff9640 (LWP 206413)]
*** buffer overflow detected ***: terminated

Thread 1 "srsieve2cl" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) backtrace
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x00007ffff7a74864 in __GI_abort () at abort.c:79
#2  0x00007ffff7ad7af6 in __libc_message (action=action@entry=do_abort, 
    fmt=fmt@entry=0x7ffff7bfeedf "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7b7779a in __GI___fortify_fail (msg=msg@entry=0x7ffff7bfee85 "buffer overflow detected") at fortify_fail.c:26
#4  0x00007ffff7b76036 in __GI___chk_fail () at chk_fail.c:28
#5  0x00007ffff7acf99f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
#6  0x00007ffff7adc594 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>)
    at libioP.h:948
#7  __GI__IO_default_xsputn (f=0x7fffffffd7b0, data=<optimized out>, n=50) at genops.c:370
#8  0x00007ffff7ac2846 in outstring_func (done=0, length=50, 
    string=0x5555555963e0 "#define HAVE_LEGENDRE_TABLES\n#define LEGENDRE_MOD %u\n", s=0x7fffffffd7b0)
    at ../libio/libioP.h:948
#9  __vfprintf_internal (s=s@entry=0x7fffffffd7b0, 
    format=format@entry=0x5555555963e0 "#define HAVE_LEGENDRE_TABLES\n#define LEGENDRE_MOD %u\n", 
    ap=ap@entry=0x7fffffffd8f0, mode_flags=mode_flags@entry=6) at vfprintf-internal.c:1404
#10 0x00007ffff7acfa49 in __vsprintf_internal (
    string=0x7fffffffde10 "#define HAVE_LEGENDRE_TABLES\n#define LEGENDRE_MOD\220\fVUU", maxlen=<optimized out>, 
    format=0x5555555963e0 "#define HAVE_LEGENDRE_TABLES\n#define LEGENDRE_MOD %u\n", args=args@entry=0x7fffffffd8f0, 
    mode_flags=6) at iovsprintf.c:95
#11 0x00007ffff7b75b1f in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, 
    format=<optimized out>) at sprintf_chk.c:40
#12 0x000055555558c335 in CisOneWithOneSequenceGpuWorker::Prepare(unsigned long, unsigned int) ()
#13 0x0000555555588d8a in CisOneWithOneSequenceHelper::CreateWorker(unsigned int, bool, unsigned long) ()
#14 0x000055555555f207 in App::CreateWorkers(unsigned long) ()
#15 0x00005555555604a7 in App::Run() ()
#16 0x000055555555d8ec in main ()

gdb stack trace work? Otherwise, I am not opposed to a better suggestion.

[rogue]

That is exactly what I needed. I'm fairly certain the issue is a char array that isn't long enough to hold what the code is trying to stuff into it. I have committed a change. Let me know if that resolves the issue. Obviously the other OSes I have tested this on don't detect this condition.

I will put a new Windows build on sourceforge if anyone needs me to do that.

[Gelly]

Originally Posted by rogue

That is exactly what I needed. I'm fairly certain the issue is a char array that isn't long enough to hold what the code is trying to stuff into it. I have committed a change. Let me know if that resolves the issue. Obviously the other OSes I have tested this on don't detect this condition.

I will put a new Windows build on sourceforge if anyone needs me to do that.

Works perfectly! The OS is Ubuntu 20.10 (Groovy Gorilla?), and it does not surprise me that it's causing hangups for this, since it also has a recent issue that leaves it unable to compile yafu. Will have to reconsider the OS I use, then.

Thanks much for your time!

[bur]

Originally Posted by rogue

Attached is sr1sieve 1.4.7. The major change is for non-x86 users. It will now work for p up tp 2^64 whereas it was limited to 2^52 previously. Based upon a few tests it is actually only about 5% slower than when running with the 64-bit ASM routines.

That means it's 5% slower but allows for p up to 2^64? So if I don't need such large p, I'd better use the older version? Or is it only slower if you actually use p > 2^52?

[sweety439]

Can someone remove srsieve divisible by 2 check? I want to prove the extended Sierpinski/Riesel problems (Finding and proving the smallest k such that (k*b^n+-1)/gcd(k+-1,b-1) (+ for Sierpinski, - for Riesel) is not prime for all integers n>=1), these Sierpinski/Riesel conjectures extended the CRUS Sierpinski/Riesel conjectures to the k such that gcd(k+-1,b-1) (+ for Sierpinski, - for Riesel) is not 1, since k*b^n+-1 is always divisible by gcd(k+-1,b-1), it is simply to take out this factor, however, I cannot use srsieve to sieve the case which k and b are both odd (e.g. it returns ERROR: 13*43^n-1: every term is divisible by 2" for R43 k=13), it can only sieve the case which at least one of k and b are even (e.g. sieve file for R36), can someone remove srsieve divisible by 2 check to let me sieve and reserve the odd Sierpinski/Riesel bases (e.g. S3, currently S3 has these k's remaining: 1187, 1801, 3007, 3047, 3307, 5321, 5743, 5893, 6427, 6569, 6575, 7927, 8161, 8227, 8467, 8609, 8863, 8987, 9263, 9449, see https://docs.google.com/document/d/e/2PACX-1vSQlPrWZgVM1g5spyMs_USkKy3XEGcBsadeLc82JmQVbXCOWbbcSkuHMtO_EmspQME3ITGNvoCcffZt/pub)?

[rogue]

Originally Posted by bur

That means it's 5% slower but allows for p up to 2^64? So if I don't need such large p, I'd better use the older version? Or is it only slower if you actually use p > 2^52?

If you have a GPU, I suggest that you use srsieve2cl instead of sr1sieve. I have a midrange GPU and it is up to 5x faster than sr1sieve.

As for sr1sieve 1.4.7, I don't recall. I think that if you compile with asm routines it will only work up to 2^52. If you compile without asm routines it will work up to 2^64, but be 5% slower overall. I don't think that I coded it to switch from asm to non-asm code at 2^52, but I could be wrong.

[rogue]

Originally Posted by sweety439

Can someone remove srsieve divisible by 2 check? I want to prove the extended Sierpinski/Riesel problems (Finding and proving the smallest k such that (k*b^n+-1)/gcd(k+-1,b-1) (+ for Sierpinski, - for Riesel) is not prime for all integers n>=1), these Sierpinski/Riesel conjectures extended the CRUS Sierpinski/Riesel conjectures to the k such that gcd(k+-1,b-1) (+ for Sierpinski, - for Riesel) is not 1, since k*b^n+-1 is always divisible by gcd(k+-1,b-1), it is simply to take out this factor, however, I cannot use srsieve to sieve the case which k and b are both odd (e.g. it returns ERROR: 13*43^n-1: every term is divisible by 2" for R43 k=13), it can only sieve the case which at least one of k and b are even (e.g. sieve file for R36), can someone remove srsieve divisible by 2 check to let me sieve and reserve the odd Sierpinski/Riesel bases (e.g. S3, currently S3 has these k's remaining: 1187, 1801, 3007, 3047, 3307, 5321, 5743, 5893, 6427, 6569, 6575, 7927, 8161, 8227, 8467, 8609, 8863, 8987, 9263, 9449, see https://docs.google.com/document/d/e/2PACX-1vSQlPrWZgVM1g5spyMs_USkKy3XEGcBsadeLc82JmQVbXCOWbbcSkuHMtO_EmspQME3ITGNvoCcffZt/pub)?

I believe that srsieve2 will work as you desire. If you run into a bug, then I will look into it.

I have no interest in modifying srsieve to support this request.