Hi everyone,

I have nearly completed a new version of genefer (currently called 3.2.0beta). You can download windows, linux and mac binaries from https://www.assembla.com/code/genefer/subversion/nodes. Look in the trunk/bin/<os> directory to get the latest set of binaries. The code is reasonably well tested now (thanks to Ron and Roger especially), and I'd like to see it tested either standalone, using prpnet, or using BOINC with app_info.xml.

What you should expect to see:

• Instead of many different apps (genefx64, genefersse3, geneferavx etc.) genefer 3.2.0 has only a 32 and 64 bit CPU app, each of which contain a range of different transforms, and will use the fastest available transform for the particular b^2^n+1 that is being tested
  
• Note this choice of transform might not alway be what you expect (e.g. SSE2 can be faster than SSE3 on some CPUs, and SSE3 may be better than AVX esp. on AMD CPUs).
  
• The performance of genefer 3.2.0 should be very similar to 3.1.2 except for some minor effects caused by changing compilers, and running on 64 bit vs 32 bit. If you see big differences in performance, please let me know.
  
• The b 'limits' may change slightly between 3.1.2 and 3.2.0 but in any case are not hard limits and you may be able to complete tests successfully beyond the B limit for a given N. If a round-off error occurs, genefer 3.2.0 will automatically try a slower transform with higher B limit.
  
• The CUDA and OpenCL apps are essentially unchanged to 3.1.2.
  

Please post your test results to this thread (both successes and failure please).

Cheers

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

Roger,

Work is actively proceeding on a combined genefer CPU app which supports all the transforms in a single executable. We'll want to put in support for that single executable into PRPNet, rather than supporting multiple versions of genefer. Possibly two versions, 64-bit and 32-bit, but no more than that.

@Iain: It says it's using the SSE2 transform on my CPU (AMD 1100T). Is that the same as genefx64? genefx64 has a B-limit of 735,000 at N=19 for Intel and AMD, and if so my current test of b=771564 should maxErr.

Well then let's test it:

Generalized Fermat Number b Limits
The upper bound m = 256, b = 7600000, Err = 0.2812
Starting b = 9470000, Err b = 7605000, Err = 0.2969, 5 Err b = 0
The upper bound m = 512, b = 6595000, Err = 0.2812
Starting b = 7690000, Err b = 6600000, Err = 0.3125, 5 Err b = 0
The upper bound m = 1024, b = 5250000, Err = 0.2812
Starting b = 6250000, Err b = 5255000, Err = 0.3438, 5 Err b = 0
The upper bound m = 2048, b = 4355000, Err = 0.2812
Starting b = 5070000, Err b = 4360000, Err = 0.3125, 5 Err b = 0
The upper bound m = 4096, b = 3485000, Err = 0.2891
Starting b = 4120000, Err b = 3490000, Err = 0.3125, 5 Err b = 0
The upper bound m = 8192, b = 2885000, Err = 0.2969
Starting b = 3340000, Err b = 2890000, Err = 0.3125, 5 Err b = 0
The upper bound m = 16384, b = 2340000, Err = 0.2969
Starting b = 2720000, Err b = 2345000, Err = 0.3125, 5 Err b = 0
The upper bound m = 32768, b = 1955000, Err = 0.2812
Starting b = 2200000, Err b = 1960000, Err = 0.3125, 5 Err b = 0
The upper bound m = 65536, b = 1600000, Err = 0.2969
Starting b = 1790000, Err b = 1605000, Err = 0.3125, 5 Err b = 0
The upper bound m = 131072, b = 1305000, Err = 0.2812
Starting b = 1450000, Err b = 1310000, Err = 0.3125, 5 Err b = 0
The upper bound m = 262144, b = 1065000, Err = 0.2969
Starting b = 1180000, Err b = 1070000, Err = 0.3125, 5 Err b = 0
The upper bound m = 524288, b = 890000, Err = 0.2969
Starting b = 960000, Err b = 895000, Err = 0.3594, 5 Err b = 0
The upper bound m = 1048576, b = 720000, Err = 0.2969
Starting b = 780000, Err b = 725000, Err = 0.3125, 5 Err b = 0
The upper bound m = 2097152, b = 595000, Err = 0.2969
Starting b = 630000, Err b = 600000, Err = 0.3281, 5 Err b = 0
The upper bound m = 4194304, b = 495000, Err = 0.2969
Starting b = 510000, Err b = 500000, Err = 0.3281, 5 Err b = 0

real 1m26.560s
user 1m25.633s
sys 0m0.812s

Generalized Fermat Number b Limits
The upper bound m = 256, b = 6005000, Err = 0.2656
Starting b = 9470000, Err b = 6010000, Err = 0.3125, 5 Err b = 8085000
The upper bound m = 512, b = 5170000, Err = 0.2812
Starting b = 7690000, Err b = 5175000, Err = 0.3125, 5 Err b = 7385000
The upper bound m = 1024, b = 4235000, Err = 0.2812
Starting b = 6250000, Err b = 4240000, Err = 0.3125, 5 Err b = 6065000
The upper bound m = 2048, b = 3470000, Err = 0.2812
Starting b = 5070000, Err b = 3475000, Err = 0.3125, 5 Err b = 4530000
The upper bound m = 4096, b = 2905000, Err = 0.2812
Starting b = 4120000, Err b = 2910000, Err = 0.3125, 5 Err b = 3735000
The upper bound m = 8192, b = 2180000, Err = 0.2812
Starting b = 3340000, Err b = 2185000, Err = 0.3125, 5 Err b = 2990000
The upper bound m = 16384, b = 1860000, Err = 0.2812
Starting b = 2720000, Err b = 1865000, Err = 0.3125, 5 Err b = 2530000
The upper bound m = 32768, b = 1540000, Err = 0.2812
Starting b = 2200000, Err b = 1545000, Err = 0.3125, 5 Err b = 1990000
The upper bound m = 65536, b = 1240000, Err = 0.2812
Starting b = 1790000, Err b = 1245000, Err = 0.3125, 5 Err b = 1675000
The upper bound m = 131072, b = 1060000, Err = 0.2812
Starting b = 1450000, Err b = 1065000, Err = 0.3125, 5 Err b = 1335000
The upper bound m = 262144, b = 870000, Err = 0.2812
Starting b = 1180000, Err b = 875000, Err = 0.3125, 5 Err b = 1115000
The upper bound m = 524288, b = 735000, Err = 0.2812
Starting b = 960000, Err b = 740000, Err = 0.3125, 5 Err b = 925000
The upper bound m = 1048576, b = 615000, Err = 0.2812
Starting b = 780000, Err b = 620000, Err = 0.3125, 5 Err b = 755000
The upper bound m = 2097152, b = 495000, Err = 0.2812
Starting b = 630000, Err b = 500000, Err = 0.3125, 5 Err b = 595000
The upper bound m = 4194304, b = 435000, Err = 0.3125
Starting b = 510000, Err b = 440000, Err = 0.3438, 5 Err b = 0

real 5m25.765s
user 5m24.124s
sys 0m1.220s

"genefersse3.64.limits" (AMD 1100T) wrote:

Generalized Fermat Number b Limits
The upper bound m = 256, b = 7600000, Err = 0.2812
Starting b = 9470000, Err b = 7605000, Err = 0.2969, 5 Err b = 0
The upper bound m = 512, b = 6595000, Err = 0.2812
Starting b = 7690000, Err b = 6600000, Err = 0.3125, 5 Err b = 0
The upper bound m = 1024, b = 5250000, Err = 0.2812
Starting b = 6250000, Err b = 5255000, Err = 0.3438, 5 Err b = 0
The upper bound m = 2048, b = 4355000, Err = 0.2812
Starting b = 5070000, Err b = 4360000, Err = 0.3125, 5 Err b = 0
The upper bound m = 4096, b = 3485000, Err = 0.2891
Starting b = 4120000, Err b = 3490000, Err = 0.3125, 5 Err b = 0
The upper bound m = 8192, b = 2885000, Err = 0.2969
Starting b = 3340000, Err b = 2890000, Err = 0.3125, 5 Err b = 0
The upper bound m = 16384, b = 2340000, Err = 0.2969
Starting b = 2720000, Err b = 2345000, Err = 0.3125, 5 Err b = 0
The upper bound m = 32768, b = 1955000, Err = 0.2812
Starting b = 2200000, Err b = 1960000, Err = 0.3125, 5 Err b = 0
The upper bound m = 65536, b = 1600000, Err = 0.2969
Starting b = 1790000, Err b = 1605000, Err = 0.3125, 5 Err b = 0
The upper bound m = 131072, b = 1345000, Err = 0.2969
Starting b = 1450000, Err b = 1350000, Err = 0.3438, 5 Err b = 0
The upper bound m = 262144, b = 1085000, Err = 0.2969
Starting b = 1180000, Err b = 1090000, Err = 0.3125, 5 Err b = 0
The upper bound m = 524288, b = 870000, Err = 0.2812
Starting b = 960000, Err b = 875000, Err = 0.3125, 5 Err b = 0
The upper bound m = 1048576, b = 725000, Err = 0.2969
Starting b = 780000, Err b = 730000, Err = 0.3281, 5 Err b = 0
The upper bound m = 2097152, b = 595000, Err = 0.2969
Starting b = 630000, Err b = 600000, Err = 0.3125, 5 Err b = 0
The upper bound m = 4194304, b = 490000, Err = 0.2969
Starting b = 510000, Err b = 495000, Err = 0.3281, 5 Err b = 0

Command line: genefer_windows64.exe -x SSE2 -b

Priority change succeeded.
Generalized Fermat Number Bench
Running benchmarks for transform implementation "SSE2"
6008024^256+1 Time: 0 us/mul. Err: 0.2500 1736 digits
4913974^512+1 Time: 29.3 us/mul. Err: 0.2500 3427 digits
4019150^1024+1 Time: 0 us/mul. Err: 0.2500 6763 digits
3287270^2048+1 Time: 7.81 us/mul. Err: 0.2500 13347 digits
2688666^4096+1 Time: 30.5 us/mul. Err: 0.2500 26336 digits
2199064^8192+1 Time: 143 us/mul. Err: 0.3125 51956 digits
1798620^16384+1 Time: 307 us/mul. Err: 0.1562 102481 digits
1471094^32768+1 Time: 651 us/mul. Err: 0.1562 202102 digits
1203210^65536+1 Time: 1.4 ms/mul. Err: 0.1562 398482 digits
984108^131072+1 Time: 3.02 ms/mul. Err: 0.1562 785521 digits
804904^262144+1 Time: 7.19 ms/mul. Err: 0.1406 1548156 digits
658332^524288+1 Time: 17.5 ms/mul. Err: 0.1328 3050541 digits
538452^1048576+1 Time: 36.4 ms/mul. Err: 0.1406 6009544 digits
440400^2097152+1 Time: 75.2 ms/mul. Err: 0.1250 11836006 digits
360204^4194304+1 Time: 198 ms/mul. Err: 0.1250 23305854 digits

>genefer_windows64.exe -x SSE2 -b3
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default 128 sse2 x87 sse3
Copyright 2001-2013, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2013, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: genefer_windows64.exe -x SSE2 -b3

Priority change succeeded.
Running benchmarks for transform implementation "SSE2"
14^32768+1 37557 digits 0 days 0.0 hours (0.64 ms/mul, 327
69 iterations) 77 GFLOPS
75898^32768+1 159916 digits 0 days 0.0 hours (0.66 ms/mul, 327
82 iterations) 77 GFLOPS
700000^32768+1 191533 digits 0 days 0.0 hours (0.64 ms/mul, 163
853 iterations) 387 GFLOPS
5000000^32768+1 219512 digits 0 days 0.0 hours (0.66 ms/mul, 196
623 iterations) 464 GFLOPS

14^65536+1 75113 digits 0 days 0.0 hours (1.40 ms/mul, 655
37 iterations) 326 GFLOPS
75898^65536+1 319831 digits 0 days 0.0 hours (1.40 ms/mul, 655
50 iterations) 326 GFLOPS
710000^65536+1 383469 digits 0 days 0.1 hours (1.39 ms/mul, 262
158 iterations) 1306 GFLOPS
2500000^65536+1 419296 digits 0 days 0.1 hours (1.40 ms/mul, 327
695 iterations) 1632 GFLOPS

14^131072+1 150226 digits 0 days 0.1 hours (3.06 ms/mul, 131
073 iterations) 1374 GFLOPS
75898^131072+1 639662 digits 0 days 0.1 hours (3.03 ms/mul, 131
086 iterations) 1375 GFLOPS
700000^131072+1 766129 digits 0 days 0.5 hours (3.03 ms/mul, 655
373 iterations) 6872 GFLOPS
1000000^131072+1 786432 digits 0 days 0.6 hours (3.03 ms/mul, 786
444 iterations) 8246 GFLOPS

14^262144+1 300451 digits 0 days 0.5 hours (7.10 ms/mul, 262
145 iterations) 5772 GFLOPS
75898^262144+1 1279324 digits 0 days 0.5 hours (7.13 ms/mul, 262
158 iterations) 5773 GFLOPS
468750^262144+1 1486604 digits 0 days 0.5 hours (7.22 ms/mul, 262
160 iterations) 5773 GFLOPS
815000^262144+1 1549575 digits 0 days 1.6 hours (7.33 ms/mul, 786
447 iterations) 17318 GFLOPS

14^524288+1 600902 digits 0 days 2.7 hours (18.88 ms/mul, 52
4289 iterations) 24189 GFLOPS
75898^524288+1 2558647 digits 0 days 2.7 hours (18.88 ms/mul, 52
4302 iterations) 24190 GFLOPS
468750^524288+1 2973207 digits 0 days 2.7 hours (18.88 ms/mul, 52
4304 iterations) 24190 GFLOPS
710000^524288+1 3067745 digits 0 days 11.0 hours (18.94 ms/mul, 20
97166 iterations) 96758 GFLOPS

>genefer_windows64.exe -x SSE3 -b
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default 128 sse2 x87 sse3
Copyright 2001-2013, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2013, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: genefer_windows64.exe -x SSE3 -b

Priority change succeeded.
Generalized Fermat Number Bench
Running benchmarks for transform implementation "SSE3"
6008024^256+1 Time: 0 us/mul. Err: 0.1484 1736 digits
4913974^512+1 Time: 0 us/mul. Err: 0.1562 3427 digits
4019150^1024+1 Time: 15.6 us/mul. Err: 0.1562 6763 digits
3287270^2048+1 Time: 22.9 us/mul. Err: 0.1562 13347 digits
2688666^4096+1 Time: 61 us/mul. Err: 0.1875 26336 digits
2199064^8192+1 Time: 130 us/mul. Err: 0.1875 51956 digits
1798620^16384+1 Time: 313 us/mul. Err: 0.2188 102481 digits
1471094^32768+1 Time: 663 us/mul. Err: 0.2109 202102 digits
1203210^65536+1 Time: 1.58 ms/mul. Err: 0.2031 398482 digits
984108^131072+1 Time: 3.31 ms/mul. Err: 0.1875 785521 digits
804904^262144+1 Time: 8.09 ms/mul. Err: 0.1875 1548156 digits
658332^524288+1 Time: 19.4 ms/mul. Err: 0.1953 3050541 digits
538452^1048576+1 Time: 46.1 ms/mul. Err: 0.1875 6009544 digits
440400^2097152+1 Time: 100 ms/mul. Err: 0.1797 11836006 digits
360204^4194304+1 Time: 241 ms/mul. Err: 0.1758 23305854 digits

>genefer_windows64.exe -x SSE3 -b3
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default 128 sse2 x87 sse3
Copyright 2001-2013, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2013, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: genefer_windows64.exe -x SSE3 -b3

Priority change succeeded.
Running benchmarks for transform implementation "SSE3"
14^32768+1 37557 digits 0 days 0.0 hours (0.67 ms/mul, 327
69 iterations) 77 GFLOPS
75898^32768+1 159916 digits 0 days 0.0 hours (0.66 ms/mul, 327
82 iterations) 77 GFLOPS
700000^32768+1 191533 digits 0 days 0.0 hours (0.67 ms/mul, 163
853 iterations) 387 GFLOPS
5000000^32768+1 219512 digits 0 days 0.0 hours (0.66 ms/mul, 196
623 iterations) 464 GFLOPS

14^65536+1 75113 digits 0 days 0.0 hours (1.59 ms/mul, 655
37 iterations) 326 GFLOPS
75898^65536+1 319831 digits 0 days 0.0 hours (1.58 ms/mul, 655
50 iterations) 326 GFLOPS
710000^65536+1 383469 digits 0 days 0.1 hours (1.59 ms/mul, 262
158 iterations) 1306 GFLOPS
2500000^65536+1 419296 digits 0 days 0.1 hours (1.59 ms/mul, 327
695 iterations) 1632 GFLOPS

14^131072+1 150226 digits 0 days 0.1 hours (3.34 ms/mul, 131
073 iterations) 1374 GFLOPS
75898^131072+1 639662 digits 0 days 0.1 hours (3.32 ms/mul, 131
086 iterations) 1375 GFLOPS
700000^131072+1 766129 digits 0 days 0.6 hours (3.31 ms/mul, 655
373 iterations) 6872 GFLOPS
1000000^131072+1 786432 digits 0 days 0.7 hours (3.31 ms/mul, 786
444 iterations) 8246 GFLOPS

14^262144+1 300451 digits 0 days 0.5 hours (8.16 ms/mul, 262
145 iterations) 5772 GFLOPS
75898^262144+1 1279324 digits 0 days 0.5 hours (8.22 ms/mul, 262
158 iterations) 5773 GFLOPS
468750^262144+1 1486604 digits 0 days 0.6 hours (8.50 ms/mul, 262
160 iterations) 5773 GFLOPS
815000^262144+1 1549575 digits 0 days 1.8 hours (8.56 ms/mul, 786
447 iterations) 17318 GFLOPS

14^524288+1 600902 digits 0 days 3.1 hours (21.53 ms/mul, 52
4289 iterations) 24189 GFLOPS
75898^524288+1 2558647 digits 0 days 3.2 hours (22.54 ms/mul, 52
4302 iterations) 24190 GFLOPS
468750^524288+1 2973207 digits 0 days 3.2 hours (22.48 ms/mul, 52
4304 iterations) 24190 GFLOPS
710000^524288+1 3067745 digits 0 days 13.0 hours (22.39 ms/mul, 20
97166 iterations) 96758 GFLOPS

Can you check the contents of the genefer.dat file in the same directory as the executable and let me know what it says.

That's what I expected to see. The first two entries are the B & N. Then a list of the transforms followed by the estimated times. Looks like SSE2 beats SSE3 by quite a bit on your machine. I don't know enough about the 1100T but generally SSE3 does better on systems with smaller caches and/or less memory bandwidth, but if there is plenty then SSE2 can be faster.

x87 is the old genefer80 implementation (except it is extended so that is can be used in a 64-bit app as well as the old 32-bit version)
default is what used to be called 'genefer32' or 'genefer64' i.e. the FFT does not use SIMD intrinsics, but lets the compiler do the best it can.

I ran the Mac 64-bit CPU version.

On the limit tests for both SSE2 and SSE3, I got the same results as rroonnaalldd posted in message 71275.

I ran the benchmarks for SSE2 and SSE3. This was on a Sept. 2009 vintage iMac, C2D @2.93 GHz, no other significant system load.

In the PRPNet prpclient.ini can you pass command line flags to the application? i.e.
geneferexe=genefer_windows64.exe -x SSE3

Below is an example where it would be useful. genefer_windows64.exe first tries SSE2 because it is quicker, but then it exceeds maxErr and switches to SSE3.
The -x flag forces use of the specified code path.

In the PRPNet prpclient.ini can you pass command line flags to the application? i.e.
geneferexe=genefer_windows64.exe -x SSE3

During test, I hit Ctrl+C so I would try to continue from checkpoint.

c:\_PG\PRPclient.1>prpclient.exe
Total percent of servers does not equal 100. Normalizing
[2013-12-08 10:01:52 CEST] PRPNet Client application v5.3.0 started
[2013-12-08 10:01:52 CEST] User name Honza at email address is x@xxx.xx
It appears that the PRPNet client was aborted without completing
the workunits asigned by server GFN32768. What do you want to do with them?
1 = Report completed and abort the rest, then get more work
2 = Report completed and abort the rest, then shut down
3 = Return completed, then continue
4 = Complete in-progress, abort the rest, report them, then get more work
5 = Complete in-progress, abort the rest, report them, then shut down
6 = Complete all work units, report them, then shut down
7 = Complete all work units, then shut down
9 = Continue from client left off when it was shut down

Choose option: 6
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default 128 sse2 x87 avx sse3
Copyright 2001-2013, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2013, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: genefer_windows64.exe work_GFN32768.in

Priority change succeeded.
Start test of file 'work_GFN32768.in' - 10:01:57
Testing 7028526^32768+1...
Using x87 (80-bit) transform
Resuming 7028526^32768+1 from a checkpoint (511582 iterations left)
Estimated total run time for 7028526^32768+1 is 0:20:23
Testing 7028526^32768+1... 507904 steps to go (0:13:53 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=507904. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=507904. Continuing processing anyway...
Testing 7028526^32768+1... 503808 steps to go (0:13:47 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=503808. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=4096. Continuing processing anyway...
7028526^32768+1 is a probable composite. (RES=a3187b9a9831f147) (224359 digits) (err = 0.0068) (time = 0:20:17) 10:15:45

Running PRPNet Client 5.2.4, genefer windows 64 bit downloaded from above.

Intel i5 2500k @ 4.5GHz
Port 12005 GFN32768

[2013-12-08 18:51:52 MST] PRPNet Client application v5.2.4 started
[2013-12-08 18:51:52 MST] User name 1998golfer at email address is fake@email.invald
[2013-12-08 18:51:53 MST] GFN32768: Getting work from server prpnet.primegrid.com
at port 12005
[2013-12-08 18:51:54 MST] GFN32768: PRPNet server is version 5.2.8
Generalized Fermat Number Prime Search N=32768
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default 128 sse2 x87 avx sse3
Copyright 2001-2013, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2013, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: genefer_windows64.exe work_GFN32768.in

Priority change succeeded.
Start test of file 'work_GFN32768.in' - 18:51:54
No relevant benchmark data exists, testing available transform implementations...
Testing 7028596^32768+1...
Using AVX transform

Starting initialization...
Initialization complete (0.022 seconds).
Estimated total run time for 7028596^32768+1 is 0:02:11
Testing 7028596^32768+1... 741376 steps to go (0:02:11 remaining)
maxErr exceeded for 7028596^32768+1, 0.5000 > 0.4500
maxErr exceeded while using AVX; switching to SSE3.
Testing 7028596^32768+1...
Using SSE3 transform

Starting initialization...
Initialization complete (0.022 seconds).
Estimated total run time for 7028596^32768+1 is 0:04:13
Testing 7028596^32768+1... 741376 steps to go (0:04:12 remaining)
maxErr exceeded for 7028596^32768+1, 1.0000 > 0.4500
maxErr exceeded while using SSE3; switching to SSE2.
Testing 7028596^32768+1...
Using SSE2 transform

Starting initialization...
Initialization complete (0.021 seconds).
Estimated total run time for 7028596^32768+1 is 0:05:13
Testing 7028596^32768+1... 741376 steps to go (0:05:11 remaining)
maxErr exceeded for 7028596^32768+1, 1.0000 > 0.4500
maxErr exceeded while using SSE2; switching to Default.
Testing 7028596^32768+1...
Using Default transform

Starting initialization...
Initialization complete (0.021 seconds).
Estimated total run time for 7028596^32768+1 is 0:06:43
Testing 7028596^32768+1... 741376 steps to go (0:06:41 remaining)
maxErr exceeded for 7028596^32768+1, 1.0000 > 0.4500
maxErr exceeded while using Default; switching to x87 (80-bit).
Testing 7028596^32768+1...
Using x87 (80-bit) transform

Starting initialization...
Initialization complete (0.021 seconds).
Estimated total run time for 7028596^32768+1 is 0:14:42
Testing 7028596^32768+1... 729088 steps to go (0:14:23 remaining)

[2013-12-08 18:56:13 MST] PRPNet Client application v5.2.4 started
[2013-12-08 18:56:13 MST] User name 1998golfer at email address is fake@email.invald
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default 128 sse2 x87 avx sse3
Copyright 2001-2013, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2013, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: genefer_windows64.exe work_GFN32768.in

Priority change succeeded.
Start test of file 'work_GFN32768.in' - 18:56:13
Testing 7028596^32768+1...
Using x87 (80-bit) transform
Resuming 7028596^32768+1 from a checkpoint (539700 iterations left)
Estimated total run time for 7028596^32768+1 is 0:15:23
Testing 7028596^32768+1... 536576 steps to go (0:11:04 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=536576. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=536576. Continuing processing anyway...
Testing 7028596^32768+1... 532480 steps to go (0:10:59 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=532480. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=532480. Continuing processing anyway...
Testing 7028596^32768+1... 528384 steps to go (0:10:54 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=528384. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=528384. Continuing processing anyway...
Testing 7028596^32768+1... 524288 steps to go (0:10:49 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=524288. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=524288. Continuing processing anyway...
Testing 7028596^32768+1... 520192 steps to go (0:10:44 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=520192. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=520192. Continuing processing anyway...
Testing 7028596^32768+1... 516096 steps to go (0:10:39 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=516096. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=516096. Continuing processing anyway...
Testing 7028596^32768+1... 512000 steps to go (0:10:34 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=512000. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=512000. Continuing processing anyway...
Testing 7028596^32768+1... 507904 steps to go (0:10:29 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=507904. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=507904. Continuing processing anyway...
Testing 7028596^32768+1... 503808 steps to go (0:10:24 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=503808. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=503808. Continuing processing anyway...
Testing 7028596^32768+1... 499712 steps to go (0:10:19 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=499712. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=499712. Continuing processing anyway...
Testing 7028596^32768+1... 495616 steps to go (0:10:14 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=495616. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=495616. Continuing processing anyway...
Testing 7028596^32768+1... 491520 steps to go (0:10:08 remaining)
Problem renaming genefer.ckpt to genefer.ckpt.old at i=491520. Continuing processing anyway...

Problem renaming genefer.ckpt.new to genefer.ckpt at i=491520. Continuing processing anyway...

Looks like there is an issue with checkpointing - I'll look into that!

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

Apart from checkpointing cosmetic issue.

It seems like Genefer is trying using fastest AVX and just before finishing it realises maxErr.
Next try with SSE3 and again just before finishinig, retry using SSE2.
After a while using SSE2, restarted using Default from scratch.

Perhaps stupid questing but would it be possible to restart from ckeckpoint?
Task was finished almost twice only to let it run using slowest method from scratch :-(

Hi! Welcome to PrimeGrid's GFN 262144 Prime Search.
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default 128 sse2 x87 avx sse3
Copyright 2001-2013, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2013, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: genefer_windows64.exe work_GFN262144.in

Priority change succeeded.
Start test of file 'work_GFN262144.in' - 21:17:07
Testing 1026120^262144+1...
Using AVX transform

Starting initialization...
Initialization complete (0.732 seconds).
Estimated total run time for 1026120^262144+1 is 6:00:29
Testing 1026120^262144+1... 466944 steps to go (0:32:09 remaining)
maxErr exceeded for 1026120^262144+1, 0.4531 > 0.4500
maxErr exceeded while using AVX; switching to SSE3.
Testing 1026120^262144+1...
Using SSE3 transform

Checkpoint is for AVX transform, expected SSE3. Current test will be restarted

Starting initialization...
Initialization complete (0.733 seconds).
Estimated total run time for 1026120^262144+1 is 9:07:06
Testing 1026120^262144+1... 466944 steps to go (0:48:48 remaining)
maxErr exceeded for 1026120^262144+1, 0.4531 > 0.4500
maxErr exceeded while using SSE3; switching to SSE2.
Testing 1026120^262144+1...
Using SSE2 transform

Checkpoint is for SSE3 transform, expected SSE2. Current test will be restarted

Starting initialization...
Initialization complete (1.544 seconds).
Estimated total run time for 1026120^262144+1 is 11:08:17
Testing 1026120^262144+1... 5230592 steps to go (11:07:46 remaining)
maxErr exceeded for 1026120^262144+1, 0.5000 > 0.4500
maxErr exceeded while using SSE2; switching to Default.
Testing 1026120^262144+1...
Using Default transform

Checkpoint is for SSE2 transform, expected Default. Current test will be restarted

Starting initialization...
Initialization complete (0.748 seconds).
Estimated total run time for 1026120^262144+1 is 17:14:22
Testing 1026120^262144+1... 4554752 steps to go (15:00:01 remaining)

Hi Honza, that is interesting! I knew that in principle it's possible for a test to run a long time without a round-off error, and you have found a good example of this. It's most likely when B is 'close' to the B limit, so unfortunately there are quite a lot of test like this on that port coming up... clearly what is happening now is not efficient.

It was also suggested that the transform to start with could be chosen as a result of a limits test but for N=262144 the B limit is 1065000 - it's a conservative estimate so would still result in the same behaviour you saw.

At present it's not possible to restart from a checkpoint created by a different transform implementation, whether it's possible or not I'd have to think hard about.

Cheers

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

...clearly what is happening now is not efficient

At present it's not possible to restart from a checkpoint created by a different transform implementation, whether it's possible or not I'd have to think hard about.

Cheers

- Iain

Mike, the checkpoint arrays are premultiplied by the sin/cos twiddle factors, which makes restarting with a different transform without loss of accuracy tricky. I propose to modify so that we checkpoint out the arrays when rounded to integer - this way we a restart will be deterministic, can work with any transform implementation. It will require a bit of reorganisation of the code though...

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

On checkpoint and .ini parameter file, I would like to see option to set checkpointing interval if possible.

GFN262144 writes about 3.5GB per test in 5 hours, this would be about 100GB a day on 6-core machine.
____________
My stats

On checkpoint and .ini parameter file, I would like to see option to set checkpointing interval if possible.

GFN262144 writes about 3.5GB per test in 5 hours, this would be about 100GB a day on 6-core machine.

Assuming you're using it under BOINC, you can set that option in the BOINC preferences.

Hi all,

New binaries are posted at https://www.assembla.com/code/genefer/subversion/nodes in the trunk/bin/<os> directories. New features include:

• Working CUDA and OpenCL applications featuring the new error recovery from genefer 3.1.2-9
  
• If a CPU test falls back to a slower (higher B limit) transform, it will carry on from the previous checkpoint rather than restarting from the beginning. This addresses the issues Honza reported on the GFN262144 port.
  
• As a side effect, the checkpoint file is independent of the transform, so it is possible to start a calculation with AVX, stop, then restart with CUDA!
  
• Note, as this is a beta release, I have not incremented the checkpoint version number. Please ensure you delete any existing checkpoint files before restarting with the new app.
  

If you're not too busy running the current GFN challenge, please test and continue to post results here!

Cheers

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

Thanks for new builds.

Updated to latest version which started test from scratch. It OK, checkpoint from old version. Aborted the test so restarting from checkpoint can be tested.
What I found interesting: It started on SSE2 then switched to SSE3, not the other way around.

Other instances started using AVX and holding so far.

c:\_Honza\PRPNet.1>prpclient.exe
[2014-01-08 15:35:43 SE(Ŕ] PRPNet Client application v5.3.0 started
[2014-01-08 15:35:43 SE(Ŕ] User name Honza at email address is x@xxx.xx
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default sse2 x87 sse3

Command line: genefer_windows64.exe work_GFN262144.in

Priority change succeeded.
Start test of file 'work_GFN262144.in' - 15:35:43
Testing 1039322^262144+1...
Using SSE2 transform
Resuming 1039322^262144+1 from a checkpoint (5233521 iterations left)
Estimated total run time for 1039322^262144+1 is 11:57:43
Testing 1039322^262144+1... 5230592 steps to go (11:56:30 remaining)
maxErr exceeded for 1039322^262144+1, 0.5000 > 0.4500
maxErr exceeded while using SSE2; switching to SSE3.
Testing 1039322^262144+1...
Using SSE3 transform
Resuming 1039322^262144+1 from a checkpoint (5233521 iterations left)
Estimated total run time for 1039322^262144+1 is 12:42:42
Testing 1039322^262144+1... 5210112 steps to go (12:38:25 remaining)

Hi Honza, thanks for the testing!

Updated to latest version which started test from scratch. It OK, checkpoint from old version.

Aborted the test so restarting from checkpoint can be tested.

What I found interesting: It started on SSE2 then switched to SSE3, not the other way around.

Other instances started using AVX and holding so far.

This is working as designed, you have one of the particular host/WU combinations where SSE2 is faster than SSE3. For SSE2 the runtime estimate is 11:57:43, and for SSE3 it is 12:42:42

This one is interesting...
Started using AVX, then SSE3, SSE2, Default and x87.
Aboarted to see if it can continue from checkpoint and it did - using AVX, whereby completing using AVX and saving a lot of time.

Start test of file 'work_GFN262144.in' - 02:59:13
Testing 1040142^262144+1...
Using AVX transform

Starting initialization...
Initialization complete (0.874 seconds).
Estimated total run time for 1040142^262144+1 is 5:01:06
Testing 1040142^262144+1... 4624384 steps to go (4:25:44 remaining)
maxErr exceeded for 1040142^262144+1, 0.4531 > 0.4500
maxErr exceeded while using AVX; switching to SSE3.
Testing 1040142^262144+1...
Using SSE3 transform
Resuming 1040142^262144+1 from a checkpoint (4628479 iterations left)
Estimated total run time for 1040142^262144+1 is 8:56:49
Testing 1040142^262144+1... 4624384 steps to go (7:53:46 remaining)
maxErr exceeded for 1040142^262144+1, 0.4531 > 0.4500
maxErr exceeded while using SSE3; switching to SSE2.
Testing 1040142^262144+1...
Using SSE2 transform
Resuming 1040142^262144+1 from a checkpoint (4628479 iterations left)
Estimated total run time for 1040142^262144+1 is 11:04:45
Testing 1040142^262144+1... 4624384 steps to go (9:46:40 remaining)
maxErr exceeded for 1040142^262144+1, 0.5000 > 0.4500
maxErr exceeded while using SSE2; switching to Default.
Testing 1040142^262144+1...
Using Default transform
Resuming 1040142^262144+1 from a checkpoint (4628479 iterations left)
Estimated total run time for 1040142^262144+1 is 14:19:40
Testing 1040142^262144+1... 4624384 steps to go (12:38:42 remaining)
maxErr exceeded for 1040142^262144+1, 0.4531 > 0.4500
maxErr exceeded while using Default; switching to x87 (80-bit).
Testing 1040142^262144+1...
Using x87 (80-bit) transform
Resuming 1040142^262144+1 from a checkpoint (4628479 iterations left)
Estimated total run time for 1040142^262144+1 is 32:06:25
Testing 1040142^262144+1... 3682304 steps to go (22:33:47 remaining)
^C caught. Writing checkpoint.
[2014-01-10 09:24:45 CEST] GFN262144: No data in file [genefer.log]. Is genefer broken?

c:\_Honza\PRPNet.1>prpclient.exe
[2014-01-10 09:24:46 CEST] PRPNet Client application v5.2.7 started
[2014-01-10 09:24:46 CEST] User name Honza at email address is x@xxx.xx
It appears that the PRPNet client was aborted without completing
the workunits asigned by server GFN262144. What do you want to do with them?
...
Choose option: 3
...

Command line: genefer_windows64.exe work_GFN262144.in

Priority change succeeded.
Start test of file 'work_GFN262144.in' - 09:24:49
Testing 1040142^262144+1...
Using AVX transform
Resuming 1040142^262144+1 from a checkpoint (3678528 iterations left)
Estimated total run time for 1040142^262144+1 is 5:03:44
1040142^262144+1 is a probable composite. (RES=76e7632c96ac2f4e) (1577345 digits) (err = 0.4062) (time = 9:57:52) 12:59:01
[2014-01-10 12:59:01 CEST] GFN262144: 1040142^262144+1 is not prime. Residue 76e7632c96ac2f4e
[2014-01-10 12:59:01 CEST] Total Time: 3:34:15 Total Work Units: 1 Special Results Found: 0

Assuming that the residual is correct (somebody aught to check that), that is interesting. I'd like to get Yves' thoughts on this one.

To me, this seems like a test that's close to the boundary of where AVX can work. Perhaps in this particular test, the part of the test that is "worst" from a limit perspective is the very beginning, and once it's past that part, it can continue using the much faster AVX.

If that's true, perhaps some thought should be given to whether the "One-strike-and-you're out" strategy for downshifting the transform isn't the best when you're near the boundary. Trying to shift back to faster transforms might be advantageous. The logic would have to be a lot smarter if we do that. We need to identify when it's hopeless and not repeatedly waste time trying to run AVX when b is way beyond what AVX can handle.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

If that's true, perhaps some thought should be given to whether the "One-strike-and-you're out" strategy for downshifting the transform isn't the best when you're near the boundary. Trying to shift back to faster transforms might be advantageous. The logic would have to be a lot smarter if we do that. We need to identify when it's hopeless and not repeatedly waste time trying to run AVX when b is way beyond what AVX can handle.

Assuming that the residual is correct (somebody aught to check that)

If you're not too busy running the current GFN challenge, please test and continue to post results here!

Cheers

- Iain

Successfully tested a GFN262144:

Benchmarks are repeated at the start of every test. Not only might the system perform differently with a different n (or b), but environmental conditions could have changed which might affect performance.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Hi all, new binaries are posted at https://www.assembla.com/code/genefer/subversion/nodes in the trunk/bin/<os> directories. At the moment, only Windows available as my main dev box is down for a HDD restore :(

This version introduces a scheme to automatically restart the calculation with a faster transform after a maxErr is encountered and successfully recovered using a slower transform. I have done some testing, but would be good to see how the behaviour works with 'close-to-B-limit' tests that are current available via PRPNet.

The checkpoint file format is the same, so you can just drop this app in as a replacement for the current binary without any worries!

Please have a go and let me know the results.

Cheers

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

Iain's commit message in the source control describes the implemented algorithm:

Author: ibethune
2014-02-01 15:41 (about 2 hours ago)

Allow transform 'up-shift' after successful progress with a slower transform. Algorithm is as follows:
* When down-shifting, only attempt to compute as far as the next checkpoint.
* When the checkpoint is reached, restart with the fastest available transform (subject to the following rule):
** If a maxErr exceeded is encountered, this increments a counter (per transform).
** A penalty of 5 is applied if the maxErr is encountered before reaching a checkpoint as this indicates the transform is likely past the B limit.
** Once the count reaches 10 that transform is blacklisted and will no longer be used.

This should reduce the impact of 'transient' maxErrs - we can see 10 within a calculation and still continue with the fast transform. 'hard' maxErrs i.e. beyond the B limit, we will stop using the transform after seeing 2 of these (just to be sure). The total of 10 and penalty of 5 might need tuning.

So far so good.

Roger, I guess up-shift to faster transform after checkpoint should work fine, there are enough intervations between.
What I wish for is that let the checkpoint interval be set via .ini file. I've mentioned elsewhere that checkpointing is a bit I/O intensive - especially for machines running 24/7 with bunch of cores.

Testing 1045004^262144+1...
Using AVX transform

Starting initialization...
Initialization complete (0.811 seconds).
Estimated total run time for 1045004^262144+1 is 5:05:19
Testing 1045004^262144+1... 2502656 steps to go (2:25:46 remaining)
maxErr exceeded for 1045004^262144+1, 0.4531 > 0.4500
maxErr exceeded while using AVX; switching to SSE3.
Testing 1045004^262144+1...
Using SSE3 transform
Resuming 1045004^262144+1 from a checkpoint (2502655 iterations left)
Estimated total run time for 1045004^262144+1 is 9:03:48

maxErr exceeded for 1045004^262144+1, 0.4531 > 0.4500
maxErr exceeded while using SSE3; switching to SSE2.
Testing 1045004^262144+1...
Using SSE2 transform
Resuming 1045004^262144+1 from a checkpoint (2502655 iterations left)
Estimated total run time for 1045004^262144+1 is 11:03:45

maxErr exceeded for 1045004^262144+1, 0.4688 > 0.4500
maxErr exceeded while using SSE2; switching to Default.
Testing 1045004^262144+1...
Using Default transform
Resuming 1045004^262144+1 from a checkpoint (2502655 iterations left)
Estimated total run time for 1045004^262144+1 is 14:29:34
Successful computation progress with Default; switching back to AVX.)
Testing 1045004^262144+1...
Using AVX transform
Resuming 1045004^262144+1 from a checkpoint (2498559 iterations left)
Estimated total run time for 1045004^262144+1 is 5:12:08
1045004^262144+1 is a probable composite. (RES=0de8012d27aa62c2) (1577876 digits) (err = 0.4062) (time = 5:05:08) 10:15:13
[2014-02-02 10:15:13 CEST] GFN262144: 1045004^262144+1 is not prime. Residue 0de8012d27aa62c2

Thanks Honza, that appears to be working as designed. For the record, I retested 1040142^262144+1 with the new code and got a matching residue, so all seems to be working well.

It should be fairly straightforward to limit the checkpoint rate according to a value in a file. Do you want this to be a time-based measure i.e. to checkpoint every X seconds? This is similar to BOINC, where we currently only checkpoint after a certain amount of time (set by the client) has elapsed.

My only critique is that maybe should do more than one checkpoint on a successful transform, otherwise will bounce through the faster transforms too quickly.

Yes, I prefer a time-based measure. We are used to it, this makes it easier for participants.
Iteration-based would require a bit of math - different N's and speed among transforms, CUDA etc.

Thanks Honza, that appears to be working as designed. For the record, I retested 1040142^262144+1 with the new code and got a matching residue, so all seems to be working well.

It should be fairly straightforward to limit the checkpoint rate according to a value in a file. Do you want this to be a time-based measure i.e. to checkpoint every X seconds? This is similar to BOINC, where we currently only checkpoint after a certain amount of time (set by the client) has elapsed.

Resuming application after Ctrl-C works fine:

Is there a plan for an OpenCL version with auto-transform shifting?
GFN524288 on PRPnet still has ~50,000 worth of b left for OpenCL but I am getting about 1 in 5 WUs fail due to maxErr.

Is there a plan for an OpenCL version with auto-transform shifting?
GFN524288 on PRPnet still has ~50,000 worth of b left for OpenCL but I am getting about 1 in 5 WUs fail due to maxErr.

Is there a plan for an OpenCL version with auto-transform shifting?

Back on topic, Iain, if/when a Linux version of the latest source is available, let us know if you need testing assistance.
--Gary

Is there a plan for an OpenCL version with auto-transform shifting?

Not at the moment - we only have one implementation of the transform using OpenCL, and to an extent it auto-tunes itself for better performance. There is no 'high B limit' OpenCL implementation, so nothing to shift down to once the current transform hits maxErr exceeded. It is *possible* (with some implementation effort), to combine OpenCL (or CUDA) with the CPU transforms, but I don't have an immediate plan to do so.

- Iain

Is there a plan for an OpenCL version with auto-transform shifting?

Not at the moment - we only have one implementation of the transform using OpenCL, and to an extent it auto-tunes itself for better performance. There is no 'high B limit' OpenCL implementation, so nothing to shift down to once the current transform hits maxErr exceeded. It is *possible* (with some implementation effort), to combine OpenCL (or CUDA) with the CPU transforms, but I don't have an immediate plan to do so.

- Iain

Actually, what would be most useful at the moment (I think) would be an OpenCL version that auto-transforms to CUDA with maxerr. The failure rate of the OpenCL app is much higher on Kepler cards than CUDA, but it is typically 40% faster. It would be really nice to have an OpenCL app that shifts to CUDA when encountering maxerr (even if it doesn't shift back) to allow these to complete a bit slower rather than failing outright.

Running latest Genefer for ~3 days, run times are much more consistent.
Variability can be attributed rather to different CPU loads using other apps than up-shift/down-shift transformations.
For sure, the average run-time is now lower :-)

Well done.

I expect total time per task to be much more similar to each other, i.e. smaller variability.
Running GFN262144 for a while using 3 instances, I've got 200+ WUs from each instance to compare with.
GeneferAVX B limit is ~1,065,000, we are doing ~8K (1K tests) a month and with recent 1,045,072 we should be there in ~2 months. (I can put x10 CPU power to this and find out in a week but guess there is no rush).

Running latest Genefer for ~3 days, run times are much more consistent.
Variability can be attributed rather to different CPU loads using other apps than up-shift/down-shift transformations.
For sure, the average run-time is now lower :-)

Well done.

17 tests so far with GFN262144, all good. Will be interesting over the next 2.5 months as this port heads to the SSE3/AVX hard limit at 1,065,000. No downshifts so far for me to 80-bit unlike this test: http://www.primegrid.com/forum_thread.php?id=5389&nowrap=true#72555

Is there a plan for an OpenCL version with auto-transform shifting?

Not at the moment - we only have one implementation of the transform using OpenCL, and to an extent it auto-tunes itself for better performance. There is no 'high B limit' OpenCL implementation, so nothing to shift down to once the current transform hits maxErr exceeded. It is *possible* (with some implementation effort), to combine OpenCL (or CUDA) with the CPU transforms, but I don't have an immediate plan to do so.

- Iain

Actually, what would be most useful at the moment (I think) would be an OpenCL version that auto-transforms to CUDA with maxerr. The failure rate of the OpenCL app is much higher on Kepler cards than CUDA, but it is typically 40% faster. It would be really nice to have an OpenCL app that shifts to CUDA when encountering maxerr (even if it doesn't shift back) to allow these to complete a bit slower rather than failing outright.

From a linking perspective, I'm not sure if that's possible with a single executable. I think it would have to be a multi-executable app, with a master app that calls different OpenCL and CUDA apps when needed. More complicated, but not impossible.

I'm only guessing about not being to link CUDA and OpenCL together. It's conceivable it can be done.

Here's a linux-64-bit test run, using the number used in post 71280:

Apart from being slower, is there any evidence that SSE3 (and SSE2) transform is more accurate than AVX? Since they all use IEEE 64-bit, shouldn't they all work out to roughly the same capability? If so, isn't it better to directly failover from AVX (or SSE3/2) to x87 and back?

PS:- It is possible that a (new, would be) transform using Haswell FMA instructions can be more accurate than AVX/SSE3/SSE2, in which case the fastest would also become the best.

Apart from being slower, is there any evidence that SSE3 (and SSE2) transform is more accurate than AVX? Since they all use IEEE 64-bit, shouldn't they all work out to roughly the same capability? If so, isn't it better to directly failover from AVX (or SSE3/2) to x87 and back?

PS:- It is possible that a (new, would be) transform using Haswell FMA instructions can be more accurate than AVX/SSE3/SSE2, in which case the fastest would also become the best.

Just posted a Windows CUDA 3.2.0-0beta binary in https://www.assembla.com/code/genefer/subversion/nodes in the trunk/bin/windows directory. Please go ahead and test - there are a couple of things particularly to look for:

• My build environment is different to Mike's previous one, so please report if for any reason the binary doesn't work on your system.
  
  
• I have built with CUDA 5.5 but I believe it should still run on systems with earlier CUDA SDKs / drivers installed
  
  
• There are some small improvements to the CUDA kernels (these have been present in recent linux & mac builds), which might give up to 5% speed improvement, especially for large N.
  
  
• The windows build now includes code generated for CC 1.3, 2.0, 3.0 and 3.5, so might run a little faster on modern cards.
  

Let me know if you have success or not!

Cheers

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

Also a Windows OpenCL binary is now available in SVN. Please download and test! It should be exactly the same performance-wise as the current 3.1.2 binary. It's build using the Nvidia OpenCL stack, so if someone has an ATI/AMD card to test on that would be great. I think it should work, but I don't have the hardware to test.

Cheers

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

GTX 645 on Win Vista Home Premium 64-bit driver 331.82

GFN 524288 PRPnet port

Old CUDA Est. run time: 9 hours 15 minutes
New CUDA Est. run time: Not Applicable...will not run without CUDA 5.5 dll files

Old OCL Est. run time: 7 hours 34 minutes
New OCL Est. run time: 7 hours 36 minutes


EDIT:

Added the CUDA 5.5 files manually and it is faster by a good margin.

New CUDA Est. run time: 8 hours 15 minutes (That's about 12% faster!).

Win 7, i5-3570, HD7950.

Running on platform 'AMD Accelerated Parallel Processing', device 'Tahiti', version 'OpenCL 1.2 AMD-APP (1124.2)' and driver '1124.2 (VM)'.

...
Running benchmarks for transform implementation "OCL"
14^262144+1 300451 digits 0 days 0.1 hours (0.39 ms/mul, 998074 iterations) 21978 GFLOPS
75898^262144+1 1279324 digits 0 days 0.4 hours (0.42 ms/mul, 4249818 iterations) 93581 GFLOPS
468750^262144+1 1486604 digits 0 days 0.5 hours (0.39 ms/mul, 4938388 iterations) 108744 GFLOPS
815000^262144+1 1549575 digits 0 days 0.6 hours (0.42 ms/mul, 5147574 iterations) 113350 GFLOPS

14^524288+1 600902 digits 0 days 0.3 hours (0.72 ms/mul, 1996149 iterations) 92097 GFLOPS
75898^524288+1 2558647 digits 0 days 1.6 hours (0.69 ms/mul, 8499637 iterations) 392151 GFLOPS
468750^524288+1 2973207 digits 0 days 1.8 hours (0.67 ms/mul, 9876777 iterations) 455688 GFLOPS
710000^524288+1 3067745 digits 0 days 1.9 hours (0.71 ms/mul, 10190825 iterations) 470178 GFLOPS

14^1048576+1 1201803 digits 0 days 1.3 hours (1.23 ms/mul, 3992299 iterations) 385133 GFLOPS
75898^1048576+1 5117293 digits 0 days 5.7 hours (1.22 ms/mul, 16999276 iterations) 1639903 GFLOPS
468750^1048576+1 5946413 digits 0 days 6.6 hours (1.21 ms/mul, 19753555 iterations) 1905606 GFLOPS
700000^1048576+1 6129030 digits 0 days 6.7 hours (1.20 ms/mul, 20360194 iterations) 1964127 GFLOPS

14^2097152+1 2403605 digits 0 days 5.4 hours (2.45 ms/mul, 7984600 iterations) 1607512 GFLOPS
75898^2097152+1 10234585 digits 0 days 23.1 hours (2.45 ms/mul, 33998553 iterations) 6844813 GFLOPS
380742^2097152+1 11703432 digits 1 days 2.1 hours (2.42 ms/mul, 38877955 iterations) 7827166 GFLOPS
570000^2097152+1 12070945 digits 1 days 2.6 hours (2.40 ms/mul, 40098808 iterations) 8072956 GFLOPS

14^4194304+1 4807210 digits 0 days 21.6 hours (4.88 ms/mul, 15969202 iterations) 6697969 GFLOPS
1248^4194304+1 12986466 digits 2 days 9.5 hours (4.80 ms/mul, 43140102 iterations) 18094270 GFLOPS
10000^4194304+1 16777217 digits 3 days 3.2 hours (4.86 ms/mul, 55732704 iterations) 23375990 GFLOPS
50000^4194304+1 19708909 digits 3 days 15.9 hours (4.84 ms/mul, 65471576 iterations) 27460769 GFLOPS
150000^4194304+1 21710101 digits 3 days 22.6 hours (4.72 ms/mul, 72119391 iterations) 30249065 GFLOPS
309258^4194304+1 23028076 digits 4 days 5.1 hours (4.76 ms/mul, 76497608 iterations) 32085422 GFLOPS
480000^4194304+1 23828853 digits 4 days 7.5 hours (4.71 ms/mul, 79157734 iterations) 33201160 GFLOPS
____________
My stats

Win 7, Intel E7400, R280X.

Running on platform 'AMD Accelerated Parallel Processing', device 'Tahiti', version 'OpenCL 1.2 AMD-APP (1348.5)' and diver '1348.5 (VM)'.

Running benchmarks for transform implementation "OCL"

...

14^262144+1 300451 digits 0 days 0.0 hours (0.34 ms/mul, 998074 iterations) 21978 GFLOPS
75898^262144+1 1279324 digits 0 days 0.3 hours (0.33 ms/mul, 4249818 iterations) 93581 GFLOPS
468750^262144+1 1486604 digits 0 days 0.4 hours (0.34 ms/mul, 4938388 iterations) 108744 GFLOPS
815000^262144+1 1549575 digits 0 days 0.5 hours (0.36 ms/mul, 5147574 iterations) 113350 GFLOPS

14^524288+1 600902 digits 0 days 0.3 hours (0.66 ms/mul, 1996149 iterations) 92097 GFLOPS
75898^524288+1 2558647 digits 0 days 1.5 hours (0.66 ms/mul, 8499637 iterations) 392151 GFLOPS
468750^524288+1 2973207 digits 0 days 1.8 hours (0.67 ms/mul, 9876777 iterations) 455688 GFLOPS
710000^524288+1 3067745 digits 0 days 1.8 hours (0.66 ms/mul, 10190825 iterations) 470178 GFLOPS

14^1048576+1 1201803 digits 0 days 1.2 hours (1.09 ms/mul, 3992299 iterations) 385133 GFLOPS
75898^1048576+1 5117293 digits 0 days 5.1 hours (1.09 ms/mul, 16999276 iterations) 1639903 GFLOPS
468750^1048576+1 5946413 digits 0 days 6.0 hours (1.09 ms/mul, 19753555 iterations) 1905606 GFLOPS
700000^1048576+1 6129030 digits 0 days 6.2 hours (1.11 ms/mul, 20360194 iterations) 1964127 GFLOPS

14^2097152+1 2403605 digits 0 days 4.7 hours (2.14 ms/mul, 7984600 iterations) 1607512 GFLOPS
75898^2097152+1 10234585 digits 0 days 20.3 hours (2.16 ms/mul, 33998553 iterations) 6844813 GFLOPS
380742^2097152+1 11703432 digits 0 days 23.1 hours (2.14 ms/mul, 38877955 iterations) 7827166 GFLOPS
570000^2097152+1 12070945 digits 1 days 0.0 hours (2.16 ms/mul, 40098808 iterations) 8072956 GFLOPS

14^4194304+1 4807210 digits 0 days 19.0 hours (4.30 ms/mul, 15969202 iterations) 6697969 GFLOPS
1248^4194304+1 12986466 digits 2 days 3.4 hours (4.30 ms/mul, 43140102 iterations) 18094270 GFLOPS
10000^4194304+1 16777217 digits 2 days 17.7 hours (4.25 ms/mul, 55732704 iterations) 23375990 GFLOPS
50000^4194304+1 19708909 digits 3 days 5.2 hours (4.25 ms/mul, 65471576 iterations) 27460769 GFLOPS
150000^4194304+1 21710101 digits 3 days 13.1 hours (4.25 ms/mul, 72119391 iterations) 30249065 GFLOPS
309258^4194304+1 23028076 digits 3 days 17.9 hours (4.23 ms/mul, 76497608 iterations) 32085422 GFLOPS
480000^4194304+1 23828853 digits 3 days 21.1 hours (4.24 ms/mul, 79157734 iterations) 33201160 GFLOPS

Gave it a try, even b limit is passed.
It was all OK until WU actually finished - with maxerr.

c:\_PG>geneferocl-windows.exe -q "1052182^262144+1"
geneferocl 3.2.0beta-0 (Windows/OpenCL/32-bit)
Copyright 2001-2014, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2014, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: geneferocl-windows.exe -q 1052182^262144+1


Running on platform 'AMD Accelerated Parallel Processing', device 'Tahiti', version 'OpenCL 1.2 AMD-APP (1124.2)' and driver '1124.2 (VM)'.

Testing 1052182^262144+1...
Using OCL transform

Starting initialization...
Initialization complete (1.395 seconds).
Estimated total run time for 1052182^262144+1 is 0:35:34
Testing 1052182^262144+1... 65536 steps to go (0:00:26 remaining)
maxErr exceeded for 1052182^262144+1, 0.4844 > 0.4500
maxErr exceeded by all available transform implementations

This one looks OK.

c:\_PG>geneferocl-windows.exe -q "24518^262144+1"

Testing 24518^262144+1...
Using OCL transform

Starting initialization...
Initialization complete (1.095 seconds).
Estimated total run time for 24518^262144+1 is 0:27:00
24518^262144+1 is a probable prime. (1150678 digits) (err = 0.0003) (time = 0:26:23) 18:57:38

GTX 645 on Win Vista Home Premium 64-bit driver 331.82

GFN 524288 PRPnet port

Old CUDA Est. run time: 9 hours 15 minutes
New CUDA Est. run time: Not Applicable...will not run without CUDA 5.5 dll files

Old OCL Est. run time: 7 hours 34 minutes
New OCL Est. run time: 7 hours 36 minutes


EDIT:

Added the CUDA 5.5 files manually and it is faster by a good margin.

New CUDA Est. run time: 8 hours 15 minutes (That's about 12% faster!).

• faster for the 600
  
• even faster for the 700
  
• equal with minimal improvements for the 500
  
• slower for the 400 series
  

The linux applications are linked against Cuda3.2 and the current Cuda version since a while now. I have not read anything by the PG community about a performance improvement in the interim. My hope with Cuda5.0 was that this version would unleash the maximum performance of the freshly released GTX Titan. But a GTX Titan or the entire series 600 and 700 in combination with Linux were not an often used combination here on Primegrid in the past. I think the main problem was the low DP-performance of the entire 600 and 700 series. The Cuda5.0-app will not be updated anymore since august 2013. I upgraded to Cuda5.5 and have upgrade plans for Cuda6.0 after their release but you can recompile the sources against all Cuda versions since 3.2.
____________
Best wishes. Knowledge is power. by jjwhalen

hi i run test on prpnet and it works cuda to avx

Started with b=1046946 (over b limit) on OpenCL.
>geneferocl-windows.exe -q "1046946^262144+1"

Got it to the end with marerr.
Trying to resume using Genefer64 made it stop working.
Perhaps OpenCL wrote nonsense to checkpoint file.
____________
My stats

Speed comparisons:

All tests on C2Q Q6600 with GTX 460.

Old 3.1.2 (CUDA 3.2):

Thanks Honza,

I'm looking at this - it should work, so there is evidently a bug here…

- Iain

Started with b=1046946 (over b limit) on OpenCL.
>geneferocl-windows.exe -q "1046946^262144+1"

Got it to the end with marerr.
Trying to resume using Genefer64 made it stop working.
Perhaps OpenCL wrote nonsense to checkpoint file.

Hi Honza,

Can you send me the output you got from the restart with genefer? Also if you have a copy of the checkpoint file that would be great? I have tried on Linux but not able to recreate the problem so far.

For reference, the residues I got for your two tests were:

1052182^262144+1 - 56bc7bb02840dabe
1046946^262144+1 - f4696dd0281b538e

- Iain

Thanks Honza,

I'm looking at this - it should work, so there is evidently a bug here…

- Iain

Started with b=1046946 (over b limit) on OpenCL.
>geneferocl-windows.exe -q "1046946^262144+1"

Got it to the end with marerr.
Trying to resume using Genefer64 made it stop working.
Perhaps OpenCL wrote nonsense to checkpoint file.

hi i run test on prpnet and it works cuda to avx

Started using OpenCL on R280X, got maxerr

Testing 1046946^262144+1...
Using OCL transform

Starting initialization...
Initialization complete (2.157 seconds).
Estimated total run time for 1046946^262144+1 is 0:31:27
Testing 1046946^262144+1... 65536 steps to go (0:00:23 remaining)
maxErr exceeded for 1046946^262144+1, 0.5000 > 0.4500
maxErr exceeded by all available transform implementations

c:\_Honza\xxl>genefer_windows64.exe -q "1046946^262144+1"
genefer 3.2.0beta-0 (Windows/CPU/64-bit)
Supported transform implementations: default sse2 x87 sse3

Command line: genefer_windows64.exe -q 1046946^262144+1

Priority change succeeded.
No relevant benchmark data exists, testing available transform implementations...
Benchmarks completed (53.094 seconds).
Testing 1046946^262144+1...
Using SSE3 transform
Resuming 1046946^262144+1 from a checkpoint (65535 iterations left)
Estimated total run time for 1046946^262144+1 is 12:29:28
1046946^262144+1 is a probable composite. (RES=f4696dd0281b538e) (1578088 digits) (err = 0.3750) (time = 0:38:27)