For reference, I figured I'd post some benchmark run times. We search for GFNs of the form b^N+1. N, by far, has the biggest impact on run time, although b does play a smaller role.

The lowest value of N that's currently being searched using GeneferCUDA is 262144 (2^18), and the largest we can reasonably search right now is 4194304 (2^22). So these are the expected run times for those values of N. Times are based on my GTX 460, which is maybe half the speed of the fastest GeForce GPU, and double the speed of the slowest GPU that can run GeneferCUDA. It's more or less dead center in the middle of the pack of potentially usable GPUs. In practice, it seems that most people have faster GPUs rather than slower, so for most people your run times should be lower than these benchmarks. If you happen to have access to Tesla GPUs I would expect substantially higher performance due to increased DP performance on those $2000 GPUs. (Amazon rents dual-Tesla servers for as little as $0.67 per hour at their spot rate.)

N=262144: 90 minutes (Available on PRPNet; currently running on Boinc)

N=524288; 5 hours (Available on PRPNet)

N=1048576; 17 hours

N=2097152; 2.5 days

N=4194304; 8 days (Eventually to be available on Boinc)
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I would argue that the GTX 460 is a bit above middle, and I would caution that, unlike the sieve applications, the number of shaders does not directly correspond to performance the same way. For example, on the 262k units, my GTX 460 gets a bit better (probably higher clocked than Mike's) at 85 minutes, but my OEM GTX 560Ti does the same work in about 65 minutes (shader clocks on the two cards are the same). In shaders, that's a 336 shader card vs. a 352 shader card (about 5% more shaders). But the performance increase is about 23%. It is likely that the memory bus width (192-bit vs. 320-bit) account for some of this.

When considering a card for the Genefer project one will need to take a more comprehensive look at other features of the cards than just shaders (e.g., DP power--Quadros and Teslas have much more than GeForce cards).

On a related note, common low end cards (e.g., the 96 shader models) are running for me at about 4 to 5 hours for the 262k units. The slowest cards that are DP capable from NVidia have only 48 shaders, and these will run much slower (probably not advised for the N=4194304 work...though Admin will need to take these into consideration when setting work/report/purge deadlines).

____________
141941*2^4299438-1 is prime!

On a related note, common low end cards (e.g., the 96 shader models) are running for me at about 4 to 5 hours for the 262k units. The slowest cards that are DP capable from NVidia have only 48 shaders, and these will run much slower (probably not advised for the N=4194304 work...though Admin will need to take these into consideration when setting work/report/purge deadlines).

Well, yeah. if someone want to go searching for the world's largest known prime number on a laptop, it might take a while.
[\quote]

On the low end ones, but there are actually some fairly hefty mobile options out there (e.g., GTX 485M and 580M mathc up fairly well with the GTX 560 Ti desktop model).

[quote]
I think the smallest non-mobile DP GPU (GTX 260) has 192 shaders, although I might be mistaken. There's a lot of DP GPUs.

FWIW, it seems like the majority of the GPUs being used are 500-series cards. I'm usually the slowest of the wingmen in any WU. People sure do seem to like their teraflops. ;-)

Slowest capable desktop cards are probably the GT 420 (OEM), GeForce 510 (OEM), and GT 520...all have 48 shaders and should run at about half what a GT430/GT530 will do (well, the 510 card has really slow stock clocks, so even less than half might be more accurate). I think most will avoid using these cards on such a big search, but since many of the low end cards are OEM, many new users will likely give it a try with what they've got.

I'd suggest that, much like the PRPnet setup, the Genefer task be divided as separate projects based on N when we move out of beta into production mode. I might not mind running the biggest ones on my 460 or 560, but even on those (or my GTS 450) running the 1048576 or 2097152 separately would be a nice option.

Mine runs at stock clocks.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I'd suggest that, much like the PRPnet setup, the Genefer task be divided as separate projects based on N when we move out of beta into production mode. I might not mind running the biggest ones on my 460 or 560, but even on those (or my GTS 450) running the 1048576 or 2097152 separately would be a nice option.

That was my suggestion also, but it seems that it's problematic. Boinc wasn't designed to run multiple projects like this and the number of projects PrimeGrid already has is stressing the server. There's probably going to only be one GFN project on the BOINC side. I suppose we can always direct people with slower cards over to the PSA.

Excuse me if I am wrong, but it looks like that on same range (262144) my card is faster on Boinc ( 64 minutes per WU) compared to 90 minutes per WU on PRPNet.
Is this new app 1.05 really faster of it is some other factors that influence on speed?
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Excuse me if I am wrong, but it looks like that on same range (262144) my card is faster on Boinc ( 64 minutes per WU) compared to 90 minutes per WU on PRPNet.
Is this new app 1.05 really faster of it is some other factors that influence on speed?

We talk before about this: and I know that cuda 3.2 is faster then cuda 4.0, and I revert even older drivers . But that was my run times: maybe I am wrong, but it is simple to make test : i will use "new 1.05 app" and app from GeneferPRPNET and compare : on same machine, on same os, with same card ad sii. Maybe I was wrong about times.
When I revert to cuda3.2 and older drivers I got something like 5 minutes per WU, but when yesterday first GENFERCUDA was finished I was surprised with result of 3996 second per WU.
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

I revert even older drivers .

I found "old logs" from 27.1.2011 when I run GeneferCuda from PRPNet
Run time with Cuda 4.0 was around 4130 seconds per WU , but switched to Cuda 3.2 dropped to 3985 sec per WU
So you was right, I was wrong, computation times difference in only 30 sec at top...
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

I have been going through results and compiling a list of performance data (now that the 1.05 version reports cards, shaders, clocks, etc. in the output file--Thanks for that Mike!)...I'll post a table of times by card when I get chance. In any case, here are some rules of thumb on the perfomance side of things (note: these are based on performance of 580k by 262k work):

1) The most important thing (as is also true with sieve GPU apps) is the number of shaders. More is better. However, compared to the sieve apps where this is overwhlemingly the big factor, it is not as dominant as a performance indicator with the Genefer app (for example, I have a 192 shader card with shorter times than some 336 shader cards and a 352 shader card that is better than several cards with 448 shaders--even better than a 480 shader card in one case).

2) Next most important thing is the shader clock. Higher clocks = better performance, but be careful here as overclocking can cause problems (for example, my superclocked EVGA GTX 550 Ti is completing work in about 1 minute less time than a stock clocked GTX 460--i.e., the much higher shader clock makes up for a difference of 144 fewer shaders).

3) Double-Precision capability of the card is also tremendously important (unlike with the sieve apps where single-precision is all that matters). Generally, on consumer cards this won't be relevant since the DP capability is a function of the number of shaders x shader clock. Basically, on Fermi cards, the DP capability is one-eighth of the SP capability (if you are using one of the GTX 2xx cards or Quadro or Tesla cards based on these chips, the number to use is one-twelfth of the SP capability). However, Fermi-based Quadro and Tesla cards have DP capability equal to one-half the SP capability. This results in slower clocked cards with fewer shaders performing as well as much more powerful (at least in SP capabiity) cards. For example, a 256 shader Quadro 4000 card clocked at only 1110 shader clock performs almost exactly the same as a 384 shader GTX 560 Ti with shader clocks at 1645.

4) Picking the best "Shift" value is also very important. In general, with the 262k units, I have observed improvements of as little 250 fewer seconds to as much as 1000 fewer seconds per work unit depending on the card involved when changing this value from 8 to 7. Keep in mind that shift values will need to be adjusted at different Genefer N (generally, higher N is better with higher shift value). For example, I have observed a GTX 570 (480 shaders, 1566 clock) outperform a GTX 580 (512 shaders, 1566 clock) by about 100 seconds per workunit by using shift=7 on the former vs. shift=8 on the latter. The key advice here--find the optimal shift value for your card at the given N value being tested.

5) Memory Bus-width may also matter (more is better again), but the results here are much less conclusive. It may be the case that some threshold process is involved here more than a linear process. Or it may be the case that certain ranges group together in performance (e.g., not much difference between 192-bit and 256-bit, but a bit of a jump at 320-bit).




**Note shader clocks are reported here as listed in Genefer output. To get actual shader clock, use the closest multiple of 54 that does not exceed the reported shader clock (i.e., shader clock reported as 1645 is actually clocked at 1620).***


____________
141941*2^4299438-1 is prime!

Lastly -- and this one won't work on PRPNet yet, sorry -- the boinc version has a tuning option that can add some additional speed. On my computer, for example, changing the block size parameter from its default (8 or 0) to 7 reduces run time on my machine by 5 minutes. Boinc can take advantage of this, and you can use this from the command line if you're running Genefer CUDA by hand, but PRPNet currently has no way to take advantage of this.

**Note shader clocks are reported here as listed in Genefer output. To get actual shader clock, use the closest multiple of 54 that does not exceed the reported shader clock (i.e., shader clock reported as 1645 is actually clocked at 1620).***

http://www.primegrid.com/result.php?resultid=343013945

33,763 seconds on a Xeon CPU X5365 @ 3.00GHz (Core2 based)
____________
Reno, NV

For reference, here are my estimated run times for larger N values where I've done some test runs. This supersedes the first post in this thread as I'm now including several different estimates at various b's, since it does vary somewhat, especially at the lowest b values.

All times are on a stock GTX 460. The fastest GPUs right now are almost twice as fast. The slowest GPUs (anything below a 450) are a lot slower. The very fastest, most expensive CPUs (with HT off and all other cores idle for maximum turbo boost) are probably about four times slower. YMMV.

N=1048576
(max b will be about 700,000)

b=14 4.5 hours
b=75898 20 hours
b=468750 22 hours

N=2097152
(max b will be about 570,000)

b=14 18 hours
b=75898 80 hours
b=380742 89 hours

N=4194304
(max b will be about 480,000)

b=14 72 hours
b=1248(*) 192 hours (12,986,467 digits) (actual run time; not an estimate)
b=309258 351 hours

N=8388608 (No search is currently planned at this N)
(max b will be about 405,000; fast init code currently limits b to about 100)

b=14 288 hours
b=36(**) 396 hours (13,055,212 digits)
b=100 522 hours

(*) This would be the world's largest known prime, except for one detail: it's composite. This is where we're in world record territory.

(**) If prime, this would be a new world record.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

All times are on a stock GTX 460. The fastest GPUs right now are almost twice as fast.

All times are on a stock GTX 460. The fastest GPUs right now are almost twice as fast.

GTX 580 at stock speed is exactly twice as fast as GTX 460.

It looks like N=1048576 is where GPU is really starting to shine and is very efficient. From there, every next n makes run time ~4X longer.

Does the app checkpoint? Just curious.
____________
Reno, NV

Yes, and it checkpoints immediately when you shut it down, so you don't lose any processing time because the last checkpoint was an hour ago.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

N=8388608 (No search is currently planned at this N)
(max b will be about 405,000; fast init code currently limits b to about 100)

b=14 288 hours
b=36(**) 396 hours (13,055,212 digits)
b=100 522 hours

Anyone else have this experience? I have been running just gfn's and no cpu jobs for some time now. Today I started up 1 core up on some pps llr's but left the other core free. My runtimes on the gfn's jumped by 100+ seconds immediately and I had a unit error out. I'm pretty sure now that the cpu usage or lack affects gfns.

Been awhile since I ran any gfn's so I was wondering if there was an update on current run times for both the short and long units. Specifically for the gtx 460 and gtx 570 (I would assume that the card(s) have been set to stock or near stock).

I ran some of the short units over the last few days with both the default "shift" and with it explicitly set to 8 in preferences. Overall runtime on the GPU (570) didn't seem to change, maybe the default was 1% faster. CPU usage was a different story. At the default (0, meaning 7) CPU seemed quite high, about 20% of 1 of 4 physical cores (HT off on a 2600K). With shift=8, CPU usage was roughly half of that. Is this expected or not?

The few World Record units that I've done, I've left at the default (meaning 9, I think). CPU usage is nice and low... maybe 2% of one core.

This is on Linux with 295.xx driver.

--Gary

There's a lot of variables, but, yes, higher block sizes can cause lower CPU utilization.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1