[M]M32159551[/M] has a 77.841-bit (24-digit) factor: [URL="https://www.mersenne.ca/M32159551"]270719245854611997909647[/URL] (P-1,B1=1100000,B2=61600000)
found it with 30.4 b3
about 8169 M of ram



Also maybe move the discussion about 30.4b3 in its own thread?

Initial observations
 

All of my current work is N/A.
As soon as I started Prime95 it fetched 36 ECM assignments (that is my default).
However there were only 18 new ECM assignments in Worker #1; none anywhere else.
There were 36 on my Assignments page.

It no longer reports number of relative factors processed in Stage 2; only percent complete.

In my case it chose a B2=48*B1 =48,000,000. (I had 20*B1)
I have 2 Workers with 2 CPUs each.
I have 4000MB RAM allocated.

With prior B1/B2 it was taking about 9 hours per assignment.
Based on preliminary results it appears it will take:
3 hours for Stage 1
9 hours for Stage 2.

More to follow

Part 2: 2nd worker finished Stage 1 and of course split the RAM with Worker 1.
However this assignments was given a B2=43*B1

The exponents are very close 41,778,xxx and 41,780,xxx.
Both would have had a prior P-1 with B1=B2=685,000 (or very close)

Part 3:
So far it seems that:
If Worker x is still on Stage 1 when Worker y finishes Stage 1 it gets a B2=48xB1 for Stage 2.
If Worker x then is ready for Stage 2 while Worker y is still on Stage 2 then Worker x gets B2=41 or 43xB1.
Is that because it detects less RAM available (ie. the workers now have to share RAM)?

Format suggestion
 

Any chance you could display this on 2 lines; I believe on most of our windows it will scroll into the Right Abyss.


[CODE]Dec 29 18:17] With trial factoring done to 2^74, optimal B2 is 41*B1 = 32800000. If no prior P-1, chance of a new factor is 4.57%[/CODE]

Like this instead...

[CODE]Dec 29 18:17] With trial factoring done to 2^74, optimal B2 is 41*B1 = 32800000.
Dec 29 18:17] If no prior P-1, chance of a new factor is 4.57%[/CODE]

[QUOTE=petrw1;567696]Any chance you could display this on 2 lines;[/QUOTE]

Will do

[QUOTE=petrw1;567595]As soon as I started Prime95 it fetched 36 ECM assignments (that is my default). However there were only 18 new ECM assignments in Worker #1; none anywhere else.[/quote]

Weird. That code hasn't changed.

[quote]It no longer reports number of relative factors processed in Stage 2; only percent complete.[/quote]

Relative primes are no longer processed in passes. They are all done at once as prime95 steps from B1 to B2 in steps of size D.

[quote]
If Worker x is still on Stage 1 when Worker y finishes Stage 1 it gets a B2=48xB1 for Stage 2.
If Worker x then is ready for Stage 2 while Worker y is still on Stage 2 then Worker x gets B2=41 or 43xB1.
Is that because it detects less RAM available (ie. the workers now have to share RAM)?[/QUOTE]

Your guess is correct.

I still prefer that Gerbicz error checks do not occur every 1 million iterations polluting the worker window. Perhaps it should scale so the larger the exponent the less frequently it runs like every 10 million iterations or no output for no error.

Also - up to date ETA in the worker title bar windows would be nice.

[QUOTE=rainchill;567741]I still prefer that Gerbicz error checks do not occur every 1 million iterations polluting the worker window. Perhaps it should scale so the larger the exponent the less frequently it runs like every 10 million iterations or no output for no error.[/QUOTE]

You can change it in prime.txt, from undoc.txt:

[QUOTE]When doing highly-reliable error checking, the interval between compares can be
controlled with these two settings in prime.txt:
[B] PRPGerbiczCompareInterval=n (default is 1000000)
PRPDoublecheckCompareInterval=n (default is 100000)[/B]
Reducing the interval will reduce how far the program "rolls back" when an error
is detected. It will also increase the overhead associated with error-checking.
NOTE: For technical reasons, PRPGerbiczCompareInterval is rounded to the nearest perfect square.
ALSO NOTE: The program automatically adjusts the Gerbicz interval downward when an error is
detected. This will reduce the amount of time "lost" rolling back to the last verified good
iteration after an error is detected. Over time, the Gerbicz interval will be adjusted back
upward after many successful compares.[/QUOTE]

Kaboom!!!!
 

Ok maybe that's a little dramatic but I did crash 30.4 doing P-1; albeit an unlikely scenario.

I choose 6 exponents that I had previously found a factor via 29.8 P-1 to see if 30.4 would find them as well.

I hand picked B1 just slightly higher than necessary.
If B2 was less than 40xB1, I left it be determined; if B2 needed to be MUCH higher I set it; leaving off the last parm (Factor Bits).

Case 1: 41,711,611 (I failed Grade 3 math)
[url]https://www.mersenne.ca/exponent/41711611[/url]
Current required B1/B2 34171 / 4514869.(B2=133xB1)
However, I erroneously allowed 30.4 to choose B2.
When Stage 1 finished and B2 was chosen I realized it was too small and stopped it very early in Stage 2.
I edited worktodo and changed B2=4600000 and removed Factor Bits.

As soon as it seemed Stage 2 should be done based on progress reports this happened and then Prime95 crashed and went away. (See attachment)
I had to use my camera as I couldn't get a Copy Window to work at crash time.

I started it again and it restarted at the 14% mark and crashed the same way.

So I renamed the P1SaveFile to make it restart.
This time it finished but Stage 2 was much slower.

I surmised this indicates the first time it did NOT use my changed B2...but realized at the end that something was amiss and appeared to start Stage 2 again (Stage 2 init complete message) and crashed.

Successful run:

[CODE]
[Dec 30 16:11] Worker starting
[Dec 30 16:11] Setting affinity to run worker on CPU core #1
[Dec 30 16:11]
[Dec 30 16:11] P-1 on M41711611 with B1=35000, B2=4600000
[Dec 30 16:11] Using AVX FFT length 2240K, Pass1=448, Pass2=5K, clm=4, 2 threads
[Dec 30 16:11] Setting affinity to run helper thread 1 on CPU core #2
[Dec 30 16:15] M41711611 stage 1 is 41.446% complete. Time: 223461.917 ms.
[Dec 30 16:18] M41711611 stage 1 is 82.976% complete. Time: 197321.365 ms.
[Dec 30 16:20] M41711611 stage 1 complete. 101268 transforms. Time: 504207.464 ms.
[Dec 30 16:20] Stage 1 GCD complete. Time: 13102.162 ms.
[Dec 30 16:20] Available memory is 2006MB.
[Dec 30 16:20] D: 210, relative primes: 108, stage 2 primes: 318709, pair%=76.20
[Dec 30 16:20] Using 1994MB of memory.
[Dec 30 16:20] Stage 2 init complete. 1280 transforms. Time: 9618.672 ms.
[Dec 30 16:25] M41711611 stage 2 is 8.641% complete. Time: 290833.989 ms.
[Dec 30 16:30] M41711611 stage 2 is 17.402% complete. Time: 289398.635 ms.
[Dec 30 16:35] M41711611 stage 2 is 26.255% complete. Time: 290844.452 ms.
[Dec 30 16:39] M41711611 stage 2 is 35.219% complete. Time: 287364.578 ms.
[Dec 30 16:44] M41711611 stage 2 is 44.213% complete. Time: 290137.708 ms.
[Dec 30 16:49] M41711611 stage 2 is 53.246% complete. Time: 292558.611 ms.
[Dec 30 16:54] M41711611 stage 2 is 62.209% complete. Time: 272009.590 ms.
[Dec 30 16:59] M41711611 stage 2 is 71.055% complete. Time: 291066.751 ms.
[Dec 30 17:03] M41711611 stage 2 is 79.909% complete. Time: 292442.674 ms.
[Dec 30 17:08] M41711611 stage 2 is 88.699% complete. Time: 293089.292 ms.
[Dec 30 17:13] M41711611 stage 2 is 97.439% complete. Time: 290943.709 ms.
[Dec 30 17:15] M41711611 stage 2 complete. 474230 transforms. Time: 3265839.830 ms.
[Dec 30 17:15] Stage 2 GCD complete. Time: 13100.147 ms.
[Dec 30 17:15] P-1 found a factor in stage #2, B1=35000, B2=4600000.
[Dec 30 17:15] M41711611 has a factor: 244626322402475529262488198689 (P-1, B1=35000, B2=4600000)
[Dec 30 17:15]
[Dec 30 17:15] P-1 on M43028441 with B1=50000, B2=TBD
[Dec 30 17:15] Setting affinity to run helper thread 1 on CPU core #2
[Dec 30 17:15] Using AVX FFT length 2240K, Pass1=448, Pass2=5K, clm=4, 2 threads[/CODE]

On the plus side
 

Seems stage 2 is almost twice as fast.

To duplicated my current P-1 work; (41.7M; B1=1000000,B2=20000000) I had to use the override to force 30.4 to use my bounds; that is leave off the Factor Bits Parm at the end.

Pminus1=N/A,1,2,41781227,-1,1000000,20000000

Running with 2 Workers x 2 Cores on a i5-3570K OC'd to 4.2 with 4GB allocated.
As assignment like the above was taking about 9 hours.
I don't have the exact breakdown bit was something like 3 & 6 hours for stages 1 and 2;
maybe 3.5 & 5.5 hours.

With 30.4 this is taking about 3.5 and 3 hours for a total of 6.5.

Woot Woot

[QUOTE=petrw1;567792]Seems stage 2 is almost twice as fast.[/QUOTE]For the same bounds. As I understand it, part of that speedup involves omitting Brent-Suyama. Since stage2 is faster, higher bounds can be selected for a similar runtime and increased chance of factor.

[QUOTE=James Heinrich;567793]As I understand it, part of that speedup involves omitting Brent-Suyama. [/QUOTE]
Omitting B-S simplifies the code somewhat, but yields only minor speedup. The main speed up comes from better prime pairing. Previously, the prime pairing was like 10-15%. Now it is more like 85-95%. I don't have much insight into how this is achieved, but I'm guessing the increased number of temps (much higher than the relprimes(D)) is somehow involved.

I am getting about 1.5-1.6x speedup in stage 2. Admittedly, doing 6 P-1 in parallel might be reducing some efficiency gains.

While on the topic of prime pairing, a question to George. Is it worth it to not handle unpaired primes at all? Say, if a stage 2 prime is unpaired and > 0.75 B2, then just don't use it. The "> 0.75 B2" condition is to minimise the loss of probability (smaller primes being more likely to be useful than larger ones).

You could even compensate for this by increasing B2 until enough additional paired primes are added back to the pool. I mean, there is nothing sacrosanct about "all the primes < B2".