ECM Stage 2 RAM
 

As most know, the minimum RAM size for any stage 2 process in [I]Prime95[/I] is 8MB. Assignments are based on whatever the amount is As I take the size up, the exponent values increase. When this happens, the smaller exponents, < 100,000, are eventually bypassed. Is there a way to compensate for this?

This might be a new "feature".

Several years ago I used to set RAM really now; get assigned a bunch of LOW ECM work; stop Prime95 and increase the RAM and start it so they would finish faster.

[QUOTE=petrw1;499903]This might be a new "feature".

Several years ago I used to set RAM really now; get assigned a bunch of LOW ECM work; stop Prime95 and increase the RAM and start it so they would finish faster.[/QUOTE]

This is where I run into a wall, of sorts. If I go above a certain point, [I]Prime95[/I] begins to pause during stage 2. Going any higher decreases the time between pauses and increases the pause time. It eventually becomes self-defeating. P-1 stage 2 does [U]not[/U] do this! I suspect this is unique to my setup.

The cutoff seems to be in the 48MB to 64MB range. This is not a problem with smaller exponents, regardless of the RAM setting. By smaller, I mean anything at, or below, six digits.

What it does during these pauses, I have not a clue. All I can say is that there is no hard drive activity and everything else responds properly. This applies to Windows 7 and 10, both x64.

Perhaps I need to do some experimentation with the RAM settings in the BIOS. Something is amiss and I would like to find it.

Maybe I don't understand your question entirely, but if you want to manually do ECM on a exponent, you can just add it to your queue with:
ECM2=1,2,exponent,-1,B1,B2,numbersofcurves,"knowfactorn,knownfactor"
for instance:

ECM2=1,2,1682911,-1,250000,25000000,3
will let Prime95 do 3 ECM curves on 2^1682911-1 with B1=250e3 B2=25e6

Seconded.
If you do that, you may test whatever exponent you wish, regardless of the RAM size assigned to Prime95. Of course, if you are testing very small exponents, the amount of RAM needed will be very low, but it´s good practice to have a generous amount assigned to Prime95, in case you decide to test larger exponents.
I am curently running curves on M8581, and the program is using only 431 MB for Stage 2, but this is a very small exponent. If you test exponents in the 2M range, for example, the amount of RAM used wll jump to a couple of gigabytes.

I did this a while back because I didn't want the hassle of manually entering assignments.

In my case I wanted ECM-Fermat assignments and I noticed that for my specific PC that GhzDays per Day was noticeably more generous with the smaller assignments (up to about 131072) but I also noted that the RAM I needed to specify for Prime95 to give me assignments this low was less than ideal to quickly complete these.

So I would set RAM to about 100; get 30 days worth of low ECM-F; then set RAM to about 2,000.
Rinse and repeat monthly.

[QUOTE=VictordeHolland;499934]Maybe I don't understand your question entirely...[/QUOTE]

Forgive me. I went a bit off target with this.

[QUOTE=petrw1]So I would set RAM to about 100; get 30 days worth of low ECM-F; then set RAM to about 2,000.[/QUOTE]

What I do, is allow [I]Prime95[/I] to get the assignments it wants based on the memory allocation, then I go into the preferences and set days of work to zero. Then, I can take the RAM up. It reports each completion, but does not reserve more as it goes along.

I found something in relation to the pausing in stage 2. This system BIOS has two memory settings, Auto, and XMP or "eXtreme Memory Profile." Setting it to XMP creates a drop-down list of options which includes the RAM speed. The rest, I do not understand what they are. No worry. On the XMP setting and not changing anything else in the list, the pause times are greatly reduced.

I have been testing with the RAM set to 512MB and exponents > 1,000,000. The pause time is about 1.1 seconds for every 7%. It can complete each test in about eight minutes. If I drop this to 256MB, it takes nine minutes to complete on slightly smaller exponents. I do not see any pauses.

About setting it to get 30 days of work: In my case, 15 is about the maximum number that it will maintain. I will give this another try.

A couple of questions:

Take the assignment below from my HP:

[CODE]ECM2=<ID>,1,2,109229,-1,250000,25000000,3,"7680983281,2929719921407"[/CODE]

(1) The values at the end, in quotes, are known factors. Does [I]Prime95[/I] continue if it finds one of these, or does it stop?

(2) Is there a rule-of-thumb for determining the B! and B2 values? All I know is that B2 is approximately equal to B1 x 10.

Thank you! :smile:

[QUOTE=storm5510;500032](1) The values at the end, in quotes, are known factors. Does [I]Prime95[/I] continue if it finds one of these, or does it stop?[/QUOTE]

No, it ignores those and keeps going.

Note: if the program finds a [I]new[/I] factor not in the list of known factors, then the ECM assignment will terminate, unless you put [c]ContinueECM=1[/c] in your [c]prime.txt[/c] file, in which case it will finish doing all the curves specified in the worktodo line (in your example, 3), possibly finding additional factors.

[QUOTE](2) Is there a rule-of-thumb for determining the B! and B2 values? All I know is that B2 is approximately equal to B1 x 10.[/QUOTE]

Actually it's B1 × 100, and your example reflects that. That is a commonly used rule of thumb, although other values are possible.

You can look at the [URL="https://www.mersenne.org/report_ecm/?txt=0&ecmnof_lo=109000&ecmnof_hi=110000&ecm_lo=109000&ecm_hi=110000"]ECM Progress report page[/URL], setting the appropriate exponent range you're interested in, to see how much ECM has been done already and with what parameters.

[QUOTE=GP2;500038]...Actually it's B1 × 100, and your example reflects that. That is a commonly used rule of thumb, although other values are possible...[/QUOTE]

Thank you for your reply!!!

My example shows 250,000 and 25,000,000. What happens if I were to narrow this range? An example might be lowering B2 to 2,500,500. Based on what I've seen, B1 seems to be much more important than B2.

A shot-in-the-dark: These are bounds for calculations using the seed value that appears at the start of Stage 1. If this is not the case, then I am unsure how they are used.

I apologize for going somewhat [U]off-topic[/U] with this!

[QUOTE=storm5510;500041]Thank you for your reply!!!

My example shows 250,000 and 25,000,000. What happens if I were to narrow this range? An example might be lowering B2 to 2,500,500. Based on what I've seen, B1 seems to be much more important than B2.

A shot-in-the-dark: These are bounds for calculations using the seed value that appears at the start of Stage 1. If this is not the case, then I am unsure how they are used.

I apologize for going somewhat [U]off-topic[/U] with this![/QUOTE]
[url]https://en.m.wikipedia.org/wiki/Lenstra_elliptic-curve_factorization[/url]

B2=B1*100 is actually low. GMP-ECM chooses a much higher B2 if you do not specify it yourself:

B1=11000, B2=1684420
B1=50000, B2=15446350
B1=250000, B2=183032866
B1=1000000, B2=974637522
B1=3000000, B2=4592487916
B1=11000000, B2=30114149530

So roughly B2=3.8 * B1[SUP]1.4[/SUP]

I think ideally stage2 should take the same amount of time as stage1.

[QUOTE=storm5510;500041]What happens if I were to narrow this range? An example might be lowering B2 to 2,500,500.[/QUOTE]

I think a factor of 10 is just too small. If anything, some people even recommend using a factor larger than 100.

[QUOTE]
Based on what I've seen, B1 seems to be much more important than B2.

A shot-in-the-dark: These are bounds for calculations using the seed value that appears at the start of Stage 1. If this is not the case, then I am unsure how they are used.[/QUOTE]

Stage 1 is only affected by B1. Stage 2 is determined by both B1 and B2. In my experience working with ECM on small exponents, factors are much more likely to be found during stage 2. So the choice of B2 does matter a lot. It's a tradeoff. If it's too small, you'll have much less chance of finding anything, if it's too large, there will be diminishing returns and it will take too long. I would stick with B1 × 100.

[QUOTE=ATH;500049]B2=B1*100 is actually low. GMP-ECM chooses a much higher B2 if you do not specify it yourself[/QUOTE]

But GMP-ECM uses a different algorithm that is only helpful for quite small exponents. He is talking about the exponent 109229, I think that is out of GMP-ECM's useful range.

For mprime I'd say the factor of 100 rule of thumb would still apply. No sense spending a ton of time pursuing diminishing returns on one ECM curve when you can just start another curve and maybe a factor will pop out much more easily with that one.

[QUOTE=GP2;500051]He is talking about the exponent 109229, I think that is out of GMP-ECM's useful range.
[/QUOTE]

It is indeed. I did some tests with GMP-ECM a while ago and, AFAIR, the useful limit was ~40K.

[QUOTE=ATH;500049]B2=B1*100 is actually low. GMP-ECM chooses a much higher B2 [U]if you do not specify it yourself[/U]:....So roughly B2=3.8 * B1[SUP]1.4.[/SUP][/QUOTE]

An interesting formula. How would you format a worktodo line without specifying B2? Something would have to fill that space.

Now, we get back to RAM and on-topic. The most I can allocate on this I7 is 2.5GB. When I built this last year, I had intended to add more RAM later on. That didn't happen. So, it still has 8GB. As a point of reference, my much older HP has 4GB and seems to do quite well.

As B2 increases, so does the amount of RAM required, or so it seems. George talks about memory-thrashing in his documentation. I would prefer to avoid that. In my experimentation this morning, I tried squeezing the amount for Stage 2 RAM lower and lower. The only result I saw was that Stage 2 would take longer to run.

[QUOTE=storm5510;500081]An interesting formula. How would you format a worktodo line without specifying B2? Something would have to fill that space.[/QUOTE]

He is talking about an entirely different program called GMP-ECM. It doesn't use worktodo.txt files. If you use mprime/Prime95, you have to specify B2.

One reason that GMP-ECM can use much larger B2 is because it uses a much more efficient algorithm for stage 2. But it can only be used for small exponents. As lycorn mentioned, for anything bigger than about 40k, you need to use mprime instead.

[QUOTE]As B2 increases, so does the amount of RAM required, or so it seems. George talks about memory-thrashing in his documentation. I would prefer to avoid that. In my experimentation this morning, I tried squeezing the amount for Stage 2 RAM lower and lower. The only result I saw was that Stage 2 would take longer to run.[/QUOTE]

Higher B2 will take larger memory to run efficiently. If you reduce the memory a lot, it will take a lot longer to run.

With B1 = 250k and B2 = 100 × B1 and exponents in the 100k range, I don't think it will need anywhere near 2.5 GB actually.

If you run with [c]mprime -d[/c], then when it starts ECM stage 2 it will output lines of the form [c]Using ____MB of memory in stage 2.[/c] Obviously this will be no greater than the amount of kB you specified in the [c]Memory=[/c] line in your [c]local.txt[/c] file.

I did not mean of for you to not enter B2 value in Prime95, it is not possible. I was just illustrating that the "standard" B2 in GMP-ECM is so high, and yes this algorithm will not work for higher numbers. But my point was that B2=100*B1 is not crazy high and it might be a bit lower than we could do.

I do think that the optimal values are such that stage1 time = stage2 time, so if you feel like optimizing and your stage2 time is way faster than stage1 you could raise B2 provided you give Prime95 enough RAM, otherwise it will just be slow if you do a big B2 with low RAM, it has to split stage2 in too many stages.

But otherwise just leave it at B2=100*B1, or lower it to 10*B1 if you want, it is your clock cycles and power bill to spend like you want :smile:

[QUOTE=ATH;500084]....I do think that the optimal values are such that stage1 time = stage2 time, so if you feel like optimizing and your stage2 time is way faster than stage1 you could raise B2 provided you give Prime95 enough RAM, otherwise it will just be slow if you do a big B2 with low RAM, it has to split stage2 in too many stages.

But otherwise just leave it at B2=100*B1, or lower it to 10*B1 if you want, it is your clock cycles and power bill to spend like you want :smile:[/QUOTE]

Actually, I used your formula from above. B2 = B1[SUP]1.4[/SUP] * 3.8. The time difference is very small. So, I will keep using it.

[I]Windows 10[/I] has a pretty good Task Manager. As I was testing, I would watch the RAM usage by [I]Prime95[/I]. I found that I could go up to 4,096 MB with no problems. 5,120 may even be possible, but I don't see the need. [I]Windows 10[/I] compresses its memory contents on-the-fly. For some strange reason, I set this using powers of 2. Imagine that.

Running all this does not seem to have a lot of affect on my power bill. My rate is 0.1286 USD per kWh. It stays in that area year round.

About [I]mprime[/I], I've never ran any flavor of [I]Linux[/I]. I've watched local friends run it. It sails over my head. Too many years of MS. :smile:

[U]Edit[/U]: Look at the examples below. Are the bounds too close to each other from one test to the next for the same exponent?

[CODE]ECM2=<ID>,1,2,<Exponent>,-1,10000 1000000,<Curves>,"<Known factors>"
ECM2=<ID>,1,2,<Exponent>,-1,11000 1100000,<Curves>,"<Known factors>"[/CODE]

ECM uses a random seed for its work, and each seed does work independently of other seeds. You can use the same bounds as many times as you like without repeating work. It's normal to complete a "level" of ECM testing without changing bounds (though some folks jump to higher bounds before a previous level completes; mersenne.org converts these curves to count work reasonably accurately).

So, unlike PM1 work, don't worry about using the same bounds multiple times.

[QUOTE=VBCurtis;500159]...It's normal to complete a "level" of ECM testing without changing bounds (though some folks jump to higher bounds before a previous level completes...[/QUOTE]

Could you define "level" in this context?

After doing some observation while [I]Prime95[/I] was running, I saw that the "at prime" value does not exceed B1 in stage 1 or B2 in stage 2. This would explain the variation I see in the bounds when looking at the recent data on [I]mersenne.org[/I]. This would sort of support the argument that some say wider bounds are better.

The formula that [B]ATH[/B] posted above goes well beyond B2 = B1 * 100. With a B1 of 10,000, the typical B2 would be 1,000,000. With his formula B2 becomes 1,512,807. Of course, this is not set in stone. He also indicates the time for Stage 1 and Stage 2 should be about the same. In order to match this, I would have to further increase B2 by 27%, more or less.

[QUOTE=storm5510;500183]After doing some observation while [I]Prime95[/I] was running, I saw that the "at prime" value does not exceed B1 in stage 1 or B2 in stage 2. This would explain the variation I see in the bounds when looking at the recent data on [I]mersenne.org[/I]. This would sort of support the argument that some say wider bounds are better.

The formula that [B]ATH[/B] posted above goes well beyond B2 = B1 * 100. With a B1 of 10,000, the typical B2 would be 1,000,000. With his formula B2 becomes 1,512,807. Of course, this is not set in stone. He also indicates the time for Stage 1 and Stage 2 should be about the same. In order to match this, I would have to further increase B2 by 27%, more or less.[/QUOTE]

What are you trying to do? What is wrong with just completing the assignment you were given?

[QUOTE=storm5510;500183]Could you define "level" in this context?
[/QUOTE]
See [url]https://www.mersenne.org/report_ecm/[/url]. Each column is a "level", a set of curves expected to find a factor of a specific size. It is customary to jump B1 to a higher level once the prescribed number of curves are complete at a lower level.

Citing ATH's B2 from GMP-ECM isn't very relevant for Prime95. They're two different programs using two different algorithms to do ECM. I will say that when I used P95 to do ECM, I used B2 = 150* B1, but I'm not sure it was faster at finding factors than the default B2 = 100* B1. I disagree that stage 2 time should be as long as stage 1 time; stage 2 taking anywhere from 40% to 70% of stage 1 time is perfectly normal for both GMP-ECM and Prime95.

If your goal is to maximize probability of finding a factor per unit of computation, you should not mess with the assignments as given. There are changes that might be a tiny bit better, say 10% more likely to find a factor per unit time, but there are lots of settings that will be quite a bit less efficient such as setting bounds suitable for a factor size much larger than you're likely to spend the time to run enough curves to find. If you're assigned curves with B1=50,000 and decide to use B1=500,000, your factors-found-per-curve will be much much better, but factors-found-per-time will be quite a bit worse (because you're running curves that take 10 times as long but not finding 10 times as many factors).

[QUOTE=VBCurtis;500190]See [url]https://www.mersenne.org/report_ecm/[/url]. Each column is a "level", a set of curves expected to find a factor of a specific size. It is customary to jump B1 to a higher level once the prescribed number of curves are complete at a lower level...[/QUOTE]

This report is somewhat hard for me to follow. The first column B1 is 50,000 and the second is 250,000. What about the B1's in between? I would take this as meaning there are no bounds left to run below 50,000. :confused2:

My HP is running assignments as given by the server. No changes. What I am doing with this Asus is experimentation. What I run is not assigned. I just comb through the existing records to find something with very little ECM work done.

There is no particular reason to run B1's in between. You can if you like, but bookkeeping is easier if folks run t25 curves (B1=50k) or t30 curves (B1=250k). There's nothing wrong with picking arbitrary B1 values, but there is little to gain either. They're called t25 and t30 because those B1 sizes are most efficient for finding factors of those respective sizes. After the t25 column is "done", it is more time-efficient to target larger factors even though it's not impossible that a 25 digit factor is still out there.
Larger-bound curves will still find factors of a smaller size, and there is little harm in choosing B1 one level higher than the current column. Or, for that matter, any B1 between the current level's B1 and the next-higher B1.
Running curves smaller than recommended is a waste of time. Running curves larger increases the chance per curve to find a larger factor, at the cost of decreasing the chance per day of finding a relatively smaller factor.
The site I linked converts curves at odd B1 to the current wavefront linearly; that is, if your candidate has curves listed on the 50k column, and you run a curve at 100k, it'll count as two curves at 50k. It also takes twice as long as one curve at 50k.

I found this a few nights ago when I was trying different things:

[QUOTE]M250259 has a factor: 7756917629147385999280835759 (ECM curve 87, B1=16000, B2=2921135)[/QUOTE]

I was running a 100 curve test. I was not sending any of my experiments to the server, and was deleting the results files. I forgot the .spl file. So all of it went in. I should have been paying more attention.

I looked at the assignments on my HP. B1 is either 250,000 or 1,000,000. This goes along with the link to the report pages. I cannot say that I fully understand it, but enough to see how it is working.

[QUOTE=storm5510;500206]This report is somewhat hard for me to follow. The first column B1 is 50,000 and the second is 250,000. What about the B1's in between? I would take this as meaning there are no bounds left to run below 50,000. :confused2:

My HP is running assignments as given by the server. No changes. What I am doing with this Asus is experimentation. What I run is not assigned. I just comb through the existing records to find something with very little ECM work done.[/QUOTE]

[url]https://www.mersenne.org/report_ecm/[/url]

Those "optimal" values was calculated >20 years ago. They are calculated so after ~280 curves at B1=50,000 there are "only" 1/e ~ 37 % risk/chance of missing a 25 digit factor and 63% chance of finding it, if there is one.

Then you go to B1=250,000 at the 30 digit level, but those curves will also find any missing 25 digit factor or even smaller factors. After ~640 curves there are again 63% chance of finding any 30 digit factor and now there are >99% chance of having found any 25 digit factor.

And so on at each digit level the calculated number of curves assures 63% chance of finding the factor at that level while assuring practically 100% chance of any factors at the earlier levels. Factors between the "levels" for example 28 digits and 32 digits will have difference odds of being found but will eventually be found at the next "level".

[QUOTE=ATH;500229][url]https://www.mersenne.org/report_ecm/[/url]

Those "optimal" values was calculated >20 years ago. They are calculated so after ~280 curves at B1=50,000 there are "only" 1/e ~ 37 % risk/chance of missing a 25 digit factor and 63% chance of finding it, if there is one.

Then you go to B1=250,000 at the 30 digit level, but those curves will also find any missing 25 digit factor or even smaller factors. After ~640 curves there are again 63% chance of finding any 30 digit factor and now there are >99% chance of having found any 25 digit factor.

And so on at each digit level the calculated number of curves assures 63% chance of finding the factor at that level while assuring practically 100% chance of any factors at the earlier levels. Factors between the "levels" for example 28 digits and 32 digits will have difference odds of being found but will eventually be found at the next "level".[/QUOTE]

[I]Prime95[/I] uses random numbers in the ECM process, as everyone knows Given that, I would guess that it would be nearly impossible to be 100% certain that every possible factor is found for any exponent. If a person were to keep increasing the bounds, perhaps a larger factor could be found.

I noticed something last night that I did not know. Someone had written that B1 was only used in Stage 1, Both B1 and B2 are used in Stage 2. Consider the sample below:

[CODE]ECM2=<ID>,1,2,<Exponent>,-1,250000,25000000,50,<Knowns factors>[/CODE]

I saw that Stage 1 will begin with a very low "at prime" value and works its way up to something just short of the B1 value. Stage 2 starts just above the B1 value and proceeds to something near, or at, the B2 value. Basically, it is a continuous flow of primes, only breaking to grab more RAM in order to finish. A lot of this made more sense to me when I realized how it was working. Last week, I ran into an instance of curve 1 repeating because I had not allocated enough memory for the test.

As for the probability percentages, I am not an advanced mathematician. I know enough to do what I need. My area of expertise is hardware. I believe I can say that after 30 years of experience. If that doesn't make sense, consider the fact that I am 63 years old.

[QUOTE=storm5510;500234][I]Prime95[/I] uses random numbers in the ECM process, as everyone knows Given that, I would guess that it would be nearly impossible to be 100% certain that every possible factor is found for any exponent. If a person were to keep increasing the bounds, perhaps a larger factor could be found.[/QUOTE]

Only way to be 100% sure is if you find a factor and the remaining co-factor is a PRP or a Prime.

But if you run all the curves for 25digit and 30digit level you can be "nearly 100%" sure there are no factor at or below 25 digits, and if you then also run the curves for the 35 digit level, you can be "nearly 100%" sure there are no factors at or below 30 digits and so on.

[QUOTE=ATH;500235]But if you run all the curves for 25digit and 30digit level you can be "nearly 100%" sure there are no factor at or below 25 digits[/QUOTE]

Right. I get about 99.9895% for GMP-ECM 7 at the default settings, using Alexander Kruppa's [url=https://www.mersenneforum.org/showthread.php?t=2000]script[/url].

[QUOTE=ATH;500235]if you then also run the curves for the 35 digit level, you can be "nearly 100%" sure there are no factors at or below 30 digits[/QUOTE]

Yep, about 99.967%. My ugly code for both:

[code]nr=1; \\ approximate as 1, not very important
1-(1-ecmprob (50000, 12746592, 5e24, nr, 2))^261*(1-ecmprob (250000, 128992510, 5e24, nr, -3))^513
1-(1-ecmprob (50000, 12746592, 5e29, nr, 2))^261*(1-ecmprob (250000, 128992510, 5e29, nr, -3))^513*(1-ecmprob (10^6, 1045563762, 5e29, nr, -6))^1071[/code]

Everyone here will think I am nutty when I say that I keep a record of everything I run, except TF. So far this month, on this machine, I have ran 1,103 ECM's. 26 tests found a factor. That is 2.35% All of these had B1's of either 250,000 or 1,000,000. i didn't check the numbers on the HP. I suspect it would trend the same way.

[U]Edit[/U]. Counting what the HP has done, drops the percentage to 1.7

[QUOTE=axn;500187]What are you trying to do? What is wrong with just completing the assignment you were given?[/QUOTE]

What [U]was[/U] I trying to do? [U]Learn something[/U]. I do not see a problem with that. :exclaim:

My question is: Is there any difference in the probability of finding a factor when performing ECM on a small Mersenne number vs. a larger one (assuming plenty of memory is available)?

[QUOTE=PhilF;501705]My question is: Is there any difference in the probability of finding a factor when performing ECM on a small Mersenne number vs. a larger one (assuming plenty of memory is available)?[/QUOTE]

The thing is, for small Mersenne numbers there has already been fairly deep ECM search done. It's easier to find factors for smaller Mersenne numbers, but many of the easy factors have already been found.

There are still new factors being found by ECM on a regular basis.

If you are interested in finding any new factors, including second and higher factors of exponents which already have at least one known factor, then it's probably a tossup whether you choose small or large Mersenne numbers.

If you're mostly interested in finding first factors of exponents without any known factors, then I think it is easier to find them for larger Mersenne numbers, simply because there's a lot of unexplored territory.

[QUOTE=PhilF;501705]My question is: Is there any difference in the probability of finding a factor when performing ECM on a small Mersenne number vs. a larger one (assuming plenty of memory is available)?[/QUOTE]

If you mean probability per curve run, given identical prior curves run on each number, there is no significant difference in probabilities by size of Mersenne input.

However, the probability of 1 ECM curve finding a factor for a number depends heavily on how much previous ECM has been run; if the ECM size you're considering has already been run thousands of times, the chances of the next one finding a factor are quite small compared to chances of the first ECM curve run on a number!

In terms of probability of finding a factor per day..... that's complicated. Smaller numbers have already been ECM'ed to small and medium bounds, so you'll need to use a pretty big ECM curve to find a factor; however, since the input is small, this curve might take a similar amount of time as smaller B1/B2 bounds on larger inputs. I think GP2 was commenting on this "factors per day" probability in his reply.

[QUOTE=VBCurtis;501772]If you mean probability per curve run, given identical prior curves run on each number, there is no significant difference in probabilities by size of Mersenne input.[/QUOTE]

That's really the answer I was looking for. I am just performing 1 curve per number and allowing the Primenet server to assign the work.

The numbers I'm being assigned are in the M12,000,000 and M19,000,000 range, with 4096MB of memory assigned (prime95 is actually using 3808MB in stage 2).

From what I can tell, all the numbers I'm getting have never had any curves run on them. So, based on your input, on numbers that have no prior curves run, the probability of any 1 curve finding a factor is not dependent on the length of the number being factored.

[QUOTE=VBCurtis;501772]However, the probability of 1 ECM curve finding a factor for a number depends heavily on how much previous ECM has been run; if the ECM size you're considering has already been run thousands of times, the chances of the next one finding a factor are quite small compared to chances of the first ECM curve run on a number[/QUOTE]

Incorrect.

Flip a fair coin a thousand times and it turns up heads each time. What is the chance it will turn up tails the next flip?

[QUOTE=chalsall;501775]Incorrect.

Flip a fair coin a thousand times and it turns up heads each time. What is the chance it will turn up tails the next flip?[/QUOTE]

I think we all know the next flip is not dependent on the previous flips. But I don't think that is an applicable analogy. Coins have just 2 sides, but the number of factors any given Mersenne number has is highly variable.

That is why I am running only 1 curve per candidate, and I assumed it is why the server assigns curves this way.

So if I hammer one number with 100 or more curves, and that number happens to have only a few very large, almost equal factors, the chances of finding them is almost zero. All those curves would be wasted.

However, if I run just one curve per number, some of them will be run on numbers with lots of factors, which decreases the chance of wasting curves on impossible candidates.

Of course I may be way off base here, because I admit the math is way above my head.

[QUOTE=lycorn;500079]It is indeed. I did some tests with GMP-ECM a while ago and, AFAIR, the useful limit was ~40K.[/QUOTE]

Not quite strictly true, here's one I found earlier

ECM found a factor in curve #25, stage #2
Sigma=3673943552503015, B1=1000000, B2=1000000000.
UID: nitro/haswell, [B]M85027[/B] has a factor: 113574028377227867558212550573836752813871 (ECM curve 25, B1=1000000, B2=1000000000)

[QUOTE=PhilF;501781]That is why I am running only 1 curve per candidate, and I assumed it is why the server assigns curves this way.[/QUOTE]

Similar thinking is why some people still play the lottery. Or, as some call it, a tax on those who are bad at the maths.... (no disrespect intended)

How much ram will it use?
 

I am referring now to gmp-ecm.

I'm currently working on M4007 with fairly high values for B1,B2

B1=32X10[SUP]11[/SUP]
B2=12x10[SUP]14[/SUP]

I have 32gb in this system and gmp-ecm will try to use all that it can, there is a bug either in gmp-ecm or windows memory management.

When it gets to 16gig (not a typo) and tries to allocate another 4 gig chunk it fails with out of memory - even though 8 gig is still free...so I cap it at 14 gb for stage 2

[QUOTE=chalsall;501784]Similar thinking is why some people still play the lottery. Or, as some call it, a tax on those who are bad at the maths.... (no disrespect intended)[/QUOTE]

Well, the least you could do is point out the flaw in my logic.

I was under the impression that the reason the curves are split up into "levels" is due to the very reason I spelled out. Once a sufficient number of curves have been run at a specific level of a specific number, that level is considered done and the next level started. That is because the chance of finding a factor goes down as each curve in a level is run.

Am I wrong?

[QUOTE=PhilF;501794]Am I wrong?[/QUOTE]

Sorry. I was just being a bit flippant.

You are correct. The more searching done in a constrained space decreases the likelihood of success for each subsequent search attempt.

[QUOTE=chalsall;501795]The more searching done in a constrained space decreases the likelihood of success for each subsequent search attempt.[/QUOTE]

All of this is based on using random numbers. One could never be certain that [U]all[/U] of the existing factors could be found at any level. I suppose the word "done" could be applied if many thousands of CPU's did many thousands of curves and found nothing new. Still, the possibility remains.

[QUOTE=storm5510;501810]Still, the possibility remains.[/QUOTE]

Of course. None zero probability applies here. Many nines, but not zero....

[QUOTE=PhilF;501774]The numbers I'm being assigned are in the M12,000,000 and M19,000,000 range, with 4096MB of memory assigned (prime95 is actually using 3808MB in stage 2).

From what I can tell, all the numbers I'm getting have never had any curves run on them. So, based on your input, on numbers that have no prior curves run, the probability of any 1 curve finding a factor is not dependent on the length of the number being factored.[/QUOTE]

I briefly let Primenet assign me exponents for ECM in the 17M range which had no known factors. It assigned one ECM curve per exponent, with B1=50000, B2=5000000 (i.e., t=25 depth).

It ran for maybe 11 days on two cores and found 2 factors out of 260 attempts.

On the other hand, if I was trying to do the same thing in a smaller range like, say, under 100k — namely, finding first factors of exponents with no known factors — then it's really extremely unlikely that I'd find even one factor with the equivalent time and CPU effort, because it's been searched more extensively already.

On the other hand, if you look for additional factors of exponents in the sub-100k range that do already have known factors, you'd have better luck, but you'd still find factors at a slower rate than in the 17M range.

[QUOTE=Gordon;501783]Not quite strictly true, here's one I found earlier

ECM found a factor in curve #25, stage #2
Sigma=3673943552503015, B1=1000000, B2=1000000000.
UID: nitro/haswell, [B]M85027[/B] has a factor: 113574028377227867558212550573836752813871 (ECM curve 25, B1=1000000, B2=1000000000)[/QUOTE]

Gordon-
You quoted a post about GMP-ECM, but wasn't your demonstrated factor found with Prime95? If not, what version of GMP-ECM uses sigmas larger than 32 bits and has a user ID?

[QUOTE=chalsall;501775]Incorrect.

Flip a fair coin a thousand times and it turns up heads each time. What is the chance it will turn up tails the next flip?[/QUOTE]

Oh wise one, please illuminate the flaw in my thinking about ECM and Bayesian probability modification. What does tossing a coin have to do with looking for a factor of a certain size?

To try to use your terrible analogy- if I flip 1000 ECM "coins" and get heads every time, it's much more likely that tails doesn't exist for this size of curve than it was before I hadn't run any curves. The probability my next curve finds a factor is rather lower because I have 1000 curves' outcomes that didn't find a factor, when compared to running my first curve.

[QUOTE=GP2;501814]I briefly let Primenet assign me exponents for ECM in the 17M range which had no known factors. It assigned one ECM curve per exponent, with B1=50000, B2=5000000 (i.e., t=25 depth).

It ran for maybe 11 days on two cores and found 2 factors out of 260 attempts.

On the other hand, if I was trying to do the same thing in a smaller range like, say, under 100k — namely, finding first factors of exponents with no known factors — then it's really extremely unlikely that I'd find even one factor with the equivalent time and CPU effort, because it's been searched more extensively already.

On the other hand, if you look for additional factors of exponents in the sub-100k range that do already have known factors, you'd have better luck, but you'd still find factors at a slower rate than in the 17M range.[/QUOTE]

All of that makes perfect sense to me. Thank you.

[QUOTE=chalsall;501775]Incorrect.

Flip a fair coin a thousand times and it turns up heads each time. What is the chance it will turn up tails the next flip?[/QUOTE]

Throw a thousand darts blindfolded, and fail to hit anything. What is the chance that there is actually a dartboard within ten feet in front of you that you will hit on the next throw?

Note: the dartboard might be a hundred feet away, and you might need a million throws and a slingshot. Or it might be a hundred miles away, and you need a trillion projectiles and a railgun and a prayer.

[QUOTE=Gordon;501785]I am referring now to gmp-ecm.

I'm currently working on M4007 with fairly high values for B1,B2

B1=32X10[SUP]11[/SUP]
B2=12x10[SUP]14[/SUP]

I have 32gb in this system and gmp-ecm will try to use all that it can, there is a bug either in gmp-ecm or windows memory management.

When it gets to 16gig (not a typo) and tries to allocate another 4 gig chunk it fails with out of memory - even though 8 gig is still free...so I cap it at 14 gb for stage 2[/QUOTE]

It needs a lot of RAM with those high values maybe terabytes of RAM, so unless you use -maxmem 14000 or the -k option it will crash. If you start a stage 2 with the -v parameter and without -maxmem or -k it should estimate the RAM for stage 2.

[QUOTE=ATH;501843]It needs a lot of RAM with those high values maybe terabytes of RAM, so unless you use -maxmem 14000 or the -k option it will crash. If you start a stage 2 with the -v parameter and without -maxmem or -k it should estimate the RAM for stage 2.[/QUOTE]

If he's using GMP-ECM for stage 2, then I think it responds non-linearly to memory, no? For a given B2 value it wants a certain amount of memory, and if you reduce that memory by a factor of N (by using the -k option to use multiple blocks), it will take considerably longer than N times as much execution time.

So if you're giving 14 GB to a stage 2 that really wants terabytes, you're giving it at least a hundred times less memory than it wants, and it will take maybe many thousands of times longer to complete.

Seems like a highly inefficient use of the machine. It could be tackling right-sized tasks instead.

PS,
For what it's worth, x1.32xlarge instances on AWS have 64 hyperthreaded cores and nearly 2 TB of memory (1952 GiB to be exact), and they cost $4/hour at current spot prices in us-east-2. If you need a mere 768 GiB of memory, an r5.24xlarge has that for $1/hour at spot prices (and 48 hyperthreaded cores). Various smaller options all the way down to a one-core r5.large with 16 GiB for 2 cents an hour.

There are even AWS cloud machines with 12 TiB of memory and 224 cores, but those aren't available for spot or even on-demand, just for dedicated corporate in-memory databases. Give it a few years, though, and that kind of power will probably trickle down to general availability.

So if there's some specific number-crunching task that really responds well to enormous amounts of memory and can complete in a reasonable amount of time and you can splurge or pool funding, then renting is an option.

[QUOTE=VBCurtis;501823]Gordon-
You quoted a post about GMP-ECM, but wasn't your demonstrated factor found with Prime95? If not, what version of GMP-ECM uses sigmas larger than 32 bits and has a user ID?[/QUOTE]

that was the submission file to mersenne.org

This is the output file...I chopped off the last 28k characters.

***

GMP-ECM 7.0-dev [configured with MPIR 2.7.0, --enable-asm-redc] [ECM]
Save file line has no equal sign after: [Tue Oct 13 22:
Resuming ECM residue saved with Prime95
Input number is 4758184975...7139017727 (25596 digits)
Using B1=1000000, B2=1000000000, polynomial Dickson(6), sigma=0:3673943552503015
Step 1 took 3847484ms
Step 2 took 1217010ms
********** Factor found in step 2: 113574028377227867558212550573836752813871
Found prime factor of 42 digits: 113574028377227867558212550573836752813871
Proving primality of 25555 digit cofactor may take a while...

Composite cofactor

[QUOTE=ATH;501843]It needs a lot of RAM with those high values maybe terabytes of RAM, so unless you use -maxmem 14000 or the -k option it will crash. If you start a stage 2 with the -v parameter and without -maxmem or -k it should estimate the RAM for stage 2.[/QUOTE]

I do use -maxmem 14000

[QUOTE=GP2;501860]If he's using GMP-ECM for stage 2, then I think it responds non-linearly to memory, no? For a given B2 value it wants a certain amount of memory, and if you reduce that memory by a factor of N (by using the -k option to use multiple blocks), it will take considerably longer than N times as much execution time.

So if you're giving 14 GB to a stage 2 that really wants terabytes, you're giving it at least a hundred times less memory than it wants, and it will take maybe many thousands of times longer to complete.

Seems like a highly inefficient use of the machine. It could be tackling right-sized tasks instead.

PS,
For what it's worth, x1.32xlarge instances on AWS have 64 hyperthreaded cores and nearly 2 TB of memory (1952 GiB to be exact), and they cost $4/hour at current spot prices in us-east-2. If you need a mere 768 GiB of memory, an r5.24xlarge has that for $1/hour at spot prices (and 48 hyperthreaded cores). Various smaller options all the way down to a one-core r5.large with 16 GiB for 2 cents an hour.

There are even AWS cloud machines with 12 TiB of memory and 224 cores, but those aren't available for spot or even on-demand, just for dedicated corporate in-memory databases. Give it a few years, though, and that kind of power will probably trickle down to general availability.

So if there's some specific number-crunching task that really responds well to enormous amounts of memory and can complete in a reasonable amount of time and you can splurge or pool funding, then renting is an option.[/QUOTE]

I don't know about thousands of times, it completes a run in about 4 days of wall time.

[QUOTE=Gordon;501872]
Step 1 took 3847484ms
Step 2 took 1217010ms
[/QUOTE]
Interesting.
1) Why is Step 1 running again?
2) How much time would P95 have taken on this B2?

[QUOTE=axn;501875]Interesting.
1) Why is Step 1 running again?
2) How much time would P95 have taken on this B2?[/QUOTE]

Perhaps GMP-ECM's implementation of stage 2 uses a step 1 and a step 2. So it's not redoing stage 1, at least I hope not. The README file does refer to "stage 1" and "stage 2", so I don't think "step 1" is a synonym for "stage 1", unless they're very loose with their terminology.

I'm doing some ECM of small Wagstaff numbers up to t=40, and I get the same thing when using GMP-ECM to do stage 2 where stage 1 was done by mprime.

GMP-ECM is run with the [c]-resume[/c] option specifying the output written by mprime to results.txt, where mprime used B1=B2 and the [c]GmpEcmHook=1[/c] setting in prime.txt. If it really is redoing stage 1, I hope someone will let me know how to avoid it...

Here's some sample verbose output:

[CODE]
GMP-ECM 7.0.4 [configured with GMP 6.0.0, --enable-asm-redc] [ECM]
Running on ip-***-***-***-***.us-east-2.compute.internal
[B]Resuming ECM residue saved with Prime95[/B]
Input number is 0x4D591058893F231FBE69EBEF89B145E1B39711E4E2D33DA1F18BD2E8EA9BDD232321C5FC7FDA0190625DB92793F0433C69FB1B9D55E06CB2712F78F11CB2651238578856D7C38207B0B802860CD4027485E15F72053DF77AA0A6A3C3FF21048AAAD0EB867C49CAD28F57AAB9EA017C9520C4B5241 (281 digits)
Using special division for factor of 2^1063+1
Using B1=3000000, B2=5706890290, polynomial Dickson(6), sigma=0:4566259830273646
dF=16384, k=2, d=158340, d2=11, i0=8
Expected number of curves to find a factor of n digits:
35 40 45 50 55 60 65 70 75 80
324 2351 20272 201449 2247436 2.8e+07 3.9e+08 6e+09 1.1e+11 7.4e+15
[B]Step 1 took 11982ms[/B]
Using 33 small primes for NTT
Estimated memory usage: 88.06MB
Initializing tables of differences for F took 11ms
Computing roots of F took 392ms
Building F from its roots took 620ms
Computing 1/F took 324ms
Initializing table of differences for G took 18ms
Computing roots of G took 367ms
Building G from its roots took 648ms
Computing roots of G took 368ms
Building G from its roots took 647ms
Computing G * H took 175ms
Reducing G * H mod F took 169ms
Computing polyeval(F,G) took 1221ms
Computing product of all F(g_i) took 10ms
[B]Step 2 took 5025ms[/B]
[/CODE]

[QUOTE=GP2;501879]If it really is redoing stage 1, I hope someone will let me know how to avoid it...[/QUOTE]

I am getting ready to do some Fermat ECM factoring work, and I think I'll wait until you get a firm answer on that before I start.

I'm surprised the need to hook the two programs together in order to get the most efficiency still exists. Is there a reason the faster GMP-ECM stage 2 code has not been implemented in Prime95/mprime?

Hmm... so much for my theories about "step" vs. "stage".

I just tried running a curve where both stage 1 and stage 2 were done with GMP-ECM, and the whole thing actually ran faster than letting GMP-ECM resume the output of mprime's stage 1!

At least for this particular exponent. And that doesn't even include the time that mprime itself spent doing stage 1 (needlessly??).

The value of B2=5706890290 was automatically selected in both cases, and the 281-digit "Input number is" values are equal in both cases (specified as a hex number in the first example since that's how mprime outputs it, and specified as (2^1063+1)/3 divided by the two known factors in the second example below. So the only thing different in the two situations is a different sigma.

The command was:

[CODE]
echo "(2^1063+1)/3/114584129081/26210488518118323164267329859" | ecm -v 3000000
[/CODE]

and the output was:

[CODE]
GMP-ECM 7.0.4 [configured with GMP 6.0.0, --enable-asm-redc] [ECM]
Running on ip-***-***-***-***.us-east-2.compute.internal
Input number is (2^1063+1)/3/114584129081/26210488518118323164267329859 (281 digits)
Using special division for factor of 2^1063+1
Using B1=3000000, B2=5706890290, polynomial Dickson(6), sigma=0:12915475272312803168
dF=16384, k=2, d=158340, d2=11, i0=8
Expected number of curves to find a factor of n digits:
35 40 45 50 55 60 65 70 75 80
324 2351 20272 201449 2247436 2.8e+07 3.9e+08 6e+09 1.1e+11 7.4e+15
[B]Step 1 took 10870ms[/B]
Using 33 small primes for NTT
Estimated memory usage: 88.06MB
Initializing tables of differences for F took 10ms
Computing roots of F took 357ms
Building F from its roots took 570ms
Computing 1/F took 302ms
Initializing table of differences for G took 16ms
Computing roots of G took 335ms
Building G from its roots took 592ms
Computing roots of G took 336ms
Building G from its roots took 580ms
Computing G * H took 154ms
Reducing G * H mod F took 164ms
Computing polyeval(F,G) took 1090ms
Computing product of all F(g_i) took 9ms
[B]Step 2 took 4570ms[/B]
Expected time to find a factor of n digits:
35 40 45 50 55 60 65 70 75 80
1.39h 10.08h 3.62d 36.00d 1.10y 13.81y 192.57y 2937y 54485y 4e+09y
Peak memory usage: 130MB
[/CODE]

Do you have mprime set to limit the number of cores it can use? I'm also wondering if your results would be very different if the input number was millions of digits.

[QUOTE=PhilF;501894]Do you have mprime set to limit the number of cores it can use? I'm also wondering if your results would be very different if the input number was millions of digits.[/QUOTE]

These are running on one-core virtual machines, so it's not an issue.

Also it shouldn't matter to gmp-ecm how many cores mprime used in stage 1. The input to ecm is just a number, it shouldn't matter how that number was arrived at.

Empirically, it's been reported that GMP-ECM works well only for small Mersenne exponents, under about 40k. So I don't think the millions-of-digits case would occur in practice.

[QUOTE=PhilF;501894]Do you have mprime set to limit the number of cores it can use? I'm also wondering if your results would be very different if the input number was millions of digits.[/QUOTE]

Yes, the outcome is quite different for large-large inputs!

GMP-ECM and mprime use very different methods for ECM computation. mprime (prime95) scales very well by input size, while GMP-ECM uses a stage 2 that's very very fast for small input sizes.

Below about 400(?) digits, GMP-ECM is faster in both stages. Above about 12000 digits (though Gordon above disagrees with this number!), mprime is faster for both stages. In between, the fastest method is to use mprime's fast stage1 code and GMP-ECM's fast-for-big-B2 stage 2. The set of users that care about inputs below 12000 digits is small, likely why the GMP-ECM stage 2 has never been incorporated into mprime.

How to avoid needlessly redoing stage 1 in GMP-ECM!!!!
 

I think I figured it out.

As mentioned before, if you want to do stage 1 with mprime/Prime95 and stage 2 wth GMP-ECM, first you need to run mprime/Prime95 with the line [c]GmpEcmHook=1[/c] in your prime.txt file, and you need to set B1 and B2 to the same value (say 3000000) in your [c]ECM2=[/c] lines in your worktodo.txt file.

Then mprime/Prime95 will output a bunch of lines starting with [c]N=[/c] into your results.txt file, instead of its normal output. If you specified 1000 ECM curves, then there will be 1000 lines with [c]N=[/c].

Note, if B1 and B2 aren't the same value in the worktodo.txt line, then [c]GmpEcmHook=1[/c] will be ignored and mprime/Prime95 will just do both stage 1 and stage 2 all by itself, and will output only the typical single line of the form "[c]Mxxxx completed xxx ECM curves, B1=nnnnnnn, B2=nnnnnnnnn[/c]"

Then you feed that results.txt file to GMP-ECM. I don't know if you need to filter out all the lines that don't start with [c]N=[/c], probably GMP-ECM just ignores them. You do that with the command:

(assuming you used B1=3000000, change to whatever the actual value is)

[CODE]
ecm -resume results.txt 3000000-3000000 > my_output_file.txt
[/CODE]

Then when it finishes, you search your my_output_file.txt (or whatever you called it) for lines that begin with:

[CODE]
********** Factor found in step
[/CODE]

[B]But the crucial thing is to specify the argument as [c]3000000-3000000[/c] (meaning, do stage 1 for B1 from the range 3 million to 3 million, i.e. don't do it at all, but you need to specify the 3 million twice anyway so that B2 gets automatically sized appropriately).[/B] Of course, you can specify your own value for B2 if you don't want GMP-ECM's default calculated value. And change the "3 million" to whatever actual value of B1 you used in stage 1.

If you do that, then you get "Step 1 took 0 ms".

But if you just specify the argument as [c]3000000[/c], [URL="https://mersenneforum.org/showthread.php?p=500406"]as I was doing these past few weeks for ECM on small Wagstaff numbers[/URL], then it does stage 1 for B1 from 0 to 3 million, i.e., redoes the whole thing.

I hadn't done GMP-ECM for a long time, so I forgot about this nuance, and it's not actually very well documented, if at all.

[B]TL;DR:[/B] when running GMP-ECM with [c]-resume[/c] and you don't want it to redo stage 1, [B]specify the B1 value as a range from itself to itself[/B], with a hyphen in between, rather than just specifying it as a simple number, which will be interpreted as a range from 0 to that number.

[QUOTE=axn;501875]Interesting.
1) Why is Step 1 running again?
2) How much time would P95 have taken on this B2?[/QUOTE]

In answer to point 1 - that's my fault, it was early days of using gmp-ecm and I didn't know then that if I had stated the B1 value as

1000000-1000000

then it would have skipped redoing the stage 1. Learnt from that mistake early on :-)

as to point 2 I've got no idea.

[QUOTE=GP2;501879]Perhaps GMP-ECM's implementation of stage 2 uses a step 1 and a step 2. So it's not redoing stage 1, at least I hope not. The README file does refer to "stage 1" and "stage 2", so I don't think "step 1" is a synonym for "stage 1", unless they're very loose with their terminology.

I'm doing some ECM of small Wagstaff numbers up to t=40, and I get the same thing when using GMP-ECM to do stage 2 where stage 1 was done by mprime.

GMP-ECM is run with the [c]-resume[/c] option specifying the output written by mprime to results.txt, where mprime used B1=B2 and the [c]GmpEcmHook=1[/c] setting in prime.txt. If it really is redoing stage 1, I hope someone will let me know how to avoid it...

[snip]

[/QUOTE]

ecm -maxmem 14000 -resume results.txt 1000000-1000000 100000000 > newresults.txt

[QUOTE=Gordon;501913]In answer to point 1 - that's my fault, it was early days of using gmp-ecm and I didn't know then that if I had stated the B1 value as

1000000-1000000

then it would have skipped redoing the stage 1. Learnt from that mistake early on :-)[/quote]
Cool :smile:

[QUOTE=Gordon;501913]as to point 2 I've got no idea.[/QUOTE]
The reason I ask is that I suspect P95 will be (much) faster at that exponent size and that B2 level (smaller exponent and/or larger B2 will tilt it in favor of GMP-ECM). If you ever run similar ECMs in the future, it'll be definitely worthwhile to benchmark both options before you select which way to go.

[QUOTE=GP2;501860]If he's using GMP-ECM for stage 2, then I think it responds non-linearly to memory, no? For a given B2 value it wants a certain amount of memory, and if you reduce that memory by a factor of N (by using the -k option to use multiple blocks), it will take considerably longer than N times as much execution time.

So if you're giving 14 GB to a stage 2 that really wants terabytes, you're giving it at least a hundred times less memory than it wants, and it will take maybe many thousands of times longer to complete.[/QUOTE]

It was "only" ~ 308 GB not terabytes, but still a lot compared to 14 GB:

[CODE]GMP-ECM 7.0.5-dev [configured with GMP 6.1.2, --enable-asm-redc] [ECM]
Resuming ECM residue saved by ATH@5960X with GMP-ECM 7.0.5-dev on Fri Dec 07 09:21:50 2018
Input number is 2^4007-1 (1207 digits)
Using special division for factor of 2^4007-1
Using B1=160632413-160000000, B2=3200000000000-1200000000000000, polynomial Dickson(30), sigma=0:12427217811893723496
dF=10264320, k=1, d=118107990, d2=17, i0=27077
Can't compute success probabilities for B1 <> B2min
Step 1 took 0ms
[B]Estimated memory usage: 308.19GB[/B][/CODE]

I only took B1 to 1.6e8 but that should not matter since I chose stage2 32e11-12e14 as described in the post earlier.

Since the discussion has gone to [B]GMP-ECM[/B], I have a question:

[COLOR=Blue]GMP-ECM 7.0.5-dev [configured with GMP 6.1.2, --enable-asm-redc] [ECM][/COLOR]

[COLOR=Blue][COLOR=Black]I found a Windows binary of the same version as in the most recent post by [B]ATH[/B], assuming he is referring to Linux. [/COLOR][/COLOR][COLOR=Blue][COLOR=Black]After reading the doc file, and getting it running, I noticed that it does [U]not[/U] produce a results file. However, is is [U]extremely[/U] fast and can use [U]very large[/U] B1 and B2 values.[/COLOR][/COLOR]

[COLOR=Blue][COLOR=Black][U]Question[/U]: Is it just something to toy with, or does it serve a purpose more dedicated to this project? Obviously, one must be able to submit their results.
[/COLOR][/COLOR]

[QUOTE=GP2;501906]As mentioned before, if you want to do stage 1 with mprime/Prime95 and stage 2 wth GMP-ECM, first you need to run mprime/Prime95 with the line [c]GmpEcmHook=1[/c] in your prime.txt file, and you need to set B1 and B2 to the same value (say 3000000) in your [c]ECM2=[/c] lines in your worktodo.txt file.

Then mprime/Prime95 will output a bunch of lines starting with [c]N=[/c] into your results.txt file, instead of its normal output. If you specified 1000 ECM curves, then there will be 1000 lines with [c]N=[/c].

Note, if B1 and B2 aren't the same value in the worktodo.txt line, then [c]GmpEcmHook=1[/c] will be ignored and mprime/Prime95 will just do both stage 1 and stage 2 all by itself, and will output only the typical single line of the form "[c]Mxxxx completed xxx ECM curves, B1=nnnnnnn, B2=nnnnnnnnn[/c]"[/QUOTE]

I need to clarify the last paragraph.

As I mentioned before, if GmpEcmHook is in effect, then your mprime/Prime95 results.txt file will be full of lines that start with [c]N=[/c]

However, the results.txt file will still contain the usual "[c]Mxxxx completed xxx ECM curves, B1=nnnnnnn, B2=nnnnnnnnn[/c]" lines, and if a factor is found in stage 1, then it will display the usual:

[CODE]
ECM found a factor in curve #nnn, stage #1
Sigma=xxxxxxxxxxxxxxxx, B1=3000000, B2=3000000.
UID: you/your_machine, 2^nnnn+1 has a factor: nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn (ECM curve nnn, B1=3000000, B2=3000000)
[/CODE]

The problem is, lines like this will be buried among hundreds or even thousands of lines beginning with [c]N=[/c], depending on how many ECM curves you specified in your worktodo.txt line.

[B]In other words, it's very easy to miss the fact that mprime discovered factors in stage 1![/B]

On Linux you can look for those factors with a command like [c]grep -E -v '^(N=|\[)' results.txt[/c] and in Windows PowerShell you can use [c]sls -notmatch '^(N=|\[)' results.txt[/c]

If the output is too long and scrolls off the screen, you can append [c] | less[/c] to the Linux command, and [c] | Out-Host –Paging[/c] to the PowerShell command, and use the space bar to scroll one screenful at a time.

[QUOTE=storm5510;501966]Since the discussion has gone to [B]GMP-ECM[/B], I have a question:

[COLOR=Blue]GMP-ECM 7.0.5-dev [configured with GMP 6.1.2, --enable-asm-redc] [ECM][/COLOR]

[COLOR=Blue][COLOR=Black]I found a Windows binary of the same version as in the most recent post by [B]ATH[/B], assuming he is referring to Linux. [/COLOR][/COLOR][COLOR=Blue][COLOR=Black]After reading the doc file, and getting it running, I noticed that it does [U]not[/U] produce a results file. However, is is [U]extremely[/U] fast and can use [U]very large[/U] B1 and B2 values.[/COLOR][/COLOR]

[COLOR=Blue][COLOR=Black][U]Question[/U]: Is it just something to toy with, or does it serve a purpose more dedicated to this project? Obviously, one must be able to submit their results.
[/COLOR][/COLOR][/QUOTE]

To make a results file, redirect the screen output to file by ending the command-line with something like ">ecmresults1.txt".

Your commentary that it's extremely fast relies upon choosing a small input. What input number did you test it on? As discussed elsewhere in this thread, GMP-ECM is very fast for small inputs (say, below 2^1500), and rathetr slow for large inputs (over 2^40000).

[QUOTE=VBCurtis;501985]To make a results file, redirect the screen output to file by ending the command-line with something like ">ecmresults1.txt".

Your commentary that it's extremely fast relies upon choosing a small input. What input number did you test it on? As discussed elsewhere in this thread, GMP-ECM is very fast for small inputs (say, below 2^1500), and rather slow for large inputs (over 2^40000).[/QUOTE]

I have the below in a batch file so I do not have to type it all every time:

[CODE]ecm -v %1 %2 < work.txt[/CODE] What input number? There have been several. I didn't exceed the current PrimeNet ceiling value, (19,999,999).

There are two binaries in the archive I downloaded, [I]ecm.exe[/I] and [I]ecmfactor.exe[/I]. The latter will not run. A Windows 10 issue, I imagine. I found these at a link [B]ATH[/B] had placed in another thread. He has four there, based on different CPU types.

Thank you for replying. :smile: