[QUOTE=R. Gerbicz;497455]My free (almost) 2x speedup tip: do only the k*3^n+1 prime tests, and if that is prime then later on or immediately run the k*3^n-1 prp test (which you can also verify it with a true primality test because the factorization of q+1 is trivial).

ps. but why are you using base=3? Quite unusual, also blocks my fast error checking.[/QUOTE]


The default behavior of twinsieve is that if a factor is found for -1, then -1 and +1 terms are removed. And I dont search twin primes, and this is not "ordinary" twinsiever.

So I ask Rogue, that add switch that will skip removing of +1 factor if factor for -1 is found. ( or in reverse order)
So in total I got: when sieve process is done I got sieve file for +/-side but I only sieve once: so speedup is already 50% :)
Second: why use base3? This is my little project: I already find "pair" of primes with same exponent on base2 , and now i switch on base 3 :)


P.S When I do base2 search your fast error checking was flawless Mr. Gerbicz

[QUOTE=Prime95;497457]I think the two tests are using the same save file name. Not good.

If you must do these two tests at the same time, run two different instances of prime95 in two different directories. One instance does the +1 candidates and the other instance does the -1 candidates.[/QUOTE]


Ok, then little XLS sheet will found those pairs, so I will test it different time, and all my problems are solved :)

ECM finds an improper factor
 

Here's an interesting bug:

Create [c]worktodo.txt[/c] with the following line:
[CODE]
[Worker #1]
ECM2=1,3,34961,-1,50000,5000000,279,"2"
[/CODE]

This is looking for factors of (3[SUP]34961[/SUP] − 1) /2 . It has known factors 162235122061 and 71915094739482479, but we don't include those in the factor string in the worktodo line, just "2".

Create a suitable [c]local.txt[/c], and [c]prime.txt[/c] with [c]UsePrimenet=0[/c], because Primenet doesn't want this result.

Use the save file [c]e0034961[/c] from the zip file attached to this post. This will run the ECM curve with s=4898604651034280.

Run [c]mprime -d[/c]

The result is:
[CODE]
[Main thread Oct 10 22:48] Starting worker.
[Work thread Oct 10 22:48] Worker starting
[Work thread Oct 10 22:48] Using FMA3 FFT length 3K
[Work thread Oct 10 22:48] ECM on 3^34961-1: curve #243 with s=4898604651034280, B1=50000, B2=5000000
[Work thread Oct 10 22:48] Using 65MB of memory in stage 2.
[Work thread Oct 10 22:48] Stage 2 init complete. 18626 transforms, 2 modular inverses. Time: 0.253 sec.
[Work thread Oct 10 22:48] 3^34961-1 has a factor: 216349680636949431...
...
...
...
...1985595899541669816801 (ECM curve 243, B1=50000, B2=5000000)
Segmentation fault
[/CODE]

That is, it prints out a 16681-digit factor, which turns out to be precisely (3[SUP]34961[/SUP] − 1) /2 itself, and then crashes.


When I try running the same parameters with GMP-ECM, nothing special happens. No factor is found:

[CODE]
echo "(3^34961-1)/2" | ./ecm -sigma 4898604651034280 50000 5000000
GMP-ECM 7.0.4 [configured with GMP 6.1.1, --enable-asm-redc] [ECM]
Input number is (3^34961-1)/2 (16681 digits)
Using B1=50000, B2=5000000, polynomial x^1, sigma=0:4898604651034280
Step 1 took ...ms
Step 2 took ...ms
[/CODE]

However, the documentation suggests that sigma is not always defined in the same way by mprime as by GMP-ECM, so maybe it's not doing the same calculations.

[QUOTE=GP2;497821]Here's an interesting bug:

Create [c]worktodo.txt[/c] with the following line:
[CODE]
[Worker #1]
ECM2=1,3,34961,-1,50000,5000000,279,"2"
[/CODE]

This is looking for factors of (3[SUP]34961[/SUP] − 1) /2 . It has known factors 162235122061 and 71915094739482479, but we don't include those in the factor string in the worktodo line, just "2".

Create a suitable [c]local.txt[/c], and [c]prime.txt[/c] with [c]UsePrimenet=0[/c], because Primenet doesn't want this result.

Use the save file [c]e0034961[/c] from the zip file attached to this post. This will run the ECM curve with s=4898604651034280.

Run [c]mprime -d[/c]

The result is:
[CODE]
[Main thread Oct 10 22:48] Starting worker.
[Work thread Oct 10 22:48] Worker starting
[Work thread Oct 10 22:48] Using FMA3 FFT length 3K
[Work thread Oct 10 22:48] ECM on 3^34961-1: curve #243 with s=4898604651034280, B1=50000, B2=5000000
[Work thread Oct 10 22:48] Using 65MB of memory in stage 2.
[Work thread Oct 10 22:48] Stage 2 init complete. 18626 transforms, 2 modular inverses. Time: 0.253 sec.
[Work thread Oct 10 22:48] 3^34961-1 has a factor: 216349680636949431...
...
...
...
...1985595899541669816801 (ECM curve 243, B1=50000, B2=5000000)
Segmentation fault
[/CODE]

That is, it prints out a 16681-digit factor, which turns out to be precisely (3[SUP]34961[/SUP] − 1) /2 itself, and then crashes.


When I try running the same parameters with GMP-ECM, nothing special happens. No factor is found:

[CODE]
echo "(3^34961-1)/2" | ./ecm -sigma 4898604651034280 50000 5000000
GMP-ECM 7.0.4 [configured with GMP 6.1.1, --enable-asm-redc] [ECM]
Input number is (3^34961-1)/2 (16681 digits)
Using B1=50000, B2=5000000, polynomial x^1, sigma=0:4898604651034280
Step 1 took ...ms
Step 2 took ...ms
[/CODE]

However, the documentation suggests that sigma is not always defined in the same way by mprime as by GMP-ECM, so maybe it's not doing the same calculations.[/QUOTE]

Looks like the print buffer was defined statically at 16K?

[QUOTE=GP2;497821]Here's an interesting bug:

Create [c]worktodo.txt[/c] with the following line:
[CODE]
[Worker #1]
ECM2=1,3,34961,-1,50000,5000000,279,"2"
[/CODE]This is looking for factors of (3[SUP]34961[/SUP] − 1) /2 . It has known factors 162235122061 and 71915094739482479, but we don't include those in the factor string in the worktodo line, just "2".

[/QUOTE]

There is something funny with your save file.

This job runs just fine:
[CODE]
[Worker #1]
ECM2=1,3,34961,-1,50000,5000000,1,4898604651034280,"2"
[/CODE]resulting in
[CODE]
[Oct 15 14:14] ECM on 3^34961-1: curve #1 with s=4898604651034280, B1=50000, B2=5000000
[Oct 15 14:14] Stage 1 complete. 1286025 transforms, 1 modular inverses. Time: 10.312 sec.
[Oct 15 14:14] Using 65MB of memory in stage 2.
[Oct 15 14:14] Stage 2 init complete. 18313 transforms, 1 modular inverses. Time: 0.215 sec.
[Oct 15 14:14] Stage 2 complete. 592895 transforms, 1 modular inverses. Time: 5.134 sec.
[Oct 15 14:14] Stage 2 GCD complete. Time: 0.051 sec.
[Oct 15 14:14] 3^34961-1 completed 1 ECM curve, B1=50000, B2=5000000, We4: 01420FF3
[Oct 15 14:14] No work to do at the present time. Waiting.
[/CODE]

[QUOTE=error;498073]There is something funny with your save file.

This job runs just fine:
[CODE]
[Worker #1]
ECM2=1,3,34961,-1,50000,5000000,1,4898604651034280,"2"
[/CODE][/QUOTE]

No, it crashes in the same way.

[QUOTE]
[CODE]
[Oct 15 14:14] 3^34961-1 completed 1 ECM curve, B1=50000, B2=5000000, We4: 01420FF3
[/CODE][/QUOTE]

The "We4" indicates maybe that you are using version 27 of mprime? For my run it is "Wg8". The letter indicates the version and the number indicates the platform. I am using the latest version 29 on Linux.

[QUOTE]
[CODE]
[Oct 15 14:14] Stage 2 init complete. 18313 transforms, 1 modular inverses. Time: 0.215 sec.
[/CODE]
[/QUOTE]

It's interesting that there is a different number of transforms. You get 18313, but in my runs (both times) it was 18626. Maybe this is a clue to the problem. Interestingly, 626 = 2 times 313, is that just a coincidence?

[QUOTE=GP2;498074]No, it crashes in the same way.



The "We4" indicates maybe that you are using version 27 of mprime? For my run it is "Wg8". The letter indicates the version and the number indicates the platform. I am using the latest version 29 on Linux.



It's interesting that there is a different number of transforms. You get 18313, but in my runs (both times) it was 18626. Maybe this is a clue to the problem. Interestingly, 626 = 2 times 313, is that just a coincidence?[/QUOTE]

Do you still have the savefile there? If you do, it will cause the crash. That happens to me too. I use 28.5 on Win7.

[QUOTE=error;498077]Do you still have the savefile there? If you do, it will cause the crash. That happens to me too. I use 28.5 on Win7.[/QUOTE]

Yes, that's the problem. I used the same working directory with the savefile in it. It worked the second time, 18313 transforms and no factor found, like yours.

But the savefile was written by mprime itself, so it's some kind of rare bug one way or another. And the original crash happened in the middle of a run, so resuming from the savefile merely reproduced that crash. In other words, I don't think it's because of corruption introduced by the routines that write the savefile.

P-1 bounds selected are falling short of primenet values
 

I had thought that if I gave prime95 v29.4b8 plenty of ram allocation, that it would use bounds that satisfy primenet targets. But it seems it falls well short. See for example [URL]https://www.mersenne.ca/exponent/89200591[/URL] which was run with a memory limit of 16GB for the 4-core worker. [CODE]
Limit Ghz-Days Probability B1 B2
Actual 2[SUP]76[/SUP] 171.5683 84.2649% 720,000 14,220,000
PrimeNet 2[SUP]71[/SUP] 5.3596 80.9970% 970,000 24,250,000
GPU72 2[SUP]75[/SUP] 85.7832 83.6597% 970,000 24,250,000
Difference +1 +85.7851 +0.6052% -250,000 -10,030,000 [/CODE] Reading through readme.txt and undoc.txt and searching for strings like primenet, bound, P-1 did not reveal a way to set it to use primenet bounds for P-1. Manually modifying the worktodo entries would be tedious and impractical since it's doing one each 7 hours or so. I'm running now with 32GB for the P-1 memory limit, since it looks like it was fully utilizing 16GB in stage 2.

Is there a way to cause v29.4 to automatically go to the primenet bounds?

Is satisfying primenet P-1 bounds something that will or could be included in v29.5 as an option?

Is there some reason matching primenet bounds is at least sometimes a bad idea?

[QUOTE=kriesel;498476]Is there a way to cause v29.4 to automatically go to the primenet bounds?
Is there some reason matching primenet bounds is at least sometimes a bad idea?[/QUOTE]The bounds chosen for P-1 are to optimize throughput, where the amount of work spent doing P-1 is less than the amount of work saved by any factors found. What that means for bounds is that as TF is done to higher bounds the chance of finding a P-1 factor is slightly lower, therefore less time should be spent doing P-1. Since the advent of GPU-TF all exponents are TF'd 3-4 bitlevels higher than the old CPU-TF limits of Prime95 (which are largely irrelevant now).

The important thing to note in the table you copy-pasted is the "Combined Probability" column, which is the chance of finding a factor with both TF and P-1:
[FONT="Courier New"]Prime95 CPU limits: TF:71, B1:970000, B2: 24250000 = 86.8439%
Actual work done: TF:76, B1:720000, B2: 14220000 = 87.3853%[/FONT]
Much more TF, somewhat less P-1, but overall a higher chance of finding a factor.

If you really truly want to get Prime95 to pick the higher bounds you can manually enter the bounds in worktodo (see undoc.txt for details), or you can adjust the bitlevel in your existing worktodo lines to a lower level, but just be aware that Prime95 automatically selects the optimal bounds and any changes you make will likely lower GIMPS overall throughput (even if you do find more factors).


edit: also note two things about the bounds on mersenne.ca:
1) the P-1 bounds in the GPU72 line are wrong, they are not adjusted as described above, I need to figure out how to do so.
2) the P-1 bounds in general are close to magic numbers, they're currently plucked off an Excel graph I did in 2008 based on observed bounds for exponents 1M-500M, so while they might be reasonably close to reality, they'll never match exactly.

[QUOTE=kriesel;498476]...
Is satisfying primenet P-1 bounds something that will or could be included in v29.5 as an option?
Is there some reason matching primenet bounds is at least sometimes a bad idea?[/QUOTE]James beet me to it, but I'll leave my answer.

As far as I know "PrimeNet" bounds are a concept used by mersenne.ca only.

The Prime95 program calculates the bounds for each work-unit based on how deep factored, the number of LL tests saved and the available memory. The bounds are based on the assumption that the same machine will do the LL tests. Also I have always had a better success rate than that calculated by Prime 95.

Once you allow the program to use a reasonable quantity of memory it doesn't affect the bounds very much, it will have an influence on the Brent-Sumaya extensions.

In other words, at the moment, except by modifying the work-units in the worktodo.txt file there is nothing you can do. But you can ask George if he would consider introducing a fiddling factor for P-1 factoring.

There is another way you can drastically change the bounds used by Prime95 : change the number of LL tests saved, by default it is set at two.

Jacob