Hi all,

After some delay (sorry!) version 3.3.0 of Genefer is now ready for comprehensive testing, leading up to us deploying the apps on BOINC. Quite a lot has gone in to the new release including the new OCL4/5 transforms as well as some changes to the transform switching and b-limit logic, so the test process will be quite extensive. Binaries are available from SVN:

Windows: https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/bin/windows

Linux: https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/bin/linux

Mac: https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/bin/mac

There is a full list of tests, with some instructions for how and what to run on a google sheet:

https://docs.google.com/spreadsheets/d/1dsyr9e6iSlvVZZa4qQpuJ6QxBXuSrxL1qQIBL4OpI0Q/

There are a large set of manual tests, for n=16,17 and n=22 (which will take a long time, unfortunately!), and also some BOINC tests to run under app_info.xml. Please check carefully as some tests require specifying the transform to use (via the -x option), and some leave genefer free to select the appropriate transform.

Please post into this thread if you want to reserve tests, and if you have results and/or questions. I will try to keep the thread clean by hiding posts when I update the google sheet.

Thanks in advance for the help - the more people contribute, the sooner we can start using the new apps.

Cheers

- Iain


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

uh oh.
...
Using OCL4 transform
...
Running on platform 'Apple', device 'ATI Radeon HD Tahiti XT Prototype Compute Engine', version 'OpenCL 1.2 ' and driver '1.2 (Dec 17 2015 21:00:16)'.
...
Error: build program failed.
Error returned by cvms_element_build_from_source
Error: OpenCL error detected: CL_BUILD_PROGRAM_FAILURE.
Errors occurred for all available transform implementations

I'll help out if I can :D
First few tests on a titan X, Windows 7

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

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

I'm looking into this...

I'll help out if I can :D
First few tests on a titan X, Windows 7

Hi these ones are duplicates of work ich_eben* has already done. I'm trying to keep the spreadsheet up-to-date, but please check back in the thread too.

Useful to see results from different hardware and OS though - thanks!

No ocl3 testing for gfn-22?

Error! Fail to load fglrx kernel module! Maybe you can switch to root user to load kernel module directly
Error! Fail to load fglrx kernel module! Maybe you can switch to root user to load kernel module directly
Error! Fail to load fglrx kernel module! Maybe you can switch to root user to load kernel module directly

Error: No root privilege. Please check with the system-admin.
Error: No root privilege. Please check with the system-admin.
Error: No root privilege. Please check with the system-admin.

Cannot open 'ocl5'
Fatal error (3). Genefer is terminating.

This is on windows with the modified file. it loops the error.

> genefer_windows64.exe -q "1927034^65536+1"
genefer 3.3.0-debug (Windows/CPU/64-bit)
Supported transform implementations: fma3 avx-intel sse4 sse2 default x87
Copyright 2001-2016, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2014, Michael Goetz, Ronald Schneider
Copyright 2011-2016, Iain Bethune
Genefer is free source code, under the MIT license.

Command line: genefer_windows64.exe -q 1927034^65536+1

Priority change succeeded.
Default transform is past its b limit.

Testing 1927034^65536+1...
Using FMA3 transform
Resuming 1927034^65536+1 from a checkpoint (1339558 iterations left)
Closing genefer.ckpt.new after write: Bad file descriptor remaining)
Stat genefer.ckpt: Bad file descriptor
Rename genefer.ckpt to genefer.ckpt.old: Bad file descriptor
Rename genefer.ckpt.new to genefer.ckpt: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Remove genefer.ckpt.old: Bad file descriptor
Estimated time remaining for 1927034^65536+1 is 0:09:38
Closing genefer.ckpt.new after write: Bad file descriptor remaining)
Stat genefer.ckpt: Bad file descriptor
Rename genefer.ckpt to genefer.ckpt.old: Bad file descriptor
Rename genefer.ckpt.new to genefer.ckpt: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Remove genefer.ckpt.old: Bad file descriptor

^C caught. Writing checkpoint.
Closing genefer.ckpt.new after write: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Rename genefer.ckpt to genefer.ckpt.old: Bad file descriptor
Rename genefer.ckpt.new to genefer.ckpt: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Remove genefer.ckpt.old: Bad file descriptor

No ocl3 testing for gfn-22?

This is on windows with the modified file. it loops the error.

> genefer_windows64.exe -q "1927034^65536+1"
genefer 3.3.0-debug (Windows/CPU/64-bit)

Closing genefer.ckpt.new after write: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Rename genefer.ckpt to genefer.ckpt.old: Bad file descriptor
Rename genefer.ckpt.new to genefer.ckpt: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Remove genefer.ckpt.old: Bad file descriptor

I'm not sure why OCL5 is on there; that might be a mistake. Iain will give you a definitive answer later on (it's the middle of the night in his part of the world.)

On another note -- everyone might want to hold off STARTING any new tests before I get a chance to confer with Iain. I've been testing other parts of the apps and have discovered some problems that will need fixing, so we might need to fix, build, and test everything again.

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

I added some debug statements so every time genefer checkpoints, you should see (if all is well):

Closing genefer.ckpt.new after write: No error Stat genefer.ckpt: No error Rename genefer.ckpt to genefer.ckpt.old: No error Rename genefer.ckpt.new to genefer.ckpt: No error Stat genefer.ckpt: No error Remove genefer.ckpt.old: No error

Is there any benefit to continuing to run the longer tests, given that they'll need to be re-run? I've got 5 running now which have between 50 and 180 hours left.

I'm not sure why OCL5 is on there; that might be a mistake. Iain will give you a definitive answer later on (it's the middle of the night in his part of the world.)

OCL4 doesn't work on Mac/ATI, and I believe OCL5 might be faster than OCL4 on some cards (pre-Kepler nvidia cards?).

On another note -- everyone might want to hold off STARTING any new tests before I get a chance to confer with Iain. I've been testing other parts of the apps and have discovered some problems that will need fixing, so we might need to fix, build, and test everything again.

Yes - Please don't start any new tests. Continue to post results for anything that you currently have running. I will update when I have more info re: the problems that Mike found.

- Iain

Iain, successful execution of the function will NOT reset errno to zero/"No error". You must always check exit code of each function first. Otherwise you'll get a mess referencing an error which happened long time ago, as we've already seen few posts below.

...
Note that it happened when task was restarted after system crash and checkpoint file may has been corrupted. After these two messages, it checkpointed normally. And finally, the task validated. Full log: http://www.primegrid.com/result.php?resultid=693668117

Roman

This is on windows with the modified file. it loops the error.

> genefer_windows64.exe -q "1927034^65536+1"
genefer 3.3.0-debug (Windows/CPU/64-bit)

Closing genefer.ckpt.new after write: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Rename genefer.ckpt to genefer.ckpt.old: Bad file descriptor
Rename genefer.ckpt.new to genefer.ckpt: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Remove genefer.ckpt.old: Bad file descriptor

Thanks, I'm looking into it.

- Iain

Is there any benefit to continuing to run the longer tests, given that they'll need to be re-run? I've got 5 running now which have between 50 and 180 hours left.

How big should the genefer.ckpt file be getting on gfn22?

I haven't noticed anything this big before, but I wasn't necessarily looking, either.

03/03/2016 02:07 PM 40,888,256 genefer.ckpt

How big should the genefer.ckpt file be getting on gfn22?

I haven't noticed anything this big before, but I wasn't necessarily looking, either.

03/03/2016 02:07 PM 40,888,256 genefer.ckpt

How big should the genefer.ckpt file be getting on gfn22?

I haven't noticed anything this big before, but I wasn't necessarily looking, either.

03/03/2016 02:07 PM 40,888,256 genefer.ckpt

That big. :)

The checkpoint file's size is directly proportional to the size of the number being checked.

The windows/amd ocl5 test for 64996^4194304+1 hit maxerr and aborted. This may have been my fault as I was running this at the same time as the same test using plain ocl, each on one of the cores of a 7990, but I neglected to launch each from a separate directory.

I have started each from scratch, each in their own directory so there isn't any file contention.

The windows/amd ocl5 test for 64996^4194304+1 hit maxerr and aborted. This may have been my fault as I was running this at the same time as the same test using plain ocl, each on one of the cores of a 7990, but I neglected to launch each from a separate directory.

I have started each from scratch, each in their own directory so there isn't any file contention.

So far, so good, and its about halfway through the unit on ocl5, which is farther than it was when it errored out. I am still convinced it was my fault, running 2 manual instances in the same directory, and there being contention over the checkpoint file.

However, the run time seems a but long. This machine has completed (and validated) 30 gfn 22 units since brought online december 15. The longest run time for any of those was 59 1/3 hours. The estimated time seems spot on, and the workload on the box is identical to its standard workload, save the 22 units are launched command line rather than by boinc.

...
Estimated time remaining for 64996^4194304+1 is 58:07:27
64996^4194304+1 is composite. (RES=80849c1616f3bdf9) (20186710 digits) (err = 0.0076) (time = 67:14:50) 03:42:14

Benchmark gives

Command line: ..\geneferocl_windows.exe -b -x ocl

Priority change succeeded.
Priority change succeeded.
Generalized Fermat Number Bench
Running benchmarks for transform implementation "OCL"

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

2199064^8192+1 Time: 70.3 us/mul. Err: 0.2031 51956 digits
1798620^16384+1 Time: 66.3 us/mul. Err: 0.1875 102481 digits
1471094^32768+1 Time: 81 us/mul. Err: 0.1875 202102 digits
1203210^65536+1 Time: 89.5 us/mul. Err: 0.1719 398482 digits
984108^131072+1 Time: 114 us/mul. Err: 0.1787 785521 digits
804904^262144+1 Time: 384 us/mul. Err: 0.1719 1548156 digits
658332^524288+1 Time: 416 us/mul. Err: 0.1875 3050541 digits
538452^1048576+1 Time: 828 us/mul. Err: 0.1641 6009544 digits
440400^2097152+1 Time: 1.57 ms/mul. Err: 0.1738 11836006 digits
360204^4194304+1 Time: 3.05 ms/mul. Err: 0.1562 23305854 digits
294612^8388608+1 Time: 6.1 ms/mul. Err: 0.1592 45879398 digits
Genefer Mark = 131.
Priority change succeeded.

What is somewhat interesting is that the initial estimate is what it "should" be, but the immediately reported time remaining is closer to what winds up being the run time.

Starting initialization...
Initialization complete (105.942 seconds).
Estimated time remaining for 64996^4194304+1 is 57:33:33
Testing 64996^4194304+1... 67043328 steps to go (70:08:39 remaining)

This

http://www.primegrid.com/show_host_detail.php?hostid=504933

is the machine in question.

What is somewhat interesting is that the initial estimate is what it "should" be, but the immediately reported time remaining is closer to what winds up being the run time.

Starting initialization...
Initialization complete (105.942 seconds).
Estimated time remaining for 64996^4194304+1 is 57:33:33
Testing 64996^4194304+1... 67043328 steps to go (70:08:39 remaining)

Well, that certainly looks more accurate

Testing 64996^4194304+1...
Using OCL transform

Running on platform 'Apple', device 'ATI Radeon HD Tahiti XT Prototype Compute Engine', version 'OpenCL 1.2 ' and driver '1.2 (Dec 17 2015 21:00:16)'.

Starting initialization...
Initialization complete (55.661 seconds).
Estimated time remaining for 64996^4194304+1 is 74:41:37
Testing 64996^4194304+1... 67043328 steps to go (74:22:56 remaining)

Any chance you could throw a windows version out there? The system which was producing the slower-than-expected results was a one of those.

The mac producing the above output has historically completed 22 units in no greater than 74.5 hours, so that looks pretty spot on.

Would there be any objection to testing "live" via boinc/app_info on the suspect machine?

Any chance you could throw a windows version out there? The system which was producing the slower-than-expected results was a one of those.

Would there be any objection to testing "live" via boinc/app_info on the suspect machine?

I've been testing combined apps on GFN-20 for some time, both the old 3.2.10-dev and the new 3.3.0. With 3.2.10-dev, many recent tasks (e.g., 691921583) can still be successfully completed using OCL transform, which is significantly faster than OCL4 on my AMD R9-280X. Genefer 3.3.0, however, just notes that "OCL transform is past its b limit." (e.g., 694560388) and goes ahead using OCL4. So there appears to be some more room for improvement in the b-limit logic.

Any chance you could throw a windows version out there? The system which was producing the slower-than-expected results was a one of those.

Here you go: http://www.epcc.ed.ac.uk/~ibethune/files/geneferocl_windows.zip

Any chance you could throw a windows version out there? The system which was producing the slower-than-expected results was a one of those.

Here you go: http://www.epcc.ed.ac.uk/~ibethune/files/geneferocl_windows.zip

Would there be any objection to testing "live" via boinc/app_info on the suspect machine?

Go for it!

This is on windows with the modified file. it loops the error.

> genefer_windows64.exe -q "1927034^65536+1"
genefer 3.3.0-debug (Windows/CPU/64-bit)

Closing genefer.ckpt.new after write: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Rename genefer.ckpt to genefer.ckpt.old: Bad file descriptor
Rename genefer.ckpt.new to genefer.ckpt: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Remove genefer.ckpt.old: Bad file descriptor

Thanks, I'm looking into it.

- Iain

Andrew, there is a new debug binary posted at http://www.epcc.ed.ac.uk/~ibethune/files/genefer330debug.zip
It doesn't solve the problem but might help to clarify the error via some better debugging (thanks to stream). Please retry the same test again.

- Iain

It will take a few hours (days) before it finishes completely, but I started a n22 unit in boinc on my 290x machine. Like the 7990 machine, performance seems to be a bit off.

With 55 min, 25 sec complete, the 290x is 1.184% done, which I believe equates to a 78 hour or so run time. Out of a sample of 11, the longest previous n22 run time on this machine was 71.4 hours.

Once the last (manual) test unit on the 7990 finishes, I'll fire up an app_info test on it as well. I have two boxes with identical hardware, so I can run one with the test ocl and one with production at the same time, with identical workloads.

Interesting that the performance hit doesn't seem to affect a mac.

What do I need to do to log the executable's transform selection whilst running from Boinc?

Closing genefer.ckpt.new after write: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Rename genefer.ckpt to genefer.ckpt.old: Bad file descriptor
Rename genefer.ckpt.new to genefer.ckpt: Bad file descriptor
Stat genefer.ckpt: Bad file descriptor
Remove genefer.ckpt.old: Bad file descriptor

I believe it may have been solved

This makes no sense....

What do I need to do to log the executable's transform selection whilst running from Boinc?

As of this morning, 20.166% done after 14:30 hours, so I should be looking at around 71.9 hours run time, which is pretty close to what I would have expected from this machine.

And from stderr.txt, the initial time estimate

Testing 65946^4194304+1...
Estimated time remaining for 65946^4194304+1 is 71:51:18

For that size task, that is quite accurate.

[edit] The initial startup time before the task actually hit the gpu was nearly 6 minutes, I suspect that will have an impact on any "early" estimates. I actually thought I had something misconfigured until I just let it run. That startup time was 1.5 minutes on a n21 task.[/edit]

[edit2] And by early estimates, I mean manual estimates based on percent completed and time run. [/edit2]

It will take a few hours (days) before it finishes completely, but I started a n22 unit in boinc on my 290x machine. Like the 7990 machine, performance seems to be a bit off.

With 55 min, 25 sec complete, the 290x is 1.184% done, which I believe equates to a 78 hour or so run time. Out of a sample of 11, the longest previous n22 run time on this machine was 71.4 hours.

Once the last (manual) test unit on the 7990 finishes, I'll fire up an app_info test on it as well. I have two boxes with identical hardware, so I can run one with the test ocl and one with production at the same time, with identical workloads.

Interesting that the performance hit doesn't seem to affect a mac.

What do I need to do to log the executable's transform selection whilst running from Boinc?

This makes no sense....

Thanks for investigating... Assuming you did your latest tests using the 3.3.0-debug2 version then the 'Estimated Time Remaining' code is essentially the same as has been in the previous release, so I think these should be as accurate as they have been in the previous standalone apps - can you check if you see the same behaviour with those as with the current app, manually selecting the transform?

- Iain

For a phalanx of pending and validated units on windows/amd
n=19
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=27
n=18
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=26
17low
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=24
n=16
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=23

No errors, no invalid tasks.

This:
http://www.primegrid.com/result.php?resultid=696057063
is the in progress n=22 unit.

These were running the original test executable as of 2 March, and the update Ian provided as of the early morning (EST) of 8 March, when I switched to the 22 unit, so these are likely all on the original test app.

The only observation is that run times are all over the place, with maxerr exceeded on a number of units. http://www.primegrid.com/result.php?resultid=693523497 is a good example.

This will teach me to type before coffee. Apologies Iain.

For a phalanx of pending and validated units on windows/amd
n=19
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=27
n=18
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=26
17low
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=24
n=16
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=23

No errors, no invalid tasks.

This:
http://www.primegrid.com/result.php?resultid=696057063
is the in progress n=22 unit.

These were running the original test executable as of 2 March, and the update Ian provided as of the early morning (EST) of 8 March, when I switched to the 22 unit, so these are likely all on the original test app.

The only observation is that run times are all over the place, with maxerr exceeded on a number of units. http://www.primegrid.com/result.php?resultid=693523497 is a good example.

This is odd. This is using the binary form the 7 March post. Retrying on a 980.

emil:Downloads vzimmerman$ ./geneferocl_macintel -d 1 -q "64996^4194304+1" -x ocl4
geneferocl 3.3.0-1 (Apple-x86/OpenCL/64-bit)
Supported transform implementations: ocl ocl3 ocl4 ocl5
Copyright 2001-2016, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2014, Michael Goetz, Ronald Schneider
Copyright 2011-2016, Iain Bethune
Genefer is free source code, under the MIT license.

Command line: ./geneferocl_macintel -d 1 -q 64996^4194304+1 -x ocl4

Priority change succeeded.

Testing 64996^4194304+1...
Using OCL4 transform

Running on platform 'Apple', device 'GeForce GTX 770', version 'OpenCL 1.2 ' and driver '10.9.14 346.03.05f02'.

Starting initialization...
Initialization complete (65.241 seconds).
Estimated time remaining for 64996^4194304+1 is 117:47:21
Testing 64996^4194304+1... 65536000 steps to go (113:20:05 remaining)
maxErr exceeded for 64996^4194304+1, 1.0000 > 0.4500
Errors occurred for all available transform implementations

Boinc tests on the machine which was having the curiously long ocl run times have commenced. Q9550 with 3 sgs units and 2 n22 units running.
http://www.primegrid.com/result.php?resultid=696455063
http://www.primegrid.com/result.php?resultid=696445078

The benchmark phase of the startup really clobbers the cpu, and for a long time, particularly where it is trying to initialize 2 units:

Command line: projects/www.primegrid.com/geneferocl_windows.exe -boinc -q 65990^4194304+1 --device 1

Priority change succeeded.
A benchmark is needed to determine best transform, testing available transform implementations...
Testing OCL transform...

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

Testing OCL3 transform...
Testing OCL4 transform...
Testing OCL5 transform...
Benchmarks completed (675.544 seconds).
Using OCL transform
Starting initialization...
Initialization complete (127.167 seconds).
Testing 65990^4194304+1...
Estimated time remaining for 65990^4194304+1 is 58:17:01

This 770 is suspect. I'm not sure this outcome means anything.

This is odd. This is using the binary form the 7 March post. Retrying on a 980.

emil:Downloads vzimmerman$ ./geneferocl_macintel -d 1 -q "64996^4194304+1" -x ocl4
geneferocl 3.3.0-1 (Apple-x86/OpenCL/64-bit)
Supported transform implementations: ocl ocl3 ocl4 ocl5
Copyright 2001-2016, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2014, Michael Goetz, Ronald Schneider
Copyright 2011-2016, Iain Bethune
Genefer is free source code, under the MIT license.

Command line: ./geneferocl_macintel -d 1 -q 64996^4194304+1 -x ocl4

Priority change succeeded.

Testing 64996^4194304+1...
Using OCL4 transform

Running on platform 'Apple', device 'GeForce GTX 770', version 'OpenCL 1.2 ' and driver '10.9.14 346.03.05f02'.

Starting initialization...
Initialization complete (65.241 seconds).
Estimated time remaining for 64996^4194304+1 is 117:47:21
Testing 64996^4194304+1... 65536000 steps to go (113:20:05 remaining)
maxErr exceeded for 64996^4194304+1, 1.0000 > 0.4500
Errors occurred for all available transform implementations

This 770 is suspect. I'm not sure this outcome means anything.

Yeah, I beat on it and it produced some strange results. I'm not sure if it has a problem itself, or the total power draw it and the gt640 in the mac pro its running in is causing it to flake out. I don't have the telemetry on a mac that I would have with afterburner or something like that.

I have relegated it to sieving. Genefer units on it wind up drawing 30-40 watts more power.

This 770 is suspect. I'm not sure this outcome means anything.

Thanks, I'll ignore the previous result then :)

Hi all,

Sorry I've been hiding under a rock for the last few days due to some work, home and illness pressures! Normal service to be resumed shortly. Of the couple of issues on my todo list, the benchmark and estimate times are first on the list. Excuse the stream-of-consciousness post here, but I hope it will help to explain the previous results (thanks to Rafael and VZ for the detailed testing).

The digit length of a GFN b^2^n+1 is roughly l = log(b)*2^n .

The component parts of a test:

* The initialisation, which computes the entire GFN as a large integer array, using a long-multiplication which is O(l^2) for small l and roughly O(l^1.585) for large l.

* The main test, which performs a certain number of squarings. Each squaring is O(l*log(l)) and the number of iterations is O(l).

This leads to three observations:

* The initialisation is O(l^2) or less and the calculation time is O(l^2*log(l)), so the initialisation will become less and less significant the larger the number.

* The time per iteration should approximately double when n is increased by 1 since (2^n+1)^2/(2^n)^2 = 2 (ignoring the log term).

* The time for the main test increases by a factor of 4 when n is increased by 1 since each iteration costs twice as much and there are twice as many iterations.

How the number of iterations for a benchmark is determined by:

* n <= 14 - i = 2^n
* n >= 15 - i = 2^(28-n) i.e. 64 iterations for n=22, 128 for n=21 etc...
* So the total amount of time for the benchmark should be roughly constant for large n.
* There is also a maximum time limit for a single benchmark set as 10 minutes, to avoid e.g. benchmarking at large n for x87 taking excessively long

What benchmarks are available and what they measure:

* -b benchmark runs at high priority. Runs a few (24) iterations to prepare CPU/GPU cache. Does not compute the initialisation, and reports the time per iteration. i.e. it measures the maximum speed achievable by a particular transform iteration

* -b3 benchmark runs at high priority. Computes the initialisation and some iterations. Returns the time taken for the iterations (ignoring the intialisation) and projects the time to completion according to: totalNumberOfIterations * measuredTime / benchmarkIterations - i.e. a linear extrapolation of the benchmark

* Transform selection benchmark runs at normal priority (i.e. representative of the runtime environment). Uses the same code as -b3. Really, this should skip the initialisation since it is common to all transforms, and there is no need to run it several times. I will fix this, as it wastes a lot of time.

What timings are printed and what they count:

* "Estimated time remaining for b^N+1 is ...". Printed after same number of iterations as normal benchmark (or at latest 10 minutes after initialisation completed). Based on elapsedTime*iterationsRemaining / iterationsSoFar i.e. linear extrapolation. I discovered a bug here, if the timer limit is hit rather than estimation based on the set number of iterations, but this wouldn't have been the case for any of the large tests you ran...

* "(XXXX remaining)". Printed every time a checkpoint is written. Same method as for the initial estimate.

* Final time display "(time = )". Simply based on wall clock time elapsed during the entire test.

So in summary, fixed a few things, but still no real idea why the initial estimate should be off…

New builds to follow in the next day or so, hopefully!

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

* The initialisation, which computes the entire GFN as a large integer array, using a long-multiplication which is O(l^2) for small l and roughly O(l^1.585) for large l.

* The initialisation, which computes the entire GFN as a large integer array, using a long-multiplication which is O(l^2) for small l and roughly O(l^1.585) for large l.

Why not use the same multiplication as the main one (l.log(l)) for the initialization as well?

* The initialisation, which computes the entire GFN as a large integer array, using a long-multiplication which is O(l^2) for small l and roughly O(l^1.585) for large l.

Why not use the same multiplication as the main one (l.log(l)) for the initialization as well?

The initialisation computes a base-2 representation. The transform radix is b.

Will the current method be faster than computing b^2^N using main FFT, and convert radix-b balanced representation to base-2?

Side question: Does the init logic take advantage of the fact that b=c.2^s, so we can compute c^2^N and left shift it to get the full number?

The only observation is that run times are all over the place, with maxerr exceeded on a number of units. http://www.primegrid.com/result.php?resultid=693523497 is a good example.

Running these individually resulted in err=0 for everything through n=19.

However, and a big however

The units I ran with valid results, I ran 2 at a time on the GPU, as historically one unit alone wouldn't peg the gpu (290x) for ocl3/ocl4.

If I run 2 instances of -t (in separate directories) I hit maxerr on the third or fourth test unit.

I ran one instance of -t and one instance of -r at the same time, and my video driver crashed.

The card has otherwise been rock solid, so I don't think it is suspect.

I've got a second WR unit finishing up in an hour or so, after that I'll put it on 17mega, 18, and 19, running one unit at a time, to see if I get the same results.

[edit]The same does _not_ occur on the 7990 system I was also using to test. Both test runs coexisted peacefully. Time to go check drivers. Sigh.[/edit]

The only observation is that run times are all over the place, with maxerr exceeded on a number of units. http://www.primegrid.com/result.php?resultid=693523497 is a good example.

This is a bit odd. On the plus side, the error detection and handling is working nicely, and all your results are valid. However, OCL4 should not be giving errors at all, since the transform is deterministic. Can you run the tests ( -t -x ocl4 and -r -x ocl4) on that machine?

- Iain

Tasks starting to come in. Clean runs so far. March 14th and newer are the "single" tasks.

18 here:
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=26

19 here:
http://www.primegrid.com/results.php?hostid=502810&offset=0&show_names=0&state=0&appid=27

2nd wr unit:
http://www.primegrid.com/result.php?resultid=696700183 (note the error handling. Fallout 4 contention?)

The only observation is that run times are all over the place, with maxerr exceeded on a number of units. http://www.primegrid.com/result.php?resultid=693523497 is a good example.

This is a bit odd. On the plus side, the error detection and handling is working nicely, and all your results are valid. However, OCL4 should not be giving errors at all, since the transform is deterministic. Can you run the tests ( -t -x ocl4 and -r -x ocl4) on that machine?

- Iain

Thanks for testing. Interesting that running multiple tests per card appears to break things. This would appear to point to a driver issue (esp since it works on your 7990 system).

- Iain

Running these individually resulted in err=0 for everything through n=19.

However, and a big however

The units I ran with valid results, I ran 2 at a time on the GPU, as historically one unit alone wouldn't peg the gpu (290x) for ocl3/ocl4.

If I run 2 instances of -t (in separate directories) I hit maxerr on the third or fourth test unit.

I ran one instance of -t and one instance of -r at the same time, and my video driver crashed.

The card has otherwise been rock solid, so I don't think it is suspect.

I've got a second WR unit finishing up in an hour or so, after that I'll put it on 17mega, 18, and 19, running one unit at a time, to see if I get the same results.

[edit]The same does _not_ occur on the 7990 system I was also using to test. Both test runs coexisted peacefully. Time to go check drivers. Sigh.[/edit]

The only observation is that run times are all over the place, with maxerr exceeded on a number of units. http://www.primegrid.com/result.php?resultid=693523497 is a good example.

This is a bit odd. On the plus side, the error detection and handling is working nicely, and all your results are valid. However, OCL4 should not be giving errors at all, since the transform is deterministic. Can you run the tests ( -t -x ocl4 and -r -x ocl4) on that machine?

- Iain

2nd wr unit:
http://www.primegrid.com/result.php?resultid=696700183 (note the error handling. Fallout 4 contention?)

2nd wr unit:
http://www.primegrid.com/result.php?resultid=696700183 (note the error handling. Fallout 4 contention?)

Was this running with another task on the same card?

So far finished 13 18s and 2 19s, all clean, no error fallback. 5 second variance on completion for the 18's, which isn't bad :)

2nd wr unit:
http://www.primegrid.com/result.php?resultid=696700183 (note the error handling. Fallout 4 contention?)

Was this running with another task on the same card?

No.

I left it running when I fired up fallout, and later civ5.

New builds (labelled 3.3.0-1) are available:

Windows: https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/bin/windows

Linux: https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/bin/linux

Mac: https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/bin/mac

Please grab the new binaries and continue with the testing matrix:

https://docs.google.com/spreadsheets/d/1dsyr9e6iSlvVZZa4qQpuJ6QxBXuSrxL1qQIBL4OpI0Q/

I'm particularly interested to see:

* Re-runs of the windows CPU tests that showed problems related to checkpointing.

* Tests with AMD/ATI cards running on Linux.

* Tests with Linux and Mac on BOINC using app_info.xml

but all help is appreciated - if you have any questions about how to help, please post here!

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

How are those linux binaries looking? I have a linux64/amd install on deck and ready to go.

And another hiccup in logic when running files!

Let's say you have 2 candiate files, A and B. And let's say you make a .bat with "genefer A" on one line and "genefer B" on the other, so that once it finishes the candidates in A, it'll immediately start the candidates in B.

Now, everything works good, until you get to B. Once it finishes the candidate list A, the program doesn't delete the genefer file which stores the current line. As a result, if A had 100 candidates, it'll start reading B from the 100th line, instead of the first.

It's also a shame that it can only store 1 file name at a time, so if you have multiple files, it can't track the individual progress of each, meaning you risk skipping lines on either if you mix them up.


Not so much of a problem as it is more of a complain. I wasn't expecting the program to keep track of each individual file progress, but I'd expect that it would at least delete the previous line counter once it's finished, much like it deletes the checkpoint file once it finishes a candidate.

Iget that the current way is better for single files (as if you change the name of the file and it won't lose track of the progress), but I think it would be better if we had a <Filename> <line> format instead of the current one.

This hit me early on when I was trying to test on 2 gpus at the same time.

My quick and dirty workaround was to run from multiple (sub)directories.

And another hiccup in logic when running files!

Let's say you have 2 candiate files, A and B. And let's say you make a .bat with "genefer A" on one line and "genefer B" on the other, so that once it finishes the candidates in A, it'll immediately start the candidates in B.

Now, everything works good, until you get to B. Once it finishes the candidate list A, the program doesn't delete the genefer file which stores the current line. As a result, if A had 100 candidates, it'll start reading B from the 100th line, instead of the first.

It's also a shame that it can only store 1 file name at a time, so if you have multiple files, it can't track the individual progress of each, meaning you risk skipping lines on either if you mix them up.


Not so much of a problem as it is more of a complain. I wasn't expecting the program to keep track of each individual file progress, but I'd expect that it would at least delete the previous line counter once it's finished, much like it deletes the checkpoint file once it finishes a candidate.

Iget that the current way is better for single files (as if you change the name of the file and it won't lose track of the progress), but I think it would be better if we had a <Filename> <line> format instead of the current one.

This hit me early on when I was trying to test on 2 gpus at the same time.

My quick and dirty workaround was to run from multiple (sub)directories.

Iget that the current way is better for single files (as if you change the name of the file and it won't lose track of the progress), but I think it would be better if we had a <Filename> <line> format instead of the current one.

How are those linux binaries looking? I have a linux64/amd install on deck and ready to go.

Linux binaries now available thanks to Ron: https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/bin/linux

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

Thanks folks! Does anyone have a genuine 32 bit linux system to test on?

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

2nd wr unit:
http://www.primegrid.com/result.php?resultid=696700183 (note the error handling. Fallout 4 contention?)

OK, odd that it gets such a huge roundoff error, and that there are later roundoff errors with OCL. I will keep an eye on this and see if it validates eventually...

2nd wr unit:
http://www.primegrid.com/result.php?resultid=696700183 (note the error handling. Fallout 4 contention?)

OK, odd that it gets such a huge roundoff error, and that there are later roundoff errors with OCL. I will keep an eye on this and see if it validates eventually...

I think whatever happened to the driver when you were playing Fallout killed this one. The wingman came in (who has a history of good results) and mismatches with your residue. Can you run another one, ideally with a result already returned so it will validate quickly?

- Iain

Thanks folks! Does anyone have a genuine 32 bit linux system to test on?

- Iain

Thanks folks! Does anyone have a genuine 32 bit linux system to test on?

- Iain

If no-one else does, I can reinstall with 32-bit (albeit on 64-bit hardware) and re-run everything.

Thanks folks! Does anyone have a genuine 32 bit linux system to test on?

- Iain

If no-one else does, I can reinstall with 32-bit (albeit on 64-bit hardware) and re-run everything.

We're looking specifically for a 32 bit CPU.

32-bit linux installs on 64 bit hardware are easy to find. :)

Thanks folks! Does anyone have a genuine 32 bit linux system to test on?

- Iain

If no-one else does, I can reinstall with 32-bit (albeit on 64-bit hardware) and re-run everything.

We're looking specifically for a 32 bit CPU.

32-bit linux installs on 64 bit hardware are easy to find. :)

I'm guessing 32-bit linux installs on 32-bit hardware with an amd gpu that can run double precision/ocl are not exactly run-of-the mill these days.

On this computer the genefer_linux32 version does not run properly.

./genefer_linux32 -b -x default
genefer 3.3.0-1 (Linux/CPU/32-bit)
Supported transform implementations: default x87
Copyright 2001-2016, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2014, Michael Goetz, Ronald Schneider
Copyright 2011-2016, Iain Bethune
Genefer is free source code, under the MIT license.

Command line: ./genefer_linux32 -b -x default

Priority change succeeded.
Priority change failed (needs superuser privileges).
Generalized Fermat Number Bench
Running benchmarks for transform implementation "Default"
Illegal instruction


./genefer_linux32 -b -x x87
genefer 3.3.0-1 (Linux/CPU/32-bit)
Supported transform implementations: default x87
Copyright 2001-2016, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2014, Michael Goetz, Ronald Schneider
Copyright 2011-2016, Iain Bethune
Genefer is free source code, under the MIT license.

Command line: ./genefer_linux32 -b -x x87

Priority change succeeded.
Priority change failed (needs superuser privileges).
Generalized Fermat Number Bench
Running benchmarks for transform implementation "x87 (80-bit)"
Illegal instruction

We've seen this before on this computer. I have notes from late September of 2015. I don't have notes on the outcome, though.

On this computer the genefer_linux32 version does not run properly.

We want to make sure that the program was built with compiler options that permit it to run on a real 32 bit CPU that lacks even the SSE2 instruction set.

On this computer the genefer_linux32 version does not run properly.
...
We've seen this before on this computer. I have notes from late September of 2015. I don't have notes on the outcome, though.

Kind of a silly question, but during all this testing I was wondering if any of the tests had been done on an overclocked system just to see if the overclock/heating issue might have magically disappeared on both cpu and gpu platforms.

Cheers

Kind of a silly question, but during all this testing I was wondering if any of the tests had been done on an overclocked system just to see if the overclock/heating issue might have magically disappeared on both cpu and gpu platforms.

Cheers

[edit] B68 started [/edit]

For fun, I tried looking at the initial time estimates for the test n=22 unit based on a titan black in double vs. single precision mode. Specifically, I was a curious if ocl4 in SP mode was on par with ocl in DP mode. Alas no, but its not a maxwell, either.

Double precision:
OCL 48:35
OCL3 104:30
OCL4 64:37
OCL5 110:29

Single precision:
OCL 59:45
OCL3 95:17
OCL4 59:56
OCL5 101:50

Although we have not completed every last test, we have reached the point where enough combinations of hardware, software and algorithms have been tested that I have given the go ahead to roll out the 3.3.0-1 binaries to BOINC. Mike will be setting these up sometime in the next few days I think.

Please complete any outstanding tests, and if you spot any problems please let me know!

Thanks for all the testing effort - I will be applying manual credit for the tests soon.

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

Although we have not completed every last test, we have reached the point where enough combinations of hardware, software and algorithms have been tested that I have given the go ahead to roll out the 3.3.0-1 binaries to BOINC. Mike will be setting these up sometime in the next few days I think.

Genefer 3.3.0-1 is now live on GFN-16

Let us know if there's any problems.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1