Primo/FastECPP reservation thread

[R. Gerbicz]

Originally Posted by paulunderwood

The results of the tests are attached.

OK, so for balanced division it seems to be to working, could you run with
#define div 15
so when d is roughly 15 times shorter. On the code if you have few tested numbers at trial division then the primorial number will be way longer.

[paulunderwood]

Originally Posted by R. Gerbicz

OK, so for balanced division it seems to be to working, could you run with
#define div 15
so when d is roughly 15 times shorter. On the code if you have few tested numbers at trial division then the primorial number will be way longer.

The primorial for R86453 takes O(700 core hrs) to compute each time the computer resumes So you see the efficiency of using the primorial is not necessarily a great thing.

Second test file attached.

[R. Gerbicz]

Originally Posted by paulunderwood

The primorial for R86453 takes O(700 core hrs) to compute each time the computer resumes So you see the efficiency of using the primorial is not necessarily a great thing.

We could store also these primorials in a file, but would not be slower to read it ?

Originally Posted by paulunderwood

Second test file attached.

OK, so not crashed, are you using gmp-6.2.1 (this is the newest) and at least gcc 11 ?
It could be also a cpu bug.

[paulunderwood]

Originally Posted by R. Gerbicz

We could store also these primorials in a file, but would not be slower to read it ?



OK, so not crashed, are you using gmp-6.2.1 (this is the newest) and at least gcc 11 ?
It could be also a cpu bug.

If you can write the code to save and read if saved the primorial that would be great. It would speed up resumption, but the error I have been getting would still occur -- that is at Size [0].

I know you wrote some low machine memory code -- would it worth me trying that? If it works I would get further,

GMP 6.2.1 and gcc 10.2.1. The machine is not connected to the internet. I can hook it up and upgrade to gcc 11 if you really think that is where the problem might be.

[R. Gerbicz]

Originally Posted by paulunderwood

If you can write the code to save and read if saved the primorial that would be great. It would speed up resumption, but the error I have been getting would still occur -- that is at Size [0].

I know you wrote some low machine memory code -- would it worth me trying that? If it works I would get further,

I remember for that, but it is also using mod, as I can remember way much fewer number of mods, so I'd say it would also crash, but not that frequently. One real solution would be to write also that part in gwnum (for the cracked code), don't know how would it be complicated.
What I've seen in the trial division part that it could crash only for mpz_mod. We are using mpz_gcd for similar sized numbers, and mpz_divexact when d is very small and in these cases mpn_preinv_mu_div_qr is not called.

Originally Posted by paulunderwood

GMP 6.2.1 and gcc 10.2.1. The machine is not connected to the internet. I can hook it up and upgrade to gcc 11 if you really think that is where the problem might be.

The compiler could also have the bug, but gcc 10 is not that old...

[paulunderwood]

Originally Posted by R. Gerbicz

I remember for that, but it is also using mod, as I can remember way much fewer number of mods, so I'd say it would also crash, but not that frequently. One real solution would be to write also that part in gwnum (for the cracked code), don't know how would it be complicated.
What I've seen in the trial division part that it could crash only for mpz_mod. We are using mpz_gcd for similar sized numbers, and mpz_divexact when d is very small and in these cases mpn_preinv_mu_div_qr is not called.



The compiler could also have the bug, but gcc 10 is not that old...

I think it was due to a bad GMP configuration on my computer, which is now fixed.

I would no like to reserve R86453.

[andreas]

I have actually started r86453 a while ago to see how far my code could get me, and just finished the first phase. Now I expect the second phase to take a few more months (or to never finish, if the machine I am running this on keeps having a problem every few weeks - just finding the roots of some of the class polynomials takes over a month...).

[paulunderwood]

Originally Posted by andreas

I have actually started r86453 a while ago to see how far my code could get me, and just finished the first phase. Now I expect the second phase to take a few more months (or to never finish, if the machine I am running this on keeps having a problem every few weeks - just finding the roots of some of the class polynomials takes over a month...).

It's yours. Andreas! I can do something else. All the best with a successful certification. I look forward to details of it!

[andreas]

Originally Posted by paulunderwood

The primorial for R86453 takes O(700 core hrs) to compute each time the computer resumes So you see the efficiency of using the primorial is not necessarily a great thing.

With the MPI version from the git repository you could try setting the environment variable CM_ECPP_TMPDIR before starting the cm binary: Then chunks of the primorial (and the class numbers for the second phase) are stored there at the first call, and read from the files in subsequent calls.

[paulunderwood]

Originally Posted by paulunderwood

Taking W127031.

Completed.

I had to run with INI_FFT_SIZE 1 for a couple of steps around ~86000 bits during Stage 1; My cores were idling. Also the computer had a couple of signal 9 faults during Stage 2 most likely due to OOM.

I have started certification of M221509 cofactor (prp66673).

[andreas]

Excellent, congratulations for the new record!

Could you say a bit more about the running times and the size of the certificate?