mfaktc: a CUDA program for Mersenne prefactoring

[Mr. P-1]

Originally Posted by davieddy

Hmm.

1) I think "No" meant "Yes".

"No" means "No". A quick test showed that the client will happily run P-1 on a 43M exponent even if the TF bit level is set as high as 80, albeit at much reduced limits.

2) Without fully understanding P-1, I would have thought
"reduction" meant "increase"!

No. The limits are determined by the law of diminishing returns. Specifically, the program stops doing stage 1 when the benefit gained by doing additional stage 1 falls below the cost of doing it. Similarly with stage 2. Additional levels of TF reduce the benefit of P-1, which means that these cross-over points are reached earlier.

[davieddy]

Originally Posted by Mr. P-1

"No" means "No". A quick test showed that the client will happily run P-1 on a 43M exponent even if the TF bit level is set as high as 80, albeit at much reduced limits.



No. The limits are determined by the law of diminishing returns. Specifically, the program stops doing stage 1 when the benefit gained by doing additional stage 1 falls below the cost of doing it. Similarly with stage 2. Additional levels of TF reduce the benefit of P-1, which means that these cross-over points are reached earlier.

Many thanks.

David

PS are you the inventor of P-1?

[Mr. P-1]

Originally Posted by Christenson

Sorry I didn't have any numbers....hoping that the extra TF will allow P-1 to look for larger factors...

Unfortunately it doesn't work like that. Information about the TF level is used in the calculation of the P-1 probability of success, which in turn influences the optimal bounds - in a negative direction.

What you want is for P-1 to find more large factors by somehow skipping small ones. Unfortunately there is no way for this algorithm to do this.

It could work in the opposite direction: You could have the TF factoring algorithm skip "smooth" potential factors which P-1 would find. However the cost of testing each potential factor for smoothness would greatly exceed the cost of doing them all.

[Mr. P-1]

Originally Posted by davieddy

PS are you the inventor of P-1?

Good Heavens, no, just a fan of it.

The algorithm was first publicly described by John Pollard in 1974, though I have read (don't ask me where) that it was known to Selfridge and Lehmer before then.

I started doing P-1 work near exclusively for GIMPS shortly after the function was included within the client. At that time it was not possible to obtain this kind of work from the server. I would take Test assignments and manually convert them to Pfactor, unreserving them when done. Few, if any, other GIMPS participants worked this way, so Mr. P-1 seemed a reasonable moniker when I joined the forum. It's far less justifiable now.

[davieddy]

Originally Posted by Mr. P-1

Good Heavens, no, just a fan of it.

The algorithm was first publicly described by John Pollard in 1974, though I have read (don't ask me where) that it was known to Selfridge and Lehmer before then.

I started doing P-1 work near exclusively for GIMPS shortly after the function was included within the client. At that time it was not possible to obtain this kind of work from the server. I would take Test assignments and manually convert them to Pfactor, unreserving them when done. Few, if any, other GIMPS participants worked this way, so Mr. P-1 seemed a reasonable moniker when I joined the forum. It's far less justifiable now.

Modesty here is a sensible attitude.

There are usually some folk who know more than you!

Now what sort of music floats your boat?

David

OK Silence is Golden

[Christenson]

Dumb question for everyone, especially P95.
If we fool with the format of results.txt...making it state that it's [mfaktc 0.17 barret79_mul32] or whatever on the factor found lines, should we also make it report the assignment key on the same line?

Thanks

[Batalov]

Poisson distribution is a bee... /stings like a bee, anyway/

Just to see what people were obsessing about, I tried some mfaktc'ing - and of course, there were no factors for more than a hundred tests (these were 69ers, slow and annoying). And then ...one, then three more within an hour (granted, I've made the search a bit faster by finding a 64-to-65-bit niche :-).

309927157 F 2011-06-16 06:06 0.2 22510517584353120737 0.0017
309926621 F 2011-06-16 06:06 0.2 30955062015569795249 0.0089
309926359 F 2011-06-16 06:06 0.2 47315537535696427297 0.0307
309932159 F 2011-06-16 03:49 0.0 22436461899374945833 0.0070

Too easy. The program seems to work fine

[davieddy]

Yep.
If any "conspiracy theorist" thinks it's missing factors, the proof of this couldn't be simpler to come up with!

David

[davieddy]

Another point is that suggesting a TF program is "slightly broken"
is akin to saying a woman is "a bit pregnant"!

David

[Christenson]

The arguments for being "sligthly broken" are as follows:
a) doesn't quite tickle the server optimally when reports are resulted manually.....
b) requires manual care and feeding, instead of being able to be told to go get work from the server, and having results show up on the server automagically.
c) mfaktc uses the CPU to sieve, so you need a decent CPU core to feed a good GPU card.
d) It can break if interrupted...needs to keep multiple checkpoint files for when working on large jobs.
e) Once those issues are fiixed, I'd argue the program is perfect....all of these have to do with care and feeding.

[davieddy]

Originally Posted by Christenson

c) mfaktc uses the CPU to sieve, so you need a decent CPU core to feed a good GPU card.

Can't quite understand why sieving is an issue.

~2005 I wrote TF and LL programs and proved that M29? was M29.
Really fun excercise BTW.
Can't remember precisely how I timed it, but optimal sieving took
a negligible time compared with the division.

As for all the "high level hassles" - aren't and never could
be bothered with them.

Tell the "OS" to shut up, invoke "protected mode",
then get on with it.

David

PS have you heard that "8 bit tune" yet?