mersenneforum.org - gpuOwL: an OpenCL program for Mersenne primality testing

Page 11 of 29

Show 97 post(s) from this thread on one page

mersenneforum.org (https://www.mersenneforum.org/index.php)

- GpuOwl (https://www.mersenneforum.org/forumdisplay.php?f=171)

- - gpuOwL: an OpenCL program for Mersenne primality testing (https://www.mersenneforum.org/showthread.php?t=22204)

kriesel

2019-02-06 01:40

Openowl V6.2 on Windows and first takes (trouble in 6.2 and 6.1)

V6.2 openowl build for Win64 and first takes

No executable posted yet. Skip to the end for why.

Same 3 warnings again during the build process as listed for v6.1.

-h worked with or without a valid worktodo file, good.

openowl -h output:[CODE]2019-02-05 17:39:12 gpuowl 6.2-4a213af

Command line options:

-user <name> : specify the user name.
-cpu <name> : specify the hardware name.
-time : display kernel profiling information.
-fft <size> : specify FFT size, such as: 5000K, 4M, +2, -1.
-block <value> : PRP GEC block size. Default 400. Smaller block is slower but detects errors sooner.
-carry long|short : force carry type. Short carry may be faster, but requires high bits/word.
-D <value> : P-1 second-stage D block size; multiple of 210; default auto based on GPU available memory.
-device <N> : select a specific device:
0 : Ellesmere-36x1266-@28:0.0 Radeon (TM) RX 480 Graphics
1 : gfx804-8x1203-@3:0.0 Radeon 550 Series

FFT Configurations:
FFT 8K [ 0.01M - 0.18M] 64-64
FFT 32K [ 0.05M - 0.68M] 64-256 256-64
FFT 48K [ 0.07M - 1.01M] 64-64-6
FFT 64K [ 0.10M - 1.34M] 64-512 512-64
FFT 72K [ 0.11M - 1.50M] 64-64-9
FFT 80K [ 0.12M - 1.66M] 64-64-10
FFT 128K [ 0.20M - 2.63M] 1K-64 64-1K 256-256
FFT 192K [ 0.29M - 3.91M] 64-256-6 256-64-6
FFT 256K [ 0.39M - 5.18M] 64-2K 256-512 512-256 2K-64
FFT 288K [ 0.44M - 5.81M] 64-256-9 256-64-9
FFT 320K [ 0.49M - 6.44M] 64-256-10 256-64-10
FFT 384K [ 0.59M - 7.69M] 64-512-6 512-64-6
FFT 512K [ 0.79M - 10.18M] 1K-256 256-1K 512-512 4K-64
FFT 576K [ 0.88M - 11.42M] 64-512-9 512-64-9
FFT 640K [ 0.98M - 12.66M] 64-512-10 512-64-10
FFT 768K [ 1.18M - 15.12M] 1K-64-6 64-1K-6 256-256-6
FFT 1M [ 1.57M - 20.02M] 1K-512 256-2K 512-1K 2K-256
FFT 1152K [ 1.77M - 22.45M] 1K-64-9 64-1K-9 256-256-9
FFT 1280K [ 1.97M - 24.88M] 1K-64-10 64-1K-10 256-256-10
FFT 1536K [ 2.36M - 29.72M] 64-2K-6 256-512-6 512-256-6 2K-64-6
FFT 2M [ 3.15M - 39.34M] 1K-1K 512-2K 2K-512 4K-256
FFT 2304K [ 3.54M - 44.13M] 64-2K-9 256-512-9 512-256-9 2K-64-9
FFT 2560K [ 3.93M - 48.90M] 64-2K-10 256-512-10 512-256-10 2K-64-10
FFT 3M [ 4.72M - 58.41M] 1K-256-6 256-1K-6 512-512-6 4K-64-6
FFT 4M [ 6.29M - 77.30M] 1K-2K 2K-1K 4K-512
FFT 4608K [ 7.08M - 86.70M] 1K-256-9 256-1K-9 512-512-9 4K-64-9
FFT 5M [ 7.86M - 96.07M] 1K-256-10 256-1K-10 512-512-10 4K-64-10
FFT 6M [ 9.44M - 114.74M] 1K-512-6 256-2K-6 512-1K-6 2K-256-6
FFT 8M [ 12.58M - 151.83M] 2K-2K 4K-1K
FFT 9M [ 14.16M - 170.28M] 1K-512-9 256-2K-9 512-1K-9 2K-256-9
FFT 10M [ 15.73M - 188.68M] 1K-512-10 256-2K-10 512-1K-10 2K-256-10
FFT 12M [ 18.87M - 225.32M] 1K-1K-6 512-2K-6 2K-512-6 4K-256-6
FFT 16M [ 25.17M - 298.13M] 4K-2K
FFT 18M [ 28.31M - 334.34M] 1K-1K-9 512-2K-9 2K-512-9 4K-256-9
FFT 20M [ 31.46M - 370.44M] 1K-1K-10 512-2K-10 2K-512-10 4K-256-10
FFT 24M [ 37.75M - 442.34M] 1K-2K-6 2K-1K-6 4K-512-6
FFT 36M [ 56.62M - 656.22M] 1K-2K-9 2K-1K-9 4K-512-9
FFT 40M [ 62.91M - 727.03M] 1K-2K-10 2K-1K-10 4K-512-10
FFT 48M [ 75.50M - 868.07M] 2K-2K-6 4K-1K-6
FFT 72M [113.25M - 1287.53M] 2K-2K-9 4K-1K-9
FFT 80M [125.83M - 1426.38M] 2K-2K-10 4K-1K-10
FFT 96M [150.99M - 1702.92M] 4K-2K-6
FFT 144M [226.49M - 2525.23M] 4K-2K-9
FFT 160M [251.66M - 2797.39M] 4K-2K-10[/CODE]p=756839 error on load, program terminated.
p=859433 error on load, program terminated.
p=1398269 error on load, program terminated.
p=13466917 error on load, program terminated.
p=20996011 error on load, program terminated.
p=24036583 error on load, program terminated.

1536k fft length anomalously long timing 3.51ms/iter
2304k similarly, 5.15ms/iter, while 3072k is 2.55

The big item though, is no [B]known Mersenne prime[/B] that I ran to completion in V6.2 produced a prime indication at console or results file. [B]All[/B] from 19937 to 1257787 [B]indicated composite[/B] or a load error. So, I'm not posting a Windows executable for gpuowl v6.2, for now. [B]The same problem occurred with V6.1. Don't use that posted executable.[/B]
The interim 64-bit residues at 10000, 100000, and 1000000 that I checked all matched expected values.
[CODE]2019-02-05 08:35:12 gpuowl 6.1-569e6ef
2019-02-05 08:35:12 condorella/rx-480 -device 0 -user kriesel -cpu condorella/rx-480
2019-02-05 08:35:12 condorella/rx-480 19937 FFT 8K: Width 8x8, Height 8x8; 2.43 bits/word
2019-02-05 08:35:12 condorella/rx-480 using long carry kernels
2019-02-05 08:35:18 condorella/rx-480 OpenCL compilation in 4156 ms, with "-DEXP=19937u -DWIDTH=64u -DSMALL_HEIGHT=64u -DMIDDLE=1u -I. -cl-fast-relaxed-math -cl-std=CL2.0"
2019-02-05 08:35:18 condorella/rx-480 19937.owl not found, starting from the beginning.
2019-02-05 08:35:18 condorella/rx-480 19937 OK 800 4.00%; 0.13 ms/sq; ETA 0d 00:00; 7aa6c3340ce46bab (check 0.06s)
2019-02-05 08:35:20 condorella/rx-480 19937 10000 50.00%; 0.14 ms/sq; ETA 0d 00:00; 6248f957ba3ee3c5
2019-02-05 08:35:21 condorella/rx-480 [COLOR=Red][B]CC[/B][/COLOR] 19936 / 19937, [B][COLOR=SeaGreen]fffffffffffffffc[/COLOR][/B]
2019-02-05 08:35:21 condorella/rx-480 19937 OK 20000 100.00%; 0.14 ms/sq; ETA 0d 00:00; f5eb5782c7855ffd (check 0.06s)
2019-02-05 08:35:21 condorella/rx-480 {"exponent":"19937", "worktype":"PRP-3", "status":"[COLOR=red][B]C[/B][/COLOR]", "program":{"name":"gpuowl", "version":"6.1-569e6ef"}, "timestamp":"2019-02-05 14:35:21 UTC", "user":"kriesel", "computer":"condorella/rx-480", "aid":"0", "fft-length":8192, "res64":"[B][COLOR=SeaGreen]fffffffffffffffc[/COLOR][/B]", "residue-type":4}
[/CODE][CODE]2019-02-05 17:49:24 condorella/rx-480 44497 FFT 8K: Width 8x8, Height 8x8; 5.43 bits/word
2019-02-05 17:49:24 condorella/rx-480 using long carry kernels
2019-02-05 17:49:28 condorella/rx-480 OpenCL compilation in 3948 ms, with "-DEXP=44497u -DWIDTH=64u -DSMALL_HEIGHT=64u -DMIDDLE=1u -I. -cl-fast-relaxed-math -cl-std=CL2.0"
2019-02-05 17:49:28 condorella/rx-480 44497.owl not found, starting from the beginning.
2019-02-05 17:49:29 condorella/rx-480 44497 OK 800 1.79%; 0.42 ms/sq; ETA 0d 00:00; c89e6116066cebba (check 0.31s)
2019-02-05 17:49:33 condorella/rx-480 44497 10000 22.32%; 0.46 ms/sq; ETA 0d 00:00; d45f9720e7aa56ae
2019-02-05 17:49:38 condorella/rx-480 44497 20000 44.64%; 0.48 ms/sq; ETA 0d 00:00; e0fc41c8eadc4e96
2019-02-05 17:49:43 condorella/rx-480 44497 30000 66.96%; 0.53 ms/sq; ETA 0d 00:00; 8792168dfe598ffa
2019-02-05 17:49:48 condorella/rx-480 44497 40000 89.29%; 0.47 ms/sq; ETA 0d 00:00; 9b4920985d079c24
2019-02-05 17:49:50 condorella/rx-480 [B][COLOR=red]CC[/COLOR][/B] 44496 / 44497, [B][COLOR=seagreen]fffffffffffffffc[/COLOR][/B]
2019-02-05 17:49:51 condorella/rx-480 44497 OK 44800 100.00%; 0.54 ms/sq; ETA 0d 00:00; e92a77e2d568e367 (check 0.45s)
2019-02-05 17:49:51 condorella/rx-480 {"exponent":"44497", "worktype":"PRP-3", "status":"[B][COLOR=red]C[/COLOR][/B]", "program":{"name":"gpuowl", "version":"6.2-4a213af"}, "timestamp":"2019-02-05 23:49:51 UTC", "user":"kriesel", "computer":"condorella/rx-480", "aid":"0", "fft-length":8192, "res64":"[B][COLOR=seagreen]fffffffffffffffc[/COLOR][/B]", "residue-type":4}
[/CODE]

SELROC

2019-02-06 06:12

Something is wrong with gpuowl !!!

[QUOTE=kriesel;507780]V6.2 openowl build for Win64 and first takes

No executable posted yet. Skip to the end for why.

Same 3 warnings again during the build process as listed for v6.1.

-h worked with or without a valid worktodo file, good.

openowl -h output:[CODE]2019-02-05 17:39:12 gpuowl 6.2-4a213af

Command line options:

-user <name> : specify the user name.
-cpu <name> : specify the hardware name.
-time : display kernel profiling information.
-fft <size> : specify FFT size, such as: 5000K, 4M, +2, -1.
-block <value> : PRP GEC block size. Default 400. Smaller block is slower but detects errors sooner.
-carry long|short : force carry type. Short carry may be faster, but requires high bits/word.
-D <value> : P-1 second-stage D block size; multiple of 210; default auto based on GPU available memory.
-device <N> : select a specific device:
0 : Ellesmere-36x1266-@28:0.0 Radeon (TM) RX 480 Graphics
1 : gfx804-8x1203-@3:0.0 Radeon 550 Series

FFT Configurations:
FFT 8K [ 0.01M - 0.18M] 64-64
FFT 32K [ 0.05M - 0.68M] 64-256 256-64
FFT 48K [ 0.07M - 1.01M] 64-64-6
FFT 64K [ 0.10M - 1.34M] 64-512 512-64
FFT 72K [ 0.11M - 1.50M] 64-64-9
FFT 80K [ 0.12M - 1.66M] 64-64-10
FFT 128K [ 0.20M - 2.63M] 1K-64 64-1K 256-256
FFT 192K [ 0.29M - 3.91M] 64-256-6 256-64-6
FFT 256K [ 0.39M - 5.18M] 64-2K 256-512 512-256 2K-64
FFT 288K [ 0.44M - 5.81M] 64-256-9 256-64-9
FFT 320K [ 0.49M - 6.44M] 64-256-10 256-64-10
FFT 384K [ 0.59M - 7.69M] 64-512-6 512-64-6
FFT 512K [ 0.79M - 10.18M] 1K-256 256-1K 512-512 4K-64
FFT 576K [ 0.88M - 11.42M] 64-512-9 512-64-9
FFT 640K [ 0.98M - 12.66M] 64-512-10 512-64-10
FFT 768K [ 1.18M - 15.12M] 1K-64-6 64-1K-6 256-256-6
FFT 1M [ 1.57M - 20.02M] 1K-512 256-2K 512-1K 2K-256
FFT 1152K [ 1.77M - 22.45M] 1K-64-9 64-1K-9 256-256-9
FFT 1280K [ 1.97M - 24.88M] 1K-64-10 64-1K-10 256-256-10
FFT 1536K [ 2.36M - 29.72M] 64-2K-6 256-512-6 512-256-6 2K-64-6
FFT 2M [ 3.15M - 39.34M] 1K-1K 512-2K 2K-512 4K-256
FFT 2304K [ 3.54M - 44.13M] 64-2K-9 256-512-9 512-256-9 2K-64-9
FFT 2560K [ 3.93M - 48.90M] 64-2K-10 256-512-10 512-256-10 2K-64-10
FFT 3M [ 4.72M - 58.41M] 1K-256-6 256-1K-6 512-512-6 4K-64-6
FFT 4M [ 6.29M - 77.30M] 1K-2K 2K-1K 4K-512
FFT 4608K [ 7.08M - 86.70M] 1K-256-9 256-1K-9 512-512-9 4K-64-9
FFT 5M [ 7.86M - 96.07M] 1K-256-10 256-1K-10 512-512-10 4K-64-10
FFT 6M [ 9.44M - 114.74M] 1K-512-6 256-2K-6 512-1K-6 2K-256-6
FFT 8M [ 12.58M - 151.83M] 2K-2K 4K-1K
FFT 9M [ 14.16M - 170.28M] 1K-512-9 256-2K-9 512-1K-9 2K-256-9
FFT 10M [ 15.73M - 188.68M] 1K-512-10 256-2K-10 512-1K-10 2K-256-10
FFT 12M [ 18.87M - 225.32M] 1K-1K-6 512-2K-6 2K-512-6 4K-256-6
FFT 16M [ 25.17M - 298.13M] 4K-2K
FFT 18M [ 28.31M - 334.34M] 1K-1K-9 512-2K-9 2K-512-9 4K-256-9
FFT 20M [ 31.46M - 370.44M] 1K-1K-10 512-2K-10 2K-512-10 4K-256-10
FFT 24M [ 37.75M - 442.34M] 1K-2K-6 2K-1K-6 4K-512-6
FFT 36M [ 56.62M - 656.22M] 1K-2K-9 2K-1K-9 4K-512-9
FFT 40M [ 62.91M - 727.03M] 1K-2K-10 2K-1K-10 4K-512-10
FFT 48M [ 75.50M - 868.07M] 2K-2K-6 4K-1K-6
FFT 72M [113.25M - 1287.53M] 2K-2K-9 4K-1K-9
FFT 80M [125.83M - 1426.38M] 2K-2K-10 4K-1K-10
FFT 96M [150.99M - 1702.92M] 4K-2K-6
FFT 144M [226.49M - 2525.23M] 4K-2K-9
FFT 160M [251.66M - 2797.39M] 4K-2K-10[/CODE]p=756839 error on load, program terminated.
p=859433 error on load, program terminated.
p=1398269 error on load, program terminated.
p=13466917 error on load, program terminated.
p=20996011 error on load, program terminated.
p=24036583 error on load, program terminated.

1536k fft length anomalously long timing 3.51ms/iter
2304k similarly, 5.15ms/iter, while 3072k is 2.55

The big item though, is no [B]known Mersenne prime[/B] that I ran to completion in V6.2 produced a prime indication at console or results file. [B]All[/B] from 19937 to 1257787 [B]indicated composite[/B] or a load error. So, I'm not posting a Windows executable for gpuowl v6.2, for now. [B]The same problem occurred with V6.1. Don't use that posted executable.[/B]
The interim 64-bit residues at 10000, 100000, and 1000000 that I checked all matched expected values.
[CODE]2019-02-05 08:35:12 gpuowl 6.1-569e6ef
2019-02-05 08:35:12 condorella/rx-480 -device 0 -user kriesel -cpu condorella/rx-480
2019-02-05 08:35:12 condorella/rx-480 19937 FFT 8K: Width 8x8, Height 8x8; 2.43 bits/word
2019-02-05 08:35:12 condorella/rx-480 using long carry kernels
2019-02-05 08:35:18 condorella/rx-480 OpenCL compilation in 4156 ms, with "-DEXP=19937u -DWIDTH=64u -DSMALL_HEIGHT=64u -DMIDDLE=1u -I. -cl-fast-relaxed-math -cl-std=CL2.0"
2019-02-05 08:35:18 condorella/rx-480 19937.owl not found, starting from the beginning.
2019-02-05 08:35:18 condorella/rx-480 19937 OK 800 4.00%; 0.13 ms/sq; ETA 0d 00:00; 7aa6c3340ce46bab (check 0.06s)
2019-02-05 08:35:20 condorella/rx-480 19937 10000 50.00%; 0.14 ms/sq; ETA 0d 00:00; 6248f957ba3ee3c5
2019-02-05 08:35:21 condorella/rx-480 [COLOR=Red][B]CC[/B][/COLOR] 19936 / 19937, [B][COLOR=SeaGreen]fffffffffffffffc[/COLOR][/B]
2019-02-05 08:35:21 condorella/rx-480 19937 OK 20000 100.00%; 0.14 ms/sq; ETA 0d 00:00; f5eb5782c7855ffd (check 0.06s)
2019-02-05 08:35:21 condorella/rx-480 {"exponent":"19937", "worktype":"PRP-3", "status":"[COLOR=red][B]C[/B][/COLOR]", "program":{"name":"gpuowl", "version":"6.1-569e6ef"}, "timestamp":"2019-02-05 14:35:21 UTC", "user":"kriesel", "computer":"condorella/rx-480", "aid":"0", "fft-length":8192, "res64":"[B][COLOR=SeaGreen]fffffffffffffffc[/COLOR][/B]", "residue-type":4}
[/CODE][CODE]2019-02-05 17:49:24 condorella/rx-480 44497 FFT 8K: Width 8x8, Height 8x8; 5.43 bits/word
2019-02-05 17:49:24 condorella/rx-480 using long carry kernels
2019-02-05 17:49:28 condorella/rx-480 OpenCL compilation in 3948 ms, with "-DEXP=44497u -DWIDTH=64u -DSMALL_HEIGHT=64u -DMIDDLE=1u -I. -cl-fast-relaxed-math -cl-std=CL2.0"
2019-02-05 17:49:28 condorella/rx-480 44497.owl not found, starting from the beginning.
2019-02-05 17:49:29 condorella/rx-480 44497 OK 800 1.79%; 0.42 ms/sq; ETA 0d 00:00; c89e6116066cebba (check 0.31s)
2019-02-05 17:49:33 condorella/rx-480 44497 10000 22.32%; 0.46 ms/sq; ETA 0d 00:00; d45f9720e7aa56ae
2019-02-05 17:49:38 condorella/rx-480 44497 20000 44.64%; 0.48 ms/sq; ETA 0d 00:00; e0fc41c8eadc4e96
2019-02-05 17:49:43 condorella/rx-480 44497 30000 66.96%; 0.53 ms/sq; ETA 0d 00:00; 8792168dfe598ffa
2019-02-05 17:49:48 condorella/rx-480 44497 40000 89.29%; 0.47 ms/sq; ETA 0d 00:00; 9b4920985d079c24
2019-02-05 17:49:50 condorella/rx-480 [B][COLOR=red]CC[/COLOR][/B] 44496 / 44497, [B][COLOR=seagreen]fffffffffffffffc[/COLOR][/B]
2019-02-05 17:49:51 condorella/rx-480 44497 OK 44800 100.00%; 0.54 ms/sq; ETA 0d 00:00; e92a77e2d568e367 (check 0.45s)
2019-02-05 17:49:51 condorella/rx-480 {"exponent":"44497", "worktype":"PRP-3", "status":"[B][COLOR=red]C[/COLOR][/B]", "program":{"name":"gpuowl", "version":"6.2-4a213af"}, "timestamp":"2019-02-05 23:49:51 UTC", "user":"kriesel", "computer":"condorella/rx-480", "aid":"0", "fft-length":8192, "res64":"[B][COLOR=seagreen]fffffffffffffffc[/COLOR][/B]", "residue-type":4}
[/CODE][/QUOTE]

I have just tested prime 44497 and the result is "C".

Please double-check the program...we are computing also large numbers...

SELROC

2019-02-06 06:15

[QUOTE=SELROC;507792]I have just tested prime 44497 and the result is "C".

Please double-check the program...we are computing also large numbers...[/QUOTE]
Same with prime 86243...

preda

2019-02-06 07:43

Thanks -- I've been careless, the same bug strikes again!
Anybody can check if he found a misreported prime by searching for fffffffffffffffc in gpuowl.log, e.g. with grep under linux.
The fix is underway.

Fixed now, please re-checkout.

It's fine to upgrade in the middle of an ongoing PRP test, the result will be good.

SELROC

2019-02-06 08:22

[QUOTE=preda;507794]Thanks -- I've been careless, the same bug strikes again!
Anybody can check if he found a misreported prime by searching for fffffffffffffffc in gpuowl.log, e.g. with grep under linux.
The fix is underway.

Fixed now, please re-checkout.

It's fine to upgrade in the middle of an ongoing PRP test, the result will be good.[/QUOTE]

Wow thanks for the quick response. I will upgrade ASAP :-)

SELROC

2019-02-06 09:16

[QUOTE=preda;507794]Thanks -- I've been careless, the same bug strikes again!
Anybody can check if he found a misreported prime by searching for fffffffffffffffc in gpuowl.log, e.g. with grep under linux.
The fix is underway.

Fixed now, please re-checkout.

It's fine to upgrade in the middle of an ongoing PRP test, the result will be good.[/QUOTE]

The problem is that some exponents have already been computed to completion. I would double or triple check them...

preda

2019-02-06 10:52

[QUOTE=SELROC;507798]The problem is that some exponents have already been computed to completion. I would double or triple check them...[/QUOTE]

No need. If the final residue was not 0xfffffffffffffffc (i.e. -3), there is no risk of being prime. Just do this:

grep fffffffffffffffc gpuowl.log

and only re-check the exponents that produced that as final residue (most probably there are none).

kriesel

2019-02-06 13:21

readymade qa input for worktodo

I strongly recommend running some known-mersenne-prime low exponents before committing to github for the author, or before using for production for the end users.

[url]https://www.mersenneforum.org/showpost.php?p=506082&postcount=3[/url]
(And look closely at the results, more closely than I did for v6.1 the first time yesterday!)

kriesel

2019-02-06 13:27

[QUOTE=preda;507806]No need. If the final residue was not 0xfffffffffffffffc (i.e. -3), there is no risk of being prime. Just do this:

grep fffffffffffffffc gpuowl.log

and only re-check the exponents that produced that as final residue (most probably there are none).[/QUOTE]
And only from the last saved interim iteration count before the previous completion, not the whole computation duration, and which the program will do automatically. (Unless you deleted the interim files yourself: p.owl and p-prev.owl) The interim residues checked out ok, as did the final, in the cases I checked. It's only the very last bit that went wrong.

SELROC

2019-02-06 14:26

kriesel

2019-02-06 15:15

[QUOTE=SELROC;507825]Obviously none found.
Thinking out loud on the distribution of "luck" in the world, it is not the same everywhere.[/QUOTE]If you're referring to national location of GIMPS new mersenne prime discoverers, I think it's some combination of population, affluence, energy extravagance, and maybe some other factors, that has many in the US and few elsewhere. And it helps to have access to the numerous computers of a largish employer. But now and then, someone finds one, after testing a very few exponents. (As little as 3 or 4. But the odds are better with more.)
We GIMPSters are a select lot; about one in a million of the human population contributed a result in the past year.
Speaking of luck, consider that no GIMPS application other than prime95 is listed for performing the first successful primality test in the 17 discovered by GIMPS. Prime95 17, all others 0 (presumably including mprime 0; Windows 17, all others 0). There's strength in numbers.

SELROC

2019-02-06 15:26

[QUOTE=kriesel;507830]If you're referring to nationality of GIMPS new mersenne prime discoverers, I think it's some combination of population, affluence, energy extravagance, and maybe some other factors, that has many in the US and few elsewhere. And it helps to have access to the numerous computers of a largish employer. But now and then, someone finds one, after testing a very few exponents. (As little as 3 or 4. But the odds are better with more.)
We GIMPSters are a select lot; about one in a million of the human population contributed a result in the past year.[/QUOTE]

In practice it seems different for everyone. Some employer may be unhappy with usage of its own resources and energy for hpc (or mining).

kriesel

2019-02-06 16:49

V6.2-e2ffe65 on Win7 x64, RX480

1 Attachment(s)

v6.2-e2ffe65 timings on RX480
[CODE]fft ms/sq -fft +1
8K .13 na
32K .13 ?
48K ? na
64K .2239 ?
72K ?
192K .46
384K .92
768k ?
1152k ?
1280k ?
1.5M 3.51 1.413
2M 1.60*
2304K 5.15 1.99
3M 2.55#
4M 3.19
4.5M 3.74[/CODE]*one exponent ran at 1.74, two others at 1.60
#one exp at 2.93, another at 2.55

For PRP=0,1,2,11213,-1,40,1 the 8k fft is too large, at 1.37 bits/word.
There was an error on load on each of the next several, so no timings for them. I think this is specific to the fft length not the exponent.
[CODE]PRP=0,1,2,756839,-1,40,1
PRP=0,1,2,859433,-1,40,1
PRP=0,1,2,1398269,-1,56,1
PRP=0,1,2,13466917,-1,64,1
PRP=0,1,2,20996011,-1,65,1
PRP=0,1,2,24036583,-1,66,1[/CODE]Is this formatting on ignored worktodo lines intentional? (overwriting most of date)

[CODE]2019-02-06 09:51:09 condorella/rx480 -user kriesel -cpu condorella/rx480 -device 0 -fft +1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,11213,-1,40,1 8k too large, 1.37 bits/word
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#error on load on each of the next several
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,756839,-1,40,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,859433,-1,40,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,1398269,-1,56,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,13466917,-1,64,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,20996011,-1,65,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,24036583,-1,66,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#
2019-02-06 09:51:09 condorella/rx480 25964951 FFT 1536K: Width 64x4, Height 64x8, Middle 6; 16.51 bits/word[/CODE]
Executable and modified makefile attached in zip file. As always, use caution.

preda

2019-02-06 20:17

[QUOTE=kriesel;507838]Is this formatting on ignored worktodo lines intentional? (overwriting most of date)

[CODE]2019-02-06 09:51:09 condorella/rx480 -user kriesel -cpu condorella/rx480 -device 0 -fft +1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,11213,-1,40,1 8k too large, 1.37 bits/word
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#error on load on each of the next several
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,756839,-1,40,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,859433,-1,40,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,1398269,-1,56,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,13466917,-1,64,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,20996011,-1,65,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#PRP=0,1,2,24036583,-1,66,1
" ignored6 09:51:09 condorella/rx480 worktodo.txt: "#
2019-02-06 09:51:09 condorella/rx480 25964951 FFT 1536K: Width 64x4, Height 64x8, Middle 6; 16.51 bits/word[/CODE]
[/QUOTE]

I guess that the formatting you see is produced by the worktodo.txt lines you use being terminated with CR,LF (\n\r), while the program only consumes the first one (\n) as line separator. So the LF is left as the last character on the line, and affects the printing on the terminal.

I should sanitize that.

kriesel

2019-02-06 22:06

O2 vs O3

No, not oxygen vs ozone. Wondering why the gpuowl makefiles always specify -O2 rather than the deeper -O3 optimization option.

kriesel

2019-02-06 22:15

[QUOTE=preda;507853]I guess that the formatting you see is produced by the worktodo.txt lines you use being terminated with CR,LF (\n\r), while the program only consumes the first one (\n) as line separator. So the LF is left as the last character on the line, and affects the printing on the terminal.

I should sanitize that.[/QUOTE]Every step you take to make it Windows-friendly is appreciated. (I remember the Windows worktodo file update wars.) Sanitizing input is probably a good idea in general.

I tried appending " -fft +1" on the end of worktodo lines but it was ignored. It would be a handy feature for testing.

preda

2019-02-07 08:12

[QUOTE=kriesel;507864]No, not oxygen vs ozone. Wondering why the gpuowl makefiles always specify -O2 rather than the deeper -O3 optimization option.[/QUOTE]

In general there is little difference observed in practice between the two (-O2 vs. -O3). Also, -O3 sometimes involves "trade-offs".

In particular (i.e. GpuOwl), it's not performance-bound on the CPU. If you'd compile without optimization at all (dropping -O2) you should see only a tiny slowdown, because the GPU stuff, which is where the action is, is not affected.

preda

2019-02-07 08:18

[QUOTE=kriesel;507865]Every step you take to make it Windows-friendly is appreciated. (I remember the Windows worktodo file update wars.) Sanitizing input is probably a good idea in general.

I tried appending " -fft +1" on the end of worktodo lines but it was ignored. It would be a handy feature for testing.[/QUOTE]

Yes I know, and I try [to attend to different needs and feature requests]. One problem is that since recently my bandwidth (i.e. my available time, not my internet speed) has been severely reduced; So I must prioritize carefully.

SELROC

2019-02-07 09:13

[QUOTE=preda;507896]Yes I know, and I try [to attend to different needs and feature requests]. One problem is that since recently my bandwidth (i.e. my available time, not my internet speed) has been severely reduced; So I must prioritize carefully.[/QUOTE]

I have been thinking and rethinking on this: a command line argument to specify the exponent to compute. That is may be "-c <number>" should start gpuowl and computer <number>. It could be useful.

preda

2019-02-07 10:29

SELROC

2019-02-07 10:34

[QUOTE=preda;507900]Should it stop afterwards? (ignoring worktodo.txt)[/QUOTE]

Yes. This is only meant for quick testing and validating.

kriesel

2019-02-07 13:36

[QUOTE=SELROC;507898]I have been thinking and rethinking on this: a command line argument to specify the exponent to compute. That is may be "-c <number>" should start gpuowl and compute <number>. It could be useful.[/QUOTE]Maybe call it -exp. Or something that distinguishes it as PRP3 as opposed to P-1 (-pm1)? -c might be confused with -cpu.

I'd like to see either at command line or worktodo entry (both choices would be nice but maybe not a good use of Mihai's time budget) an option to do -iters (number). If I had to pick one, I'd choose command line. The combination of SELROC's suggestion plus -iters would make benchmarking the various fft lengths for a given gpu model much easier. As is, I find myself babysitting it. Mlucas and prime95 have the -iters feature.

An option on worktodo entries -fft +(number) or -(number)would be useful. As is, a worktodo file can't efficiently mix exponents of different fft list offset.

Also if there's an issue with one worktodo entry instead of quitting, continue to the next.
Openowl could modify the trouble assignment to be a comment, then rescan the file for input.

SELROC

2019-02-07 15:25

[QUOTE=kriesel;507909]Maybe call it -exp. Or something that distinguishes it as PRP3 as opposed to P-1 (-pm1)? -c might be confused with -cpu.

I'd like to see either at command line or worktodo entry (both choices would be nice but maybe not a good use of Mihai's time budget) an option to do -iters (number). If I had to pick one, I'd choose command line. The combination of SELROC's suggestion plus -iters would make benchmarking the various fft lengths for a given gpu model much easier. As is, I find myself babysitting it. Mlucas and prime95 have the -iters feature.

An option on worktodo entries -fft +(number) or -(number)would be useful. As is, a worktodo file can't efficiently mix exponents of different fft list offset.

Also if there's an issue with one worktodo entry instead of quitting, continue to the next.
Openowl could modify the trouble assignment to be a comment, then rescan the file for input.[/QUOTE]

Mfakto has the argument -tf <exp> <bitmin> <bitmax>
it ignores the worktodo file, so for consistency with mfakto:

openowl -prp <exp> ...

kriesel

2019-02-07 20:44

[QUOTE=SELROC;507917]Mfakto has the argument -tf <exp> <bitmin> <bitmax>
it ignores the worktodo file, so for consistency with mfakto:

openowl -prp <exp> ...[/QUOTE]

Makes sense.
openowl -pm1 <exp> -B1 <b1bound> -B2 <b2bound>

SELROC

2019-02-08 06:53

[QUOTE=kriesel;507956]Makes sense.
openowl -pm1 <exp> -B1 <b1bound> -B2 <b2bound>[/QUOTE]

the -B1 and -B2 are not strictly necessary:

openowl -pm1 <exp> <b1bound> <b2bound>

kriesel

2019-02-08 06:57

[QUOTE=SELROC;508000]the -B1 and -B2 are not strictly necessary:

openowl -pm1 <exp> <b1bound> <b2bound>[/QUOTE]
True. I think it would be easier to read though with them. It also maintains a symmetry in parsing; one field identifier, one value, rather than one with 3 parameters and order-sensitive.

SELROC

2019-02-08 07:43

[QUOTE=kriesel;508001]True. I think it would be easier to read though with them. It also maintains a symmetry in parsing; one field identifier, one value, rather than one with 3 parameters and order-sensitive.[/QUOTE]

Let preda decide on this, but I am just curious what you have against order-sensitive arguments :-)

M344587487

2019-02-08 09:39

How it typically works is that an op has either nothing or one string attached to it. This makes arg parsing a doddle with something like getopt, which easily allows defining a short and long version of an op like -h and --help. Personally I'd convert the arg parsing to getopt and do "openowl --pm1 <exp>,<b1bound>,<b2bound>" assuming the bounds are only used with pm1.

preda

2019-02-08 09:46

[QUOTE=M344587487;508008]How it typically works is that an op has either nothing or one string attached to it. This makes arg parsing a doddle with something like getopt, which easily allows defining a short and long version of an op like -h and --help. Personally I'd convert the arg parsing to getopt and do "openowl --pm1 <exp>,<b1bound>,<b2bound>" assuming the bounds are only used with pm1.[/QUOTE]

Is getopt available on windows? (for people building on windows)

M344587487

2019-02-08 10:39

An internet search indicates it's available on MingW/cygwin and that workarounds for MSVC appear to simply copy getopt.h from MingW ( [url]https://www.codefull.org/2015/04/cannot-find-getopt-h-header-file-when-compiling-under-windows/[/url] ). What a pain MSVC is.

henryzz

2019-02-08 10:51

[QUOTE=preda;508009]Is getopt available on windows? (for people building on windows)[/QUOTE]

getopt has been used as part of lasieve which compiles in pretty much all environments(these days). There was a bit of issue with POSIXLY_CORRECT not being set sometimes when compiling on windows which is worth watching out for. This was discussed in [url]https://www.mersenneforum.org/showthread.php?t=18043[/url]

M344587487

2019-02-08 14:32

I converted argument parsing to getopt, should be fully backwards compatible with the current way ops are parsed: [URL]https://github.com/sillygitter/gpuowl[/URL]

Haven't heavily tested it but my Linux build appears to work. Can someone test with MingW and MSVC? MingW and Linux should work as is, MSVC should fail and require you to copy getopt.h from mingw ( [URL]https://github.com/skandhurkat/Getopt-for-Visual-Studio/blob/master/getopt.h[/URL] ) into the build directory, and also change #include <getopt.h> to #include "getopt.h" in Args.cpp.

Once you get the build working there should be many ways to define the ops. For example -f -fft and --fft should all work and require an argument. I had to take some liberties with the short op letters used as letters c and d are heavily overloaded.

[code] static struct option long_options[]=
{
{"help", no_argument, 0, 'h'},
{"D", required_argument, 0, 'D'},
{"fft", required_argument, 0, 'f'},
{"dump", required_argument, 0, 'k'},
{"user", required_argument, 0, 'u'},
{"cpu", required_argument, 0, 'n'},
{"cl", required_argument, 0, 'C'},
{"time", no_argument, 0, 't'},
{"carry", required_argument, 0, 'c'},
{"block", required_argument, 0, 'b'},
{"device", required_argument, 0, 'd'},
{0, 0, 0, 0}
};[/code]
Don't feel obligated to convert to getopt if you don't want to preda, in the end you're the one maintaining the code I'm just trying to be helpful.

kriesel

2019-02-09 20:57

RX480 gpuowl V6.2 benchmarks, and anomalies encountered

1 Attachment(s)

Gpuowl V6.2 was benchmarked at many fft lengths on an RX480. Results are tabulated along with summarized results from benchmarks on earlier versions, 3.8, 5.0, 1.9, 2.0. Each offers still some fastest fft lengths, except v2.0's 500K transform is eclipsed by later versions' nearby fft lengths. There were a few fft choices that would not run in V6.2; four cases of EE load error, and an "assertion failed" at very large fft length. At some lengths, earlier versions are from 0.4% to up to 3.4% faster on this gpu. V6.2 was the fastest-version in 9 fft lengths, more than any other version compared. Of those 9, 7 are the -fft +0 option, 2 are the -fft +2 option.

V1.9's power of two fft lengths are still the fastest, 3 out of 3.
V3.8 had 5 fastest lengths; V5.0 2 lengths.

It sure would be nice if all the fastest transforms were in one recent executable.

Benchmark method was as follows. Prepare batch file and worktodo for the version and exponent to be timed, while the gpu runs something else. With minimum execution interruption, make the switch to benchmarking. Ignore the next 10,000+ iterations while the gpu warms back up and stabilizes. Average the time of the following 50,000 iterations (more if the computed average falls on a rounding boundary at 50,000 or the version under test does not display 10,000 iteration timings). Round as appropriate to remove unjustified precision.

Some versions were omitted from this comparison.
All versions older than V1.9 were omitted.
Also omitted were V3.3, uniformly slower than v3.5; 3.5-3.7 previously found to be essentially identical speed to 3.8; 3.9 and 4.x found to be slower. V6.1 was omitted since it has the prime-called-composite bug.

V6.0 may be tested at a later time.
Timing tests on an RX550 may be run at a later time.

GP2	2019-02-11 21:35

Residue type 0

What is residue type 0?

For instance: [M]81885841[/M], [M]82249393[/M], etc.

There are 26 examples, all from October through December of last year.

Is mprime capable of double-checking these results?

kriesel

2019-02-12 03:38

preda

2019-02-12 10:02

[QUOTE=GP2;508286]What is residue type 0?

For instance: [M]81885841[/M], [M]82249393[/M], etc.

There are 26 examples, all from October through December of last year.

Is mprime capable of double-checking these results?[/QUOTE]

That is PRP-1. mprime can't double-check them now, but there are only a few such results in total. In the future they might be double-checked when the need arises, but the confidence there is rather high. Anyway, GpuOwl is not generating these anymore.

kriesel

2019-02-13 01:20

[QUOTE=GP2;508286]What is residue type 0?
For instance: [M]81885841[/M], [M]82249393[/M], etc.
There are 26 examples, all from October through December of last year.
Is mprime capable of double-checking these results?[/QUOTE]
While it would be less satisfying than a matching computation type and residue type on different offset, different hardware, and different software, the composite conclusion for these dozens of exponents could be confirmed by another run each of standard PRP or LL. The alternative of running gpuowl V5.0 PRP-1 again would be on the same zero offset as the first runs. If I recall correctly, a PRP-1 rerun would need to be on the same B1 value also to match the residue of the first PRP-1 run. I think gpuowl v4.x also. See [url]https://www.mersenneforum.org/showpost.php?p=499292&postcount=823[/url]

kriesel

2019-02-15 18:11

gpuowl PRP3 file continuation compatibility reference

See [URL]https://www.mersenneforum.org/showpost.php?p=508637&postcount=12[/URL] for a lookup table of what gpuowl version's files can be run in what other gpuowl versions. A run begun in V1.9 can be migrated to v6.x with two intermediate versions. Back migration in gpuowl is very limited, to the same file version. (To make it otherwise would require fitting older versions with file format back-converters. It's understandable that Mihai has not done so.)

tServo

2019-02-21 18:19

I was curious about the 2 columns marked H and W when a -list fft is run on V5. For newer versions, they are shown as numbers on the far right. Displaying the log shows what they are when a new exponent is started. Also for V5, "middle 5" is displayed after them.
I couldn't find any reference to these anywhere.
TIA

kriesel

2019-02-21 18:49

[QUOTE=tServo;509059]I was curious about the 2 columns marked H and W when a -list fft is run on V5. For newer versions, they are shown as numbers on the far right. Displaying the log shows what they are when a new exponent is started. Also for V5, "middle 5" is displayed after them.
I couldn't find any reference to these anywhere.
TIA[/QUOTE]
Mihai is using a nomenclature of height, width, and middle for the components of the individual fft transforms in gpuowl, and up to 3 components. See [URL]https://www.mersenneforum.org/showpost.php?p=507015&postcount=956[/URL]

Mlucas does differently, with up to 5, if I recall correctly, and possibly more to come. Here's an excerpt from an mlucas.cfg file, with 5, and it appears room to go up to 10:[CODE]radices = 36 16 16 32 32 0 0 0 0 0[/CODE] for an 18M fft length. (36 x 16 x 16 x 32 x 32, x 2 for real plus imaginary I guess, = 18432K)

kriesel

2019-02-21 19:26

[QUOTE=SELROC;508004]Let preda decide on this, but I am just curious what you have against order-sensitive arguments :-)[/QUOTE]
Not adamant about it, but

1) I find the aid to memory or explicit labeling useful. It's becoming more useful with age.

2) Without having thought about it much, it seemed to me that requiring 3 parameters or coding in an assumption that if it's two parameters it's B1 given, limits possible future features. Making them labeled and optional individually allows more cases in the future.
For -PRP <exponent> <b1bound> <b2bound> all three would be required to be present,
or b1 could be specified and b2 left up to the program if omitted, but there's no way to express program select b1 and specify b2, unless -PRP <exponent> 0 <b2bound> is given special meaning.
For -PM1 <exponent> [-B1 <b1bound>] [-B2 <b2bound>] [-n 1|2|3] [etc]
specify what you like and let the program select the rest seems an easy code evolution path. Some default such as -n 2 could be adopted (how many primality tests are saved by a factor, so input how hard to try to find a factor).

3) Batch files or shell scripts could be compatible as more features become supported.

There's existing code in both prime95/mprime and CUDAPm1 for optimizing bounds selection in a program (to save maximal time over many P-1 attempts given varying probabilities of finding factors by P-1 and therefore avoiding primality tests) rather than leaving it to the user to specify.

I trust Mihai to consider such matters, make reasonable choices, and occasionally break with the past when it makes sufficient sense.

I'm in favor of any idea generation or discussion by us mere users that makes Mihai's time more productive.

[URL]https://idioms.thefreedictionary.com/paint+into+a+corner[/URL]

GP2	2019-02-25 04:30

Recently, PRP triple-checks were done on [M]M78410041[/M] and [M]M79109357[/M].

Unfortunately, they were done with residue type 4, whereas the original two tests were done with residue type 1. And so the result is much less useful, and a new test is needed.

Presumably these were manually self-assigned triple checks using gpuOwL? Or were they assigned automatically with some utility program?

It's a drawback of different programs having different default residue types, since it places the burden on the user not to make this mistake.

PS,
These were cases where Simon Cunningham found that his computers were producing bad PRP residues because the implementation of Gerbicz error checking in mprime 29.5 had some shortcomings in the final processing.

SELROC

2019-03-15 11:13

[QUOTE=kriesel;499410]I tested v4.3 a total of one little 11 minute m1257787 run to see if my edit left it still functional. Why would you object to that?
Worked through a backlog of builds, giving the newest at the time (V5.0-f604bb1) priority.
Execution speed seems to me to have been declining since v3.8, and V5.0 apparently continues that trend even when no P-1 is done. [URL]https://www.mersenneforum.org/showpost.php?p=499306&postcount=830[/URL]

I'm still running V3.8 for production because of its speed advantage. I think I'm not alone in that.
I may run V5 for exponents needing P-1, after it's shown sufficiently reliable, if the run time of PRP-1 in V5 is shown to be less than the run time of P-1 in CUDAPm1 plus PRP in V3.8 separately on comparable gpus. My recent benchmarking indicates V5 is often 4-5% slower (PRP only, not PRP-1) than V3.8. That difference is longer than an entire typical P-1, which is 2-2.5% of a CUDALucas LL test, in the 100M to 500M range, unless PRP was ~ twice as fast as LL.

Case in point: 87m P-1 on GTX1060, ~5 hours, PRP in V3.8, 3d 22 hours; so combined time is 4d 3h. Compare to 4d 12h for gpuowl V5, 9 hours slower.
Again: 171m P-1 on GTX1060, ~20 hours, PRP in V3.8, 14d 21h, combined 15d 17 h; Estimated V5.0 PRP time 15d 16h. If PRP-1 is within ~1 hour of PRP, V5 wins.[/QUOTE]

[QUOTE=SELROC;499418]The fastest version was 3.5, performance regression after that, and little performance recovery in 4.6.[/QUOTE]

To my great surprise the gpuowl performance regression on amdgpu-pro is [B]now gone[/B] with amdgpu-pro version 18.50

I have the same performance on amdgpu-pro 18.50 and ROCm 2.2

I am using the latest gpuowl version aka GitHub master branch.

M344587487

2019-03-26 18:31

Will the below DC definitely DC and not do a first time test of the wrong type? gpuowl did that once before so I avoided DC but now I want to verify that this card is producing correct results:

PRP=N/A,1,2,79335979,-1,75,0,3,1
[URL]https://www.mersenne.org/report_exponent/?exp_lo=79335979[/URL]
gpuowl 6.2-3a95f98-mod, a recent version.

Prime95

2019-03-26 19:28

That looks like the correct worktodo.txt entry to me.

ewmayer

2019-03-26 19:47

[QUOTE=kriesel;509060]Mihai is using a nomenclature of height, width, and middle for the components of the individual fft transforms in gpuowl, and up to 3 components. See [URL]https://www.mersenneforum.org/showpost.php?p=507015&postcount=956[/URL]

Mlucas does differently, with up to 5, if I recall correctly, and possibly more to come. Here's an excerpt from an mlucas.cfg file, with 5, and it appears room to go up to 10:[CODE]radices = 36 16 16 32 32 0 0 0 0 0[/CODE] for an 18M fft length. (36 x 16 x 16 x 32 x 32, x 2 for real plus imaginary I guess, = 18432K)[/QUOTE]
Correct re. Mlucas - those entries are complex-FFT radices. You may see 6 or even 7 for some FFT lengths of current-GIMPS-wavefront interest, depending on what works best on your hardware, as determined by the standard post-install self-tests, but 4-5 radices is more common.

M344587487

2019-03-27 01:31

SELROC

2019-03-27 06:39

preda

2019-03-27 06:46

M344587487

2019-03-27 08:43

preda if you're saying that the DC will erroneously do a type 4 blink twice

LaurV

2019-03-27 10:23

haha, good one!

SELROC

2019-03-27 12:44

benchmarking

SELROC

2019-03-27 16:49

last attempt: benchmarking gpus is subject to temperature. when benchmarking please note gpu temp.

test advanced editor.

OK

M344587487

2019-03-27 22:01

Damn the DC did use the wrong type, the worktodo was not wrong I guess gpuowl can only do type 4. Can anyone point me in the direction of a DC with type 4 exponent to grab? Don;t think the DB can be searched by type and the recent results are all type 5 or 1.

kriesel

2019-03-27 23:42

M344587487

2019-03-28 01:02

Thanks, I was lazy researching but would never have figured to use v3.8.

kriesel

2019-03-28 01:21

[QUOTE=M344587487;512009]Thanks, I was lazy researching but would never have figured to use v3.8.[/QUOTE]If you want to qualify your modification or gpu, you could try
[url]https://www.mersenne.org/report_exponent/?exp_lo=84102691&full=1[/url]. Since I ran it, I have a list of interim residues a short run could be checked against.

SELROC

2019-03-31 05:39

In some cases gpuowl fails on radeon VII

It was with the wrong set of system software, not enough up to date, gpuowl started but after a while the residue was zeroed out, and a page fault occurred.

After installing the latest kernel, modules and headers, v. 5.0, then gpuowl works without problems and the zero-residue error is gone.

SELROC

2019-03-31 13:53

[QUOTE=SELROC;512276]It was with the wrong set of system software, not enough up to date, gpuowl started but after a while the residue was zeroed out, and a page fault occurred.

After installing the latest kernel, modules and headers, v. 5.0, then gpuowl works without problems and the zero-residue error is gone.[/QUOTE]

The same error has occurred again, zero-residue, but this time gpuowl reloaded the last checkpoint and continued.

I found that I was running a version of openowl compiled against old libs. Now I have recompiled and waiting to see if the error occurs again.

kriesel

2019-03-31 14:00

[QUOTE=kriesel;512010]If you want to qualify your modification or gpu, you could try
[URL]https://www.mersenne.org/report_exponent/?exp_lo=84102691&full=1[/URL]. Since I ran it, I have a list of interim residues a short run could be checked against.[/QUOTE]
There's also a table of interim residues for powers of ten iterations for known Mersenne primes, in the attachment of post 5 at [URL]https://www.mersenneforum.org/showthread.php?t=24003[/URL]

kriesel

2019-03-31 15:04

gpuowl asymptotic run time scaling

I've extended the third attachment at [URL]https://www.mersenneforum.org/showpost.php?p=488535&postcount=2[/URL] to include a plot of the per iteration times on an RX480 gpu for whichever version of gpuowl tested fastest for each fft length. An approximation of the asymptotic scaling of gpuowl is p[SUP]1.078[/SUP] for ms/iter, p[SUP]2.078[/SUP] for exponent run time, from the trend line fit for fft lengths 6M to 144M (exponents 100M<p<2520M). This is close to values obtained for CUDALucas and prime95, ~2.094, and finally provides for gpuowl a scaling above p[SUP]2[/SUP], which is more consistent with expectations of scaling n[SUP]2[/SUP] log n log log n from such reliable sources as Knuth.

SELROC

2019-04-01 08:02

[QUOTE=SELROC;512290]The same error has occurred again, zero-residue, but this time gpuowl reloaded the last checkpoint and continued.

I found that I was running a version of openowl compiled against old libs. Now I have recompiled and waiting to see if the error occurs again.[/QUOTE]

After some hour no error. Will see today the continuation.

kracker

2019-04-03 03:06

GP2	2019-04-03 05:39

[QUOTE=M344587487;511994]Damn the DC did use the wrong type, the worktodo was not wrong I guess gpuowl can only do type 4. Can anyone point me in the direction of a DC with type 4 exponent to grab? Don;t think the DB can be searched by type and the recent results are all type 5 or 1.[/QUOTE]

You can find some PRPs that need DC from the following users:

Warning: not all are type 4. There's no way to filter by residue type, although you can click on the "Residue Type" column header to sort by it.

Also, I think gpuOwL only produces residues with shift count zero, so the double check will also have shift count zero, and some might insist that it's not a proper double check unless it's with a different shift count.
[LIST][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=Mihai+Preda&exdchk=1&dispdate=1&B1="]Mihai Preda[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=Kriesel&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]Kriesel[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=kwe5ykdf&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]kwe5ykdf[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=tServo&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]tServo[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=Franklin+Webber&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]Franklin Webber[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=Xebecer&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]Xebecer[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=xx005fs&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]xx005fs[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=SEL-ROC&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]SEL-ROC[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=kracker&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]kracker[/URL][/LIST]

SELROC

2019-04-03 05:50

[QUOTE=GP2;512503]You can find some PRPs that need DC from the following users:

Warning: not all are type 4. There's no way to filter by residue type, although you can click on the "Residue Type" column header to sort by it.

Also, I think gpuOwL only produces residues with shift count zero, so the double check will also have shift count zero, and some might insist that it's not a proper double check unless it's with a different shift count.
[LIST][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=Mihai+Preda&exdchk=1&dispdate=1&B1="]Mihai Preda[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=Kriesel&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]Kriesel[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=kwe5ykdf&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]kwe5ykdf[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=tServo&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]tServo[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=Franklin+Webber&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]Franklin Webber[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=Xebecer&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]Xebecer[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=xx005fs&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]xx005fs[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=SEL-ROC&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]SEL-ROC[/URL][*][URL="https://www.mersenne.org/report_prp/?exp_lo=82000000&exp_hi=999999999&exp_date=&end_date=&user_only=1&user_id=kracker&exdchk=1&dispdate=1&exbad=1&exfactor=1&B1="]kracker[/URL][/LIST][/QUOTE]

At this point gpuOwl is good for discovering new primes, the double-check should be done with a different program, maybe mprime with fast cpu and memory.

LaurV

2019-04-04 17:12

[offtopic]
hehe, we love the new thread title, some supermods are really creative :razz:

[/offtopic]

SELROC

2019-04-05 09:57

[QUOTE=SELROC;512276]It was with the wrong set of system software, not enough up to date, gpuowl started but after a while the residue was zeroed out, and a page fault occurred.

After installing the latest kernel, modules and headers, v. 5.0, then gpuowl works without problems and the zero-residue error is gone.[/QUOTE]

[QUOTE=SELROC;512290]The same error has occurred again, zero-residue, but this time gpuowl reloaded the last checkpoint and continued.

I found that I was running a version of openowl compiled against old libs. Now I have recompiled and waiting to see if the error occurs again.[/QUOTE]

[QUOTE=SELROC;512361]After some hour no error. Will see today the continuation.[/QUOTE]

The error occurred again today, after X days of work. Gpuowl has reloaded last checkpoint and is continuing.

preda

2019-04-05 11:57

[QUOTE=SELROC;512744]The error occurred again today, after X days of work. Gpuowl has reloaded last checkpoint and is continuing.[/QUOTE]

On what hardware -- is the hardware setup verified reliable?

What do you suspect as the reason for errors? (GPUowl, driver, hardware, something else)

SELROC

2019-04-05 12:27

[QUOTE=preda;512747]On what hardware -- is the hardware setup verified reliable?

What do you suspect as the reason for errors? (GPUowl, driver, hardware, something else)[/QUOTE]

Gigabyte mainboard

radeon VII
Ubuntu
ROCm 2.2

kernel 5.0.5

the previous time I hit a page fault but not this time (after recompiling gpuowl)

preda

2019-04-05 12:29

[QUOTE=SELROC;512750]Gigabyte mainboard

radeon VII
Ubuntu
ROCm 2.2

kernel 5.0.5

the previous time I hit a page fault but not this time (after recompiling gpuowl)[/QUOTE]

Congrats on the R7! Did you undervolt/overclock? (if yes, that may explain the errors from time to time)

SELROC

2019-04-05 12:36

[QUOTE=preda;512752]Congrats on the R7! Did you undervolt/overclock? (if yes, that may explain the errors from time to time)[/QUOTE]

PS: the setup has been validated against known prime.

the gpu is in automatic mode.

preda

2019-04-05 12:38

[QUOTE=SELROC;512755]PS: the setup has been validated against known prime.

the gpu is in automatic mode.[/QUOTE]

So you did not undervolt/overclock? (when you see the errors you report)

SELROC

2019-04-05 12:55

[QUOTE=preda;512756]So you did not undervolt/overclock? (when you see the errors you report)[/QUOTE]

No.

the voltage is ~1.04 V

SCLK 1802 MHz
MCLK 1001 MHz

SELROC

2019-04-06 07:45

[QUOTE=preda;512747]On what hardware -- is the hardware setup verified reliable?

What do you suspect as the reason for errors? (GPUowl, driver, hardware, something else)[/QUOTE]

No no, gpuowl on his part has done a very good job of reloading the checkpoint and continuing.

The error manifests with a zero residue, so it may be that gpuowl is sometimes reading from the wrong location, and this may correspond to a page fault.

SELROC

2019-04-07 07:12

[QUOTE=preda;512747]On what hardware -- is the hardware setup verified reliable?

What do you suspect as the reason for errors? (GPUowl, driver, hardware, something else)[/QUOTE]

[QUOTE=SELROC;512841]No no, gpuowl on his part has done a very good job of reloading the checkpoint and continuing.

The error manifests with a zero residue, so it may be that gpuowl is sometimes reading from the wrong location, and this may correspond to a page fault.[/QUOTE]

It may be my negligence, I was running kernel 5.0.5 but with an outdated initramfs. After updating initramfs the error is not occurring.

SELROC

2019-04-07 13:14

[QUOTE=SELROC;512945]It may be my negligence, I was running kernel 5.0.5 but with an outdated initramfs. After updating initramfs the error is not occurring.[/QUOTE]

I must note that the error (zero residue) has appeared for the first time to me with the radeon VII.

preda

2019-04-07 20:14

[QUOTE=SELROC;512961]I must note that the error (zero residue) has appeared for the first time to me with the radeon VII.[/QUOTE]

Yes, I have no idea why it happens. I'm also using an R7 now, I'll keep an eye on it and let you know if I see the same.

M344587487

2019-04-07 20:32

I've been running an R7 24/7 at 1.03V, 50mV under stock voltage since testing it a few weeks ago. No crashes or suspicious results, the only issue was a corrupted checkpoint after a power cut forced a rollback to the latest 20M checkpoint.

SELROC

2019-04-08 05:44

[QUOTE=M344587487;513007]I've been running an R7 24/7 at 1.03V, 50mV under stock voltage since testing it a few weeks ago. No crashes or suspicious results, the only issue was a corrupted checkpoint after a power cut forced a rollback to the latest 20M checkpoint.[/QUOTE]

That is another story, which happened to me also: hit ctrl-C and cut off the power without waiting. The result is a zero-length checkpoint, invalid.

SELROC

2019-04-08 05:45

[QUOTE=preda;513001]Yes, I have no idea why it happens. I'm also using an R7 now, I'll keep an eye on it and let you know if I see the same.[/QUOTE]

Thanks. I keep an eye to see if it happens again.

preda

2019-04-08 10:33

[QUOTE=M344587487;513007]I've been running an R7 24/7 at 1.03V, 50mV under stock voltage since testing it a few weeks ago. No crashes or suspicious results, the only issue was a corrupted checkpoint after a power cut forced a rollback to the latest 20M checkpoint.[/QUOTE]

There is also another checkpoint, NNNNNN-prev.owl, which likely should not be corrupted at the same time as the main checkpoint. But the recovery from it is not automatic (i.e. you have to manually rename it).

preda

2019-04-08 10:36

[QUOTE=SELROC;513036]That is another story, which happened to me also: hit ctrl-C and cut off the power without waiting. The result is a zero-length checkpoint, invalid.[/QUOTE]

Maybe recover from the "previous" checkpoint, -prev.owl, in such a situation.

SELROC

2019-04-08 10:37

[QUOTE=preda;513055]Maybe recover from the "previous" checkpoint, -prev.owl, in such a situation.[/QUOTE]

Yes I did.

M344587487

2019-04-08 10:41

Tried it and it did the same thing as the normal checkpoint. Sorry I can't remember the exact details but think the initial restart printed out half a dozen lines before erroring, could that have been enough to overwrite a good prev.owl checkpoint with a bad one before I got to it?

preda

2019-04-08 11:45

[QUOTE=M344587487;513058]Tried it and it did the same thing as the normal checkpoint. Sorry I can't remember the exact details but think the initial restart printed out half a dozen lines before erroring, could that have been enough to overwrite a good prev.owl checkpoint with a bad one before I got to it?[/QUOTE]

before writing a checkpoint, GPUowl always does a check, and only writes anything if the check succeeds. So in a bad state nothing should be written. At least that's the theory..

OTOH a check is also done on startup/load, so in a bad state it shouldn't even start.

preda

2019-04-09 21:39

News:
Added arguments for bypassing worktodo.txt
-prp <exponent>
-pm1 <exponent>

Embedded gpuowl.cl in executable, the .cl file next to the executable is not needed anymore.

kriesel

2019-04-09 22:57

1 Attachment(s)

[QUOTE=preda;513288]News:
Added arguments for bypassing worktodo.txt
-prp <exponent>
-pm1 <exponent>

Embedded gpuowl.cl in executable, the .cl file next to the executable is not needed anymore.[/QUOTE]Welcome changes.

Are there any changes in the performance compared to v6.2?
Here's a Windows compile.

xx005fs

2019-04-09 23:28

[QUOTE=preda;513288]
Embedded gpuowl.cl in executable, the .cl file next to the executable is not needed anymore.[/QUOTE]

Does shared.h still need to be included in the folder?

preda

2019-04-10 00:29

[QUOTE=xx005fs;513295]Does shared.h still need to be included in the folder?[/QUOTE]

no

preda

2019-04-12 12:17

There was a memory leak in the GCD, triggered when doing P-1. If somebody is doing many P-1, an update is recommended. PRP is not affected.

The symptom is gradually increasing memory use by gpuowl in time. Leak is on the order of 20MB per P-1 test.

preda

2019-04-12 13:26

[QUOTE=preda;513494]There was a memory leak in the GCD, triggered when doing P-1. If somebody is doing many P-1, an update is recommended. PRP is not affected.

The symptom is gradually increasing memory use by gpuowl in time. Leak is on the order of 20MB per P-1 test.[/QUOTE]

Please use v6.5 for the fix (just commited to github)

preda

2019-04-12 14:28

New in 6.5

In recent commits (v6.5) I changed a bit how configuration and work files are handled.

A new command-line argument was added: "-dir", which takes a folder name. This allows to specify the working folder of the program. All the files are accessed in that folder, such as: worktodo.txt, gpuowl.log, results.txt, checkpoints.

If -dir is not specified, the current directory is the working dir (i.e. this preserves the old behavior).

A new special file was added, "config.txt". If it exists, it should contain arguments in the same syntax as the command line arguments. These arguments will be parsed and have the same effect as the ones on the command line, except that in case of conflict the command line wins.

Example:
I have two GPUs. I keep two work folders, one per gpu. In each folder I keep a config.txt containing something like:
user preda -cpu r7 -device 1 -B1 300000

I can use a single openowl binary for both folders. I start them with something like:
./openowl -dir gpu0
./openowl -dir gpu1

I can still override what's in config.txt on the command line:
./openowl -dir gpu0 -B1 500000

Let me know what you think. Also, there may be bugs or other problems.

M344587487

2019-04-12 17:13

I think it's great. It'll allow for clean compartmentalisation without having to resort to sym links. The binary builds but seg faults with or without args (except -h) and with or without a config.txt. Could be a fault my end, I'm having to mess about transferring the source manually and the internet is not good enough to clone the entire repo (had to use --depth 1 for just the latest commit).

kriesel

2019-04-12 19:28

V6.5 gpuowl Windows build attempt failed

Same method as used for V6.4, produced [CODE]$ make openowl-win
g++ -Wall -O2 -std=c++17 -DREV=\"aa9f555f\" -Wall Pm1Plan.cpp GmpUtil.cpp Worktodo.cpp common.cpp gpuowl.cpp Gpu.cpp clwrap.cpp Task.cpp checkpoint.cpp timeutil.cpp Args.cpp Primes.cpp state.cpp Signal.cpp FFTConfig.cpp -o openowl -lOpenCL -lgmp -pthread -L/opt/rocm/opencl/lib/x86_64 -L/opt/amdgpu-pro/lib/x86_64-linux-gnu -L/c/Windows/System32 -L. -static
gpuowl.cpp: In function 'int main(int, char**)':
gpuowl.cpp:33:57: error: no matching function for call to 'std::__cxx11::basic_string<char>::basic_string(std::filesystem::__cxx11::path)'
log("Working directory: %s\n", string(current_path()).c_str());
^
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:649:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::__sv_wrapper, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(__sv_wrapper __svw, const _Alloc& __a)
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:649:7: note: candidate expects 2 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:639:2: note: candidate: 'template<class _Tp, class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Tp&, const _Alloc&)'
basic_string(const _Tp& __t, const _Alloc& __a = _Alloc())
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:639:2: note: template argument deduction/substitution failed:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:628:2: note: candidate: 'template<class _Tp, class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Tp&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&)'
basic_string(const _Tp& __t, size_type __pos, size_type __n,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:628:2: note: template argument deduction/substitution failed:
gpuowl.cpp:33:57: note: candidate expects 4 arguments, 1 provided
log("Working directory: %s\n", string(current_path()).c_str());
^
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:614:9: note: candidate: 'template<class _InputIterator, class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(_InputIterator, _InputIterator, const _Alloc&)'
basic_string(_InputIterator __beg, _InputIterator __end,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:614:9: note: template argument deduction/substitution failed:
gpuowl.cpp:33:57: note: candidate expects 3 arguments, 1 provided
log("Working directory: %s\n", string(current_path()).c_str());
^
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:576:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(basic_string&& __str, const _Alloc& __a)
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:576:7: note: candidate expects 2 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:572:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(const basic_string& __str, const _Alloc& __a)
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:572:7: note: candidate expects 2 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:568:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::initializer_list<_Tp>, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(initializer_list<_CharT> __l, const _Alloc& __a = _Alloc())
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:568:7: note: no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'std::initializer_list<char>'
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:541:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(basic_string&& __str) noexcept
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:541:7: note: no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'std::__cxx11::basic_string<char>&&'
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:529:7: note: candidate: 'template<class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&)'
basic_string(size_type __n, _CharT __c, const _Alloc& __a = _Alloc())
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:529:7: note: template argument deduction/substitution failed:
gpuowl.cpp:33:57: note: candidate expects 3 arguments, 1 provided
log("Working directory: %s\n", string(current_path()).c_str());
^
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:514:7: note: candidate: 'template<class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&)'
basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:514:7: note: template argument deduction/substitution failed:
gpuowl.cpp:33:55: note: cannot convert 'std::filesystem::current_path()()' (type 'std::filesystem::__cxx11::path') to type 'const char*'
log("Working directory: %s\n", string(current_path()).c_str());
~~~~~~~~~~~~^~
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:499:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long long unsigned int]'
basic_string(const _CharT* __s, size_type __n,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:499:7: note: candidate expects 3 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:481:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long long unsigned int]'
basic_string(const basic_string& __str, size_type __pos,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:481:7: note: candidate expects 4 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:465:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long long unsigned int]'
basic_string(const basic_string& __str, size_type __pos,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:465:7: note: candidate expects 3 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:450:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long long unsigned int]'
basic_string(const basic_string& __str, size_type __pos,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:450:7: note: candidate expects 3 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:437:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(const basic_string& __str)
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:437:7: note: no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'const std::__cxx11::basic_string<char>&'
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:429:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(const _Alloc& __a) _GLIBCXX_NOEXCEPT
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:429:7: note: no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'const std::allocator<char>&'
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:420:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string()
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:420:7: note: candidate expects 0 arguments, 1 provided
make: *** [Makefile:14: openowl-win] Error 1
[/CODE]

SELROC

2019-04-13 05:14

[QUOTE=kriesel;513543]Same method as used for V6.4, produced [CODE]$ make openowl-win
g++ -Wall -O2 -std=c++17 -DREV=\"aa9f555f\" -Wall Pm1Plan.cpp GmpUtil.cpp Worktodo.cpp common.cpp gpuowl.cpp Gpu.cpp clwrap.cpp Task.cpp checkpoint.cpp timeutil.cpp Args.cpp Primes.cpp state.cpp Signal.cpp FFTConfig.cpp -o openowl -lOpenCL -lgmp -pthread -L/opt/rocm/opencl/lib/x86_64 -L/opt/amdgpu-pro/lib/x86_64-linux-gnu -L/c/Windows/System32 -L. -static
gpuowl.cpp: In function 'int main(int, char**)':
gpuowl.cpp:33:57: error: no matching function for call to 'std::__cxx11::basic_string<char>::basic_string(std::filesystem::__cxx11::path)'
log("Working directory: %s\n", string(current_path()).c_str());
^
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:649:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::__sv_wrapper, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(__sv_wrapper __svw, const _Alloc& __a)
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:649:7: note: candidate expects 2 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:639:2: note: candidate: 'template<class _Tp, class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Tp&, const _Alloc&)'
basic_string(const _Tp& __t, const _Alloc& __a = _Alloc())
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:639:2: note: template argument deduction/substitution failed:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:628:2: note: candidate: 'template<class _Tp, class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Tp&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&)'
basic_string(const _Tp& __t, size_type __pos, size_type __n,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:628:2: note: template argument deduction/substitution failed:
gpuowl.cpp:33:57: note: candidate expects 4 arguments, 1 provided
log("Working directory: %s\n", string(current_path()).c_str());
^
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:614:9: note: candidate: 'template<class _InputIterator, class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(_InputIterator, _InputIterator, const _Alloc&)'
basic_string(_InputIterator __beg, _InputIterator __end,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:614:9: note: template argument deduction/substitution failed:
gpuowl.cpp:33:57: note: candidate expects 3 arguments, 1 provided
log("Working directory: %s\n", string(current_path()).c_str());
^
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:576:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(basic_string&& __str, const _Alloc& __a)
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:576:7: note: candidate expects 2 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:572:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(const basic_string& __str, const _Alloc& __a)
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:572:7: note: candidate expects 2 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:568:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::initializer_list<_Tp>, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(initializer_list<_CharT> __l, const _Alloc& __a = _Alloc())
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:568:7: note: no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'std::initializer_list<char>'
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:541:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(basic_string&& __str) noexcept
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:541:7: note: no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'std::__cxx11::basic_string<char>&&'
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:529:7: note: candidate: 'template<class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&)'
basic_string(size_type __n, _CharT __c, const _Alloc& __a = _Alloc())
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:529:7: note: template argument deduction/substitution failed:
gpuowl.cpp:33:57: note: candidate expects 3 arguments, 1 provided
log("Working directory: %s\n", string(current_path()).c_str());
^
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:514:7: note: candidate: 'template<class> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&)'
basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:514:7: note: template argument deduction/substitution failed:
gpuowl.cpp:33:55: note: cannot convert 'std::filesystem::current_path()()' (type 'std::filesystem::__cxx11::path') to type 'const char*'
log("Working directory: %s\n", string(current_path()).c_str());
~~~~~~~~~~~~^~
In file included from C:/msys64/mingw64/include/c++/8.2.0/string:52,
from clwrap.h:8,
from Args.h:6,
from gpuowl.cpp:3:
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:499:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long long unsigned int]'
basic_string(const _CharT* __s, size_type __n,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:499:7: note: candidate expects 3 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:481:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long long unsigned int]'
basic_string(const basic_string& __str, size_type __pos,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:481:7: note: candidate expects 4 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:465:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long long unsigned int]'
basic_string(const basic_string& __str, size_type __pos,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:465:7: note: candidate expects 3 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:450:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long long unsigned int]'
basic_string(const basic_string& __str, size_type __pos,
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:450:7: note: candidate expects 3 arguments, 1 provided
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:437:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(const basic_string& __str)
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:437:7: note: no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'const std::__cxx11::basic_string<char>&'
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:429:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string(const _Alloc& __a) _GLIBCXX_NOEXCEPT
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:429:7: note: no known conversion for argument 1 from 'std::filesystem::__cxx11::path' to 'const std::allocator<char>&'
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:420:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'
basic_string()
^~~~~~~~~~~~
C:/msys64/mingw64/include/c++/8.2.0/bits/basic_string.h:420:7: note: candidate expects 0 arguments, 1 provided
make: *** [Makefile:14: openowl-win] Error 1
[/CODE][/QUOTE]

[url]https://github.com/preda/gpuowl/pull/41[/url]

preda

2019-04-13 05:50

[QUOTE=M344587487;513520]I think it's great. It'll allow for clean compartmentalisation without having to resort to sym links. The binary builds but seg faults with or without args (except -h) and with or without a config.txt. Could be a fault my end, I'm having to mess about transferring the source manually and the internet is not good enough to clone the entire repo (had to use --depth 1 for just the latest commit).[/QUOTE]

This is the segfault, has been reported but no diagnosis yet: [url]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050[/url]

I did work-around that problem by compiling with gcc-9, which is available on ubuntu 19.04 with "sudo apt install g++-9"

I still don't understand how a problem so severe is in the wild like that. If more people hit it, I'll probably try to change the implementation to avoid using filesystem::path, although that's convenient.

SELROC

2019-04-13 05:58

[QUOTE=preda;513581]This is the segfault, has been reported but no diagnosis yet: [URL]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050[/URL]

I did work-around that problem by compiling with gcc-9, which is available on ubuntu 19.04 with "sudo apt install g++-9"

I still don't understand how a problem so severe is in the wild like that. If more people hit it, I'll probably try to change the implementation to avoid using filesystem::path, although that's convenient.[/QUOTE]

I have attempted to reproduce the segfault without success. I have fixed the Makefile by adding -lstdc++fs , the pull request is waiting.

All times are UTC. The time now is 07:02.

Page 11 of 29

« First

Last »

Show 97 post(s) from this thread on one page