[QUOTE=TheJudger;266940]I'll try to remove/replace some of them in my official version (e.g. optional parameters for debuging, etc.)
[/QUOTE]

Oliver, should I continue posting code here or should I pm them to you. My current code has bare minimum of the changes against 0.17 right now so it should be easy to merge them in. I also have some other ideas and also could help with making it more readable.

I ran a quick test looking for multiple factors, seemed to work as expected:[code]got assignment: exp=999903251 bit_min=1 bit_max=67
tf(999903251, 1, 67, ...);
k_min = 0
k_max = 73794115801
Using GPU kernel "71bit_mul24"
class | candidates | time | avg. rate | SievePrimes | ETA | avg. wait
1/4620 | 2.98M | 0.114s | 26.16M/s | 200000 | n.a. | 371us
Result[00]: M999903251 has a factor: 1999806503
1884/4620 | 2.98M | 0.115s | 25.93M/s | 166923 | n.a. | 395us
Result[00]: M999903251 has a factor: 2347679090418412249
3153/4620 | 3.10M | 0.116s | 26.69M/s | 143668 | n.a. | 834us
Result[00]: M999903251 has a factor: 135710897421958333087
4609/4620 | 2.98M | 0.111s | 26.86M/s | 161503 | n.a. | 631us
found 3 factor(s) for M999903251 from 2^ 1 to 2^67 [mfaktc 0.17.1-Win !!!TEST!!!
apsen 71bit_mul24]
tf(): total time spent: 2m 48.483s[/code]

[QUOTE=James Heinrich;266951]I ran a quick test looking for multiple factors, seemed to work as expected:[code]got assignment: exp=999903251 bit_min=1 bit_max=67
tf(999903251, 1, 67, ...);
k_min = 0
k_max = 73794115801
Using GPU kernel "71bit_mul24"
class | candidates | time | avg. rate | SievePrimes | ETA | avg. wait
1/4620 | 2.98M | 0.114s | 26.16M/s | 200000 | n.a. | 371us
Result[00]: M999903251 has a factor: 1999806503
1884/4620 | 2.98M | 0.115s | 25.93M/s | 166923 | n.a. | 395us
Result[00]: M999903251 has a factor: 2347679090418412249
3153/4620 | 3.10M | 0.116s | 26.69M/s | 143668 | n.a. | 834us
Result[00]: M999903251 has a factor: 135710897421958333087
4609/4620 | 2.98M | 0.111s | 26.86M/s | 161503 | n.a. | 631us
found 3 factor(s) for M999903251 from 2^ 1 to 2^67 [mfaktc 0.17.1-Win !!!TEST!!!
apsen 71bit_mul24]
tf(): total time spent: 2m 48.483s[/code][/QUOTE]

I wonder if you know the case where multiple factors will fall within the same class...

[QUOTE=apsen;266953]I wonder if you know the case where multiple factors will fall within the same class...[/QUOTE]I haven't come across any multiple-factor exponents with even the same number of bits or digits in different factors. But, I should be able to dig around in the PrimeNet list of known factors and come up with a list of "close" factor pairs. I don't know how close the two factors have to be to be in the same class...?

[QUOTE=James Heinrich;266957] I don't know how close the two factors have to be to be in the same class...?[/QUOTE]
The single assignment is divided into 4620 classes. I'm not sure how the sieving works but I would guess that it assigns candidates sequentially...

To be honest I doubt anyone would be able to trigger any bugs related to absence of atomics intentionally.

For example difference between my last two versions (assuming candidates are fed sequentially) deals with odds of two factors in the same assignment (and if you allow mfaktc to split them that would mean at the same bit level) fall close enough to fall into 1/4620 of the whole range but further apart then 1/4620/block_count and the streams processing them run at the same time and then multiply this probability by 1/threads_per_block.

Does anyone care to estimate a number to that.

Of course there could be some other bug unrelated to the use of atomics that makes it fail it every single time but at least we could exclude the later part (every single time, that is) due to the fact that we have run successful selftests. Was this confusing enough? :-)

Methinks that if you want to excite this problem, the easiest way is going to be to construct something....

[QUOTE=James Heinrich;266957]I should be able to dig around in the PrimeNet list of known factors and come up with a list of "close" factor pairs.[/QUOTE]I just tested this list of known multi-factor exponents, and they all found multiple factors real close together, but never in the same class, almost always 1 class apart (with a suspiciously large number of them found in classes 3 and 4?):[code]Factor=1008857,1,23
Factor=1040597,1,23
Factor=1048213,1,27
Factor=1053809,1,27
Factor=1153967,1,25
Factor=1198247,1,25
Factor=1305607,1,28
Factor=1308497,1,27
Factor=1357351,1,25
Factor=1380949,1,25
Factor=1398701,1,24
Factor=1443257,1,24
Factor=1485017,1,24
Factor=1490717,1,24
Factor=1516421,1,24
Factor=1518071,1,27
Factor=1519277,1,24
Factor=1527857,1,24
Factor=1564421,1,24
Factor=1566811,1,25
Factor=1588757,1,24
Factor=1604297,1,24
Factor=1613057,1,24
Factor=1655897,1,24
Factor=1677787,1,25
Factor=1678877,1,24
Factor=1684937,1,24
Factor=1715717,1,24
Factor=1719547,1,25
Factor=1735421,1,24[/code]I guess I'll dig up some more to try...

[QUOTE=Christenson;266967]Methinks that if you want to excite this problem, the easiest way is going to be to construct something....[/QUOTE]

I'm not aware of any problem with mkfaktc171apsen code so I do not know what could be constructed.

mkfaktc17apsen does have a problem. And if we recompile the code with custom number of classes and threads based on chosen exponent and run it with custom number of streams and sieve level we should be able to guaranty that specific candidates will get processed by conflicting threads. But then we would still have to deal with uncertainty of thread scheduling...
It is probably easier to prove the problem mathematically then to actually trigger it...

[QUOTE=James Heinrich;266969]I just tested this list of known multi-factor exponents, and they all found multiple factors real close together, but never in the same class, almost always 1 class apart (with a suspiciously large number of them found in classes 3 and 4?):
...
I guess I'll dig up some more to try...[/QUOTE]

Thanks, I appreciate the effort.

If you'd like I could recompile the program without MORE_CLASSES option. This
would reduce the number of classes to 420.
You could also play with sieve level to force specific candidates to go into different threads.

[QUOTE=apsen;266971]If you'd like I could recompile the program without MORE_CLASSES option. This would reduce the number of classes to 420.[/QUOTE]Sounds like a plan. And then you should be able to quickly test it yourself, since I've given you a list of likely assignments that could probably find 2 factors in the same class.

[QUOTE=apsen;266970]I'm not aware of any problem with mkfaktc171apsen code so I do not know what could be constructed.

mkfaktc17apsen does have a problem. And if we recompile the code with custom number of classes and threads based on chosen exponent and run it with custom number of streams and sieve level we should be able to guaranty that specific candidates will get processed by conflicting threads. But then we would still have to deal with uncertainty of thread scheduling...
It is probably easier to prove the problem mathematically then to actually trigger it...[/QUOTE]

It often is easier to prove a problem exists than reliably trigger it...but the construction I would use would work like this:
Notice that we are a) sieving for candidates of a certain form, and b) running them through a large, relatively slow expression in parallel.

Now, I'm willing to temporarily introduce a "bug" in the program to determine whether a problem exists. What if the exponent had several factors [e.g. look up the exponent "god" was using, or look through the operation Billion Digits web page] and, in addition, the CPU sieving process just "got lucky" and included them all in the same class, preferably one right after another? This is the statistically unlikely construction we are searching for.

However, I'd also like to point out that in my practical mfaktc work, actually finding a factor is relatively rare, and finding two within a bit level is definitely rare, though not unknown: [url]http://www.mersenneforum.org/showpost.php?p=265202&postcount=179[/url] Therefore, detecting the problem of a collision somewhat after not quite reporting correct results isn't an unreasonable course of action. The user will be able to re-run a more careful, if slower, TF program over a very narrow range quickly and get the correct results. Something very similar happens when factors are reported to the server and the server verifies them with much less effort than that required to find them in the first place.