mfakto: an OpenCL program for Mersenne prefactoring - Page 80

Bdot · 2013-07-03, 20:01

Quote:

Originally Posted by Rodrigo

I plead temporary insanity.

Good that it's only temporary

kladner · 2013-07-04, 16:14

Quote:

Originally Posted by Rodrigo

How weird. My backup of the original mfakto.ini shows exactly what you give there.

The only way that I can think of that could lead to the value changing in the comments line, would be if I had made the change manually to the comments line and never actually adjusted the real setting to the 24 that @kracker had recommended. (In which case I never changed it to OR from 16.)

Although I have no memory of it, this is entirely possible: my wife and I spent several days doing some intense (physical and Web) car shopping.

I can picture hurriedly making this change on the way out to yet another auto dealership. This must be what happened, there's no other sensible explanation. I plead temporary insanity.

Rodrigo

I have found in the past, after the fact, that I had edited the comment line instead of the functional one. It's an easy slip to make.

Axelsson · 2013-07-05, 23:47

Quote:

Originally Posted by Bdot

...
What is the general opinion if any of the tests need to be repeated? I tried to come up with an estimate how "bad" the bug is ...

Even at a probability of 1 in 256 (worst case) to retest these factors is not worth the time.

I'm going to make a simplification and assume mfakto/mfaktc was used to raise the factoring limit one bit level for a start.
If in normal cases we have a probability on roughly 2% of finding a factor per bitlevel, rerunning the suspected factors gives a probability 2%/256 = 0.008% of finding a factor and eliminating that candidate.
To raise the factoring depth of half the candidates one step would take as long time as rerunning all the candidates but in that case we would have 2% probability to find a factor in half the number of candidates... that would be 128 times higher probability to find a factor when going deeper than rerunning the suspected candidates.

If my math is correct an error rate of 1/2 would make it break even between rerunning and ignoring it. This is in case the bug only affected one bitlevel.... how about if the assignment were over several bit levels?
It feels obvious that for two bitlevels an error rate of 1/4 would be break even...am I right?

So unless mfakto / mfaktc was used for more than 7 bitlevels (break even at eight) I would'nt recommend rerunning the factors. Factor hunting isn't finding anything critical, we just make it a bit more probable that the following LL-tests will find a prime, speeding up the project. Statistically, this bug has introduced a 0.4% speed penalty(

) in the affected candidates. Nothing to lose sleep over.

/Göran

Bdot · 2013-07-06, 19:32

Quote:

Originally Posted by Axelsson

Even at a probability of 1 in 256 (worst case) to retest these factors is not worth the time.

Thanks, Göran! I think, along with the fact that only few people used GPUSieveProcessSize=24, the effect of the bug is very little.

But you need to keep going and find another bug

Axelsson · 2013-07-07, 02:59

Quote:

Originally Posted by Bdot

But you need to keep going and find another bug

I'm trying, but mfakto runs so stable and fast now. My production went up with 50% with the new software.

It's a bit slow on lower bitlevels (2^66), runs really fast on double check assignments ( 200-210 GHzd/d ) and a bit slower on the LL front ( 140-170 GHzd/d ).
But then I haven't taken the time to optimize the settings in the ini-file for the different assignments.

/Göran

LaurV · 2013-07-18, 16:56

Overnight test: I am taking the 22420 exponents in 335M range from 65 to 66 bits. Testing a rig with 2xHD7970, 12 workers (is there any "less classes" version of mfakto available? so I won't need to start so many workers to max the GPUs? because this is wasting a lot of time printing, I think...-- it prints that line of text 960 times every 3 seconds!). With an average of 3.2 seconds per exponent, it would take about 20 hours. Stay away from 335M tonight (next 20 hours).

kracker · 2013-07-18, 17:17

Quote:

Originally Posted by LaurV

Overnight test: I am taking the 22420 exponents in 335M range from 65 to 66 bits. Testing a rig with 2xHD7970, 12 workers (is there any "less classes" version of mfakto available? so I won't need to start so many workers to max the GPUs? because this is wasting a lot of time printing, I think...-- it prints that line of text 960 times every 3 seconds!). With an average of 3.2 seconds per exponent, it would take about 20 hours. Stay away from 335M tonight (next 20 hours).

Got another one I see, nice

(no bother, but I am still curious about this only if you have time... two quick ones (low bit level I guess) is fine...)

LaurV · 2013-07-18, 17:35

Quote:

Originally Posted by kracker

Got another one I see, nice

(no bother, but I am still curious about this only if you have time... two quick ones (low bit level I guess) is fine...)

I already replied to that (not only once) in the subsequent posts. Currently is 13.6 which at the time of installation was a beta (didn't check AMD page after). Between 420 and 440 GHzD/D in LL/DC ranges. The drop (to 390) is normal, see following discussions.

P.S. finished 655 exponents and got 10 factors, which fits amazingly well in the theory about having 1 factor of 65 bits in every 65 or 66 exponents (this is "untouched domain", i.e no selective TF or P-1 was done to eliminate exponents, so the ratio should keep nicely). My hopes to infirm the theory are gone...

12:35 AM here. Going to bed... nighty night...

Bdot · 2013-07-18, 17:58

Quote:

Originally Posted by LaurV

is there any "less classes" version of mfakto available?

No, there's not. When I started the porting effort, I skipped that to save effort. Since then, the request for it was not overwhelming ...
You can probably save a few microseconds CPU time by trimming ProgressHeader and ProgressFormat to the absolute minimum you need (a fix single-letter string would be fastest) and setting Verbosity=0 to save another few lines output.

But I think that printing is not the majority of overhead - it's rather the per-class-initialization of the kernels. That is not solvable witht the current version of mfakto.

kracker · 2013-07-24, 19:24

OpenCL 2.0 announced... see anything interesting?

kracker · 2013-08-01, 19:59

Just a note that, on catalyst 13.8 beta mfakto does not run at all,at selftest the driver crashes and I have to hard reset.

2013-07-18, 16:56	#875
LaurV Romulan Interpreter Jun 2011 Thailand 2⁶×151 Posts	Overnight test: I am taking the 22420 exponents in 335M range from 65 to 66 bits. Testing a rig with 2xHD7970, 12 workers (is there any "less classes" version of mfakto available? so I won't need to start so many workers to max the GPUs? because this is wasting a lot of time printing, I think...-- it prints that line of text 960 times every 3 seconds!). With an average of 3.2 seconds per exponent, it would take about 20 hours. Stay away from 335M tonight (next 20 hours). Last fiddled with by LaurV on 2013-07-18 at 16:59

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
mfaktc: a CUDA program for Mersenne prefactoring	TheJudger	GPU Computing	3498	2021-08-06 21:07
gpuOwL: an OpenCL program for Mersenne primality testing	preda	GpuOwl	2719	2021-08-05 22:43
LL with OpenCL	msft	GPU Computing	433	2019-06-23 21:11
OpenCL for FPGAs	TObject	GPU Computing	2	2013-10-12 21:09
Program to TF Mersenne numbers with more than 1 sextillion digits?	Stargate38	Factoring	24	2011-11-03 00:34

2013-07-24, 19:24	#879
kracker "Mr. Meeseeks" Jan 2012 California, USA 2³·271 Posts	OpenCL 2.0 announced... see anything interesting?

2013-08-01, 19:59	#880
kracker "Mr. Meeseeks" Jan 2012 California, USA 2³×271 Posts	Just a note that, on catalyst 13.8 beta mfakto does not run at all,at selftest the driver crashes and I have to hard reset.