About M1277

[Magellan3s]

I'm pretty uninformed when it comes to this but.....

Is there a reason mfaktc can't be used? I know it has a minimum exponent size requirement but can that be changed?

[bsquared]

Mfaktc is great at finding small factors but the miminal possible factor size of M1277 is many many orders of magnitude larger than anything it can find. We know this because of the amount of ECM completed on this number.

[Magellan3s]

Originally Posted by bsquared

Mfaktc is great at finding small factors but the miminal possible factor size of M1277 is many many orders of magnitude larger than anything it can find. We know this because of the amount of ECM completed on this number.

I think I understand, thank you!

[kriesel]

Aside from the low-exponent issue, there's a limit in mfaktc at 95 bits, mfakto at 92 bits. M1277 has already been TF to 68 bits, and it took ~47,000 GHD. To go to 69 bits would take another ~47,000 GHD, which is ~3 weeks on an RTX2080 GPU. From 69-70 would take twice as long, 70-71 four times, etc., growing exponentially. Well before ~2²⁷ times 3 weeks, run time gets prohibitively long. And if not for that, from 95 bits to 1277/2 is beyond its current capability, requiring someone to code new kernels. https://www.mersenne.ca/exponent/1277
There's no multi-GPU implementation of TF for Mersenne numbers, so running a span of x to x+y bits, only parallelizes to 2 GPUs:
x to x+y-1 on GPU a, x+y-1 to x+y on GPU b, giving about equal run time for same model GPUs.
Some other possibilities were mentioned earlier in this thread https://mersenneforum.org/showpost.p...3&postcount=18
and VBCurtis responds that reachable TF is pointless because of the amount of ECM that has been done
https://mersenneforum.org/showpost.p...7&postcount=19
My attempted summary of factoring choices & past M1277 effort is https://mersenneforum.org/showpost.p...5&postcount=22 which indicates that almost any factors <166. bits would have already been found by ECM, so there's nothing reachable by TF remaining.

[Magellan3s]

Originally Posted by kriesel

Aside from the low-exponent issue, there's a limit in mfaktc at 95 bits, mfakto at 92 bits. M1277 has already been TF to 68 bits, and it took ~47,000 GHD. To go to 69 bits would take another ~47,000 GHD, which is ~3 weeks on an RTX2080 GPU. From 69-70 would take twice as long, 70-71 four times, etc., growing exponentially. Well before ~2²⁷ times 3 weeks, run time gets prohibitively long. And if not for that, from 95 bits to 1277/2 is beyond its current capability, requiring someone to code new kernels. https://www.mersenne.ca/exponent/1277
There's no multi-GPU implementation of TF for Mersenne numbers, so running a span of x to x+y bits, only parallelizes to 2 GPUs:
x to x+y-1 on GPU a, x+y-1 to x+y on GPU b, giving about equal run time for same model GPUs.
Some other possibilities were mentioned earlier in this thread https://mersenneforum.org/showpost.p...3&postcount=18
and VBCurtis responds that reachable TF is pointless because of the amount of ECM that has been done
https://mersenneforum.org/showpost.p...7&postcount=19
My attempted summary of factoring choices & past M1277 effort is https://mersenneforum.org/showpost.p...5&postcount=22 which indicates that almost any factors <166. bits would have already been found by ECM, so there's nothing reachable by TF remaining.

This cleared things up even more, thank you!

[LaurV]

Originally Posted by kriesel

There's no multi-GPU implementation of TF for Mersenne numbers, so running a span of x to x+y bits, only parallelizes to 2 GPUs

Not my intention to contradict anything you (and other guys) said about the difficulty of such job, just want to point out that the TF can be easily paralelized to 960 GPUs (for the 4620 classes version) just by rewriting the checkpoint file of mfaktc, for example. Of course, writing a "parallel" version (where you can specify the class) is quite easy. However, this is futile, it will just shorter the time from (arbitrary) 900 million years to one million years

[kriesel]

Originally Posted by LaurV

TF can be easily paralelized to 960 GPUs (for the 4620 classes version) just by rewriting the checkpoint file of mfaktc, for example. Of course, writing a "parallel" version (where you can specify the class) is quite easy. However, this is futile, it will just shorter the time from (arbitrary) 900 million years to one million years

And require setting up a foundation (def'n 3b) to maintain the 1000 GPU farm including a few dozen hot spares for the long term. For NO factor-found utility, since ECM has already covered any reachable bit level. Ernst's Mfactor could be used in an analogous futile mass space heater game using CPUs, using existing code, and achieving even larger absurd run time estimates. And it allows specifying start and end k values, so each of the many classes could be subdivided for greater futile parallelism.

[retina]

Originally Posted by kriesel

And require setting up a foundation to maintain the 1000 GPU farm including a few dozen hot spares for the long term. For NO factor-found utility, since ECM has already covered any reachable bit level. Mfactor could be used in an analogous futile mass space heater game using CPUs, using existing code, and achieving even larger absurd run time estimates. And allows specifying start and end k values, so each of the many classes could be subdivided for greater futile parallelism.

Yeah, you are 100% correct.

Instead we should be TFing RSA-1024 (and ECMing also). It's smaller so it should be really easy.

I think you missed the trailing razz emoji in your quote. I put another one in here, I hope you don't miss that one also.

[kruoli]

A sincere question would be: How much ECM needs to be done on M1277 right now to reach the ECM target? This is a question that is likely only answerable if e.g. Ryan Propper and Sam Wagstaff state on how much ECM they have spent.

[Mark Rose]

Originally Posted by VBCurtis

Note that Ken's citation of 660 core-years was an estimate for the matrix step. That step is usually 1/6 or so of the time spent sieving, so the whole job might be expected to take 7 times as long as the numbers Ken just mentioned.

Greg's development of GPU-enhanced msieve matrix solving has dramatically reduced the time required for the matrix solving step. If we sieved this job enough to get a matrix that would fit onto 8x A100 GPUs, a single system could solve the matrix in something on the order of a week. These numbers are based on scaling up from the GNFS-221 matrix job just completed (see Cunningham subforum), which was 114M matrix size, fit on 4x A100, and took 38 hours to solve on 8x A100. If we double the matrix size it would fit onto 8x A100 and take 4-5 times as long to solve.

So, on the order of 20,000 weeks on a single 12-core machine to sieve, and one week on a really fancy 8-GPU machine for the matrix.

168 hours of p4d.24xlarge at AWS is $5506 on demand or about $1600 using current spot prices.

The ~4000 core‐years is a little harder to come up with.

[Andrew Usher]

The difficulty then would be of the same order as the record factorisation of RSA-250, now 3 years ago. I would put this number to be somewhat a bigger deal than that. As for the ECM, even our limited Primenet records have it near t70, and I wouldn't doubt the real figure to be near t75 - surely this has been a very highly investigated number, perhaps the highest ever in ECM effort.

The job will be done by SNFS - either sooner or later - with very good odds. I imagine we'd prefer it sooner, but it's purely a matter of assembling the needed resources.