I just wrote a new application "Cyclo".
It searches for (probable) primes of the form b^{2^n} - b^{2^{n-1}} + 1.

It is about as fast as Genefer, the "bound" bMax is a bit smaller.
The first version is an OpenCL application for Windows that can be downloaded at
http://yves.gallot.pagesperso-orange.fr/Cyclo/
Source code is available if someone wants to compile it for another OS.

The form b^{2^n} - b^{2^{n-1}} + 1 has never been tested, it is an open range!

Because a sieve is not available yet, small factors are checked quickly in this version. But of course a sieve is necessary to test efficiently these numbers (is anybody volunteering?).

Note that b^{2^n} - b^{2^{n-1}} + 1 = Phi_{3.2^n}(b), the 3.2^n-th cyclotomic polynomial. Then its factors are of the form k.3.2^n + 1.

The small list

2^2 - 2^1 + 1
2^4 - 2^2 + 1
2^8 - 2^4 + 1
5^16 - 5^8 + 1
4^32 - 4^16 + 1
2^64 - 2^32 + 1
5^128 - 5^64 + 1
196^256 - 196^128 + 1
14^512 - 14^256 + 1
129^1024 - 129^512 + 1
424^2048 - 424^1024 + 1
484^4096 - 484^2048 + 1
22^8192 - 22^4096 + 1

should be completed...

Yves

Yves,

When running -b, it seems to be testing (b^n) - (b^n) + 1 rather than (b^n) - (b^(n/2)) + 1. Is that intentional?

When running -b, it seems to be testing (b^n) - (b^n) + 1 rather than (b^n) - (b^(n/2)) + 1. Is that intentional?

Also, at what value of maxErr is it supposed to error out? It appears it's accepting a calculation where maxErr is 0.5

Hi Yves,

This looks very interesting. I have posted a Mac build and makefile to http://www.epcc.ed.ac.uk/~ibethune/files/cyclo_mac.tar.gz. Feel free to redistribute from your page if you want.

I ran some tests on my machine with an AMD FirePro D700:

Seems to have run fine on my PC -- Win 7 pro x64, Intel i5-2500k w/ Nvidia GTX 760

macpro-ib:cyclo ibethune$ ./cyclo_macintel -b Cyclo (OpenCL, v0.1), Copyright (C) 2014-15, Yves Gallot. 2199064^8192 - 2199064^8192 + 1 Time: 96.2 us / mul. Err : 0.5000 51956 digits 1798620^16384 - 1798620^16384 + 1 Time: 95.9 us / mul. Err : 0.5000 102481 digits 1471094^32768 - 1471094^32768 + 1 Time: 97.3 us / mul. Err : 0.5000 202102 digits 1203210^65536 - 1203210^65536 + 1 Time: 99.8 us / mul. Err : 0.5000 398482 digits 984108^131072 - 984108^131072 + 1 Time: 103 us / mul. Err : 0.5000 785521 digits 804904^262144 - 804904^262144 + 1 Time: 156 us / mul. Err : 0.5000 1548156 digits 658332^524288 - 658332^524288 + 1 Time: 167 us / mul. Err : 0.5000 3050541 digits 538452^1048576 - 538452^1048576 + 1 Time: 180 us / mul. Err : 0.5000 6009544 digits 440400^2097152 - 440400^2097152 + 1 Time: 194 us / mul. Err : 0.5000 11836006 digits 360204^4194304 - 360204^4194304 + 1 Time: 207 us / mul. Err : 0.5000 23305854 digits 294612^8388608 - 294612^8388608 + 1 Time: 176 us / mul. Err : 0.5000 45879398 digits

Benchmark times are a little odd, since n=23 is consistently faster than n=22. I note that the errors here are high (this may explain the composites before?). I suspect this is due to the non-IEEE floating point on these cards, as we found before with Genefer, but I haven't gone digging into the code to propose a fix yet!

Cheers
- Iain

7000009^128 - 7000009^64 + 1 is composite [Res=442454942]. (0.3 sec., err=2.81e-01) 5000349^256 - 5000349^128 + 1 is composite [Res=637926927]. (0.5 sec., err=3.44e-01)

Not sure if the two composites were expected or not?

These are related to PIES. Mike Oakes and then Phil Carmody searched in this class for years.

With only squaring implemented, b^{2^n} + b^{2^{n-1}} + 1 is still also a good interesting form.

7000009^128 - 7000009^64 + 1 is composite [Res=442454942]. (0.3 sec., err=2.81e-01) 5000349^256 - 5000349^128 + 1 is composite [Res=637926927]. (0.5 sec., err=3.44e-01)

294612^8388608 - 294612^8388608 + 1 Time: 176 us / mul. Err : 0.5000 45879398 digits

UTM has some numbers that can be double-checked with Cyclo.
http://primes.utm.edu/primes/search.php?Description=Phi%28%2565536%25&OnList=all&Number=9999 (none at this time)
http://primes.utm.edu/primes/search.php?Description=Phi%28%2532768%25&OnList=all&Number=9999 *
http://primes.utm.edu/primes/search.php?Description=Phi%28%2516384%25&OnList=all&Number=9999
http://primes.utm.edu/primes/search.php?Description=Phi%28%258192%25&OnList=all&Number=9999
http://primes.utm.edu/primes/search.php?Description=Phi%28%254096%25&OnList=all&Number=9999 ...etc**

P.P.S. There are also relevant OEIS sequences with references.
http://oeis.org/A246119 will be extended by finding a n=16 prime.

UTM has some numbers that can be double-checked with Cyclo.
http://primes.utm.edu/primes/search.php?Description=Phi%28%2532768%25&OnList=all&Number=9999 *
http://primes.utm.edu/primes/search.php?Description=Phi%28%2516384%25&OnList=all&Number=9999

Also runs fine on my AMD HD 7970 GPU (with AMD X6 1100 CPU).

2. If base b is very small (b<1000), internally square it (maybe repeatedly) until it reaches reasonable size (e.g. <1000000) and halve the n each time. This will lead to smaller FFT size and much faster run time (but the test number obviously is still the same).

Some ideas for version 0.2 (some of them trivial and likely on Yves' roadmap anyway):

2. If base b is very small (b<1000), internally square it (maybe repeatedly) until it reaches reasonable size (e.g. <1000000) and halve the n each time. This will lead to smaller FFT size and much faster run time (but the test number obviously is still the same).

3a. Alternatively (like mfaktc): the finished worklines can be yanked [...]

I wish you rocket scientists would put this all together so the rest of us can crunch...

(of course, after the Year of the Sheep Challenge..)

Neo
AtP
____________

[...] The math and internal logic (Calculate the first primitive root; Derive the rest; Filter) would remain the same.

[...]... Actually, Anand axn's gfn-sieve would be the way to go.

GFN Sieve algorithm - http://fatphil.org/maths/GFN/maths.html

My sieve pretty much follows it (but uses jacobi symbol to avoid guessing which starting point will yield a primitive root)

I have already adapted the GFN sieve for Cyclo. Will need some more testing before releasing it. However, the sieve approach requires coordination. It proceeds thru primes much slower than individual candidate trial factoring, so for independent testers, it is best to stick with trial factoring (I believe Serge has working code for that).

I have already adapted the GFN sieve for Cyclo.

A new version of "Cyclo" is available at
http://yves.gallot.pagesperso-orange.fr/Cyclo/

Slightly faster, it reads/writes .ckpt files and is able to continue if an input file is checked.
The current line is tagged with *: you can modify the input file during the computation.
Device number can be set with the -d option.

TODO:
- trap ctrl-C
- set priority

What else is needed for it to run with PRPNet?

A new version of "Cyclo" is available at
http://yves.gallot.pagesperso-orange.fr/Cyclo/

Slightly faster, it reads/writes .ckpt files and is able to continue if an input file is checked.
The current line is tagged with *: you can modify the input file during the computation.
Device number can be set with the -d option.

TODO:
- trap ctrl-C
- set priority

What else is needed for it to run with PRPNet?

I can work on changes to PRPNet. If someone could provide to me an ABC file with candidates to test and an example of cycle input and output, that would be great.

I can work on changes to PRPNet. If someone could provide to me an ABC file with candidates to test and an example of cycle input and output, that would be great.

I can work on changes to PRPNet. If someone could provide to me an ABC file with candidates to test and an example of cycle input and output, that would be great.

Cyclo interface is very similar to the genefer one:

Usage: CycloOCL [options] Options: -h Print this help message, the OpenCL device list and exit, -b Run benchmark, -t Run some tests of known primes, -q "b^N - b^{N/2} + 1" Check 'q'uick expression (N must be a power of two), <filename> Test numbers in <filename>, one per line, in the format b N, -d <n> Set device number = n (default is 0), -v Print the startup banner and immediately exit.

You can use a "trick" with -q option. It is sufficient to write

CycloOCL.exe -q "129^1024"

and the program checks 129^1024 - 129^512 + 1.
You can also write

CycloOCL.exe -q "129^1024+1".

Then I think that PRPNet <-> genefer interface can be used as is, just replacing "genefer.exe" with "CycloOCL.exe".

Note that the options should have a lowercase letter: -h, -q, -v is OK but -H, -Q, -V is NOK.
If uppercase or lowercase letters should be supported, I can quicly add this feature.

Wouldn't one possible ABC header just be:

ABC $a^$b-$a^($b/2)+1

followed by a pair of b N on each line? That's how most of these things work.

Whether programs like srfile would be compatible with that, I don't know. We can always work around that if needed.

I guess it's time to start thinking of how we move forward with this.

The first question is "Which n do you want to start testing?"

That question is rather important, because axn's GFN sieve program is very fast at higher n's (n=19 and above), but slows down significantly at lower n's. That may be fixable, but at least for right now, I would guess that it won't be that fast if we want to start Cyclo testing at n=15 or lower.

A second question refers to "the admins may need top seive 0-1P (or 10P) themselves." Is that because of the large factor files produced, or because the GPU sieve can't handle low P's? If it can't do it, what other software do we have that can?

It sounds like we're really close to having Cyclo ready for running on PRPnet, but do we want/need to start without sieving first?


____________
My lucky number is 75898⁵²⁴²⁸⁸+1

The first question is "Which n do you want to start testing?"

That question is rather important, because axn's GFN sieve program is very fast at higher n's (n=19 and above), but slows down significantly at lower n's. That may be fixable, but at least for right now, I would guess that it won't be that fast if we want to start Cyclo testing at n=15 or lower.

A second question refers to "the admins may need top seive 0-1P (or 10P) themselves." Is that because of the large factor files produced, or because the GPU sieve can't handle low P's? If it can't do it, what other software do we have that can?

It sounds like we're really close to having Cyclo ready for running on PRPnet, but do we want/need to start without sieving first?

A second question refers to "the admins may need top seive 0-1P (or 10P) themselves." Is that because of the large factor files produced, or because the GPU sieve can't handle low P's? If it can't do it, what other software do we have that can?

I started most Genefer ranges on CPUs locally. There is no need for GPU app for low P (if it takes hours to make is running there)
Using CPU app offline to start sieves and GPU to split ranges if fine.

If possible, might I suggest starting a PRPNet port with a single n large enough so the numbers are eligible for the Top 5K list? If we do that before February 1st, people could crunch it for Tour de Primes. It might be worth doing that even without sieving. That would give folks something fast to crunch with a GPU for TDP.

Mark, how does double checking in PRPNet work? Since this is a new project, I'd like to give it a try. Can't really try it on existing ports because (I think) the server would immediately want to double check every single completed task in the database.

And speaking of size, is the formula for computing the number of digits the same for cyclo as it is for GFN? The part that gets subtracted out is so much smaller that it shouldn't affect the size at all right? It's insignificant in that regard. Or am I missing something?
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

2^64 - 2^32 + 1 is a probable prime. (0.1 sec., err=7.99e-015, 20 digits)
5^128 - 5^64 + 1 is a probable prime. (0.0 sec., err=9.95e-014, 90 digits)
196^256 - 196^128 + 1 is a probable prime. (0.1 sec., err=2.33e-010, 587 digits)
14^512 - 14^256 + 1 is a probable prime. (0.1 sec., err=1.88e-012, 587 digits)
129^1024 - 129^512 + 1 is a probable prime. (0.3 sec., err=6.98e-010, 2162 digits)
424^2048 - 424^1024 + 1 is a probable prime. (0.5 sec., err=5.12e-009, 5381 digits)
484^4096 - 484^2048 + 1 is a probable prime. (1.0 sec., err=1.07e-008, 10998 digits)
22^8192 - 22^4096 + 1 is a probable prime. (1.0 sec., err=3.59e-011, 10998 digits)
5164^16384 - 5164^8192 + 1 is a probable prime. (6.3 sec., err=3.22e-006, 60834 digits)
7726^32768 - 7726^16384 + 1 is a probable prime. (17.9 sec., err=1.19e-005, 127401 digits)
13325^65536 - 13325^32768 + 1 is a probable prime. (73.0 sec., err=9.25e-005, 270315 digits)
96873^131072 - 96873^65536 + 1 is a probable prime. (368.8 sec., err=1.02e-002, 653552 digits)

10000120^64 - 10000120^32 + 1 is a probable prime. (0.1 sec., err=2.03e-001, 449 digits)
7000009^128 - 7000009^64 + 1 is a probable prime. (0.1 sec., err=3.28e-001, 877 digits)
5000349^256 - 5000349^128 + 1 is a probable prime. (0.2 sec., err=4.84e-001, 1715 digits)
4000414^512 - 4000414^256 + 1 is a probable prime. (0.3 sec., err=1.68e-001, 3381 digits)
3200056^1024 - 3200056^512 + 1 is a probable prime. (0.7 sec., err=1.80e-001, 6662 digits)
2505769^2048 - 2505769^1024 + 1 is a probable prime. (1.1 sec., err=3.13e-001, 13106 digits)
2005838^4096 - 2005838^2048 + 1 is a probable prime. (2.1 sec., err=1.88e-001, 25815 digits)
1805064^8192 - 1805064^4096 + 1 is a probable prime. (4.3 sec., err=2.73e-001, 51254 digits)
1401068^16384 - 1401068^8192 + 1 is a probable prime. (10.3 sec., err=2.46e-001, 100704 digits)
1007934^32768 - 1007934^16384 + 1 is a probable prime. (27.4 sec., err=2.22e-001, 196721 digits)
93500^65536 - 93500^32768 + 1 is a probable prime. (87.8 sec., err=2.53e-003, 325768 digits)

C:\Temp\Cyclo>Cycloocl -q "1000^65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

1000^65536 - 1000^32768 + 1 is composite [Res=3]. (0.1 sec., err=0.00e+000)


C:\Temp\Cyclo>Cycloocl -q "1002^65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

1002^65536 - 1002^32768 + 1 is composite [Res=32796769]. (53.4 sec., err=2.91e-007)

C:\Temp\Cyclo>Cycloocl -q "1000^65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

1000^65536 - 1000^32768 + 1 is composite [Res=3]. (0.1 sec., err=0.00e+000)

C:\Temp\Cyclo>Cycloocl -q "1000^65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

1000^65536 - 1000^32768 + 1 is composite [Res=32745926]. (53.4 sec., err=3.20e-007)

One project that could already be started is the sieve. n=18, 19 and 20 should be encouraged over n=21 and 22 (these will take much more time to pick up speed). n<=17 are too small for Top5k and can be left to individual searchers.

axn wrote a sieve (quite similar to GFNSvCUDA) which works very well and a few (minor) bugs were already removed. What's more, Anand seems to have figured out a way to make the linux binary work, as well.

So, a very similar framework should be set up at http://uwin.mine.nu/sieves/cyclo/ (a near identical clone of http://uwin.mine.nu/sieves/gfn/ )
and an edited version of these instructions should be written (just search-and-replace, mostly)

How high can maxErr go before it becomes a problem?

Also, I ran 1000^65536 and 1002^65536. The residues don't look like the normal 16 hex digits we normally see. And 1000^65536 ran in 0.1 seconds.

How high can maxErr go before it becomes a problem?

It's a complicated question, see
http://www.primegrid.com/forum_thread.php?id=6062&nowrap=true#81774
All candidates are prime.

Also, I ran 1000^65536 and 1002^65536. The residues don't look like the normal 16 hex digits we normally see. And 1000^65536 ran in 0.1 seconds.

You found a bug!
The program continued the computation from a checkpoint that was generated with different b and n. It may occur if you use the -q command, but not if the input is a file.
I'm going to fix it.

Mark, how does double checking in PRPNet work? Since this is a new project, I'd like to give it a try. Can't really try it on existing ports because (I think) the server would immediately want to double check every single completed task in the database.

Mark, how does double checking in PRPNet work? Since this is a new project, I'd like to give it a try. Can't really try it on existing ports because (I think) the server would immediately want to double check every single completed task in the database.

There need to be two matching residues for the same candidate, typically done on different computers.

As for the ABC file, I would prefer:

ABC Phi($a,$b^$c)

and grouping over $a and $c for the stats. My reason for that is because it is much harder in code to identify a polynomial as a cyclotomic polynomial. I want PRPNet to support other values for $a and $c than just 3 and c=2^n. Those can be tested by pfgw.

Would instead be: (note the minus sign before 1234)

ABC Phi($a,$b^$c)
3 -1234 32768

Is that correct?

I'll support

ABC Phi($a,$b^$c)

and

ABC Phi($a,$b)

but for the latter the grouping would be over $a whereas the former has a the grouping by $a and $c.

pfgw treats the expression correctly when $b is negative. I verified that both Phi(3,-129^512) and Phi(6,126^512) are both PRP.

I'll change the PRPNet client to use cyclo if $a = 6 and $c is a power of 2, but raises the question of $b being positive or negative for cyclo. I should be able to figure that out on my own.

pfgw treats the expression correctly when $b is negative. I verified that both Phi(3,-129^512) and Phi(6,126^512) are both PRP.

Yes, this will be clean.

I will email my patch to Jean Penne (that will be geared to an input in this form), and maybe he will include it in the next release; then for the CPU client you will be able to use llr v.3.8.14+

I will probably include yet another patch in the same bottle. It deals with "Divides Phi($a^$b,2)"; some people found it useful (at least one more person). It's been sitting on my disk for a while.

Thanks, serge, for the number theory tutorial. It's beginning to make sense.

For those (like me) confused about some of the nomenclature, Phi(3, x) is the same as x^2 + x +1 and Phi(6, x) is the same as x^2 - x +1. There's a Wikipedia page on cyclotomic polynomials here that explains where the 3 and 6 come from.

"3-smooth" means the number's factors consist of only twos and threes.


____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I suspect that a CPU version of Cyclo might be significantly faster than LLR, in much the same way that Genefer is for GFNs.

Last question (for now). It is easy to compute the decimal length for Phi(6,x) and Phi(3,x). Is there is generic formula for computing the decimal length of Phi(y,x) (where y is an integer as opposed to an expression)?

Disclaimer: I do not know how PRPNet or Yves's application are coded.

Last question (for now). It is easy to compute the decimal length for Phi(6,x) and Phi(3,x). Is there is generic formula for computing the decimal length of Phi(y,x) (where y is an integer as opposed to an expression)?

Good news!

My testing is almost done. It will need additional testing but I've run though a few things. The server seems to be working fine. The client handles cyclo correctly and pfgw can do the proof.

Good news!

My testing is almost done. It will need additional testing but I've run though a few things. The server seems to be working fine. The client handles cyclo correctly and pfgw can do the proof.

Good news!

My testing is almost done. It will need additional testing but I've run though a few things. The server seems to be working fine. The client handles cyclo correctly and pfgw can do the proof.

Does prpclient automatically invoke pfgw to do the proof?

I'd prefer if it didn't. It's the same situation we face with GFN -- when a PRP is found, the execution takes many times longer than normal. This is bad for two reasons. First, a user with slow hardware may find that they exceed the time limit, and the server sends the task out again -- and the second person's computer might return the task before the first computer, especially if the second computer has pfgw commented out. Secondly, the user might wrongly assume that something is wrong and abort the test.

The problem is, of course, compounded because pfgw doesn't checkpoint when doing a primality test. The proof, unless very short, is best done either on a server or inside a VM.

We can easily do the primality test on our end and save a lot of potential headaches.

As it is, we recommend that people comment out pfgw if they're running GFN.

Ideally, having a server-side configuration to enable or disable the client-side pfgw proof would be ideal, but from my perspective simply removing that function would be fine too.

Even if we have a lot of little proofs, it's no big deal for us to stick them in a file and batch process them on a server.

Making the timeout longer doesn't really help, because if we allow four times as long for the tests, inevitably someone will use a GPU that's four times as slow.

I've committed everything to svn. I've also added support for generic searches, using pfgw, but haven't tested any of that code.

I've compiled your program and am running it now. I'll then grab axn's program and start sieving with that.

Both Jim and I are having no luck running CycloSv. It's consuming 100% of a CPU core and not using the GPU at all. Jim is using a GTX 570 and I'm using a GTX 580.

We downloaded the software from here: http://mersenneforum.org/showpost.php?p=392061&postcount=33

I'm using the command line: CycloSvCUDA-0_2-win32.exe 16 1 2

I'm using nvidia driver 344.75 and Jim is using 347.25 (the latest).

Any ideas?
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

The GFN sieving was done for b<100M. Is there any reason why the Cyclo sieving is set up for b<1M?
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Here is an estimate of the expected number of primes in ranges.

The maxErr will be high for b>1M (for n>16), so there is not much benefit in sieving there.
There is no downside either though - only larger outputs (runtime is the same).

For n=16 only, maybe usable b range is higher. I will recompile the sieve to adjust output up to 2M tonight (Cyclo will probably produce some useful results higher than 1M but not as high as 2M). I've compiled the CycloSv verbatim (1M limit is in the code). Maybe axn meant that to be there only for the testing period.

The CycloCPU can be run above the GPU err limit, but we haven't seen it yet in the wild. Maybe we will soon. ;-) Its limit could be (higher? lower? the same as?) the GPU version, but maybe the 80-bit arithmetic version will be released. Just hypothesizing here...

Mark,

Prpclient will run PFGW for PRPing cyclotomic tasks on the CPU, right?

Is it possible to get a server option to disable that and only use Cyclo on either GPU or CPU? (And conversely, if PFGW is enabled, Cyclo needs to be disabled.)

Since we're going to be doublechecking, because PFGW and Cyclo use different algorithms, they produce different residues. Therefore, you can't double check Cyclo vs PFGW results.

We'll eventually have a CPU version of Cyclo, so the current need for PFGW is only temporary. We'll start off as GPU-only, and add the CPU version when it is available.

We could conceivably want to use PFGW if we ever test numbers with a b high enough to require x87 for the cyclo algorithm. But when we're using Cyclo, we can't also use PFGW.

Thanks!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I'll support

ABC Phi($a,$b^$c)

and

ABC Phi($a,$b)

but for the latter the grouping would be over $a whereas the former has a the grouping by $a and $c.

rogue wrote:

I'll support

ABC Phi($a,$b^$c)

and

ABC Phi($a,$b)

but for the latter the grouping would be over $a whereas the former has a the grouping by $a and $c.

Does that mean I can use:

ABC Phi(3,$a^$b)

or am I going to have to use ABC Phi($a,$b^$c) and specify 3 (or 6) on each line?

Mark,

Prpclient will run PFGW for PRPing cyclotomic tasks on the CPU, right?

Is it possible to get a server option to disable that and only use Cyclo on either GPU or CPU? (And conversely, if PFGW is enabled, Cyclo needs to be disabled.)

Since we're going to be doublechecking, because PFGW and Cyclo use different algorithms, they produce different residues. Therefore, you can't double check Cyclo vs PFGW results.

We'll eventually have a CPU version of Cyclo, so the current need for PFGW is only temporary. We'll start off as GPU-only, and add the CPU version when it is available.

We could conceivably want to use PFGW if we ever test numbers with a b high enough to require x87 for the cyclo algorithm. But when we're using Cyclo, we can't also use PFGW.

Mark,

Prpclient will run PFGW for PRPing cyclotomic tasks on the CPU, right?

Is it possible to get a server option to disable that and only use Cyclo on either GPU or CPU? (And conversely, if PFGW is enabled, Cyclo needs to be disabled.)

Since we're going to be doublechecking, because PFGW and Cyclo use different algorithms, they produce different residues. Therefore, you can't double check Cyclo vs PFGW results.

We'll eventually have a CPU version of Cyclo, so the current need for PFGW is only temporary. We'll start off as GPU-only, and add the CPU version when it is available.

We could conceivably want to use PFGW if we ever test numbers with a b high enough to require x87 for the cyclo algorithm. But when we're using Cyclo, we can't also use PFGW.

pfgw will be used if cyclo is not configured. I would expect a CPU version of cyclo will be available before b is large enough to require pfgw.

PRPNet will likely need to be modified to use cyclo similar to how it uses genefer as the GPU version and CPU version of cyclo will be separate executables.

The client should also be modified to look at the maxerr from cyclo and switch to pfgw.

The version 1.0 of CycloOCL is available at
http://yves.gallot.pagesperso-orange.fr/Cyclo/

The bug found by Mike

I've tried experimenting with setting up a prpnet server. I loaded an ABC file that looks like this:

It went into the db with, for example, k = 3, b = -2, and n = 32768. Presumably, when passed to Cyclo, this will translate into 2^65536-2^32768+1, correct? I haven't gotten that far yet in the testing, but assuming that's correct, there's a problem.

On the server_stats web page, it lists -10 as "Min N" and -2 as "Max N". Two problems there. it's listing them in the wrong order (and possibly will send them out in the wrong order too), and it should be "B" rather than "N".

ABC Phi($a,$b^$c) 6 2 32768 6 3 32768 6 4 32768 6 5 32768 6 6 32768 6 7 32768 6 8 32768 6 9 32768 6 10 32768

That will also address the current problems with the stats and it will use cyclo for the PRP test.

I built the client and connected to the test server above. On the client side, it happily went and crunched all the tasks. However, the first 5 tests (2<=b<=6) were rejected by the server. The next two were accepted. I can't see any difference between the ones that were accepted and the ones that were rejected. Then there were a bunch of "File Not Found" errors after I changed stopasapoption to 2.

Finally, the residue the client is reporting is NOT the complete residue reported by Cyclo.

Client output:

[2015-01-30 16:48:57 EST] PRPNet Client application v5.4.0 started
[2015-01-30 16:48:57 EST] User name Michael_Goetz at email address is XXXX
[2015-01-30 16:48:57 EST] CYCLO: Getting work from XXXX
[2015-01-30 16:48:58 EST] CYCLO: PRPNet server is version 5.4.0
Cyclotomic Polynomial Prime Search N=65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

2^65536 - 2^32768 + 1 is composite [Res=32593]. (6.4 sec., err=1.34e-012)

[2015-01-30 16:49:05 EST] CYCLO: Phi(3,-2^32768) is not prime. Residue 2593
[2015-01-30 16:49:05 EST] Total Time: 0:00:08 Total Work Units: 1 Special Results Found: 0
[2015-01-30 16:49:05 EST] CYCLO: Returning work to server XXXX
[2015-01-30 16:49:05 EST] CYCLO: INFO: Test for Phi(3,-2^32768) was ignored. Candidate and/or test was not found
[2015-01-30 16:49:05 EST] CYCLO: INFO: 0 of 1 test results were accepted
[2015-01-30 16:49:05 EST] CYCLO: Getting work from server XXXX
[2015-01-30 16:49:07 EST] CYCLO: PRPNet server is version 5.4.0
Cyclotomic Polynomial Prime Search N=65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

3^65536 - 3^32768 + 1 is composite [Res=65783]. (9.8 sec., err=2.27e-012)

[2015-01-30 16:49:17 EST] CYCLO: Phi(3,-3^32768) is not prime. Residue 5783
[2015-01-30 16:49:17 EST] Total Time: 0:00:20 Total Work Units: 2 Special Results Found: 0
[2015-01-30 16:49:17 EST] CYCLO: Returning work to server XXXX
[2015-01-30 16:49:17 EST] CYCLO: INFO: Test for Phi(3,-3^32768) was ignored. Candidate and/or test was not found
[2015-01-30 16:49:17 EST] CYCLO: INFO: 0 of 1 test results were accepted
[2015-01-30 16:49:17 EST] CYCLO: Getting work from server XXXX
[2015-01-30 16:49:18 EST] CYCLO: PRPNet server is version 5.4.0
Cyclotomic Polynomial Prime Search N=65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

4^65536 - 4^32768 + 1 is composite [Res=97844]. (13.0 sec., err=5.40e-012)

[2015-01-30 16:49:32 EST] CYCLO: Phi(3,-4^32768) is not prime. Residue 7844
[2015-01-30 16:49:32 EST] Total Time: 0:00:35 Total Work Units: 3 Special Results Found: 0
[2015-01-30 16:49:32 EST] CYCLO: Returning work to server XXXX
[2015-01-30 16:49:32 EST] CYCLO: INFO: Test for Phi(3,-4^32768) was ignored. Candidate and/or test was not found
[2015-01-30 16:49:32 EST] CYCLO: INFO: 0 of 1 test results were accepted
[2015-01-30 16:49:32 EST] CYCLO: Getting work from server XXXX
[2015-01-30 16:49:33 EST] CYCLO: PRPNet server is version 5.4.0
Cyclotomic Polynomial Prime Search N=65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

5^65536 - 5^32768 + 1 is composite [Res=131349]. (14.0 sec., err=6.75e-012)

[2015-01-30 16:49:48 EST] CYCLO: Phi(3,-5^32768) is not prime. Residue 31349
[2015-01-30 16:49:48 EST] Total Time: 0:00:51 Total Work Units: 4 Special Results Found: 0
[2015-01-30 16:49:48 EST] CYCLO: Returning work to server XXXX
[2015-01-30 16:49:48 EST] CYCLO: INFO: Test for Phi(3,-5^32768) was ignored. Candidate and/or test was not found
[2015-01-30 16:49:48 EST] CYCLO: INFO: 0 of 1 test results were accepted
[2015-01-30 16:49:48 EST] CYCLO: Getting work from server XXXX
[2015-01-30 16:49:49 EST] CYCLO: PRPNet server is version 5.4.0
Cyclotomic Polynomial Prime Search N=65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

6^65536 - 6^32768 + 1 is composite [Res=164263]. (15.4 sec., err=1.09e-011)

[2015-01-30 16:50:05 EST] CYCLO: Phi(3,-6^32768) is not prime. Residue 64263
[2015-01-30 16:50:05 EST] Total Time: 0:01:08 Total Work Units: 5 Special Results Found: 0
[2015-01-30 16:50:05 EST] CYCLO: Returning work to server XXXX
[2015-01-30 16:50:05 EST] CYCLO: INFO: Test for Phi(3,-6^32768) was ignored. Candidate and/or test was not found
[2015-01-30 16:50:05 EST] CYCLO: INFO: 0 of 1 test results were accepted
[2015-01-30 16:50:06 EST] CYCLO: Getting work from server XXXX
[2015-01-30 16:50:07 EST] CYCLO: PRPNet server is version 5.4.0
Cyclotomic Polynomial Prime Search N=65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

7^65536 - 7^32768 + 1 is composite [Res=196218]. (16.8 sec., err=1.50e-011)

[2015-01-30 16:50:24 EST] CYCLO: Phi(3,-7^32768) is not prime. Residue 96218
[2015-01-30 16:50:24 EST] Total Time: 0:01:27 Total Work Units: 6 Special Results Found: 0
[2015-01-30 16:50:24 EST] CYCLO: Returning work to server XXXX
[2015-01-30 16:50:24 EST] CYCLO: INFO: Test for Phi(3,-7^32768) was accepted
[2015-01-30 16:50:24 EST] CYCLO: INFO: All 1 test results were accepted
[2015-01-30 16:50:24 EST] CYCLO: Getting work from server XXXX
[2015-01-30 16:50:26 EST] CYCLO: PRPNet server is version 5.4.0
Cyclotomic Polynomial Prime Search N=65536
Cyclo (OpenCL, v0.2), Copyright (C) 2014-15, Yves Gallot.


Running on platform 'NVIDIA CUDA', device 'GeForce GTX 580', version 'OpenCL 1.1 CUDA' and driver '344.75'.

8^65536 - 8^32768 + 1 is composite [Res=229765]. (18.0 sec., err=1.86e-011)

[2015-01-30 16:50:44 EST] CYCLO: Phi(3,-8^32768) is not prime. Residue 29765
[2015-01-30 16:50:44 EST] Total Time: 0:01:47 Total Work Units: 7 Special Results Found: 0
[2015-01-30 16:50:44 EST] CYCLO: Returning work to server XXXX
[2015-01-30 16:50:44 EST] CYCLO: INFO: Test for Phi(3,-8^32768) was accepted
[2015-01-30 16:50:44 EST] CYCLO: INFO: All 1 test results were accepted
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
[2015-01-30 16:50:44 EST] Client shutdown complete

[2015-01-30 21:49:00 UTC] 7: client connecting from 108.14.56.11
[2015-01-30 21:49:00 UTC] 7: received [FROM 5.4.0 XXXX Viper Michael_Goetz PrimeSearchTeam 1]
[2015-01-30 21:49:00 UTC] 7: ODBC Connection via a driver: <XXXX>
[2015-01-30 21:49:00 UTC] 7: successfully connected to a MySQL database
[2015-01-30 21:49:00 UTC] 7: sending [Connected to server 5.4.0 31]
[2015-01-30 21:49:00 UTC] 7: received [RETURNWORK 5.4.0]
[2015-01-30 21:49:00 UTC] 7: received [WorkUnit: Phi(3,-2^32768) 1422654532]
[2015-01-30 21:49:00 UTC] 7: Executing statement: <select IsCompleted from CandidateTest where CandidateName = Phi(3,-2^32768) and TestID = 1422654532>
[2015-01-30 21:49:00 UTC] 7: 1 records fetched
[2015-01-30 21:49:00 UTC] 7: sending [INFO: Test for Phi(3,-2^32768) was ignored. Candidate and/or test was not found]
[2015-01-30 21:49:00 UTC] XXXX (Viper 1): Test 1422654532 for candidate Phi(3,-2^32768) was not found
[2015-01-30 21:49:00 UTC] 7: received [Start Child Phi(3,-2^32768)]
[2015-01-30 21:49:00 UTC] 7: received [Main Test: 0 2593 CycloOCL.exe 0.2), na na 6.400000]
[2015-01-30 21:49:00 UTC] 7: received [End Child Phi(3,-2^32768)]
[2015-01-30 21:49:00 UTC] 7: received [End of WorkUnit: Phi(3,-2^32768) 1422654532]
[2015-01-30 21:49:00 UTC] 7: received [End of Message]
[2015-01-30 21:49:00 UTC] 7: sending [INFO: 0 of 1 test results were accepted]
[2015-01-30 21:49:00 UTC] 7: sending [End of Message]
[2015-01-30 21:49:00 UTC] 7: disconnected from database
[2015-01-30 21:49:00 UTC] 7: closing socket

One final anomaly:

CandidateTestResult.PRPingProgramVersion contains the value "0.2)," (without the quotes) for the successfully returned tests.

I should grab v1.0 of Cyclo and run it with that.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

This may be helpful:

[2015-01-30 22:32:38 UTC] 5: client connecting from XXX
[2015-01-30 22:32:38 UTC] 5: received [FROM 5.4.0 XXXX Viper Michael_Goetz PrimeSearchTeam 1]
[2015-01-30 22:32:38 UTC] 5: ODBC Connection via a driver: <XXXXX>
[2015-01-30 22:32:38 UTC] 5: successfully connected to a MySQL database
[2015-01-30 22:32:38 UTC] 5: sending [Connected to server 5.4.0 31]
[2015-01-30 22:32:38 UTC] 5: received [GETWORK 5.4.0 1]
[2015-01-30 22:32:38 UTC] 5: received [cyclo]
[2015-01-30 22:32:38 UTC] 5: received [End of Message]
[2015-01-30 22:32:38 UTC] 5: sending [ServerConfig: 0]
[2015-01-30 22:32:38 UTC] 5: Executing statement: <select CandidateName, CompletedTests, DecimalLength, LastUpdateTime, k, b, c, n from Candidate where HasPendingTest = 0 and ifnull(MainTestResult, 0) = 0 and DoubleChecked = 0 and HasSierpinskiRieselPrime = 0 and CandidateName > and DecimalLength > 0 order by DecimalLength,LastUpdateTime limit 100>
[2015-01-30 22:32:38 UTC] 5: 1 records fetched
[2015-01-30 22:32:38 UTC] 5: Checking candidate Phi(3,-7^32768)
[2015-01-30 22:32:38 UTC] 5: Executing statement: <select count(*) from CandidateTest where CandidateName = Phi(3,-7^32768) and EmailID = XXXX@XXXX.com and MachineID = Viper >
[2015-01-30 22:32:38 UTC] 5: ODBC Information: SQL_ERROR: [MySQL][ODBC 3.51 Driver][mysqld-5.1.73-1-log]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '@XXXX.com and MachineID = Viper' at line 1
[2015-01-30 22:32:38 UTC] 5: ODBC Information: SQL Statement: select count(*) from CandidateTest where CandidateName = Phi(3,-7^32768) and EmailID = XXXX@XXXX.com and MachineID = Viper
[2015-01-30 22:32:38 UTC] 5: Cannot double-check Phi(3,-7^32768)
[2015-01-30 22:32:38 UTC] 5: 2 records fetched
[2015-01-30 22:32:38 UTC] 5: Checking candidate Phi(3,-8^32768)
[2015-01-30 22:32:38 UTC] 5: Executing statement: <select count(*) from CandidateTest where CandidateName = Phi(3,-8^32768) and EmailID = XXXX@XXXX.com and MachineID = Viper >
[2015-01-30 22:32:38 UTC] 5: ODBC Information: SQL_ERROR: [MySQL][ODBC 3.51 Driver][mysqld-5.1.73-1-log]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '@XXXX.com and MachineID = Viper' at line 1
[2015-01-30 22:32:38 UTC] 5: ODBC Information: SQL Statement: select count(*) from CandidateTest where CandidateName = Phi(3,-8^32768) and EmailID = XXXX@XXXX.com and MachineID = Viper
[2015-01-30 22:32:38 UTC] 5: Cannot double-check Phi(3,-8^32768)
[2015-01-30 22:32:38 UTC] 5: 3 records fetched
[2015-01-30 22:32:38 UTC] 5: Checking candidate Phi(3,-9^32768)
[2015-01-30 22:32:38 UTC] 5: Executing statement: <update Candidate set HasPendingTest = 1 where CandidateName = Phi(3,-9^32768) and HasPendingTest = 0>
[2015-01-30 22:32:38 UTC] 5: 1 rows affected
[2015-01-30 22:32:38 UTC] First check for candidate Phi(3,-9^32768)
[2015-01-30 22:32:38 UTC] 5: Executing statement: <insert into CandidateTest ( CandidateName, TestID, EmailID, MachineID, InstanceID, UserID, TeamID, EmailSent ) values ( Phi(3,-9^32768),1422657158,XXXX@XXXX.com,Viper,1,Michael_Goetz,PrimeSearchTeam,0 )>
[2015-01-30 22:32:38 UTC] 5: 1 rows affected
[2015-01-30 22:32:38 UTC] 5: sending [WorkUnit: Phi(3,-9^32768) 1422657158 3 -9 32768]
[2015-01-30 22:32:38 UTC] 5: Phi(3,-9^32768) sent to Email: XXXX User: Michael_Goetz Machine: Viper Instance: 1
[2015-01-30 22:32:39 UTC] 5: sending [End of Message]
[2015-01-30 22:32:39 UTC] 5: sending [Start Greeting]
[2015-01-30 22:32:39 UTC] 5: sending [Cyclotomic Polynomial Prime Search b^65536 - b^32768 +1]
[2015-01-30 22:32:39 UTC] 5: sending [End Greeting]
[2015-01-30 22:32:39 UTC] 5: disconnected from database
[2015-01-30 22:32:39 UTC] 5: closing socket

I should grab v1.0 of Cyclo and run it with that.

As I explained earlier I think it would be less confusing if that was:

By the way, I loaded the ABC file via phpadmin. The help text on phpserver reads thusly:

Mark Rodenkirch's PRPNet Server, Version 5.4.0 -d Turn on all debugging -h Show this menu -l<filename> Load ABC file <filename> into database -u Upgrade from 2.x to 3.x

I tried the -l<filename> option on prpserver to load the ABC file, but it seemed to do nothing. It did correctly parse the command line option (it didn't print the help text), but it didn't process the file:

./prpserver -ltest.abc [2015-01-30 19:07:31 UTC] PRPNet Server application v5.4.0 started. [2015-01-30 19:07:31 UTC] Please contact Mark Rodenkirch at XXXX for support [2015-01-30 19:07:31 UTC] Waiting for connections on port XXXX ^C[2015-01-30 19:08:29 UTC] Signal recieved: SIGINT - Interrupt (Ctrl-C) Error in my_thread_global_end(): 4 threads didn't exit [2015-01-30 19:08:29 UTC] Server is shutting down

The failed SQL statements are due to missing single quotes when building the SQL when doing the double-check check.

There is some code that is unnecessary when work is returned that under some conditions (unknown reasons) returns an unexpected value. It is why the tests are rejected. I would expect the code to either always be successful or always fail. I'll remove the offending code.

The client is not be extracting the version correctly from cyclo.

These are fixed and checked in.

Don't worry about the "file not found" messages. The client will delete all potential temp files created by the various helper programs when it exits.