mersenneforum.org - mfaktc: a CUDA program for Mersenne prefactoring

mersenneforum.org (https://www.mersenneforum.org/index.php)

- GPU Computing (https://www.mersenneforum.org/forumdisplay.php?f=92)

- - mfaktc: a CUDA program for Mersenne prefactoring (https://www.mersenneforum.org/showthread.php?t=12827)

[QUOTE=LaurV;296652]I think that the author is the one who can decide if he wants it to make it public or not. Of course I would like to have it, to play with it, but maybe he has a good reason why didn't make it public. It could be still [B]under test[/B], or under development,
[...][/QUOTE]

Yepp, it isn't very well tested. Without modifications in the sieve code I have to limit SievePrimes to very low values when small exponents are tested. Otherwise the code will just hang (endless loop in offset calculation).
So with such small SievePrimes it seems to work well but again: this is not tested very well.
There are two issues when the biggest prime is the sieve is greater or equal then the exponent to test:[LIST=1][*]remove the prime exponent from the list of primes used for sieving. (Candidates are 2kp+1 so they are never divisible by p. This causes the endless loop.)[*]offset calculation needs to take care that the primes used for sieving can be a factor of M[SUB][B]p[/B][/SUB]. This occurs as soon as the primes used for sieving are greater than 2[B]p[/B].[/LIST]So the simple solution is to limits SievePrimes in that way that the biggest prime in the sieve list is less than the exponent. :blush:

Another potential issue is the GPU code itself. Precalculation (mfaktc-0.18/src/tf_common.cu starting at line 89) might be too gready for small exponents. [I]Big[/I] bit_min with [I]small[/I] exponents need to be reviewed.

And another potential issue: floating point accuracy for approximation in the long divisions need to be checked for small exponents (small factor candidates).

Because there is only little use to do more TF on such small exponents this isn't high priority on my todo list, sorry!

Oliver

Taking 84M to 67 bits, just finished taking 334M up a bitlevel.
Edit: Taking 84M to 67 and finishing the other half of 334M to 66.

My first time...and not so lucky

Tinkering wth my GeForce 8400GS
Does that sound kinky?

Anyway getting suspicios errors:

[CODE]running a simple selftest...
ERROR: cudaGetLastError() returned 6: the launch timed out and was terminated[/CODE]
This is after about 45 seconds at which time the screen goes blank and then Windows7 64-bit pops up a window in the taskbar that says something like: Display Driver stopped responding and was recovered.

Only one time out of about 7 tries it did pass the selftest and then said it could not read the worktodo.txt file.

2 questions:

1. I assume it should be in the same directory as the mfaktc?
2. From the readme there is this sample line: Factor=bla,66362159,64,68
Is the bla, required?

Per James suggestion I changed Numstreams to 2 but my GUI is still quite laggy.

[QUOTE=petrw1;297209]Is the bla, required?[/QUOTE]Bla is not required. mfaktc is pretty good at ignoring invalid worktodo now, but the assignment key should either not be there at all, "N/A", or a 32-char hex string[code]Factor=66362159,64,68
Factor=N/A,66362159,64,68
Factor=6F466E3E1BCBC848ACA66E45ACBAC5FD,66362159,64,68[/code]

I'm sure you're aware, but the 8400 GS is a feeble card, depending on the CPU it's paired with it could potentially achieve [i]less[/i] combined TF throughput than just the CPU alone... :cry:

The #1 way to make compute 1.x cards usable with mfaktc is to change GridSize=[b]0[/b] (anything larger than that will lag noticeably). The values for streams are far less important.

[QUOTE=James Heinrich;297211]I'm sure you're aware, but the 8400 GS is a feeble card, depending on the CPU it's paired with it could potentially achieve [i]less[/i] combined TF throughput than just the CPU alone... :cry:
[/QUOTE]

Thanks...I suspected as much. I just wanted to see if I could get it to work.

It is paired with a i5-750 OC'd 3.20

[QUOTE=petrw1;297213]It is paired with a i5-750 OC'd 3.20[/QUOTE]Your [url=http://mersenne-aries.sili.net/throughput.php?cpu1=Intel%28R%29+Core%28TM%29+i5+CPU+750+%40+2.67GHz%7C256%7C8192&mhz1=3200]i5-750[/url] can do about 3.75GHz-days/day of TF. Your [url=http://mersenne-aries.sili.net/mfaktc.php?sort=ghdpd&noA=1]8400 GS[/url] can do about 3.1 or 2.4GHz-days/day (depending on the revision). Which means that if you spend any more than 82% or 64% of a single CPU core feeding mfaktc, you're losing throughput.

On my slower system I have an 8800GT. I've locked mfaktc on SievePrimes=5000, which isn't optimal for GPU throughput but leaves 90% of the CPU core free to work on P-1.

petrw1: the 8400GS might be too slow for real jobs but if you just want to see how/if mfaktc works it will still do the job. As James recommended: lower the GridSize, otherwise there is a high chance that you'll trigger the watchdog for blocked drivers on Windows, the 8400GS is really slow.

Oliver

[QUOTE=James Heinrich;297218]*SNIP*I've locked mfaktc on SievePrimes=5000, which isn't optimal for GPU throughput but leaves 90% of the CPU core free to work on P-1.[/QUOTE]

Mein Herr, could you (or another) explain what "SievePrimes" does? I assume (and cringe at the word) that it sieves the k values for, say, values that are divisible by 7 (6 mod 7 for exponents ending in 9), but I'm not sure. Also, please try to explain as simply as possible, I'm learning as I go :)
Thanks!
Johann

[QUOTE=c10ck3r;298009]Mein Herr, could you (or another) explain what "SievePrimes" does? I assume (and cringe at the word) that it sieves the k values for, say, values that are divisible by 7 (6 mod 7 for exponents ending in 9), but I'm not sure. Also, please try to explain as simply as possible, I'm learning as I go :)
Thanks!
Johann[/QUOTE]
It's the count of the number of primes to sieve n=2kp+1 with. The more primes you use in sieving, the more not-prime-n you eliminate, but of course the law of diminishing returns applies; the important fact is that this sieving-candidates is done on the CPU, while the actual trying-candidates happens on the GPU, so that the SP count is effectively how much work the CPU has to do before a candidate is sent to the GPU. If the CPU can't keep up with the GPU, lower sieve primes so it's doing less work; if the GPU can't keep up, increase SP so the CPU does more work.

Quick short reply

What is the “CPU Wait”? The bigger the % the worse the CPU is keeping up? Or is it the other way around?

Thanks