GPU to 72 status...

[NickOfTime]

Originally Posted by NickOfTime

hmm, It might be easier to just parse the results.txt and just have people supply the benchmark.txt for the startup variables/card specs :-)

hmm, mfacto showing 87792 GHz-days / day :)

probably want to remove Factor=49864411,75,76
from benchmark, my 290x spend 2h on it so far and it also is duplicated..

[James Heinrich]

Originally Posted by LaurV

I don't get it why the class-0 has to be excluded (?!)

No real reason, I just wanted to give it an opportunity to run through at least one class before being aborted by finding a factor. If a factor is found after 0.001ms of runtime on an exponent I wouldn't put much faith in the displayed processing rate.

Looking at the 60M-70M range, this is the approximate distribution of the first few classes. It's not even, with some classes having many more than others, and several (2, 6, 10, 14, 18, 22, etc) having none at all. Class-0 has some, but not nearly as many as class 1 or 3.

+-----------+---------+
| class4620 | howmany |
+-----------+---------+
|         0 |     276 |
|         1 |   19788 |
|         3 |   12456 |
|         4 |    9254 |
|         5 |    4850 |
|         7 |    3130 |
|         8 |    4565 |
|         9 |    3926 |
|        11 |    1803 |
|        12 |    5790 |
|        13 |    1550 |
|        15 |    3222 |
|        16 |    2209 |
|        17 |    1050 |
|        19 |     993 |
|        20 |    2434 |
|        21 |    2085 |
|        23 |     784 |
|        24 |    2907 |
|        25 |     957 |
|        27 |    1261 |
|        28 |    1544 |
|        29 |     615 |
|        31 |     574 |
|        32 |    1092 |

I'm sure there's a perfectly good mathy explanation for it that I wouldn't understand, but I just look at the pretty numbers.

[James Heinrich]

Originally Posted by NickOfTime

probably want to remove
Factor=49864411,75,76
from benchmark, my 290x spend 2h on it so far and it also is duplicated..

You're right, that one is incorrect. The factor is actually just below 2⁷⁵ at 74.9999766 bits so won't actually be found at all. (The value is stored in my database rounded to 5 decimal places, so ended up as 75.0000). Please remove that test(s).

3rd revision attached with additional checking for this kind of borderline case.

[NickOfTime]

Originally Posted by James Heinrich

You're right, that one is incorrect. The factor is actually just below 2⁷⁵ at 74.9999766 bits so won't actually be found at all. (The value is stored in my database rounded to 5 decimal places, so ended up as 75.0000). Please remove that test(s).

3rd revision attached with additional checking for this kind of borderline case.

well V2 results...for 290x
Another one to remove...
no factor for M88345373 from 2^65 to 2^66 [mfakto 0.14-Win cl_barrett15_69_gs_2]

DropBox 290x Benchmark ziped

[kracker]

Originally Posted by James Heinrich

You're right, that one is incorrect. The factor is actually just below 2⁷⁵ at 74.9999766 bits so won't actually be found at all. (The value is stored in my database rounded to 5 decimal places, so ended up as 75.0000). Please remove that test(s).

3rd revision attached with additional checking for this kind of borderline case.

Started on my GPU.

[TheJudger]

Originally Posted by James Heinrich

I'm sure there's a perfectly good mathy explanation for it that I wouldn't understand, but I just look at the pretty numbers.

Preface: (residue-)classes in mfaktX are about the k in the factor candidate (FC) = 2kp+1, not about the FC itself.

• The propability for a factor between 2ⁿ and 2ⁿ⁺¹ is 1/n. The smallest possible FC is k=1 and has the highest chance to be a factor of 2^p-1
• Ignoring p=2, all primes p are 1, 3, 5 or 7 mod 8. For k = 2 all FCs are 5 mod 8 and this disqualifies the whole class for all p because FCs must be 1 or 7 mod 8
  • 2 * k * p + 1
  • 2 * 2 * 1 + 1 = 5 mod 8
  • 2 * 2 * 3 + 1 = 5 mod 8
  • 2 * 2 * 5 + 1 = 5 mod 8
  • 2 * 2 * 7 + 1 = 5 mod 8
• some classes are more common than other classes, e.g. class 0 is valid for ALL p thus you should have more factors in this class
• if you stop after a factor is found you'll find more factors in the classes you start.

So if you ignore relative small factors your statistics should be more evenly distributed (but still some classes are more common than others).

Oliver

[TheMawn]

Originally Posted by axn

We _really_ need that front page pimpage on GIMPS. George?

I agree. I only found out about GPU72 by looking up the top teams in trial factoring. I had an old i7-920 box chugging away a long time ago and I'd have brought the HD 5770 in as well had I known back then.

[kracker]

I was thinking: it probably would/might be best to skip every other M? I don't think there is a whole lot of difference. 6h later on my slow (160 GHz) I'm at 36M.

[James Heinrich]

It would probably be just fine to only do every 5th M, with possible later refinement around the "interesting" transition areas when those are identified for various architectures.

[NickOfTime]

Originally Posted by NickOfTime

well V2 results...for 290x
Another one to remove...
no factor for M88345373 from 2^65 to 2^66 [mfakto 0.14-Win cl_barrett15_69_gs_2]

DropBox 290x Benchmark ziped

yep
Factor=88345373,65,66
should be
Factor=88345373,64,65

OpenCL device info
  name                      Intel(R) Core(TM) i7-4770S CPU @ 3.10GHz (GenuineInt
el)
  device (driver) version   OpenCL 1.2 AMD-APP (1411.4) (1411.4 (sse2))
  maximum threads per block 1024
  maximum threads per grid  1073741824
  number of multiprocessors 8 (512 compute elements)
  clock rate                3105MHz

Automatic parameters
  threads per grid          2097152
  optimizing kernels for    GCN

got assignment: exp=88345373 bit_min=64 bit_max=65 (0.04 GHz-days)
Starting trial factoring M88345373 from 2^64 to 2^65 (0.04GHz-days)
Using GPU kernel "cl_barrett15_69_gs"
No checkpoint file "M88345373.ckp" found.
Date    Time | class   Pct |   time     ETA | GHz-d/day    Sieve     Wait
Jun 01 13:08 |    0   0.1% |  1.263  20m11s |      3.01    82485    0.00%
Jun 01 13:08 |    3   0.2% |  1.270  20m17s |      3.00    82485    0.00%
Jun 01 13:08 |    7   0.3% |  1.260  20m06s |      3.02    82485    0.00%
Jun 01 13:08 |   12   0.4% |  1.265  20m09s |      3.01    82485    0.00%
M88345373 has a factor: 36893056995103492273
found 1 factor for M88345373 from 2^64 to 2^65 (partially tested) [mfakto 0.13-W
in cl_barrett15_69_gs_2]
tf(): total time spent:  5.062s (721.87 GHz-days / day)

[chalsall]

Originally Posted by TheJudger

So if you ignore relative small factors your statistics should be more evenly distributed (but still some classes are more common than others).

Oliver et al, please forgive me if this is a really stupid question/suggestion...

But might there be upside (defined as factors found per GPU cycle) in deriving an empirical statistical distribution "curve" of the probability of finding a factor in each class for the ranges and depths we're currently working, and do them in that order rather than sequentially?

Taking James' data above, the optimal order to do the classes would be:

+---------+-----------+
| howmany | class4620 |
+---------+-----------+
|   19788 |         1 |
|   12456 |         3 |
|    9254 |         4 |
|    5790 |        12 |
|    4850 |         5 |
|    4565 |         8 |
|    3926 |         9 |
|    3222 |        15 |
|    3130 |         7 |
|    2907 |        24 |
|    2434 |        20 |
|    2209 |        16 |
|    2085 |        21 |
|    1803 |        11 |
|    1550 |        13 |
|    1544 |        28 |
|    1261 |        27 |
|    1092 |        32 |
|    1050 |        17 |
|     993 |        19 |
|     957 |        25 |
|     784 |        23 |
|     615 |        29 |
|     574 |        31 |
|     276 |         0 |

Perhaps have mfaktX be able to import text files containing current data for different ranges and/or TF depth (since this data is not complete, nor representative of where we're currently working)?

Again, please forgive me (and tell me) if this is a really stupid idea. I can't hold a candle to you guys when it comes to the maths.