mersenneforum.org ECM change
 Register FAQ Search Today's Posts Mark Forums Read

 2019-11-13, 05:42 #1 Prime95 P90 years forever!     Aug 2002 Yeehaw, FL 67×109 Posts ECM change I'm reworking the server's algorithm for handing out ECM assignments. The goal is to hand out assignments with the best chance of finding a factor for a fixed CPU effort. The new algorithm (which may undergo further adjustments) is handing out smaller exponents than before. This isn't of much concern for users unless you've specified multi-threaded workers. Smaller FFT sizes cannot take advantage of multi-threading.
 2019-11-21, 22:03 #2 lycorn     Sep 2002 Oeiras, Portugal 11×131 Posts Speaking of ECM assignments, would it be possible to add a new column to the right of the ECM progress table? Thanks to Ryan Propper's work, several exponents < 10K have now all B1 bounds tested to 800, 000, 000.
 2019-11-21, 23:47 #3 Dylan14     "Dylan" Mar 2017 547 Posts Another suggestion for ECM work: right now for ECM on Mersennes there are two choices: one for first factors and one for additional factors, and both seem to give curves with B1 = 50k, B2 = 100*B1. Perhaps we should have an additional ECM work type where the server will hand out curves with higher bounds, without having to manually request curves or edit worktodo.txt.
2019-11-21, 23:52   #4
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by lycorn Speaking of ECM assignments, would it be possible to add a new column to the right of the ECM progress table? Thanks to Ryan Propper's work, several exponents < 10K have now all B1 bounds tested to 800, 000, 000.
Who put together this table? It says that 360000 curves are needed at B1 = 800M
for t65.

In fact, only ~83000 curves are needed at 800M to achieve t65. 360K curves
is roughly 4.3 x t65. This is massive overkill.

I leave it to others to decide how many curves to run, BUT: after 85K (or so) curves
at 800M, the project should switch to about B1 = 3G or 4G.

2019-11-22, 00:13   #5
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

35×19 Posts

Quote:
 Originally Posted by R.D. Silverman Who put together this table? It says that 360000 curves are needed at B1 = 800Mfor t65.
Prime95 uses B2 = 100 * B1; doesn't that mean many more curves are needed than the usual GMP-ECM bounds?

2019-11-22, 00:33   #6
alpertron

Aug 2002
Buenos Aires, Argentina

134110 Posts

Quote:
 Originally Posted by R.D. Silverman Who put together this table? It says that 360000 curves are needed at B1 = 800M for t65. In fact, only ~83000 curves are needed at 800M to achieve t65. 360K curves is roughly 4.3 x t65. This is massive overkill. I leave it to others to decide how many curves to run, BUT: after 85K (or so) curves at 800M, the project should switch to about B1 = 3G or 4G.
The program Prime95 operates with huge numbers. B2 is always set to 100*B1 to prevent memory overflow. That's why the number of curves for Prime95 is greater that the number you indicated above.

2019-11-22, 00:51   #7
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

67×109 Posts

Quote:
 Originally Posted by R.D. Silverman Who put together this table? It says that 360000 curves are needed at B1 = 800M for t65. In fact, only ~83000 curves are needed at 800M to achieve t65. 360K curves is roughly 4.3 x t65. This is massive overkill. I leave it to others to decide how many curves to run, BUT: after 85K (or so) curves at 800M, the project should switch to about B1 = 3G or 4G.
The table came from GMP-ECM (not sure which version) given B2 = B1 * 100.

When results are reported with B2 <> 100*B1, they are converted into the equivalent number of B2=100*B1 curves using a formula given to me by Alex Kruppa.

The table is far from perfect but should give us a rough idea of how much effort has been completed.

2019-11-22, 01:26   #8
R.D. Silverman

Nov 2003

1D2416 Posts

Quote:
 Originally Posted by alpertron The program Prime95 operates with huge numbers. B2 is always set to 100*B1 to prevent memory overflow. That's why the number of curves for Prime95 is greater that the number you indicated above.
M1277 is not what I would call a huge number...... Nor is (say) any Mxxx for (say)
xxx < 5000.

YMMV depending on your definition of "huge". Running ECM at B2 = 100 B1 is
horribly inefficient.

2019-11-22, 01:34   #9
alpertron

Aug 2002
Buenos Aires, Argentina

32·149 Posts

Quote:
 Originally Posted by R.D. Silverman M1277 is not what I would call a huge number...... Nor is (say) any Mxxx for (say) xxx < 5000. YMMV depending on your definition of "huge". Running ECM at B2 = 100 B1 is horribly inefficient.
If you look at the current assignments at https://www.mersenne.org/primenet/ , there is a lot of assignments of numbers of several million digits (up to about 6 million digits). How can you optimize the step B2 for those numbers?

Last fiddled with by alpertron on 2019-11-22 at 01:34

2019-11-22, 02:31   #10
R.D. Silverman

Nov 2003

1D2416 Posts

Quote:
 Originally Posted by alpertron If you look at the current assignments at https://www.mersenne.org/primenet/ , there is a lot of assignments of numbers of several million digits (up to about 6 million digits). How can you optimize the step B2 for those numbers?
The tables under discussion (and for which there was a request to add a column)
do not go nearly that high. They max out at exponents ~15K. (i.e. numbers of ~4K digits
max).

For numbers in the millions of digits convolution methods are clearly out of reach.
For 2^p-1, p< 5K I see no reason not to use convolution based step 2. Save the step 1
result then use GMP-ECM for step 2.

Furthermore, no one is discussing ECM at B1=800M for numbers of the size you suggest.

Last fiddled with by R.D. Silverman on 2019-11-22 at 02:35

 2019-11-22, 03:04 #11 alpertron     Aug 2002 Buenos Aires, Argentina 32·149 Posts The program Prime95 is optimized for huge numbers. Ryan Propper uses GMP-ECM or a similarly step-2 optimized application, and then he sends the results manually to the Primenet server. It is clear that the should be no need to use Prime95 to discover prime factors of more than 55-60 digits. Notice that David Bessell found in 2011 the prime factor 7751061099802522589358967058392886922693580423169 of the 17th Fermat number using Prime95. F17 has more than 39400 digits. He also found the prime factor 37590055514133754286524446080499713 of F19 in 2009. It has more than 157800 digits. Last fiddled with by alpertron on 2019-11-22 at 03:05

 Similar Threads Thread Thread Starter Forum Replies Last Post GinoTitan PrimeNet 4 2016-05-29 19:25 deepesh Hardware 5 2016-04-05 05:30 Fred Lounge 8 2016-01-31 17:42 Xyzzy Lounge 5 2009-08-31 12:41 Andriy Information & Answers 1 2009-06-20 12:39

All times are UTC. The time now is 07:39.

Fri Jan 22 07:39:52 UTC 2021 up 50 days, 3:51, 0 users, load averages: 1.42, 1.49, 1.52