Primo/FastECPP reservation thread

[Puzzle-Peter]

Originally Posted by Gelly

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:

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

[paulunderwood]

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

[Batalov]

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.

[paulunderwood]

Originally Posted by paulunderwood

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

[paulunderwood]

Reserving:

M86137 cofactor prp25896
M86371 cofactor prp25984
M87691 cofactor prp26371
E(11848)/(5*1582043) prp40792

[Gelly]

Originally Posted by Gelly

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.

[paulunderwood]

Originally Posted by Gelly

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.

[Batalov]

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

[paulunderwood]

Originally Posted by Batalov

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?

[Batalov]

Originally Posted by wpolly

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

[paulunderwood]

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

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