GpuOwl 7.x

[firejuggler]

I have another question.
How will it work with cofactor prp?
would the line

'PRP=N/A,1,2,1841759,-1,"14734073,1694418281,5788466077109264959217""
work with a low B1 of 10000?

[kriesel]

Originally Posted by firejuggler

I have another question.
How will it work with cofactor prp?
would the line

'PRP=N/A,1,2,1841759,-1,"14734073,1694418281,5788466077109264959217""
work with a low B1 of 10000?

PRP cofactor tests are supported in prime95/mprime but not gpuowl.

[storm5510]

Originally Posted by kriesel

PRP cofactor tests are supported in prime95/mprime but not gpuowl.

Perhaps they should be.

[VBCurtis]

Originally Posted by storm5510

Perhaps they should be.

Why? Why spend the development effort for such a tiny and unimportant sub-task within this project?

[storm5510]

Originally Posted by VBCurtis

Why? Why spend the development effort for such a tiny and unimportant sub-task within this project?

I run CF's because few others want to. On my fastest hardware, a single CF takes around 4 hours to complete with Prime95. Some of us do not have the option of having a 12 core, or higher, CPU. I considered building such a machine, but I opted for an RTX 2080 instead since the vast majority of what I do uses a GPU.

If CF's are "such a tiny and unimportant" task, then why have them at all?

[kriesel]

Mihai gets to set Mihai's priorities. (Similar applies for George or anyone else.)

We can ask, beg, help, test, etc, but none of us have any claim on any of his time.
PRP Proof capability was correctly top priority because of the huge payoff.
Now it's on to reducing P-1 net cost.
LL proof per R Gerbicz' proposed method might be good someday. such as for PROVING LL tests were correct for the next Mp found, or the previous ones.

Among the other things gpuowl does not currently support that may interest some potential users are:
TF
ECM
shifts
PRP-CF
prp certs accepted by PrimeNet
Longer fft lengths
Proth numbers
Fermat numbers (Ernst may tackle this someday)
Wagstaff numbers
General repdigit numbers
APIs other than OpenCLOpenCL 1.1/1.2 on old gpus
OS other than Windows or Linux
P-1 bounds extension
Substantial P-1 error detection/correction
UI or control flow changes (continue on to next worktodo item instead of quit on error)

v7.0 is dropping LL support. Some will want it back, preferably with Jacobi and shift.

Opinions will vary on which of the above to put toward the lower and least priority.
Those who write the code get to decide.

[kriesel]

Originally Posted by storm5510

I run CF's because few others want to. On my fastest hardware, a single CF takes around 4 hours to complete with Prime95. Some of us do not have the option of having a 12 core, or higher, CPU. I considered building such a machine, but I opted for an RTX 2080 instead since the vast majority of what I do uses a GPU.

If CF's are "such a tiny and unimportant" task, then why have them at all?

To help the project of finding primes, run certs, run P-1, run TF that will help. PRP-CF does not help that. Four hours is not a long run. I have runs that take days, weeks, or months. Run some LLDC to help reduce the years of backlog.

Mainly though, run whatever makes you smile.

[Uncwilly]

Originally Posted by storm5510

I run CF's because few others want to. On my fastest hardware, a single CF takes around 4 hours to complete with Prime95. Some of us do not have the option of having a 12 core, or higher, CPU.

I have a 4 core laptop that takes more time than that for a current range CF (it has a small L2 and runs at 1.6GHz). I do it, because it brings me joy. The machine also runs certs. I have Borged a couple of 4 core machines and have them running 2 DCs on 2 cores. I have one 6 core that is running DCs on 3 cores and P-1 on the other 3. I like seeing results roll in. Do what makes you happy.

CF does not help find the next Prime, but does help that that are trying to study the factorization of Mersenne numbers.

[storm5510]

Originally Posted by kriesel

To help the project of finding primes, run certs, run P-1, run TF that will help. PRP-CF does not help that. Four hours is not a long run. I have runs that take days, weeks, or months. Run some LLDC to help reduce the years of backlog.

Mainly though, run whatever makes you smile.

This would be wavefront TF's to 76 bits making them ready for P-1. GPUto72. What makes me smile is an even mix of what I like and something productive. LL-DC is a little bug that likes to crawl around in my ear as a reminder that it is there. Perhaps, actually doing something as opposed to thinking about how to do it, might satisfy the little bug regardless of how slow and laborious it may be.

[preda]

I'm back to internet access. I'll try to get 7.0 useful/ready for testing.

[preda]

We know that for PRP, it's beneficial to run two GpuOwl processes per GPU, and this fits nicely with the very low memory requirement of the PRP.

But now in the merged PRP + P-1, there are two steps (P1, P2) that require a lot of memory. What to do? The simple solutions are: run only one process and give it the full memory of the GPU (-maxAlloc), or run two processes and give each 50% of RAM. Both solutions are somehow suboptimal.

I attempted a different solution, let's call it "Memlock". Each process knows on which device it runs (that small number in -device 0). We can use -maxAlloc to allow each process to use (almost) the full RAM of one GPU. (E.g. for a 16GB GPU that is *not* runninng the monitor, I would use -maxAlloc 15G . If running the monitor, -maxAlloc 14G). In conjunction with -pool <dir> which indicates a directory shared by all GpuOwl process. Each process, when starting the "big memory" regions (P1, P2) will attempt to aquire a memory lock on the device by creating a file in the pool directory, e.g. /pool/memlock-1 ) and wait if another process is already in a big memory region.

On normal exit the process will properly release the lock, but on crash the lock may need to be removed manually -- just delete that memlock-N directory (it's an empty directory BTW).