We had this discussion few times in the past, I still remember [URL="http://www.mersenneforum.org/showthread.php?p=299505"]the last try[/URL]. It turns out that one would need a good way to eliminate the algebraic and intrinsic factors first, and do the sieving then. It is not difficult to change the mfaktc if one don't care about missing some factors, and the goal is just to find some other factors, no matter if they are in order or not. If one is going to make a new mfaktc, I would suggest introducing a new flag, like "-allowcomposite" or whatever, and the program would not check if the exponent is composite when the flag is present (but still check if it is odd, otherwise we have trouble with 3,5 (mod 8), and more classes to parse, different logic). Modifying the program to always allow composite exponents could result in futile work when someone makes a typo, for example. What I want to say, is that is better to keep the check for primality on the default options of the program, but allow odd composites if some "special" flag is present. For these odd composite, the program would work exactly the same way as it does for prime exponents. Of course, it will miss the algebraic factors.

[QUOTE=akruppa;332632]Correct, this is of no value to GIMPS as a prime search project. Some people, including me, sometimes do look for factors of large 2^n-1 numbers, and it would be awesome to be able to use GPUs for the job. If factoring composite exponents is permitted, I think it should be done with minimal developer effort, even if that neglects some relatively easy optimizations that could be done, precisely because factoring such numbers is not the main purpose of mfakc.[/QUOTE]

True, there is no harm in giving mfaktc the ability to TF composite exponents. Perhaps there could be a switch that makes it skip the primality check.

[QUOTE=ixfd64;332769]True, there is no harm in giving mfaktc the ability to TF composite exponents. Perhaps there could be a switch that makes it skip the primality check.[/QUOTE]

I'm not familiar with the mfaktc code at all, or I could probably make the changes myself. If the changes to allow composite exponents are implemented, maybe I can add some code to skip useless classes according to quadratic character, if such changes are well-localized.

Remove the check for prime exponent is easy, aswell as the classes stuff is easy, too, as long as we'll keep 420/4620 classes. But the (CPU-)sieve needs to be reworked, currently there is no code to remove primes from the sieve base, but this would be needed for composite exponents, otherwise there will be an endless loop in the offset calculation. Anyway, it seems feasible if someone wants to do so.

Oliver

Btw, what is the relationship between mfaktc and mmff? I haven't kept up with developments, and digging through a 100-page thread seems a daunting task... is one a superset of the other?

[QUOTE=akruppa;332861]Btw, what is the relationship between mfaktc and mmff? I haven't kept up with developments, and digging through a 100-page thread seems a daunting task... is one a superset of the other?[/QUOTE]

mfaktc is for TF'ing GIMPS-class numbers, and mmff is for double Mersenne and Fermat numbers. The mmff source code is largely based on that of mfaktc.

[QUOTE=ixfd64;332864]mfaktc is for TF'ing GIMPS-class numbers, and mmff is for double Mersenne and Fermat numbers. The mmff source code is largely based on that of mfaktc.[/QUOTE]

Although I think the gpu sieving code now in mfaktc was originally in mmff. Just to be confusing.

So finally I got my hands on a Titan (temporary), too.
Seems that I've underestimated to boost clock. So with stock clockrates the Titan is the fastest GPU for mfaktc, but it wins only by a small margin compared to the old GTX 580.

There [B][U]might[/U][/B] be a very small performance increase for the Titan once I test the new [I]funnel shift[/I] instruction. The barrett_{76,77,79} kernels don't make use of multiword shifts expect for the initialization but barrett_{87,88,92} do a multiword shift in each iteration.

Oliver

[QUOTE=TheJudger;333722]So finally I got my hands on a Titan (temporary), too.[/QUOTE]Would you mind sending me a benchmark? I'd feel better about my mfaktc performance chart ratios if I had more than 1 benchmark to go on.

Yepp, I was right: the funnel shift gives a small advantage.

A quick hack using stock mfaktc 0.20 code and barrett_87 for testing on a Tesla K20 (CUDA 5.0)
[CODE]
base 300.8 GHzd/d
added code generation for sm_35 298.1 GHzd/d
using funnel shift in barrett_87 308.9 GHzd/d
[/CODE]

Using funnel shift in the initialization phase causes a very small slowdown!

So barrett_87 beats now barrett_77, only barett_76 is faster on GK110.
For the current TF wavefront the impact is even lower because we do TF to 2[SUP]73[/SUP] there. But hey, it is an improvement...

Oliver

We have been messing around with the extremely confusing "[URL="http://www.evga.com/precision/"]EVGA Precision X[/URL]" software. There are so many options it is ridiculous!

Anyways, we were messing with the memory clock setting. By default on our GTX690 it is 1502.3MHz. We lowered this to 1252.8MHz and the performance did not change!

The temperatures and voltages do not change, either.

Does this make sense?

Would running the memory slower like that make it less likely to have a flipped bit?

FWIW, the GPU clock is 1058.2MHz. The performance changes a lot when we mess around with that!

:mike: