[QUOTE=rogue;523869]If you use one of these commands: "make twinsieve", "make srsieve2", or
"make xyyxsieve", what happens?[/QUOTE]

make twinsieve works ok and produce twinsieve, and also xyyxsieve



make srsieve2


make srsieve2
make: *** No rule to make target 'sierpinksi_riesel/SierpinskiRieselApp.o', needed by 'srsieve2'. Stop.

[QUOTE=Dylan14;523870]Not sure if this is a bug or not, but I am trying to sieve the gap


[CODE]n 4900-4999 7e8-10e8[/CODE]in gfndsieve for someone to test for the FermatSearch. However, it seems that gfndsieve is having a bit of trouble with this range:

(some output involving term numbers not matching)
[/QUOTE]


I figured the problem out. The sieve has to start as a single thread process and then after the initial sieve is done, then multiple threads can be used.

[QUOTE=pepi37;523872]make twinsieve works ok and produce twinsieve, and also xyyxsieve



make srsieve2


make srsieve2
make: *** No rule to make target 'sierpinksi_riesel/SierpinskiRieselApp.o', needed by 'srsieve2'. Stop.[/QUOTE]

Sorry, but that is due to a misspelling in the path. I correctly the misspelling of the folder name, but didn't save the change to the makefile. It should be "sierpinski_riesel" not "sierpinksi_riesel" in the makefile. Fix that and you should be able to build.

[QUOTE=Dylan14;523877]I figured the problem out. The sieve has to start as a single thread process and then after the initial sieve is done, then multiple threads can be used.[/QUOTE]

A number of sieves, due to the high percentage of terms removed with the initial block of primes, only run a single thread for that block an in effort to avoid some of of the throttling that occurs when multiple threads try to access the same memory.

To get to multiple threads more quickly, use -w to specify smaller chunks of primes.

I posted version 1.9.5 of the framework. The only change is that I fixed the factor rate calculation.

[QUOTE=rogue;524767]I posted version 1.9.5 of the framework. The only change is that I fixed the factor rate calculation.[/QUOTE]

I ran make and found:

#include "CIsOneSubsequenceHelper.h" - the correct file name is CisOneSubsequenceHelper.h

dm_divisor/DMDivisorApp.cpp
gfn_divisor/GFNDivisorApp.cpp
fixed_bnc/FixedBNCApp.cpp
fixed_kbn/FixedKBNApp.cpp
kbb/KBBApp.cpp
sierpinski_riesel/SierpinskiRieselApp.cpp
twin/TwinApp.cpp
ALL have wrong permissions (I had to chmod 666 to them)

core/../opencl/Device.h:19:13: fatal error: CL/cl.h: File or directory not existing
And setting ENABLE_GPU=no does not work either.

Luigi

[QUOTE=ET_;524782]I ran make and found:

#include "CIsOneSubsequenceHelper.h" - the correct file name is CisOneSubsequenceHelper.h

dm_divisor/DMDivisorApp.cpp
gfn_divisor/GFNDivisorApp.cpp
fixed_bnc/FixedBNCApp.cpp
fixed_kbn/FixedKBNApp.cpp
kbb/KBBApp.cpp
sierpinski_riesel/SierpinskiRieselApp.cpp
twin/TwinApp.cpp
ALL have wrong permissions (I had to chmod 666 to them)

core/../opencl/Device.h:19:13: fatal error: CL/cl.h: File or directory not existing
And setting ENABLE_GPU=no does not work either.

Luigi[/QUOTE]

I'll fix that spelling. Windows doesn't care but OS X and Linux do.

Since the .7z file is created on Windows, I don't know how its permissions correspond to permissions on Linux.

The ENABLE_GPU flag is removed from the makefile. If you have a GPU, then you will need to install an OpenCL SDK. You also might need to modify the GPUCPPFLAGS and GPULDFLAGS in the makefile.

If you do not have a GPU, then use "make cpu_all". It will no build the OpenCL versions of the exes.

[QUOTE=rebirther;523871][CODE]n:\riesel-base537 - Kopie>srsieve2 -n2501 -N10000 -P1e9 -spl_remain.txt -fB
srsieve2 v1.1, a program to find factors of k*b^n+c numbers for fixed b and vari
able k and n
Fatal Error: srsieve2: invalid argument -f B[/CODE][/QUOTE]

That's because 'B' is missing from line 114 of SierpinskiRieselApp.cpp:

[CODE]status = Parser::Parse(arg, "ADP", value);[/CODE]

Is base 2 one of the slow bases for srsieve2? I tested 1467763*2^n-1, with n between 1.2e6 and 1.3e6, to P=1e9. srsieve took about [COLOR="Red"]141 seconds[/COLOR]. Here's the srsieve2 output:

[QUOTE]srsieve2 v1.1, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with generic logic
Sieve started: 2 < p < 1e9 with 100001 terms (1200000 < n < 1300000, k*2^n+c) (expecting 96656 factors)
Sieving with generic logic
Sieving with generic logic
p=868205083, 244.8K p/sec, 96449 factors found at 1.884 f/sec, 86.8% done. ETC 2019-08-30 22:02
Sieve completed at p=1000000009.
Processor time: 207.48 sec. (0.64 sieving) (1.00 cores)
3534 terms written to b2_n.abcd
Primes tested: 49847480. Factors found: 96467. Remaining terms: 3534. Time: [COLOR=red]208.32 seconds[/COLOR].[/QUOTE]

Multiple threads did yield much better results.

Also, in the same file, lines 528 and 530 should have newlines at the ends of the format strings. Right now, the first term is printed on the same line as the BOINC header.

[QUOTE=Happy5214;524883]That's because 'B' is missing from line 114 of SierpinskiRieselApp.cpp:

[CODE]status = Parser::Parse(arg, "ADP", value);[/CODE]

Is base 2 one of the slow bases for srsieve2? I tested 1467763*2^n-1, with n between 1.2e6 and 1.3e6, to P=1e9. srsieve took about [COLOR="Red"]141 seconds[/COLOR].[/QUOTE]

I'll add the missing 'B' and newlines

I have no explanation at this time for the time difference between the two. I suspect is has to do with cache hits and misses because they use the same logic, albeit implemented slightly differently. srsieve2 uses vector<bool> while srsieve uses a bitmap. vector<bool> uses a byte per bit, so that could be the reason. I could play around with changing that to see the impact.

BTW, here are the results on my lnew 6-core l7 laptop:

[code]
srsieve -n1200000 -N1300000 -P1e9 1467763*2^^n-1
srsieve 1.1.4 -- A sieve for integer sequences in n of the form k*b^n+c.
srsieve started: 1200000 <= n <= 1300000, 3 <= p <= 1000000000
Split 1 base 2 sequence into 1 base 2^4 subsequence.
p=557271703, 9296228 p/sec, 96371 terms eliminated, 3630 remain
Sieving 3 <= p <= 1000000000 eliminated 96467 terms, 3534 remain.
Wrote 3534 terms for 1 sequence to srsieve format file `srsieve.out'.
srsieve stopped: at p=1000000000 because --pmax was reached.
Processor time: [COLOR="Red"]104.00[/COLOR] sec

srsieve2 -n1200000 -N1300000 -P1e9 -s1467763*2^^n-1
srsieve2 v1.1, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with generic logic
Sieve started: 2 < p < 1e9 with 100001 terms (1200000 < n < 1300000, k*2^n+c) (expecting 96656 factors)
Sieving with generic logic
Sieving with generic logic
p=502635611, 419.7K p/sec, 96350 factors found at 1.612K f/sec, 50.3% done. ETC 2019-09-01 08:59
Sieve completed at p=1000000009.
Processor time: 114.41 sec. (0.28 sieving) (0.98 cores)
3534 terms written to b2_n.abcd
Primes tested: 49847480. Factors found: 96467. Remaining terms: 3534. Time: [COLOR="red"]116.21[/COLOR] seconds.
[/code]

It's still slower, but not by as much as your run.

Could this be cache size differences? Does srsieve2 adjust for different size caches?