[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]


Obviously none found.
Thinking out loud on the distribution of "luck" in the world, it is not the same everywhere.

[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.

[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).

V6.2-e2ffe65 on Win7 x64, RX480
 

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.

[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.

O2 vs O3
 

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

[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.

[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.

[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.

[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.

[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 computer <number>. It could be useful.[/QUOTE]

Should it stop afterwards? (ignoring worktodo.txt)