Prime95 v25.3

[S485122]

Originally Posted by chappjc

What is the optimal memory in terms of performance? As far as I can recall, an older v24 mprime asked for a value between 8 and 23 MB for some reason.

This question has been discussed in the second post of the following thread : optimal memory settings for the P-1 stage.

Jacob

[S485122]

Do the trial factoring limits change with this version ? It seems to me that on Core 2 architecture computers trial factoring could go one bit farther.

The mean time to trial factor a 41M exponent from 62 to 68 bits is 0,54 days.

The time to LL test that exponent on the same computer is 36 days. With the double check that is 72 days plus one day for P-1 factoring.

Trial factoring from 68 to 69 bits would require another .55 days and would find a factor in 1,45% of cases, taking into account the 69 bits factor would be found by P-1 factoring in 30% of cases, the net benefit would be another 1% of exponents eliminated. The cost would thus be 0,55 days/1% =55 days compared to 2*36 days+1day=73 days...

Another thing is the the suggestion by A Kruppa :

Originally Posted by akruppa

How about making the thresholds depend on p (mod 120)? For example, for candidate factors p==1 (mod 120), we know that 120|p-1, giving P-1 a much higher chance of recovering such factors if missed by trial division. Otoh, with p==119 (mod 120), p-1 has no prime factors <5 except a single 2, so these are poor candidates for P-1 and could be trial divided higher.

So for each class r (mod 120), compute the limit where for a prime p==r (mod 120) the probability of (1.) not being covered by P-1, and (2.) dividing the Mersenne number is better than some threshold. (1.) depends on r and the size of p, (2.) only on the size of p. (1.) can be computed accurately, I've played with problems like that recently.

It could be worthwhile to treat more separate classes, say 96 classes (mod 840), or even 960 classes (mod 9240), so knowledge that 7 or 11, resp., divides p-1 can be used for calculating the trial factoring limit for that class.

Alex :akruppa:

Originally Posted by Prime95

Now that is a clever idea!

(See New factoring breakeven points coming)

Jacob

[chappjc]

Originally Posted by S485122

This question has been discussed in the second post of the following thread : optimal memory settings for the P-1 stage.

Jacob

Thank you for that link, Jacob, but the question still stands. First of all, I have no idea how mprime v25.3 on linux x64 differs from prime95 v24. Secondly, cheesehead's information is vauge and inconclusive:

Originally Posted by cheesehead

The third case (>150M) will take the longest time, but also has the highest chance of finding a factor.

Thus we can see why wackeyh writes that increasing the Available Memory will increase the time. What wackeyh leaves out, however, is that prime95 has calculated that the increased time is justified by the increased chance of finding a factor. (Perhaps wackeyh is even unaware that increasing the memory allows prime95 to have a greater chance of finding a factor in P-1.) My advice is to trust prime95's algorithm for choosing B1/B2 limits -- the more memory you give it, the better your result will be.

As I mentioned, mprime will take over 1GB of ram. Could tell me what value you have selected as a reasonable amount of memory to sacrifice to mprime?

[Prime95]

As to splitting the available memory among the P-1 jobs: I'll do that, but it might be a little messy.

As to the optimal amount of memory to allocate: Don't over-optimize. Once you've given prime95 a "decent" amount of memory, more memory will have very, very minor improvements in GIMPS throughput. Say, you're at 300MB and tripling it to 900MB makes P-1 stage 2 run 2% faster. The fact that stage 2 of P-1 runs about half a day per month means your overall GIMPS throughput has increased 1/30%. Just set the available memory to a value that is highly unlikely to cause thrashing.

You'll probably ignore the advice in the previous paragraph. So 25.3 stage 2 now outputs a little more information. It will tell you how much memory stage 2 is using. It will also output something cryptic like "(processing 24 out of 480 relative primes)". This means that stage 2 will require 480/24 = 20 passes to complete stage 2. Each pass has a little bit of overhead. So if you can reduce the number of passes you will be a tiny bit faster. To process one more relative prime per pass, you'll need about FFT size * 8 bytes more available memory (e.g. 2048K FFT size needs 16MB). In this particular example, you'll need to process 26 relative primes to have one fewer pass in stage 2 (ceil (480/26) = 19). So you'd need 32MB more available memory to have a 5% reduction in the already small overhead associated with each stage 2 pass. Now, contrast that example with someone seeing "(processing 2 out of 480 rel primes)". Adding 32MB in this case you'll get a 50% reduction in overhead (240 passes reduced to 120 passes).

As to TF limits: They won't change in v25. Alex Kruppa's cool idea remains in the wish list file.

[S485122]

Originally Posted by chappjc

As I mentioned, mprime will take over 1GB of ram. Could tell me what value you have selected as a reasonable amount of memory to sacrifice to mprime?

The values I use are not very relevant : on my 64 bits machine I gave the maximum RAM possible to Prime95 =3619 MB out of 4096 MB on the system. It is the only machine I do P-1 factoring on : when needed I transfer workunits to it (and if P-1 does not find a factor from it back to the other machine.)

Anyway the RAM you allocate to mprime will only be used during stage 2 of P-1 test factoring, the rest of the time (98% more or less) it will use much less memory. See Question about Prime95 and virtual memory. You can even have mprime only do stage 2 of P-1 during certain hours (see the readme and helpfiles...)

[chappjc]

Originally Posted by Prime95

As to the optimal amount of memory to allocate: Don't over-optimize.

I am somewhat concerned with conserving memory at all times. So given your suggestions based on a 2048kB window, it seems reasonable to provide ~500MB for a reasonable # of passes in stage 2. Although the operating point depends on the fft size and the exponent, given the non-linear speedup with increasing memory there is no sense in using huge amounts of RAM.

I can see how this could be trouble if each worker gets a portion of the memory for stage 2. Maybe splitting available memory would be bad after all?

Originally Posted by S485122

You can even have mprime only do stage 2 of P-1 during certain hours

An excellent suggestion, but I think I am going to reduce memory usage altogether given Prime95's comments and your observations that stage 2 doesn't take very long anyway.

Thank's guys. I'll check back for updated versions to test.

[drew]

1) For example, I'm unhappy with Test / Worker threads dialog box:

I think the term "Number of CPUs to use" should be "Number of CPUs *per thread*" (or 'work unit' or whatever you decide to call it). I tried '2' because I have a dual-core machine, but since I chose to run 2 threads, '1' was the appropriate setting. It's misleading.

[drew]

I have my laptop configured to not run Prime95 when on battery power. When I have 2 tests running and restore external power, Prime95 restarts as it should.

If I run only one test by removing a line from worktodo.txt and disconnecting from the internet, it runs the remaining test. But when I remove and restore external power, the remaining test does not restart. This behavior occurs regardless of which thread has been disabled.

The 'stop' and 'continue' buttons work correctly. I suggest the external power switching logic share some of this code.

Drew

[Prime95]

Originally Posted by drew

If I run only one test ... when I remove and restore external power, the remaining test does not restart.

Nice catch. I've fixed it (but not uploaded the fix).

[garo]

Another vote for the ability to start and stop individual threads. It can be very useful in a number of situations e.g. when it is very hot, when you want to let the other core do other stuff etc. etc.

[Bent]

I think I found a problem with the program behavior when logging off, unless this is by design. When I log off of windows then log on again, Prime95 isn't running. It used to be running even when logged of, but it seems to be quitting upon logoff now.