mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Hardware > GPU Computing

Reply
 
Thread Tools
Old 2011-09-27, 11:44   #1233
diamonddave
 
diamonddave's Avatar
 
Feb 2004

2408 Posts
Default

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

Code:
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:

Code:
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?
diamonddave is offline   Reply With Quote
Old 2011-09-27, 12:11   #1234
TheJudger
 
TheJudger's Avatar
 
"Oliver"
Mar 2005
Germany

2·3·5·37 Posts
Default

Hi,

Quote:
Originally Posted by diamonddave View Post
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
Code:
  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
TheJudger is offline   Reply With Quote
Old 2011-09-27, 14:33   #1235
apsen
 
Jun 2011

13110 Posts
Default

Quote:
Originally Posted by TheJudger View Post
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?
apsen is offline   Reply With Quote
Old 2011-09-27, 14:49   #1236
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

3×23×47 Posts
Default

Quote:
Originally Posted by Christenson View Post
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:
Code:
// 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]
James Heinrich is offline   Reply With Quote
Old 2011-09-28, 09:33   #1237
Bdot
 
Bdot's Avatar
 
Nov 2010
Germany

25516 Posts
Default

Quote:
Originally Posted by James Heinrich View Post
A valid request. Could be handled in my above proposal in a number of ways:
Code:
// 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.
Bdot is offline   Reply With Quote
Old 2011-09-28, 18:59   #1238
Dubslow
Basketry That Evening!
 
Dubslow's Avatar
 
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

3·29·83 Posts
Default

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.
Dubslow is offline   Reply With Quote
Old 2011-09-28, 19:50   #1239
James Heinrich
 
James Heinrich's Avatar
 
"James Heinrich"
May 2004
ex-Northern Ontario

3·23·47 Posts
Default

Quote:
Originally Posted by Dubslow View Post
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.
James Heinrich is offline   Reply With Quote
Old 2011-09-29, 04:04   #1240
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

2×3×52×61 Posts
Default

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.

Last fiddled with by LaurV on 2011-09-29 at 04:08
LaurV is offline   Reply With Quote
Old 2011-09-30, 02:26   #1241
apsen
 
Jun 2011

131 Posts
Default

Quote:
Originally Posted by apsen View Post
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
apsen is offline   Reply With Quote
Old 2011-09-30, 02:53   #1242
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

72×149 Posts
Default

Quote:
Originally Posted by apsen View Post
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.
Prime95 is offline   Reply With Quote
Old 2011-09-30, 11:56   #1243
apsen
 
Jun 2011

2038 Posts
Default

Quote:
Originally Posted by Prime95 View Post
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:

Code:
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:

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

Last fiddled with by apsen on 2011-09-30 at 12:00
apsen is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
mfakto: an OpenCL program for Mersenne prefactoring Bdot GPU Computing 1668 2020-12-22 15:38
The P-1 factoring CUDA program firejuggler GPU Computing 753 2020-12-12 18:07
gr-mfaktc: a CUDA program for generalized repunits prefactoring MrRepunit GPU Computing 32 2020-11-11 19:56
mfaktc 0.21 - CUDA runtime wrong keisentraut Software 2 2020-08-18 07:03
World's second-dumbest CUDA program fivemack Programming 112 2015-02-12 22:51

All times are UTC. The time now is 15:40.

Thu Jan 21 15:40:36 UTC 2021 up 49 days, 11:51, 0 users, load averages: 1.73, 1.86, 1.94

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.