mfaktc: a CUDA program for Mersenne prefactoring

[TheJudger]

Some data from tf_barrett96.cu: mod_simple_96():

 qi = 0
 q =   00000007 3C3F1F20 C454D397
 nn =  00000000 00000000 00000000
 res = 00000007 3C3F1F1F C454D397

res = q - nn;

So for now it looks like CUDA 5.0.7 fails when somebody uses sub with carry when the subtrahend is 0. So for now it looks like a bug in CUDA 5.0.7.

Oliver

[axn]

Originally Posted by TheJudger

Some data from tf_barrett96.cu: mod_simple_96():

 qi = 0
 q =   00000007 3C3F1F20 C454D397
 nn =  00000000 00000000 00000000
 res = 00000007 3C3F1F1F C454D397

res = q - nn;

So for now it looks like CUDA 5.0.7 fails when somebody uses sub with carry when the subtrahend is 0. So for now it looks like a bug in CUDA 5.0.7.

Oliver

Have you tried adding the volatile keyword to your asm statements?

[TheJudger]

Nvidia confirmed the bug so I would say: not my fault/problem!

Oliver

[Xyzzy]

We submitted all of our completed work today in one file and were awarded some "extra credit". (See attached image.)

P-1 found a factor in stage #2, B1=565000, B2=12147500, E=6.
M56350163 has a factor: 24948611431313562132407
P-1 found a factor in stage #2, B1=540000, B2=11475000, E=6.
M54203297 has a factor: 43709161575143787520913

[James Heinrich]

Originally Posted by Xyzzy

We submitted all of our completed work today in one file and were awarded some "extra credit"

I'm not even sure how to come up with those numbers... that's approx 150%-200% what credit you should get for those factors even as credited for TF.

[Prime95]

Originally Posted by James Heinrich

I'm not even sure how to come up with those numbers... that's approx 150%-200% what credit you should get for those factors even as credited for TF.

James, did you change the manual web forms along the lines we were discussing? If so, did the B1/B2 bounds get recorded correctly? Maybe, the underlying PHP guessed the wrong FFT size or we passed in a bogus FFT size?

[James Heinrich]

Originally Posted by Prime95

James, did you change the manual web forms along the lines we were discussing? If so, did the B1/B2 bounds get recorded correctly? Maybe, the underlying PHP guessed the wrong FFT size or we passed in a bogus FFT size?

No, I hadn't got to that yet (I was going to... the day PrimeNet was down for a few hours), the manual form is as yet unchanged.

[Prime95]

Originally Posted by James Heinrich

No, I hadn't got to that yet...

Weird. All the more reason to make those changes!

[Prime95]

Oliver,

I propose creating a barrett77_mul32. This is the same as barrett79_mul32 but with the mod_simple_96 moved out of the loop. As long as f does not exceed 77 bits, a will not exceed 80 bits (above 80 bits and square_96_160 will fail).

I tested this out and it passes the self tests up through 77 bits. Raw speed went from 205M/sec to 250M/sec.

Crude source is attached.

[kladner]

Originally Posted by Prime95

Oliver,
.......
I tested this out and it passes the self tests up through 77 bits. Raw speed went from 205M/sec to 250M/sec.....

Wow.

[Xyzzy]

More "extra credit":

Processing result: M56505451 has a factor: 86553876518403762963169
CPU credit is 323.9309 GHz-days.
Processing result: M56488651 has a factor: 35566445275259107720993
CPU credit is 129.5622 GHz-days.
Processing result: M56491177 has a factor: 23502006329787341695151
CPU credit is 89.0731 GHz-days.