[QUOTE=rogue;526120]This is likely because -w is so large. The problem is that gcwsieve will use a single thread until the first 10000000 primes are tested, which can take a while. [B][COLOR=Red]I should be able to change it to break out of that first chunk earlier so that it can start using multiple threads more quickly.[/COLOR][/B]

The other issue is that gcwsieve is a relatively slow sieve compared to srsieve2 and cksieve. It needs to finish the chunk of 10000000 primes before it terminates (when using ^C). I highly recommend setting -w to a lower value.[/QUOTE]


If you can make that change I would like it.
Thanks

[QUOTE=pepi37;526144]If you can make that change I would like it.[/QUOTE]

I'll look into it.

Hit error one more time, now on twinsieve


[QUOTE]e:\MTSIEVE\TWINSIEVE>twinsieve -P200000000000 -w10000000 -W4 -k3 -K2999999999 -b2 -n3344556 -o BASE2.txt --format=N
twinsieve v1.2, a program to find factors of k*b^n+1/-1 numbers for fixed b and n and variable k
Sieve started: 1 < p < 2e11 with 2999999997 terms (3 < k < 2999999999, k*2^3344556) (expecting 2920087813 factors)
p=163019249773, 32.38M p/sec, 2996251067 factors found at 31.18K f/sec, 81.5% done. ETC 2019-09-21 13:36
Sieve completed at p=200000000041.
Processor time: 1190.44 sec. (94.20 sieving) (2.55 cores)
Fatal Error: Something is wrong. Counted terms (3687541) != expected terms (3690226)[/QUOTE]

There is an error when compiling mtsieve from source. When it gets to compiling srsieve2, it stops here:


[CODE]sierpinski_riesel/SierpinskiRieselApp.cpp:20:10: fatal error: CIsOneSubsequenceHelper.h: No such file or directory
#include "CIsOneSubsequenceHelper.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
makefile:118: recipe for target 'sierpinski_riesel/SierpinskiRieselApp.o' failed
make: *** [sierpinski_riesel/SierpinskiRieselApp.o] Error 1[/CODE]
which is expected since there is no file in the directory called "CIsOneSubsequenceHelper.h". But there exists a file called "CisOneSubsequenceHelper.h". Surely you meant to include that file instead?

[QUOTE=rogue;524981]vector<bool> uses a byte per bit, so that could be the reason. I could play around with changing that to see the impact.
[/QUOTE]

This is not true, vector<bool> is special, it may be implemented as a bit vector, see the documentation here: [url]https://en.cppreference.com/w/cpp/container/vector_bool[/url]. At least 5 years ago it was implemented as a bit vector in all available C++ compilers. The C++ community has not liked this (as this caused issues with iterating over the vector) and I remember that there have been discussions in the past about fixing this (by requiring vector<bool> to be implemented as a byte vector) but I don't know whether this has already been fixed.

If you want a byte vector you should use vector<char>.

Another thing: It appears the OpenCL executables are not working, regardless of whether I use the provided executables or if I compile from source. Case in point: on Windows:


[CODE]C:\Users\Dylan\Desktop\mtsieve\mtsieve>pixsievecl -h

C:\Users\Dylan\Desktop\mtsieve\mtsieve>[/CODE]after executing the command the fan spins up for a second and then it quits without printing anything. This does not change regardless if the OpenCL library is installed or not.



On Linux, using Google Colab, I used the following



[CODE]import os.path
from google.colab import drive

if not os.path.exists('/content/drive/My Drive'):
drive.mount('/content/drive')

%cd '/content/drive/My Drive/mtsieve/mtsieve'
#need gmp for some of the sieves
!ls /usr/lib/x86_64-linux-gnu/
!apt-get install libgmp-dev ocl-icd-libopencl1
!make clean
!make
!./mfsievecl -W 2 -G 1 -P 2e13 -i factorial.pfgw -o factorial.pfgw[/CODE]and it compiled successfully after renaming the offending file. But when it goes to execute the program, it didn't start the sieve.

[QUOTE=Dylan14;526255]There is an error when compiling mtsieve from source. When it gets to compiling srsieve2, it stops here:


[CODE]sierpinski_riesel/SierpinskiRieselApp.cpp:20:10: fatal error: CIsOneSubsequenceHelper.h: No such file or directory
#include "CIsOneSubsequenceHelper.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
makefile:118: recipe for target 'sierpinski_riesel/SierpinskiRieselApp.o' failed
make: *** [sierpinski_riesel/SierpinskiRieselApp.o] Error 1[/CODE]
which is expected since there is no file in the directory called "CIsOneSubsequenceHelper.h". But there exists a file called "CisOneSubsequenceHelper.h". Surely you meant to include that file instead?[/QUOTE]

Some OSes are case sensitive. Others are not. This is probably fixed in sourceforge.

[QUOTE=Dylan14;526284]Another thing: It appears the OpenCL executables are not working, regardless of whether I use the provided executables or if I compile from source. Case in point: on Windows:


[CODE]C:\Users\Dylan\Desktop\mtsieve\mtsieve>pixsievecl -h

C:\Users\Dylan\Desktop\mtsieve\mtsieve>[/CODE]after executing the command the fan spins up for a second and then it quits without printing anything. This does not change regardless if the OpenCL library is installed or not.



On Linux, using Google Colab, I used the following



[CODE]import os.path
from google.colab import drive

if not os.path.exists('/content/drive/My Drive'):
drive.mount('/content/drive')

%cd '/content/drive/My Drive/mtsieve/mtsieve'
#need gmp for some of the sieves
!ls /usr/lib/x86_64-linux-gnu/
!apt-get install libgmp-dev ocl-icd-libopencl1
!make clean
!make
!./mfsievecl -W 2 -G 1 -P 2e13 -i factorial.pfgw -o factorial.pfgw[/CODE]and it compiled successfully after renaming the offending file. But when it goes to execute the program, it didn't start the sieve.[/QUOTE]

I'll look into the Windows build. I cannot speak for other OSes, but it could be the same problem.

[QUOTE=rogue;526309]I'll look into the Windows build. I cannot speak for other OSes, but it could be the same problem.[/QUOTE]
Yes cl version on windows doesnot wok
Just stop and crash

One request fro gfndsieve


gfndsieve as output have pfgw file that is in fact ABCD file ( but not same as ABCD file produces as sr2sieve)
And since gfndsieve is wayyyy faster then sr2sieve, can you add "normal" ABCD output as option , or you have some utility to convert it ?


Your ABCD output


ABCD $a*2^140000+1 [20023] // Sieved to 90076327351
252
36
66



"Normal ABCD "output


ABCD 41067*2^$a+1 [130014] // Sieved to 1000000000 with srsieve
12
22
68
112

[QUOTE=pepi37;526326]One request fro gfndsieve


gfndsieve as output have pfgw file that is in fact ABCD file ( but not same as ABCD file produces as sr2sieve)
And since gfndsieve is wayyyy faster then sr2sieve, can you add "normal" ABCD output as option , or you have some utility to convert it ?


Your ABCD output


ABCD $a*2^140000+1 [20023] // Sieved to 90076327351
252
36
66



"Normal ABCD "output


ABCD 41067*2^$a+1 [130014] // Sieved to 1000000000 with srsieve
12
22
68
112[/QUOTE]

Why do you need this functionality?