20201023, 06:08  #111 
"Mihai Preda"
Apr 2015
2^{4}·83 Posts 
Proof v2 selfverification
With proof v2 the points at which the proof residues are collected are not affected by the power anymove. So the residues that are good for power N are also good for any power <N. (but a higher power needs more residues, as usual).
Writing the proof residues to disk should also be more reliable now. Please report any missing or corrupted proof residues  that shouldn't happen [anymore]. A new argument was added, autoverify <power> with the default autoverify power==9; this does autoverification for any proof with power >= autoverifypower. For example, with the defaults (autoverify==9), if generating a proof of power 9 (that would require proof 9), the proof will be verified (for an additional cost of 0.2% PRP) at the end. If the verification fails, the proof will be regenerated and reverified once. If this still fails, the (bad) proof is written and an exception is thrown. This is useful for users who can afford higher powers such as 9 or 10. At these powers the cost of selfverification is small enough to be worth keeping it ON by default. The selfverified proofs are expected to be good and not to generate verification errors on the server. It's also a debugging feature allowing to catch "bad proof generation" early. Last fiddled with by preda on 20201023 at 06:12 
20201023, 06:26  #112 
"Mihai Preda"
Apr 2015
2^{4}·83 Posts 
Feature requests and remaining issues
At this point the main items for 7.x are getting close to being complete.
Please let me know what you'd like changed/added/removed, bugs and annoying behaviours, etc. [I don't promise any of the requests will be addressed, of course] 
20201023, 07:24  #113 
Romulan Interpreter
Jun 2011
Thailand
8932_{10} Posts 

20201023, 07:40  #114 
Jul 2018
Martin, Slovakia
259_{10} Posts 

20201023, 08:28  #115 
"Mihai Preda"
Apr 2015
2^{4}·83 Posts 

20201023, 08:34  #116 
"Oliver"
Sep 2017
Porta Westfalica, DE
3^{2}·41 Posts 
Random Shift, I guess. That's what a lot of us want.

20201023, 09:02  #117 
"Mihai Preda"
Apr 2015
2^{4}×83 Posts 
Thanks; I'm not personally interested in that direction. I could explain why (I think the GEC is great, really low overhead and extremely good error protection), but after all that only explains my preference, and others of course have different preferences.
OTOH somebody should step up, fork a branch of the code, and do the LL+RS and maintain it. I'm not against that. As a sidebenefit, one more person (in addition to the current contributors) would become accustomed with the code. Until then, the request has been noted :) 
20201023, 09:08  #118  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
5×947 Posts 
Quote:
A few ideas: Return of LL DC. Persistent save files every 10M or 20M iterations, for salvaging part of long runs that go wrong along the way despite the Jacobi check. There may be fft boundary adjustments or other issues since I've hit exponents that steadily accumulate error counts in the same iteration stretch, with different examples found in V6.11380 LL or V7 P1 during PRP. Perhaps occasional light maintenance of the V6.11 branch, for things V7 does not include. Documentation in detail. FFT lengths capable of gigadigit candidates P1 factoring. (The OBD subproject currently only has TF capability.) Then there's F33. Repeatederror handling seems to have changed from a 3strikesgameover model to an infinite loop model. I'd like to see an nstrikesyou'rebenched as a comment, next assignment is up to bat model, for sustained unattended runs, that make progress on some work regardless of error behavior of individual work lines, given a sufficiently large work queue. If you're looking for ideas for V7.2 or 8, there's Gerbicz's LL proof concept. PRP proof would still be the way to go for routine first testing because of the GEC and less disk space for proof generation than the LL proof's massive requirements. PRP with proof has proof of correct completion but can't prove a prime. LL as available now identifies a prime but hasn't the proof of correctness. But a proof for a correct LL test of Mersenne primes would raise the level of confidence, above that of matching residues, and could become the new higher standard for confirming Mersenne prime discoveries. In that case, smaller fft lengths would allow confirmation on old discoveries. GEC and PRP proof and maybe someday LL proof all reduce the case for nonzero shift. But maybe not quite to zero. Zero shift pretty nearly identifies a result in the database as gpuowl these days. Pseudorandom shift would relax restrictions on application or manual assignment when doing LL DC. There's the argument we should quit doing LL DC and occasional LLTC etc and do PRP with proof in its place, for considerably higher reliability and a very slight speed advantage, giving up the check of the existing first LL residue. Shift doesn't have much utility if we only perform a single PRP with proof on an exponent. Last fiddled with by kriesel on 20201023 at 09:35 

20201023, 09:36  #119  
Jul 2018
Martin, Slovakia
7·37 Posts 
Quote:
I am pretty sharp and I know my way around Python, but I haven't learned the C yet. (I know it's a different kind of language, but still, it is a language for a computer, so the main structure  how does it do its thing, not how is it called, or how is it "translated" to the 1s and 0s  is always almost the same.) It is not exactly clear to me how the FFT process works, but I've got a rough idea. Same for the random shift. I must admit, FP numbers are a bit hazy for me, but as I said, I can learn quickly. So if you'd be willing to explain it in some videochat with sharing the screen (I'm having a lot of them these days , as school replacement), I think I could be of help. 

20201023, 10:17  #120 
Romulan Interpreter
Jun 2011
Thailand
2^{2}×7×11×29 Posts 
Yep. If random shift implemented, the GC (Gerbicz Check) is not necessary (for me). Of course, other people here will say otherwise, and they may be right, but my selfish goal is to be able to run LL and DC in the same time and be able to report both of them, to clear the exponent (yeah, I know pros and cons, don't need to reopen those arguments, my hardware, my time, my electricity money ). Because is not fun to run both LL and DC and only get credit for one as long as I keep both cards occupied.

20201023, 22:53  #121  
"Mihai Preda"
Apr 2015
1328_{10} Posts 
Quote:
While C++ and GPU programming are not small topics in themselves, contributing effectivelly to GpuOwl may go one step beyond that. I don't have the bandwidth for VC, sorry. OTOH I can answer questions (email or PM or here on the open forums). I can also review pull requests. Note, pull requests are more likely to not be accepted in the codebase, but hopefully I'd offer a reason why. And, if one does a fork of the project, the issue of me gatekeeping the changes vanishes :) I may also try to put together some overview documentation of the algorithms and codebase. That would be useful, if I can only get myself to do it. Last fiddled with by preda on 20201023 at 22:59 Reason: spelling 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
GpuOwl PRPProof changes  preda  GpuOwl  20  20201017 06:51 
gpuowl: runtime error  SELROC  GpuOwl  59  20201002 03:56 
gpuOWL for Wagstaff  GP2  GpuOwl  22  20200613 16:57 
gpuowl tuning  M344587487  GpuOwl  14  20181229 08:11 
How to interface gpuOwl with PrimeNet  preda  PrimeNet  2  20171007 21:32 