mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > And now for something completely different

Reply
 
Thread Tools
Old 2021-02-04, 15:15   #45
Puzzle-Peter
 
Puzzle-Peter's Avatar
 
Jun 2009

10101100012 Posts
Default

Quote:
Originally Posted by Gelly View Post

In the meantime, I have been meaning to (actually) prove the cofactor to Bern(8286), only to find what is the strangest return I have seen in a while from Primo:

Code:
[Candidate]
Input=8286.in
Output=prime-B422001C4C67B.out
Status=Sorry, Primo cannot certify the candidate
Failed in 26008 seconds. I genuinely am at a loss, as I have never ever seen this before. I checked my candidate against pfgw64, with all bases up to 15, and it seems to be really really PRP, so I guess Primo has its limitations. Will probably shoot an email to Marcel if no one here has ever seen it before.

The way Primo works is (very simply put) as follows: it looks for a number that is slightly smaller than the candidate (how much smaller is given as "gain" in bits) in such a way that the candidate is prime if the slightly smaller numer is prime. Then it repeats this process with smaller and smaller numbers until it reaches a very small number that is known to be prime.

Sometimes Primo cannot find such a smaller number. In such cases it backtracks, trying to find another helper number for the last step or the step before etc. I think backtracking is limited to 10 steps. If there are only dead ends, Primo is unably to prove the candidate prime. This happens usually at the beginning of a run when there is no or very little chance of backtracking. I don't know about the latest versions, but a few years ago, the largest number that Primo was guaranteed to be able to prove was less than a third (in terms of digits) of the largest numbers it was able to prove. So there is always a chance of failure and it's getting bigger with larger candidates.


Try contacting Marcel anyway as there might be another cause.
Puzzle-Peter is offline   Reply With Quote
Old 2021-02-04, 19:48   #46
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

1111000101112 Posts
Default

@Gelly

You might find that altering the settings under "Menu" will get you further, most likely a proof. I cant's recall what it is called, but I think it goes up to "32". You most likely would have to start from the beginning.

Also I am getting great thoughput by running two numbers at once. There are plenty of free cycles during phase 1. You can see what is happening by running top in a console. (I am running nice -n -5 on the main number and nice -n 19 on the subsidiary one. I am using all threads, but there is a slight impact on turbo.)

Last fiddled with by paulunderwood on 2021-02-04 at 20:36
paulunderwood is offline   Reply With Quote
Old 2021-02-04, 20:38   #47
Batalov
 
Batalov's Avatar
 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

2·4,783 Posts
Default

I think there is also randomness in proof and/or user can induce the proof going different paths: change some options in settings. E.g. if you change the highlighted options, it will give up optimizing gain earlier or later, and you might pass the 1st test and then it will go forward.
Attached Thumbnails
Click image for larger version

Name:	poptions.png
Views:	116
Size:	37.4 KB
ID:	24268  
Batalov is offline   Reply With Quote
Old 2021-02-24, 06:38   #48
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

1111000101112 Posts
Default

Quote:
Originally Posted by paulunderwood View Post

Since ryanp is certifying M78737 cofactor, I'll have a stab at running M82939 cofactor (prp24948) at a low priority in parrallel with R49081,
M82939 cofactor is certified

FactorDB entry

Last fiddled with by paulunderwood on 2021-02-24 at 06:38
paulunderwood is offline   Reply With Quote
Old 2021-03-15, 16:58   #49
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

3,863 Posts
Talking

Reserving:

Code:
M86137 cofactor prp25896
M86371 cofactor prp25984
M87691 cofactor prp26371
E(11848)/(5*1582043) prp40792
paulunderwood is offline   Reply With Quote
Old 2021-04-23, 15:07   #50
Gelly
 
Gelly's Avatar
 
May 2020

3·13 Posts
Default

Quote:
Originally Posted by Gelly View Post
Meanwhile, in the interest of getting my irregular prime record back, I will be doing PRP28507, a cofactor of Bern(10264).
Done! 6693424s (77.5 days). I'll first be tinkering with the cofactor of Bern(8286) (hopefully a month-ish at most), but after seeing Paul go hogwild on reservations, my next reservation is PRP32010, or M106391/286105171290931103.
Gelly is offline   Reply With Quote
Old 2021-04-28, 00:02   #51
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

3,863 Posts
Default

Quote:
Originally Posted by Gelly View Post
Done! 6693424s (77.5 days). I'll first be tinkering with the cofactor of Bern(8286) (hopefully a month-ish at most), but after seeing Paul go hogwild on reservations, my next reservation is PRP32010, or M106391/286105171290931103.
Nice one. I am looking forward to your first 30k+ digit certification.

Those 4 I reserved are running on a relatively slow Xeon Phi which has 256 threads. An instance of Primo often drops to one thread, So, in the long term I should get some nice throughput.

Last fiddled with by paulunderwood on 2021-04-28 at 00:07
paulunderwood is offline   Reply With Quote
Old 2021-05-04, 19:25   #52
Batalov
 
Batalov's Avatar
 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

225368 Posts
Default

Asuncion & Allombert did the fib(130021) proof,
but it remains to be seen if it was some other ECPP or even a hybrid proof.
They are folks widely known in narrow circles (Pari/GP team, INRIA).
Batalov is offline   Reply With Quote
Old 2021-05-04, 19:41   #53
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

3,863 Posts
Default

Quote:
Originally Posted by Batalov View Post
Asuncion & Allombert did the fib(130021) proof,
but it remains to be seen if it was some other ECPP or even a hybrid proof.
They are folks widely known in narrow circles (Pari/GP team, INRIA).
It will interesting to hear of what hardware they are using -- maybe a cluster?
paulunderwood is offline   Reply With Quote
Old 2021-05-05, 00:05   #54
Batalov
 
Batalov's Avatar
 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

956610 Posts
Question

Quote:
Originally Posted by wpolly View Post
I'll give a first call: I reserve Phi(32481,10) at 21600 digits.
It doesn't take 2 years to Primo such a small number.
Any news?

I will queue to run Phi(70842,10) at 23613 digits.
And Phi(47468,10) at 23732 digits
Batalov is offline   Reply With Quote
Old 2021-05-05, 02:09   #55
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

3,863 Posts
Default

Bill Allombert replied to my enquiry to him about the certiifcation of U(130021):

Quote:
> Bill,
>
> congrats to you and Jared for the ECPP of U(130021).

Thanks! Apology if I did not fill the form correctly.
PARI/GP is not in the list of software, and I did not found
where I could provide the relevant information.
Finding out that Fibonacci numbers were to be denoted with U() already
took some effort.

> We were wondering what methods were used, what software and what
> hardware too, and how long it took. Please let us know either by
> replying to me or directly posting on:

I used a modified version of PARI/GP primecert function,
which was written by Jared during his internship at Bordeaux.

The primality certificate is available in both PARI and Primo format at
<https://pari.math.u-bordeaux.fr/pub/bill/primecerts>
The PARI certificate can be checked with primecertisvalid in GP.

Some of the changes I made are in PARI master branch, some other
are not yet (because they would slowdown ecpp for smaller input).
The main change is the parallelisation of the Cornacchia step.

This computation was done as an experiment to find out what kind of
changes were needed for large input.

The computation was done with the pthread build of PARI on a
dual AMD EPYC 7702 64-Core (so 128 total cores) and 1Tb of
RAM. This is quite a fast system: to give an idea of the speed,
checking the certificate with primecertisvalid() take
1h 4min of running time, (137h 36min total CPU time)

I am required to state that
"
Experiments presented in this project were carried out using the PlaFRIM
experimental testbed, supported by Inria, CNRS (LABRI and IMB),
Université de Bordeaux, Bordeaux INP and Conseil Régional d’Aquitaine
(see https://www.plafrim.fr)
"

I could only reserve this system for 72 contiguous hours, so I split the
computation in 16 partial certificates.

The running time was 743h, 29min, 59,167 ms, the total CPU time
over all cores was 43386h, 1min, 9,709 ms.
paulunderwood is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
15*2^n-1, n>1M Reservation Thread Kosmaj Riesel Prime Search 706 2021-10-09 18:46
5*2^n-1 Reservation Thread VBCurtis Riesel Prime Search 679 2021-10-09 17:33
Octoproth Reservation Thread Greenbank Octoproth Search 2 2007-12-26 09:58
Dodecaproth Reservation Thread Greenbank Octoproth Search 30 2006-02-09 00:33
Hexadecaproth Reservation Thread (n=76) Greenbank Octoproth Search 0 2006-01-25 13:41

All times are UTC. The time now is 09:08.


Thu Oct 21 09:08:48 UTC 2021 up 90 days, 3:37, 1 user, load averages: 0.85, 0.98, 1.14

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.