mfaktc: a CUDA program for Mersenne prefactoring - Page 112

Dubslow · 2011-09-25, 06:12

I had a factor a couple of days ago (http://www.mersenne.org/report_expon...xp_lo=55343303) that was reported as a TF factor, and I used the default mfaktc output. Unfortunately, I clear my results file each time, so I don't think I can see what the format was, unless I can do some sort of a system restore on an individual file. The My Results page has the following line:

Code:

Manual testing	55343303	F	2011-09-19 17:20	2.8	1386725197912266966337	 5.3208

Could it be you had a P-1 assignment reserved on the exponent, as well as a TF assignment?

Edit: System restore won't work, not enough resolution from restore points.

Dubslow · 2011-09-25, 06:21

Got the format. Tested M1000033 from 22-23 bits, (http://www.mersenne.org/report_factors/?exp_lo=1000033)

and got the following output from mfaktc:

Code:

M1000033 has a factor: 6000199
found 1 factor(s) for M1000033 from 2^22 to 2^23 (partially tested) [mfaktc 0.17-Win 75bit_mul32]

Dubslow · 2011-09-25, 06:54

I think I've come to another conclusion, about the slowdowns I've sometimes experienced with mfaktc. I've been recently using CUDALucas, which has run fine without slowdowns. I stopped that and started mfaktc a few times for the above testing (over the course of not more than 5 mins) and then I tried to start it again for a third time, and then everything slowed down to half speed, including CUDALucas. This leads me to believe it's something about mfaktc causing the slowdown, because in the few minutes I was doing nothing else besides web browsing. Thoughts?

apsen · 2011-09-25, 14:05

Quote:

Originally Posted by Prime95

I think if any manual results lines contain mfaktc then the result is attributed to TF

Looking at the output of manual result submission it seems like the code to parse factors may be not application specific - there are lines for no factors found for different apps but only one for factors found:

Code:

No factor lines found: 0
Mfaktc no factor lines found: 0
Mfakto no factor lines found: 0
Factors found: 1
Processing result: M1000033 has a factor: 6000199
Error code: 40, error text: Factoring result for M1000033 was not needed
P-1 lines found: 0
LL lines found: 0
Mlucas lines found: 0
Glucas (G29) lines found: 0
Glucas lines found: 0
MacLucasFFTW lines found: 0
CUDALucas lines found: 0
ECM lines found: 0

And this time I've inserted mfaktc into the submitted line like this:

Code:

M1000033 has a factor: 6000199 [mfaktc 0.17-Win apsen barrett79_mul32]

Dubslow · 2011-09-25, 17:06

If you use a format like that it should work fine for future factors.
Does this also mean that your mfaktc output isn't the same as mine?

James Heinrich · 2011-09-25, 18:38

Hacking the output of the various TF programs won't help anything if the PrimeNet parser isn't set up to handle them. And if it's changed to handle the new format, then it could just as easily be changed to correctly handle the current results formats.

While I don't particularly support each programmer making up their own variations to results.txt output, I would heartily welcome an "official" revision to the output specs, to which all the programs (Prime95, mfaktc, etc) could/should upgrade. Something that includes some additional useful information in an easily-parsed format, e.g.

Code:

M10906243 has a factor: 23620567217973346633 [TF;64;65;mfaktc 0.18-pre1-Win 71bit_mul24]
M47575691 has a factor: 1175429360870558287187321 [PM1;520000;12480000;Prime95 26.6b1 x64]

(including TF/P1/ECM; bit-range for TF or B1/B2 for P-1/ECM; software+version) in the above examples.

Dubslow · 2011-09-25, 19:52

That's a great idea.

apsen · 2011-09-26, 20:02

Quote:

Originally Posted by James Heinrich

While I don't particularly support each programmer making up their own variations to results.txt output, I would heartily welcome an "official" revision to the output specs, to which all the programs (Prime95, mfaktc, etc) could/should upgrade.

I'm in it to fix the "official" version of mfaktc in case the problem is in it. But if primenet does not actually expect factors from mfaktc then there's nothing to do until primenet is fixed...

Dubslow · 2011-09-26, 20:42

Like I said, the default output for me works fine with PrimeNet. So either you have some different version, or something got corrupted somewhere.

Christenson · 2011-09-27, 00:59

Oliver ("The judger") needs to weigh in, but I do think this tacking on a bit of tag to the "factor found" lines will let the server side do its thing, eventually. The main bit of information I would want when finding factors is whether the bit level was completed or not.

Reporting factors hasn't been such an issue with me, because it happens infrequently, therefore somewheat incorrect handling (credit, etc) doesn't affect results much.

TheJudger · 2011-09-27, 10:56

Hi,

not a big deal to change the output style of "factor found" results but I'll do this only if the primenet servers handles them. If primenet can handle this I'll willing to release a quick fix for this (e.g. 0.17p1).

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.

Oliver

2011-09-25, 06:12	#1222
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 1C35₁₆ Posts	I had a factor a couple of days ago (http://www.mersenne.org/report_expon...xp_lo=55343303) that was reported as a TF factor, and I used the default mfaktc output. Unfortunately, I clear my results file each time, so I don't think I can see what the format was, unless I can do some sort of a system restore on an individual file. The My Results page has the following line: Code: Manual testing 55343303 F 2011-09-19 17:20 2.8 1386725197912266966337 5.3208 Could it be you had a P-1 assignment reserved on the exponent, as well as a TF assignment? Edit: System restore won't work, not enough resolution from restore points. Last fiddled with by Dubslow on 2011-09-25 at 06:17

2011-09-25, 06:21	#1223
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 1110000110101₂ Posts	Got the format. Tested M1000033 from 22-23 bits, (http://www.mersenne.org/report_factors/?exp_lo=1000033) and got the following output from mfaktc: Code: M1000033 has a factor: 6000199 found 1 factor(s) for M1000033 from 2^22 to 2^23 (partially tested) [mfaktc 0.17-Win 75bit_mul32]

2011-09-25, 18:38	#1227
James Heinrich "James Heinrich" May 2004 ex-Northern Ontario 11·311 Posts	Hacking the output of the various TF programs won't help anything if the PrimeNet parser isn't set up to handle them. And if it's changed to handle the new format, then it could just as easily be changed to correctly handle the current results formats. While I don't particularly support each programmer making up their own variations to results.txt output, I would heartily welcome an "official" revision to the output specs, to which all the programs (Prime95, mfaktc, etc) could/should upgrade. Something that includes some additional useful information in an easily-parsed format, e.g. Code: M10906243 has a factor: 23620567217973346633 [TF;64;65;mfaktc 0.18-pre1-Win 71bit_mul24] M47575691 has a factor: 1175429360870558287187321 [PM1;520000;12480000;Prime95 26.6b1 x64] (including TF/P1/ECM; bit-range for TF or B1/B2 for P-1/ECM; software+version) in the above examples.

2011-09-27, 10:56	#1232
TheJudger "Oliver" Mar 2005 Germany 10001010111₂ Posts	Hi, not a big deal to change the output style of "factor found" results but I'll do this only if the primenet servers handles them. If primenet can handle this I'll willing to release a quick fix for this (e.g. 0.17p1). 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. Oliver Last fiddled with by TheJudger on 2011-09-27 at 10:58

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
mfakto: an OpenCL program for Mersenne prefactoring	Bdot	GPU Computing	1676	2021-06-30 21:23
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

2011-09-25, 06:54	#1224
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3×29×83 Posts	I think I've come to another conclusion, about the slowdowns I've sometimes experienced with mfaktc. I've been recently using CUDALucas, which has run fine without slowdowns. I stopped that and started mfaktc a few times for the above testing (over the course of not more than 5 mins) and then I tried to start it again for a third time, and then everything slowed down to half speed, including CUDALucas. This leads me to believe it's something about mfaktc causing the slowdown, because in the few minutes I was doing nothing else besides web browsing. Thoughts?

2011-09-25, 17:06	#1226
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3×29×83 Posts	If you use a format like that it should work fine for future factors. Does this also mean that your mfaktc output isn't the same as mine?

2011-09-25, 19:52	#1228
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 3×29×83 Posts	That's a great idea.

2011-09-26, 20:42	#1230
Dubslow Basketry That Evening! "Bunslow the Bold" Jun 2011 40<A<43 -89<O<-88 1110000110101₂ Posts	Like I said, the default output for me works fine with PrimeNet. So either you have some different version, or something got corrupted somewhere.

2011-09-27, 00:59	#1231
Christenson Dec 2010 Monticello 5×359 Posts	Oliver ("The judger") needs to weigh in, but I do think this tacking on a bit of tag to the "factor found" lines will let the server side do its thing, eventually. The main bit of information I would want when finding factors is whether the bit level was completed or not. Reporting factors hasn't been such an issue with me, because it happens infrequently, therefore somewheat incorrect handling (credit, etc) doesn't affect results much.