[QUOTE=wombatman;466286]If you have Windows 10, it will build in the Ubuntu shell with
[CODE]g++ nsieve64.cpp -o nsieve64[/CODE]

And testing with
[CODE]./nsieve64 -s 6209,800000000,800000001 -N 6299 -o nsieve64_testoutput.txt -p 2,1000000000000[/CODE]

seems to be working. One note: you cannot currently use abbreviated inputs like 1e12; they must be typed out fully.[/QUOTE]

I recommend building with this:

g++ -O3 -m64 nsieve64.cpp -lstdc++ -o nsieve

It is currently slower than fermfact, but I found one optimization that seems to make it faster for multiple n, but I need to run some side-by-side comparisons with fermfact. If someone can build and compare with newpgen (for a single n), that would be great. Note that newpgen stops automatically when p > sqrt(maxk*2^n+1). nsieve does not stop automatically.

I also intend to modify nsieve to be multi-threaded, but I'm concerned about the performance it could take.

I just ran one test. nsieve and newpgen do not produce the same outputs. I assume that nsieve must have some bugs in it. That will take time to resolve.

Yeah, I was just about to post the same thing. Using n=30 with k=8e8-800000500, I get 12 candidates remaining from newpgen. Nsieve's last output on screen shows 8 remaining, and the output file has the proper header and then nothing else.

I got empty output from your build Rogue

[QUOTE=pepi37;466290]I got empty output from your build Rogue[/QUOTE]

It isn't my code. I'm trying to find contact information for Ken Brazier as he wrote it although I might be able to debug without his help.

It appears to be a miscompile on Windows with mingw. The outputs on my Mac are different and appear to be correct, although I haven't run any comparisons.

Are you able to compile it on a Linux system at all and confirm whether it mismatches?

[QUOTE=rogue;466377]It appears to be a miscompile on Windows with mingw. The outputs on my Mac are different and appear to be correct, although I haven't run any comparisons.[/QUOTE]

The first test I ran shows non-matching output on my Mac. I don't think this is a miscompile. It is either bad assembly code or the prime sieve is missing primes.

nsieve is only for base 2, so it isn't too helpful for this project.

I ran into an issue with srbsieve. When it breaks up large ranges for PRP testing it is skipping some of those ranges. I don't how that is happening, but I'm looking into it.

This means that if you did a large range of k with srbsieve it is likely that some of the k in pl_remain.txt have a prime for n < 25000. This has a definite impact on R3 and S3, but I can't speak for other bases. If you have used srbsieve then you should run from n=1 to 25000 for the k in pl_remain.txt to find any primes that it missed. There are no issues with the numbers in pl_prime.txt. They will be prime. Unfortunately this is going to create a lot of work for me due to the work I have done on S3.

Hopefully I will have time between Christmas and New Year's to track down the problem and fix it.

Does this problem concern all versions of srbsieve or only those that did checkpoint and allowed to resume? I used for my R3 ranges, the version that did not support stopping and starting again - in other words no resume was allowed.