[QUOTE=Rodrigo;345171]
I plead temporary insanity.
[/QUOTE]
Good that it's only temporary :lol:

[QUOTE=Rodrigo;345171]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. :chevy: 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[/QUOTE]


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.

[QUOTE=Bdot;345106]...
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 ... [/QUOTE]
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(:mike:) in the affected candidates. Nothing to lose sleep over. :razz:

/Göran

[QUOTE=Axelsson;345377]Even at a probability of 1 in 256 (worst case) to retest these factors is not worth the time.[/QUOTE]

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

[QUOTE=Bdot;345452]But you need to keep going and find another bug :smile:[/QUOTE]
I'm trying, but mfakto runs so stable and fast now. My production went up with [SIZE=3]50%[/SIZE] with the new software. :tu:

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

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).

[QUOTE=LaurV;346658]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).[/QUOTE]

Got another one I see, nice :razz:


[SIZE="1"](no bother, but I am still curious about [URL="http://mersenneforum.org/showpost.php?p=344429&postcount=828"]this[/URL] only if you have time... two quick ones (low bit level I guess) is fine...)[/SIZE]

[QUOTE=kracker;346661]Got another one I see, nice :razz:


[SIZE=1](no bother, but I am still curious about [URL="http://mersenneforum.org/showpost.php?p=344429&postcount=828"]this[/URL] only if you have time... two quick ones (low bit level I guess) is fine...)[/SIZE][/QUOTE]
I already replied to that (not only once) in the [URL="http://mersenneforum.org/showpost.php?p=344607&postcount=840"]subsequent[/URL] 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... :razz:

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

[QUOTE=LaurV;346658]is there any "less classes" version of mfakto available? [/QUOTE]
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.

OpenCL 2.0 [URL="http://www.khronos.org/opencl/"]announced[/URL]... see anything interesting? :smile:

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