I tried it. And I have good and bad news :smile:

Good: RES[0] was always at least 1, so we'll always have notification that a factor was found.
Also good: The "factors" that appeared in the buffer were not scrambled - they either appeared correctly or not at all - except for the last factor that was incomplete a few times. So we'll always have at least one valid factor.

Even when increasing RES[0] in more than 1000 threads, the number of factors reported was always between 1 and 10. When less than 10 threads wrote their "factors", the result was consistently one factor found, the first factor was the only one reported and it was complete. Therefore we can assume that without atomics we will simply miss the second factor and never know there is a "twin".

Now the bad news: atomics don't seem to work reliably in OpenCL. I will seek help with AMD. When using atomic_inc, the reported number of factors was around 80% of the expected. And worst: when only two or three "factors" are written to the result buffer, only the first one arrives - just as without atomics.

Bdot:
From a pragmatics standpoint, where factors are found are reasonably rare (most bit levels don't find any), can we accept that the presence of a factor is a sign to re-run the bit level or class more carefully, possibly on the host CPU instead, since it doesn't happen often?

Not that I don't think atomics are worthwhile....I am just thinking that this may be the least price to pay in the absence of atomics.

[QUOTE=Christenson;267653]Bdot:
From a pragmatics standpoint, where factors are found are reasonably rare (most bit levels don't find any), can we accept that the presence of a factor is a sign to re-run the bit level or class more carefully, possibly on the host CPU instead, since it doesn't happen often?

Not that I don't think atomics are worthwhile....I am just thinking that this may be the least price to pay in the absence of atomics.[/QUOTE]

Well, I don't think people agree to re-run their tests on the CPU whenever a factor was found ... For the course of GIMPS (finding the next mersenne prime) this has no effect - we have one factor, so the mersenne number is not prime. Of course it would be better to have both factors.

I currently think the "problem" can be ignored. We will use atomics when available, and I will see that the OpenCL-atomics get fixed. Without (proper) atomics, we'll exclude the exponent from further prime-hunting with just one of two factors found. As most mersenne numbers have many more factors anyway, that should not be a big deal - am I wrong here?

I always seem to be TF'ing the mersenne numbers with one or no factors in a given bitlevel.

As for re-running a little bit of TF on the CPU, don't forget that a whole lot of sieving goes on on my CPU to support mfaktc at the moment. Therefore, as long as the process is automatic, I think it will go largely unnoticed. Particularly if only one class is re-run, it won't take long, just a few minutes out of the many days mfaktc/mfakto runs.

While it's (almost?) guaranteed that there will be another factor, the chance of it being in even the same bitlevel is low; in the same class very low (I haven't been able to find an example). If one factor is found and reported that is sufficient for GIMPS, and not much different from running mfaktc with [i]StopAfterFactor=2[/i] -- there might be another factor in the bitlevel that won't be found.

Decades from now, someone will undoubtedly run through the list of exponents that have only a small factor and use their 100-billion-exaflop GPU to TF them all to 2^100 in a short time, so I wouldn't worry too much about a "missed" factor, since we know almost for certain that there are still unfound factors.

My math skills are admittedly atrocious, but isn't the chance of twin factors in the same class something like (1/70)^2 * (1/4620)^2 = about 1:100,000,000,000 ?

[QUOTE=James Heinrich;267686]My math skills are admittedly atrocious, but isn't the chance of twin factors in the same class something like (1/70)^2 * (1/4620)^2 = about 1:100,000,000,000 ?[/QUOTE]

Quite obviously, if there are twin factors, the chance of them being in the same class is 1 in 4620.

Furthermore, you don't always search single bit levels, though I have to admit that the multi-bitlevel case is a rare one unless you really aim for it.

[QUOTE=ckdo;267692]Quite obviously, if there are twin factors, the chance of them being in the same class is 1 in 4620.[/QUOTE]Again, I admit I don't know much here, but isn't that kind of like saying "if there are twin factors in the same class, the chance of them being in the same class is 1 in 1"?

I figured that there's already a limited chance of there being multiple factors per bit-level, around (1 / <bitlevel>)^<factors in bitlevel> --- am I mistaken on this? That for 2^70 TF, you'd have about 1:70 chance of 1 factor, 1:4900 chance of 2 factors, 1:343000 chance of 3 factors, etc? :unsure:

Would it be hard to extend mfaktc to larger exponents? It could be very useful for people who wish to search for factors of double Mersenne numbers.

that question has been answered a few page earlier : too much rewrite.

What's the form of a double-mersenne number?

MM2,MM3,MM7, MM127 etc