The GPUs are in fast boxes. 3770, 3960x, etc. Not the best bang for the buck, but I figure I have a finite amount of wall time to wait on results. I could use a net and fish for herring to feed the village or have a blast sportfishing. I run as many instances as it takes to saturate the GPU. I use minimal sieve primes. It makes the GPU work harder, but that is sometimes what it takes to get to 98%. I run two instances of prime95 with the extra CPU cycles at the same time. Just looking at counts in results files over time, for similar exponent sizes and bit depths the 580 is 2 to 3 times faster than the 7970 at least where I am currently looking. I need to calculate a GHxD/D box metric. My next dream machine will have a 590. I retire older boxes when the cost of the electricity to run them would be better spent on a faster box. Only you folks would believe the heat issues with this much hardware.

[QUOTE=dbaugh;316977]The GPUs are in fast boxes. 3770, 3960x, etc. Not the best bang for the buck, but I figure I have a finite amount of wall time to wait on results. I could use a net and fish for herring to feed the village or have a blast sportfishing. I run as many instances as it takes to saturate the GPU. I use minimal sieve primes. It makes the GPU work harder, but that is sometimes what it takes to get to 98%. I run two instances of prime95 with the extra CPU cycles at the same time.[/QUOTE]
Same here. I have two boxes with 2700Ks and two with 3770Ks. I set SP min to 2000 and let the system autoadjust. It takes 6 instances plus P95 running to balance everything. I could stop P95 and run one or two more instances, but I like to run P-1 also. I also have one AMD six-core 1055T with a 580. It was my first 580 system and I went cheaper to save some $$, but that AMD CPU can hardly max out the 580. I can't run P95 on that system or it's unusable and GHZ-days drops down too much. My next purchase is for another 3770K and a MB to match so I can max that system too.

[QUOTE]Just looking at counts in results files over time, for similar exponent sizes and bit depths the 580 is 2 to 3 times faster than the 7970 at least where I am currently looking. I need to calculate a GHxD/D box metric.[/QUOTE]
I'm going to run some benchmarks over the next few days to update James' site for 580s. In reality, I don't think any AMD cards will outpace the 580 because mfakto doesn't run as efficiently as mfaktc. It takes a lot more CPU power to drive AMD cards, which is why I was curiuos what your actual GHz-days/day output was on the 7970. I would like to get a 7990 to run some comparisons, but $1000 is a bit steep for testing.

[QUOTE]My next dream machine will have a 590. I retire older boxes when the cost of the electricity to run them would be better spent on a faster box. Only you folks would believe the heat issues with this much hardware.[/QUOTE]

I have one 590 and I'm not reallIy impressed. It's running mmff-gfn right now. It's two 580s in one, but is not anywhere near what you'd get from two 580s. Granted, in your 3960x you might get better results as I only have a 3770k @ 4.5GHz to drive it. I think it has a lot to do with the fact that it's only PCIe 2.0. Also, 590s are clocked down due to constraints and have limited overclocking capability. If you want to swap two 580s for a 590, I'm game.

I've set up my CUDA environment, but I get the following errors when I try to compile mfaktc 0.19: [see attachment]

Anyone know what I'm doing wrong?

Edit: I've changed the item type to CUDA C/C++ and the platform to VC90, and I've also installed Visual C++ 2008. However, it's still complaining of an issue with the "atomicInc" function. Anyone know how to resolve this?

I guess the issue with the "atomicInc" comes from the GPU code, right?
Change the target code to at least sm_11 (sm_10 doesn't support atomicInc).

In the mfaktc-makefiles for Windows it is this:
--generate-code arch=compute_11,code=sm_11 --generate-code arch=compute_20,code=sm_20 --generate-code arch=compute_30,code=sm_30
which is passed to the nvcc.

Oliver

Suggestions for a new default status line in mfaktc 0.20, please!

Using the default status line from 0.19 as baseline:[LIST][*][B]keep line width below 80 chars[/B][*]remove "candidates"[*]remove "avg. rate"[*]add "percent complete"[*]remove "class ID" (unsure)[*]add "GHz-days/day (GHz)" (unsure)[/LIST]
Oliver

[QUOTE=TheJudger;320798]Suggestions for a new default status line in mfaktc 0.20, please![/QUOTE]This is what I've been using since it became configurable:[code]ProgressHeader= Date-Time Pct ETA | Exponent Bits | GHz-d/day Sieve Wait
ProgressFormat=%d %T %p %e | %M %l-%u | %g %s %W[/code]

I think the current default output is good as is, except maybe "SievePrimes" is a little long. Just "Sieve" is adequate.

[QUOTE=ixfd64;320804]I think the current default output is good as is, except maybe "SievePrimes" is a little long. Just "Sieve" is adequate.[/QUOTE]

Not very descriptive. Perhaps "SieveSize"? It's shorter than SievePrimes, though not by much.

[QUOTE=James Heinrich;320799]This is what I've been using since it became configurable:[code]ProgressHeader= Date-Time Pct ETA | Exponent Bits | GHz-d/day Sieve Wait
ProgressFormat=%d %T %p %e | %M %l-%u | %g %s %W[/code][/QUOTE]

Here's mine, not that I'm stuck on it. I did tweak it to get the columns aligned-

[CODE]ProgressHeader= class | candidates | time | ETA | GHz-d/d | SievePrimes | CPU wait
ProgressFormat=%C/4620 | %n | %ts | %e |%g-d/d| %s | %W%%
[/CODE]

Add sieving with the GPU :razz: (I think this in the main point in going to 2.0 anyhow, but just want to state it clear, so you understand what I need, hehe, so I can free my CPU cores). :wink: Eagerly waiting for the beta version.

:goodposting::w00t: Right On!