update to the previous post
 

I have figured how to allow cksieve to take 1 as an argument for the -n flag without the error described in the previous post. This requires only one change to the CarolKyneaApp.cpp file. Instead of

[CODE]status = Parser::Parse(arg, 2, 1000000000, ii_MinN);[/CODE]replace it with

[CODE]status = Parser::Parse(arg, 1, 1000000000, ii_MinN);[/CODE] within the switch (opt) block in CarolKyneaApp::ParseOption and then run make to regenerate the executables.
With this change I ran the following input:
[CODE]cksieve -P1e9 -n 1 -N50000 -b50[/CODE]which worked perfectly and I got a sieve file with 18924 terms in it, the same as I got with cksieve v1.1.4.

That is the fix, but an additional change is needed. For small bases, n=1 with c=-1 yields a negative number, so those need to be excluded.

The next release will have GPU support for afsieve. My fingers are crossed that compiling and linking OpenCL with mingw works. It took me a while to figure out how to get mingw objects to link with the OpenCL library. It now links. The question is, does it run without crashing.

I have released version 1.2 of the framework.

[code]
fkbnsieve is now working.
Modify cksieve to detect candidates that are prime and to log them.
Fixed an asm bug that at worst causes factors to be missed by
fbncsieve and gfndsieve. It will nor result in invalid factors and
if it did, they would be caught at runtime due to built-in factor
checking that relies on completely different code.

Added -A option to apply factors (or reformat candidate file) and exit immdiately without sieving.
Added GPU classes. This adds the following command line options:
-D - to select the GPU platform
-d - to select the GPU device
-G - to specify the number of GPU workers
-g - to set multiple of workgroupsize which is used to compute the number of primes per GPU worker
Added GPU workers to afsieve.
[/code]

Visit my page to get the link to d/l the latest source and Windows builds.

There are a some things I need to do. First, I need to implement factor validation for the afsieve GPU worker. Second, the build on OS X is broken because getrusage doesn't have the same capabilities on OS X as it does on Linux.

I have not tested the -A option, but if it doesn't work, it should be easy to fix.

I need help from Linux developers to determine the correct settings for compiling and linking with OpenCL.

Here are some notes on using the GPU:[list][*]When you use the GPU enabled sievers, t is strongly recommended that you play with the -g and -G options when using a GPU to determine the optimal settings for your hardware.[*]You can have a mix of CPU and GPU workers. The default right now is to always have 1 CPU worker even if you have GPU workers, but there is nothing to prevent you from using -W4 -G4 to create 8 workers, 4 for the CPU and 4 for the GPU. This is an incredibly cool and powerful feature that I have not supported in any of my previous sieving programs.[/list]

Thanks for fixing the -n issue and the removal of candidates that result in unity, zero or negative unity in cksieve. However I have run into another bug - when I put this as input:

[CODE]cksieve -P150e9 -n 1 -N10000 -b214 -W 4[/CODE]it runs for a while until it terminates with the following message:

[CODE]Fatal Error: 393216 is not a root (mod 77309411329)[/CODE]In cksieve v1.1.4 it didn't terminate when this happened, but it would give out a warning, like this:

[CODE]WARNING: 393216 is not a root (mod 77309411329)[/CODE]and then continue onward to the desired sieve depth (in this case 150e9).

[QUOTE=Dylan14;480889]Thanks for fixing the -n issue and the removal of candidates that result in unity, zero or negative unity in cksieve. However I have run into another bug - when I put this as input:

[CODE]cksieve -P150e9 -n 1 -N10000 -b214 -W 4[/CODE]it runs for a while until it terminates with the following message:

[CODE]Fatal Error: 393216 is not a root (mod 77309411329)[/CODE]In cksieve v1.1.4 it didn't terminate when this happened, but it would give out a warning, like this:

[CODE]WARNING: 393216 is not a root (mod 77309411329)[/CODE]and then continue onward to the desired sieve depth (in this case 150e9).[/QUOTE]

I changed the behavior because this might be a bug, but I need to investigate. I'll look into restoring the old behavior.

fbncsieve bug
 

If you continue sieve from file ( sieve depth for example 50000000) you cannot use switches -p 1000000000000 -P 2000000000000 becauseprogram will still start from 50000000.
So if you have few workers threads you must change header line in a file for right sieve range

[QUOTE=pepi37;480983]If you continue sieve from file ( sieve depth for example 50000000) you cannot use switches -p 1000000000000 -P 2000000000000 becauseprogram will still start from 50000000.
So if you have few workers threads you must change header line in a file for right sieve range[/QUOTE]

I think I know the cause.

I have a machine with 2x [url=https://ark.intel.com/products/75789/Intel-Xeon-Processor-E5-2620-v2-15M-Cache-2_10-GHz]Intel Xeon E5-2620 v2[/url]. Which are 12 cores or 24 threads. When I tried to run cksieve version 1.2, I first received an error about a missing OpenCL.dll library.

After installing the [url=https://software.intel.com/en-us/articles/opencl-drivers]OpenCL Runtime[/url] version 16.1.2, it no longer crashes, but it notes it is not able to find a suitable device.

[code]
C:>cksieve.exe
List of available platforms and devices
Platform 0 is a Intel(R) Corporation Intel(R) OpenCL, version OpenCL 1.2
No devices
Fatal Error:
No devices were found that can run this code
[/code]

Reading the release notes of the runtime, the Xeon E5's are supported; as long as they support SSE4.2 or above. Which this particular cpu does.

[QUOTE=BotXXX;481871]I have a machine with 2x [url=https://ark.intel.com/products/75789/Intel-Xeon-Processor-E5-2620-v2-15M-Cache-2_10-GHz]Intel Xeon E5-2620 v2[/url]. Which are 12 cores or 24 threads. When I tried to run cksieve version 1.2, I first received an error about a missing OpenCL.dll library.

After installing the [url=https://software.intel.com/en-us/articles/opencl-drivers]OpenCL Runtime[/url] version 16.1.2, it no longer crashes, but it notes it is not able to find a suitable device.

[code]
C:>cksieve.exe
List of available platforms and devices
Platform 0 is a Intel(R) Corporation Intel(R) OpenCL, version OpenCL 1.2
No devices
Fatal Error:
No devices were found that can run this code
[/code]

Reading the release notes of the runtime, the Xeon E5's are supported; as long as they support SSE4.2 or above. Which this particular cpu does.[/QUOTE]

If you can build, then change this line in the makefile:

ENABLE_GPU=yes

to

ENABLE_GPU=no

I haven't tested a build with that set to no, but it might solve your problem.

In any case that it requires a "device" at runtime is a bug. I have fixed it, but not posted an update.

You can d/l the previous build from [URL="http://www.mersenneforum.org/rogue/mtsieve_1.1.7z"]here[/URL].

Thank you Mark for the 1.1 build .7z. That one works ok.

As example:
[code]C:>cksieve -b 2 -p 2 -P 1000000 -n 100 -N 10000 -o ck_remain.out -O ck_factors.out
cksieve v1.2, a program to find factors of (b^n+/-1)^2-2 numbers
Sieve started: 2 < p < 1e6 with 19802 terms
Sieve completed at p=1000033.
Processor time: 0.36 sec. (0.02 sieving) (0.61 cores)
3750 terms written to ck_remain.out
Primes tested: 39222. Factors found: 16052. Remaining terms: 3750. Time: 0.59 seconds.
[/code]

Once nice feature with mtsieve is that when starting a new sieve you don't need to specify -p. For many you probably don't want to use -P either and you just wait for the removal rate to reach what you need before you start PRP testing. Also many of the programs will generate an output file name if you don't specify one and that file name will often include information that makes it unique based upon the inputs.

And of course you can use scientific notation for most inputs that are numeric. Who wants to type --P1000000000000 when -P1e12 doesn't require you to count zeros?