mfaktc: a CUDA program for Mersenne prefactoring

[diamonddave]

I'm using mfaktc 0.17 and I get the folowing result line when factoring to 68 bit

no factor for M25941901 from 2^67 to 2^68 [mfaktc 0.17-Win barrett79_mul32]
no factor for M25973971 from 2^67 to 2^68 [mfaktc 0.17-Win barrett79_mul32]

Yet I see result in the Recent Results list that look like the folowing:

no factor for M55556113 from 2^72 to 2^73 [mfaktc 0.17-Win barrett79_mul32]
no factor for M55556113 from 2^71 to 2^72 [mfaktc 0.17-Win barrett79_mul32]
no factor for M55556113 from 2^70 to 2^71 [mfaktc 0.17-Win 71bit_mul24]
no factor for M55556113 from 2^69 to 2^70 [mfaktc 0.17-Win 71bit_mul24]

My guess is that the 71 bit kernel is faster for lower bound TF. Why would my machine always pick the 79 bit kernel when it looks like I am using the same version of mfaktc?

[TheJudger]

Hi,

Originally Posted by diamonddave

My guess is that the 71 bit kernel is faster for lower bound TF. Why would my machine always pick the 79 bit kernel when it looks like I am using the same version of mfaktc?

your guess is (partially) wrong. On old GPUs (compute capability 1.x) the 71bit kernel is indeed faster but on newer GPUs (compute capability 2.x) the 79bit kernel is faster.

file: src/mfakt.c

  if(kernel == AUTOSELECT_KERNEL)
  {
/* select the GPU kernel (fastest GPU kernel has highest priority) */
    if(mystuff->compcapa_major == 1)
    {
      if                         (bit_max <= 71)                              kernel = _71BIT_MUL24;
      else if((bit_min >= 64) && (bit_max <= 79))                             kernel = BARRETT79_MUL32;
      else if                    (bit_max <= 75)                              kernel = _75BIT_MUL32;
      else if((bit_min >= 64) && (bit_max <= 92) && (bit_max - bit_min == 1)) kernel = BARRETT92_MUL32;
      else                                                                    kernel = _95BIT_MUL32;
    }
    else // mystuff->compcapa_major != 1
    {
           if((bit_min >= 64) && (bit_max <= 79))                             kernel = BARRETT79_MUL32;
      else if((bit_min >= 64) && (bit_max <= 92) && (bit_max - bit_min == 1)) kernel = BARRETT92_MUL32;
      else if                    (bit_max <= 75)                              kernel = _75BIT_MUL32;
      else                                                                    kernel = _95BIT_MUL32;
    }
  }

as you can see they have different priorities depending on the major compute capability version.

Oliver

[apsen]

Originally Posted by TheJudger

Hi,
Currently the "manual result form" gives credits for TF for a "factor found" if the exponent is currently assigned for TF. This can be screwed by increasing the upper TF limit if the result is split into smaller ranges (bitlevel by bitlevel). Once you report the lowest "no factor" result from multiple bitlevels the exponent if no longer assigned for TF.

So, if I report lover bit levels "no factor", then get assignment for the level I have factor, and then report factor it should be assigned to TF?

[James Heinrich]

Originally Posted by Christenson

The main bit of information I would want when finding factors is whether the bit level was completed or not.

A valid request. Could be handled in my above proposal in a number of ways:

// leave upper-limit blank if not completed (how far it got can be inferred from the factor size):
M10906243 has a factor: 23620567217973346633 [TF;64;;mfaktc 0.18-pre1-Win 71bit_mul24]

// flag the incomplete bit level in some way:
M10906243 has a factor: 23620567217973346633 [TF;64;65*;mfaktc 0.18-pre1-Win 71bit_mul24]

// in either case, this would indicate continued to end of 2^65 after factor
M10906243 has a factor: 23620567217973346633 [TF;64;65;mfaktc 0.18-pre1-Win 71bit_mul24]

[Bdot]

Originally Posted by James Heinrich

A valid request. Could be handled in my above proposal in a number of ways:

// leave upper-limit blank if not completed (how far it got can be inferred from the factor size):
M10906243 has a factor: 23620567217973346633 [TF;64;;mfaktc 0.18-pre1-Win 71bit_mul24]

// flag the incomplete bit level in some way:
M10906243 has a factor: 23620567217973346633 [TF;64;65*;mfaktc 0.18-pre1-Win 71bit_mul24]

// in either case, this would indicate continued to end of 2^65 after factor
M10906243 has a factor: 23620567217973346633 [TF;64;65;mfaktc 0.18-pre1-Win 71bit_mul24]

Of course I would also adjust mfakto to support any new results syntax, if George agrees too. I'm favoring the second option (flag the incomplete bit level in some way) as with Stages=0 you do not necessarily have adjacent bit levels (and low levels can be combined anyway). Then, the "65*" would have some added value.

[Dubslow]

So if you assign a job from 69 to 71, and the log2(factor)<70, do you report 70* or 71*? The former would make more sense, I think.

[James Heinrich]

Originally Posted by Dubslow

So if you assign a job from 69 to 71, and the log2(factor)<70, do you report 70* or 71*? The former would make more sense, I think.

Definitely, it should be reported as [TF;69;70*;version]
It doesn't matter how far you were planning on going. We know that you found a factor somewhere 69<factor<70; what we don't know is whether you also finished checking between factor<70. If it's reported as [TF;69;70*;version] then you stopped as soon as you found the factor, whereas [TF;69;70;version] says that you found the factor but also finished checking the whole range.

[LaurV]

it does not really matter, everything should be ok, as an empty filed (double semicolumns, as in case 1), or just a star and no exponent, or some exponent - like 70, 71, 94 (how much you planned, or just log2 of the factor), AND a star... the meaning would be the same: "I did not went behind of the reported factor", or "I stopped after I found this factor". The "eventual more factorization" has to be continued from the reported factor, in any case.

The most difficult part would be to make George and co. to agree with it and do the changes, as his (their) free time is also limited.

[apsen]

Originally Posted by apsen

So, if I report lover bit levels "no factor", then get assignment for the level I have factor, and then report factor it should be assigned to TF?

That did not work my factor was again attributed to P-1. Back to rerunning factors with p95

[Prime95]

Originally Posted by apsen

That did not work my factor was again attributed to P-1. Back to rerunning factors with p95

No. If your results text contains both "no factor to" lines as well as "has a factor" lines, then factors should be attributed to TF.

[apsen]

Originally Posted by Prime95

No. If your results text contains both "no factor to" lines as well as "has a factor" lines, then factors should be attributed to TF.

Well, they didn't. This is what I have submitted via manual submission:

M57841799 has a factor: 2692557022299923757047
found 1 factor(s) for M57841799 from 2^71 to 2^72 [mfaktc 0.17-Win apsen barrett79_mul32]

This is what is on the results page:

Manual testing	57841799	F-PM1	2011-09-30 02:21	0.0	2692557022299923757047	 2.4586