[QUOTE=NickOfTime;374665]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 :)
[/QUOTE]

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

[QUOTE=LaurV;374660]I don't get it why the class-0 has to be excluded (?!)[/QUOTE]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.[code]+-----------+---------+
| 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 |[/code]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. :smile:

[QUOTE=NickOfTime;374680]probably want to remove
Factor=49864411,75,76
from benchmark, my 290x spend 2h on it so far and it also is duplicated..[/QUOTE]You're right, that one is incorrect. The factor is actually just below 2[sup]75[/sup] 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.

[QUOTE=James Heinrich;374686]You're right, that one is incorrect. The factor is actually just below 2[sup]75[/sup] 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.[/QUOTE]

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]

[URL="https://dl.dropboxusercontent.com/u/123993183/benchmark_290x.zip"]DropBox 290x Benchmark ziped[/URL]

[QUOTE=James Heinrich;374686]You're right, that one is incorrect. The factor is actually just below 2[sup]75[/sup] 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.[/QUOTE]

Started on my GPU. :smile:

[QUOTE=James Heinrich;374683]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. :smile:[/QUOTE]

Preface: (residue-)classes in mfaktX are about the k in the factor candidate (FC) = 2kp+1, not about the FC itself.
[LIST][*]The propability for a factor between 2[SUP]n[/SUP] and 2[SUP]n+1[/SUP] is 1/n. The smallest possible FC is k=1 and has the highest chance to be a factor of 2[SUP]p[/SUP]-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[LIST][*] 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[/LIST][*]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.[/LIST]
So if you ignore relative small factors your statistics should be more evenly distributed (but still some classes are more common than others).

Oliver

[QUOTE=axn;374673]We _really_ need that front page pimpage on GIMPS. George?[/QUOTE]

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.

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. :smile:

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.

[QUOTE=NickOfTime;374699]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]

[URL="https://dl.dropboxusercontent.com/u/123993183/benchmark_290x.zip"]DropBox 290x Benchmark ziped[/URL][/QUOTE]

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

[CODE]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)[/CODE]

[QUOTE=TheJudger;374708]So if you ignore relative small factors your statistics should be more evenly distributed (but still some classes are more common than others).[/QUOTE]

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:[CODE]+---------+-----------+
| 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 |[/CODE]

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. :smile: