mfaktc: a CUDA program for Mersenne prefactoring - Page 194

TheJudger · 2013-01-17, 22:31

Hi Mike,

Quote:

Originally Posted by Xyzzy

We changed "GPUSieveSize" from the default 32 to 4 (!) and the system is much more responsive now. On the GT 430 the estimated GHz-d/day dropped from ~50 to ~45 but we figure letting it run most of the time, rather than on and off and on and off, it might have better throughput. (The GHz-d/day is also much more variable per output line, possibly because the GPU is being allowed to do other work?)

By setting "GPUSieveSize" to the lowest value are we messing anything up, or do we need to balance any other settings?

the settings in mfaktc.ini *should* not be able to screw up stuff (except for performance). And this is not a request to try to screw it up...
With the GHz-d/day measurement it is easy to compare throughput.

Oliver

garo · 2013-01-17, 22:59

If you reduce your GPUSieveSize, try reducing the GPUSieveProcessSize to 8 and optionally the GPUSievePrimes a bit. I got better throughput by reducing the GPUSieveProcessSize.

lycorn · 2013-01-19, 18:32

Quote:

Originally Posted by garo

I got better throughput by reducing the GPUSieveProcessSize.

Me too (GTX560Ti). But raised the GPUSieveSize from the default 64 to 128.
GPUSieveProcessSize is currently at 8, down from the default 16. That´s the setting that appears to work best on my system, at least for the mainstream exponents (GPUto72 tasks).

ixfd64 · 2013-01-19, 20:01

I reduced GPUSieveProcessSize from 16 to 8, and the time per iteration (factoring from 71 to 73 bits in the 60M range) dropped by about 0.15 seconds. It's not a huge difference, but I guess it all adds up. For the record, this was on my GTX 555.

Xyzzy · 2013-01-19, 22:02

We are using our GTX 660Ti as our primary display card. We stop factoring for games but we have found that by sacrificing a (small?) portion of the card's throughput we are able to use the computer for any other task, including 1080p videos, without any lag whatsoever.

Code:

# Minimum: GPUSieveSize=4
# Maximum: GPUSieveSize=128
# Default: GPUSieveSize=64

GPUSieveSize=4

# Minimum: GPUSieveProcessSize=8
# Maximum: GPUSieveProcessSize=32
# Default: GPUSieveProcessSize=16

GPUSieveProcessSize=8

We have the GT 430 running as well, with the default settings, but it is not hooked up to anything. The GT 430 is pretty slow but it only takes up one slot, only uses around 30 watts and it does not require special power connections.

We are now running the 64-bit binaries. The performance hit for doing so does not seem to be very much.

We purposely purchased the slowest 660Ti card that Asus makes. We have read that in some cases that the more highly (factory) overclocked cards are more likely to produce faulty calculations. By running our card at a lower load and temperature it possibly will be more reliable. Certainly, the fact that it affects our desktop experience in no way means we are willing to let it run continuously, which in the long term might result in a greater overall throughput than if we had to pause it here and there.

FWIW, our system, factoring on both video cards and running 4 instances of P-1 factoring on an i7 3770 CPU, draws 258 watts. (This does not count our display or speakers.)

Disclaimer: We are very sensitive to lag and it irks us greatly. (We are also severely impaired by flickering lights, like fluorescent lights.)

swl551 · 2013-01-19, 22:18

Observing this conversation I played around with

GPUSieveSize
and
GPUSieveProcessSize (everything other than default decreased throughput)

Setting GPUSieveSize=128 increased my GhzDays from 412 to 422

I confirmed increased throughput on both of my GTX570s running 0.20

(Win 7, 64bit and Win 7, 32bit PCs)

Batalov · 2013-01-19, 22:24

Code:

GPUSieveSize=4
...
GPUSieveProcessSize=8

It appears that GPUSieveProcessSize was meant to be a fraction of GPUSieveSize (and an integer fraction, according to the source or else the value is rejected). If it is larger, then its size probably doesn't matter.

Aillas · 2013-01-20, 14:31

Hi,

could someone please make a version of mfaktc 0.20 for cuda 4.0?

Thanks a lot.

Xyzzy · 2013-01-20, 18:19

Quote:

Observing this conversation I played around with

GPUSieveSize
and
GPUSieveProcessSize

FWIW, we played around with the values to find the most productive combo, and for both of our cards that combo was "GPUSieveSize=128" and "GPUSieveProcessSize=8".

YMMV

Chuck · 2013-01-20, 19:20

Quote:

Originally Posted by Xyzzy

FWIW, we played around with the values to find the most productive combo, and for both of our cards that combo was "GPUSieveSize=128" and "GPUSieveProcessSize=8".

YMMV

Same here with GTX 580. Those two changes increased my GPU utilization from 98% to 99% and raised the GHz-d/day from 431 to 435. Extremely minor video lag which doesn't bother me.

Aramis Wyler · 2013-01-20, 20:21

Same here as well on a gtx480. Increasing the GPUSieveSize from 64 to 128 increased ghz days from ~388.4 (wobbly) to a locked on 395.00. Changing the GPUSieveProcessSize from 16 to 32 tropped ghzdays to 295, and changin it to 8 put us back to ~395 but it was wobbly. I set it back to the default 16.

I am tempted to muck with the GPUSievePrimes number again on these new settings. I had gained about 3 ghz days by dropping it from 82486 to 70000 (gpu uses 69941 at that setting).

These numbers are for doing TF in the 61M range.

2013-01-19, 22:02	#2128
Xyzzy "Mike" Aug 2002 2·23·179 Posts	We are using our GTX 660Ti as our primary display card. We stop factoring for games but we have found that by sacrificing a (small?) portion of the card's throughput we are able to use the computer for any other task, including 1080p videos, without any lag whatsoever. Code: # Minimum: GPUSieveSize=4 # Maximum: GPUSieveSize=128 # Default: GPUSieveSize=64 GPUSieveSize=4 # Minimum: GPUSieveProcessSize=8 # Maximum: GPUSieveProcessSize=32 # Default: GPUSieveProcessSize=16 GPUSieveProcessSize=8 We have the GT 430 running as well, with the default settings, but it is not hooked up to anything. The GT 430 is pretty slow but it only takes up one slot, only uses around 30 watts and it does not require special power connections. We are now running the 64-bit binaries. The performance hit for doing so does not seem to be very much. We purposely purchased the slowest 660Ti card that Asus makes. We have read that in some cases that the more highly (factory) overclocked cards are more likely to produce faulty calculations. By running our card at a lower load and temperature it possibly will be more reliable. Certainly, the fact that it affects our desktop experience in no way means we are willing to let it run continuously, which in the long term might result in a greater overall throughput than if we had to pause it here and there. FWIW, our system, factoring on both video cards and running 4 instances of P-1 factoring on an i7 3770 CPU, draws 258 watts. (This does not count our display or speakers.) Disclaimer: We are very sensitive to lag and it irks us greatly. (We are also severely impaired by flickering lights, like fluorescent lights.) Attached Thumbnails

2013-01-19, 22:18	#2129
swl551 Aug 2012 New Hampshire 2³·101 Posts	Setting GPUSieveSize=128 on my GTX 570 Observing this conversation I played around with GPUSieveSize and GPUSieveProcessSize (everything other than default decreased throughput) Setting GPUSieveSize=128 increased my GhzDays from 412 to 422 I confirmed increased throughput on both of my GTX570s running 0.20 (Win 7, 64bit and Win 7, 32bit PCs) Last fiddled with by swl551 on 2013-01-19 at 22:28

2013-01-19, 22:24	#2130
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2·47·101 Posts	Code: GPUSieveSize=4 ... GPUSieveProcessSize=8 It appears that GPUSieveProcessSize was meant to be a fraction of GPUSieveSize (and an integer fraction, according to the source or else the value is rejected). If it is larger, then its size probably doesn't matter.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
mfakto: an OpenCL program for Mersenne prefactoring	Bdot	GPU Computing	1676	2021-06-30 21:23
The P-1 factoring CUDA program	firejuggler	GPU Computing	753	2020-12-12 18:07
gr-mfaktc: a CUDA program for generalized repunits prefactoring	MrRepunit	GPU Computing	32	2020-11-11 19:56
mfaktc 0.21 - CUDA runtime wrong	keisentraut	Software	2	2020-08-18 07:03
World's second-dumbest CUDA program	fivemack	Programming	112	2015-02-12 22:51

2013-01-17, 22:59	#2125
garo Aug 2002 Termonfeckin, IE 2²·691 Posts	If you reduce your GPUSieveSize, try reducing the GPUSieveProcessSize to 8 and optionally the GPUSievePrimes a bit. I got better throughput by reducing the GPUSieveProcessSize.

2013-01-19, 20:01	#2127
ixfd64 Bemusing Prompter "Danny" Dec 2002 California 5×479 Posts	I reduced GPUSieveProcessSize from 16 to 8, and the time per iteration (factoring from 71 to 73 bits in the 60M range) dropped by about 0.15 seconds. It's not a huge difference, but I guess it all adds up. For the record, this was on my GTX 555.

2013-01-20, 14:31	#2131
Aillas Oct 2002 France 3³·5 Posts	Hi, could someone please make a version of mfaktc 0.20 for cuda 4.0? Thanks a lot.

2013-01-20, 20:21	#2134
Aramis Wyler "Bill Staffen" Jan 2013 Pittsburgh, PA, USA 2³·53 Posts	Same here as well on a gtx480. Increasing the GPUSieveSize from 64 to 128 increased ghz days from ~388.4 (wobbly) to a locked on 395.00. Changing the GPUSieveProcessSize from 16 to 32 tropped ghzdays to 295, and changin it to 8 put us back to ~395 but it was wobbly. I set it back to the default 16. I am tempted to muck with the GPUSievePrimes number again on these new settings. I had gained about 3 ghz days by dropping it from 82486 to 70000 (gpu uses 69941 at that setting). These numbers are for doing TF in the 61M range.