gpuOwL: an OpenCL program for Mersenne primality testing

[PhilF]

Originally Posted by mrh

I'm not an amd expert, but I think that indicates you are using the "amd pro" drivers (I think that is what they are called) vs. rocm.

-mike

That would make sense. If so, I highly recommend the pro drivers to others.

[kriesel]

For anyone who'd like to give it a try on Windows, this build of the latest available commit was done on Windows 7 x64 minutes ago. I haven't tried it past the help function. Make gpuown-win again generated the usual shower of warnings; see build-log.txt attached.

Originally Posted by preda

For a task of the form:
PRP=XXXXXXXX,1,2,91408469,-1,77,1
i.e. note the final integer, let's call it "wantsPm1", being "1" instead of the usual "0" -- this indicates that P-1 testing is desired;

gpuowl will automatically expand the task into a P-1 and a PRP with the "wantsPm1" set to 0.

It works like this:
- gpuowl reads the first good line from worktodo.txt
- if that line is a PRP with wantsPm1 non-zero, two new tasks are *appended* to the worktodot.txt (i.e. at the end)
- after which the PRP task that was having wantPm1 is deleted from worktodo.txt
- loop to find the first task in workdoto.txt

I.e. this would result in a re-ordering of the tasks in worktodo.txt because the "expanded" tasks are always added to the end.

It is likely there are some bugs, please let me know if you see any.

[Prime95]

Originally Posted by preda

gpuowl will automatically expand the task into a P-1 and a PRP with the "wantsPm1" set to 0.

If P-1 finds a factor are both the P-1 and PRP lines deleted?

[wfgarnett3]

Originally Posted by kriesel

An unfortunate feature of prime95 is that without hyperthreading enabled on the host, occupying one cpu core with something else can cost an entire prime95 worker's output, however many cores that is. A little cpu usage by gpuowl even with -yield is normal. Some cpu cycles are used for save checkpoints to disk, screen output, doing the GEC, etc. But if -yield is in the config.txt or the command line, it should be reduced from the full cpu core or hyperthread that occurs without that option. How much were you seeing without -yield, and how much with?

Hyperthreading is enabled on my 2 core i3-4150.

-yield does help somewhat.

Here are my tests.

Screenshot 1 is Prime95 by itself PRP testing 90519811 with a 14.3 iteration time and 53% CPU usage.
Screenshot 2 is gpuOwL by itself without -yield PRP testing 81943843 with a 17.7 iteration time and 27% CPU usage.
Screenshot 3 is gpuOwL by itself with -yield with a 17.8 iteration time and 31% CPU usage.
Screenshot 4 is both Prime95 and gpuOwL (without -yield) showing Prime95 has a 19.1 iteration time and 81% CPU usage (thus gpuOwL slowed Prime95 down from 14.3 to 19.1).
Screenshot 5 is both Prime95 and gpuOwL (with -yield) showing Prime95 now has a 17.7 iteration time and 77% CPU usage so the -yield option helped some.

Thanks.

[kriesel]

Originally Posted by wfgarnett3

Hyperthreading is enabled on my 2 core i3-4150.

-yield does help somewhat.

Here are my tests.

Screenshot 1 is Prime95 by itself PRP testing 90519811 with a 14.3 iteration time and 53% CPU usage.
Screenshot 2 is gpuOwL by itself without -yield PRP testing 81943843 with a 17.7 iteration time and 27% CPU usage.
Screenshot 3 is gpuOwL by itself with -yield with a 17.8 iteration time and 31% CPU usage.
Screenshot 4 is both Prime95 and gpuOwL (without -yield) showing Prime95 has a 19.1 iteration time and 81% CPU usage (thus gpuOwL slowed Prime95 down from 14.3 to 19.1).
Screenshot 5 is both Prime95 and gpuOwL (with -yield) showing Prime95 now has a 17.7 iteration time and 77% CPU usage so the -yield option helped some.

Thanks.

See https://www.mersenneforum.org/showpo...postcount=1403 for how much difference -yield made in my case; the difference between one core saturated, and 2% of a core. What else is using cpu during your gpuowl-only runs? Windows Task Manager, Processes tab, sort by cpu % usage. On my systems, the ratio of accumulated cpu time prime95 to gpuowl-win are >20:1.

[preda]

Originally Posted by Prime95

If P-1 finds a factor are both the P-1 and PRP lines deleted?

No, not yet (an oversight on my part). What should I do with the AID and the assignment relative to primeNet?

- should I put the AID (of the PRP) on the P-1 factor-found result?
- if I simply drop the PRP assignment from worktodo.txt on P-1 factor found, it would still be assigned on the server even if the factor is reported?

[wfgarnett3]

Originally Posted by kriesel

See https://www.mersenneforum.org/showpo...postcount=1403 for how much difference -yield made in my case; the difference between one core saturated, and 2% of a core. What else is using cpu during your gpuowl-only runs? Windows Task Manager, Processes tab, sort by cpu % usage. On my systems, the ratio of accumulated cpu time prime95 to gpuowl-win are >20:1.

See attached screenshots -- gpuOwL-only runs are basically using all of the 27% CPU usage

[preda]

I added some untested code that is supposed to:

1. when a P-1 factor is found, all PRP entries from worktodo.txt for the same exponent are removed. No result is written (to results.txt) for these deleted tasks.
2. when a P-1 factor is found in the background (GCD) while a PRP test for the same exponent is ongoing, the PRP test is aborted early and the point 1. above is applied.

I think this solution [in addition to bugs] has the problem of leaving PRP assignments "hanging" on primenet. Maybe the server could implement auto-release of the PRP assignments of a user when that user submits a factor for the same exponent (because, after a factor found, it does not make sense for the user that found the factor to pursue the PRP tests)

Originally Posted by preda

No, not yet (an oversight on my part). What should I do with the AID and the assignment relative to primeNet?

- should I put the AID (of the PRP) on the P-1 factor-found result?
- if I simply drop the PRP assignment from worktodo.txt on P-1 factor found, it would still be assigned on the server even if the factor is reported?

[preda]

Originally Posted by kriesel

Make gpuown-win again generated the usual shower of warnings; see build-log.txt attached.

Ken, I'm aware of your complaint agains those warnings, and I did look into them. IMO those warnings are invalid, a compiler problem. They could be silenced with some effort, but again IMO that effort is not worth expending because the [invalid] warnings are an incovenience only for the person building the program (Ken) but not for the users.

[kriesel]

Originally Posted by wfgarnett3

See attached screenshots -- gpuOwL-only runs are basically using all of the 27% CPU usage

I don't see any of the recent performance-enhancing -USE options on your runs. See https://www.mersenneforum.org/showpo...postcount=1654 for tuning data on a GTX1050Ti
-CARRY32 may also help.
A couple of my systems' cpu overhead for gpuowl-win are shown in the screen captures. Roa (Windows 10) is running just over a full HT "core" of overhead (of total 24 cores plus HT, one "core" = 1/48 =2.08%) while condorella (Windows 7) is running a tiny fraction of that. I don't know why there's such a difference.

wfgarnett3's 27% utilization is also ~one HT "core" on a dual-core HT Windows 10 system IIRC.

Does -yield work on Window 7 and not on Windows 10? Any Windows 8.x users out there?

[kriesel]

Originally Posted by preda

- should I put the AID (of the PRP) on the P-1 factor-found result?

It might be the easiest way to tell the PrimeNet server what to clean up.
It's sort of analogous to the case of a multibitlevel factoring assignment returning a factor in an early bit level; no point in soldiering on needlessly once the exponent has a factor discovered and reported.