Inconsistent factors with TPSieve

Caldera · 2013-01-05, 00:48

The other day I was benchmarking tpsieve from Ken’s website (https://sites.google.com/site/kenscode/prime-programs), comparing it to TwinGenX and NewPGen when I noticed the factors returned across a specific range were not matching up.

I tested the same file from 300e12 -> 301e12 and got the following results:
tpsieve-x86_64-windows (0.3.4): 81 factors
tpsieve-x86-windows (0.3.4): 65 factors
tpsieve-x86-windows-sse2 (0.3.4): 65 factors
tpsieve-x86_64-linux (0.3.4): 65 factors
TwinGenX and NewPGen: 65 factors

The 81 factors returned in tpsieve-x86_64-windows build do not correspond to any of the 65 factors found in the other programs. I first doubled checked that the range was the same, then I re-ran the test on a different computer, same result, 81 factors. Settings for each tpsieve test were the same: -i sievefile.npg -f factors.txt -p300e12 -P301e12

I tried to run the CUDA version (0.2.3b), but it would not run. The sieve file is a single-N range and TPSieveCUDA does not recognize it as such and tries to use nstep=19 and errors out with: "Error: pmin is not large enough (or nmax is close to nmin)." Another problem for another time though.

Anyways, has anyone else encountered a problem with the Windows 64-bit version of tpsieve? Is it a known problem?

Below is the first 10 factors found in each case:

tpsieve-x86_64-windows (10 of 81):
300008129931487 | 756912651*2^8981107-1
300013573230403 | 528949251*2^8981107-1
300014559752093 | 189672825*2^8981107-1
300015309702781 | 807274875*2^8981107+1
300025597993207 | 66374709*2^8981107+1
300037414313999 | 434207019*2^8981107+1
300043273991507 | 557597889*2^8981107+1
300060711822647 | 18579561*2^8981107+1
300068825040863 | 488675301*2^8981107-1
300079216280653 | 804859845*2^8981107-1

Other progams (10 of 65):
300026676368483 | 101574279*2^8981107+1
300034808011357 | 998363865*2^8981107+1
300072443511661 | 538128849*2^8981107+1
300073736551423 | 678032145*2^8981107-1
300118099137613 | 90125811*2^8981107-1
300125600487773 | 219409815*2^8981107-1
300132050329037 | 369381441*2^8981107-1
300141747737681 | 296100189*2^8981107-1
300183047551363 | 613480125*2^8981107+1
300188175547943 | 619793139*2^8981107-1

Ken_g6 · 2013-01-05, 01:11

Oh, no, not the 64-bit Windows build again! Well, I do have access to a computer with 64-bit Windows now, so I might be able to look into it. I don't (think I) build the Windows 64-bit builds, and last time there was a problem it involved a beta version of a compiler.

Unless someone else is interested in compiling the binary with 64-bit MinGW on 64-bit Windows?

Edit: Have you tried this binary? It may be the BOINC build, but I think it should work almost the same.

JimB · 2013-01-05, 01:12

Just so you know, none of the factors for tpsieve-x86_64-windows that you list are valid:

C:\>check-factors <tpsieve-x86_64-windows >nul
FACTOR DOES NOT DIVIDE: 300008129931487 | 756912651*2^8981107-1
FACTOR DOES NOT DIVIDE: 300013573230403 | 528949251*2^8981107-1
FACTOR DOES NOT DIVIDE: 300014559752093 | 189672825*2^8981107-1
FACTOR DOES NOT DIVIDE: 300015309702781 | 807274875*2^8981107+1
FACTOR DOES NOT DIVIDE: 300025597993207 | 66374709*2^8981107+1
FACTOR DOES NOT DIVIDE: 300037414313999 | 434207019*2^8981107+1
FACTOR DOES NOT DIVIDE: 300043273991507 | 557597889*2^8981107+1
FACTOR DOES NOT DIVIDE: 300060711822647 | 18579561*2^8981107+1
FACTOR DOES NOT DIVIDE: 300068825040863 | 488675301*2^8981107-1
FACTOR DOES NOT DIVIDE: 300079216280653 | 804859845*2^8981107-1

On the other hand, all the factors listed for the other programs ARE valid.

Batalov · 2013-01-05, 02:00

I second that the 64-bit binaries (off of UTM) gave me trouble recently (and srfile threw the resulting factors away), so I fell back on srsieve or newpgen.

EDIT: Actually, it was ppsieve, but the symptom seems to be common. 64-bit builds.

Ken_g6 · 2013-01-05, 03:05

Looks like you both may have gotten old builds of my sieve that were generically compiled badly. I tried the binary I linked to above just now. It wouldn't actually run for a single N, but it would run for two. I didn't let it run long enough to get to the valid factors, but it didn't find any of the early invalid ones.

For now, I have two suggestions. Try running the 32-bit client, which is about 70% as fast as the 64-bit client, and see how long it takes on a range. Then try running the 64-bit binary I linked to with a "-N 8981109" argument. (Not sure if that will work with a sieve file, but if not a single k*2^8981108 entry should be sufficient to keep it running.) I don't *think* that should be any slower than a single N. Edit: Though with a sieve file, double the RAM will be needed.

TPSieve-CUDA does not work well with a single N. Because the CPU has to generate all the prime factors to test, the test is either bandwidth-limited or CPU-limited. I have been considering making a version of TPSieve-CUDA for a single N, which would be about 1/8 as fast as "optimal", but it's entirely vaporware right now.

Caldera · 2013-01-05, 04:36

Thanks Ken_g6. Appreciate the time you spent writing the program and the time looking into the problem.

Using the "-N 8981109" argument did not work with a sieve file.
Appending a "X 8981108" factor to the end of the sieve file did allow it to run, although, being a BOINC build, it is not as verbose so no speed or checkpoint output and no multi-thread support. It was finding the correct factors though. As for the ram, got 16 GB so no worries.

For my 64-bit windows machine, TwinGenX is about 95% as fast as the 64-bit tpsieve on 4 threads, so it will be fine for the time being. And the 64-bit linux build works fine too.

I look forward to any future tpsieve and/or CUDA releases but understand how work, life and other priorities seem to steal time.

Ken_g6 · 2013-01-05, 18:16

Hm, anybody around here have a 64-bit C++ compiler for Windows? I appear to have some old source code on my site that might be faster than TwinGenX for a single N on a single core. It's faster than NewPGen, anyway, when compiled in Linux.

If you have such a compiler, is it available for free online someplace?

rogue · 2013-01-05, 18:32

Quote:

Originally Posted by Ken_g6

Hm, anybody around here have a 64-bit C++ compiler for Windows? I appear to have some old source code on my site that might be faster than TwinGenX for a single N on a single core. It's faster than NewPGen, anyway, when compiled in Linux.

If you have such a compiler, is it available for free online someplace?

I suggest mingw64. The latest version doesn't seem to have the compiling/linking issues that previous versions had. I ran into the same problem with sr2sieve output invalid factors. Once I upgraded mingw64, the problem went away.

2013-01-05, 00:48	#1
Caldera Jan 2013 2 Posts	Inconsistent factors with TPSieve The other day I was benchmarking tpsieve from Ken’s website (https://sites.google.com/site/kenscode/prime-programs), comparing it to TwinGenX and NewPGen when I noticed the factors returned across a specific range were not matching up. I tested the same file from 300e12 -> 301e12 and got the following results: tpsieve-x86_64-windows (0.3.4): 81 factors tpsieve-x86-windows (0.3.4): 65 factors tpsieve-x86-windows-sse2 (0.3.4): 65 factors tpsieve-x86_64-linux (0.3.4): 65 factors TwinGenX and NewPGen: 65 factors The 81 factors returned in tpsieve-x86_64-windows build do not correspond to any of the 65 factors found in the other programs. I first doubled checked that the range was the same, then I re-ran the test on a different computer, same result, 81 factors. Settings for each tpsieve test were the same: -i sievefile.npg -f factors.txt -p300e12 -P301e12 I tried to run the CUDA version (0.2.3b), but it would not run. The sieve file is a single-N range and TPSieveCUDA does not recognize it as such and tries to use nstep=19 and errors out with: "Error: pmin is not large enough (or nmax is close to nmin)." Another problem for another time though. Anyways, has anyone else encountered a problem with the Windows 64-bit version of tpsieve? Is it a known problem? Below is the first 10 factors found in each case: tpsieve-x86_64-windows (10 of 81): 300008129931487 \| 7569126512^8981107-1 300013573230403 \| 5289492512^8981107-1 300014559752093 \| 1896728252^8981107-1 300015309702781 \| 8072748752^8981107+1 300025597993207 \| 663747092^8981107+1 300037414313999 \| 4342070192^8981107+1 300043273991507 \| 5575978892^8981107+1 300060711822647 \| 185795612^8981107+1 300068825040863 \| 4886753012^8981107-1 300079216280653 \| 8048598452^8981107-1 Other progams (10 of 65): 300026676368483 \| 1015742792^8981107+1 300034808011357 \| 9983638652^8981107+1 300072443511661 \| 5381288492^8981107+1 300073736551423 \| 6780321452^8981107-1 300118099137613 \| 901258112^8981107-1 300125600487773 \| 2194098152^8981107-1 300132050329037 \| 3693814412^8981107-1 300141747737681 \| 2961001892^8981107-1 300183047551363 \| 6134801252^8981107+1 300188175547943 \| 6197931392^8981107-1

2013-01-05, 01:11	#2
Ken_g6 Jan 2005 Caught in a sieve 5·79 Posts	Oh, no, not the 64-bit Windows build again! Well, I do have access to a computer with 64-bit Windows now, so I might be able to look into it. I don't (think I) build the Windows 64-bit builds, and last time there was a problem it involved a beta version of a compiler. Unless someone else is interested in compiling the binary with 64-bit MinGW on 64-bit Windows? Edit: Have you tried this binary? It may be the BOINC build, but I think it should work almost the same. Last fiddled with by Ken_g6 on 2013-01-05 at 01:14 Reason: I may have forgotten how I built these binaries - it's been years.

2013-01-05, 02:00	#4
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 9,857 Posts	I second that the 64-bit binaries (off of UTM) gave me trouble recently (and srfile threw the resulting factors away), so I fell back on srsieve or newpgen. EDIT: Actually, it was ppsieve, but the symptom seems to be common. 64-bit builds. Last fiddled with by Batalov on 2013-01-05 at 02:02

2013-01-05, 03:05	#5
Ken_g6 Jan 2005 Caught in a sieve 5×79 Posts	Looks like you both may have gotten old builds of my sieve that were generically compiled badly. I tried the binary I linked to above just now. It wouldn't actually run for a single N, but it would run for two. I didn't let it run long enough to get to the valid factors, but it didn't find any of the early invalid ones. For now, I have two suggestions. Try running the 32-bit client, which is about 70% as fast as the 64-bit client, and see how long it takes on a range. Then try running the 64-bit binary I linked to with a "-N 8981109" argument. (Not sure if that will work with a sieve file, but if not a single k2^8981108 entry should be sufficient to keep it running.) I don't think* that should be any slower than a single N. Edit: Though with a sieve file, double the RAM will be needed. TPSieve-CUDA does not work well with a single N. Because the CPU has to generate all the prime factors to test, the test is either bandwidth-limited or CPU-limited. I have been considering making a version of TPSieve-CUDA for a single N, which would be about 1/8 as fast as "optimal", but it's entirely vaporware right now. Last fiddled with by Ken_g6 on 2013-01-05 at 03:06

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Inconsistent page display	Uncwilly	PrimeNet	8	2014-02-03 01:07
tpsieve-cuda slows down with increasing p	amphoria	Twin Prime Search	0	2011-07-23 10:52
TPSieve CUDA Testing Thread	Ken_g6	Twin Prime Search	52	2011-01-16 16:09
Is TPSieve-0.2.1 faster than Newpgen?	cipher	Twin Prime Search	4	2009-05-18 18:36
Missing factors at the 'Known Factors' page	MatWur-S530113	PrimeNet	11	2009-01-21 19:08

2013-01-05, 01:12	#3
JimB Sep 2012 New Jersey, USA 73₈ Posts	Just so you know, none of the factors for tpsieve-x86_64-windows that you list are valid: C:\>check-factors <tpsieve-x86_64-windows >nul FACTOR DOES NOT DIVIDE: 300008129931487 \| 7569126512^8981107-1 FACTOR DOES NOT DIVIDE: 300013573230403 \| 5289492512^8981107-1 FACTOR DOES NOT DIVIDE: 300014559752093 \| 1896728252^8981107-1 FACTOR DOES NOT DIVIDE: 300015309702781 \| 8072748752^8981107+1 FACTOR DOES NOT DIVIDE: 300025597993207 \| 663747092^8981107+1 FACTOR DOES NOT DIVIDE: 300037414313999 \| 4342070192^8981107+1 FACTOR DOES NOT DIVIDE: 300043273991507 \| 5575978892^8981107+1 FACTOR DOES NOT DIVIDE: 300060711822647 \| 185795612^8981107+1 FACTOR DOES NOT DIVIDE: 300068825040863 \| 4886753012^8981107-1 FACTOR DOES NOT DIVIDE: 300079216280653 \| 8048598452^8981107-1 On the other hand, all the factors listed for the other programs ARE valid.

2013-01-05, 04:36	#6
Caldera Jan 2013 2 Posts	Thanks Ken_g6. Appreciate the time you spent writing the program and the time looking into the problem. Using the "-N 8981109" argument did not work with a sieve file. Appending a "X 8981108" factor to the end of the sieve file did allow it to run, although, being a BOINC build, it is not as verbose so no speed or checkpoint output and no multi-thread support. It was finding the correct factors though. As for the ram, got 16 GB so no worries. For my 64-bit windows machine, TwinGenX is about 95% as fast as the 64-bit tpsieve on 4 threads, so it will be fine for the time being. And the 64-bit linux build works fine too. I look forward to any future tpsieve and/or CUDA releases but understand how work, life and other priorities seem to steal time.

2013-01-05, 18:16	#7
Ken_g6 Jan 2005 Caught in a sieve 5·79 Posts	Hm, anybody around here have a 64-bit C++ compiler for Windows? I appear to have some old source code on my site that might be faster than TwinGenX for a single N on a single core. It's faster than NewPGen, anyway, when compiled in Linux. If you have such a compiler, is it available for free online someplace?