mersenneforum.org why DC credit can be so different
 Register FAQ Search Today's Posts Mark Forums Read

 2017-10-24, 10:38 #1 rudi_m     Jul 2005 2×7×13 Posts why DC credit can be so different Hi, I've notice in the current cat-1 DC Range (about 41.6 - 41.7 mill) that usually I get about 63.x GHz-Days credit but sometimes 61.x GHz Days. Example: Code: 41715517 C - Verified 2017-10-24 04:11 2.5 EB1DAE6DFFDC3E75 63.6741 41714069 C - Verified 2017-10-23 18:16 2.3 3E613C73FBFDB0B5 61.484 41712071 C - Verified 2017-10-23 17:06 2.6 3129BFD8229F268E 63.6688 How can this happen? Last fiddled with by rudi_m on 2017-10-24 at 10:39
2017-10-24, 12:09   #2
GP2

Sep 2003

22·647 Posts

Quote:
 Originally Posted by rudi_m How can this happen?
Probably different FFT sizes.

The program dynamically adjusts the FFT size if necessary, rather than using fixed boundaries.

 2017-10-24, 13:14 #3 axn     Jun 2003 10011010010112 Posts Are these on the same machines? AVX vs AVX2 (FMA3) can sometimes have different FFTs.
 2017-10-24, 16:12 #4 rudi_m     Jul 2005 2·7·13 Posts Ok thank you both. Seems that the last used implementation has influence on the credits, see the logs below (all from the same machine). Code: [Work thread Oct 15 22:19] Starting primality test of M41663449 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Work thread Oct 15 23:10] Resuming primality test of M41663449 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Work thread Oct 16 20:10] Resuming primality test of M41663449 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Comm thread Oct 17 13:34] CPU credit is 61.4102 GHz-days. [Work thread Oct 17 13:34] Starting primality test of M41689003 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Work thread Oct 17 13:44] Resuming primality test of M41689003 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Work thread Oct 18 05:48] Resuming primality test of M41689003 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads [Work thread Oct 19 02:48] Resuming primality test of M41689003 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Comm thread Oct 19 03:06] CPU credit is 61.4479 GHz-days. [Work thread Oct 19 03:06] Starting primality test of M41699461 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Work thread Oct 19 12:27] Resuming primality test of M41699461 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Work thread Oct 20 05:31] Resuming primality test of M41699461 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads [Comm thread Oct 20 17:38] CPU credit is 63.6496 GHz-days. [Work thread Oct 20 17:38] Starting primality test of M41706887 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads [Work thread Oct 21 02:31] Resuming primality test of M41706887 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Work thread Oct 21 23:31] Resuming primality test of M41706887 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads [Comm thread Oct 22 07:20] CPU credit is 63.6609 GHz-days. [Work thread Oct 22 07:20] Starting primality test of M41714069 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads [Work thread Oct 22 20:31] Resuming primality test of M41714069 using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 3 threads [Work thread Oct 23 17:31] Resuming primality test of M41714069 using FMA3 FFT length 2240K, Pass1=448, Pass2=5K, clm=2, 3 threads [Comm thread Oct 23 20:16] CPU credit is 61.4848 GHz-days. If "Pass1=384, Pass2=6K" was last used then I get more credits than "Pass1=448, Pass2=5". This does not make much sense to me. Also Pass1=384 is also always about 3-4% faster than Pass1=448 for this machine. So it seems that the new benchmark mechanism does not really help to improve things in my case. In summary, It happens that I need 3-4% more time to finish an exponent and I will also get another penalty of 3.5% less credits. :( Last fiddled with by rudi_m on 2017-10-24 at 16:13
2017-10-24, 18:02   #5
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

11101000001012 Posts

Quote:
 Originally Posted by rudi_m If "Pass1=384, Pass2=6K" was last used then I get more credits than "Pass1=448, Pass2=5". This does not make much sense to me.
Longer FFT lengths always get more CPU credit than shorter FFT lengths.

Quote:
 Also Pass1=384 is also always about 3-4% faster than Pass1=448 for this machine. So it seems that the new benchmark mechanism does not really help to improve things in my case.
That prime95 is switching back and forth means the auto-benchmark code thinks the throughtput of the two FFT sizes is nearly identical.

You might be able to edit the gwnum.txt file so that the 2240K FFT is never selected.

Last fiddled with by Prime95 on 2017-10-24 at 18:03

2017-10-25, 01:08   #6
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

24·383 Posts

Quote:
 Originally Posted by Prime95 Longer FFT lengths always get more CPU credit than shorter FFT lengths.
To my mind, regardless of the FFT length, when testing the same number we have done the same amount of useful work, and thus should be credited with the same amount of shagging rights. Note that I said "useful work", not simply "work". I could set myself a 32M FFT length and work on a 42M exponent. I'd get a lot more credit (if I had an account) than someone using a 2240K FFT length but most of the work is redundant/wasted. Do we really want to reward wasted effort?

Last fiddled with by retina on 2017-10-25 at 01:09

2017-10-25, 03:42   #7
Serpentine Vermin Jar

Jul 2014

37·89 Posts

Quote:
 Originally Posted by retina To my mind, regardless of the FFT length, when testing the same number we have done the same amount of useful work, and thus should be credited with the same amount of shagging rights. Note that I said "useful work", not simply "work". I could set myself a 32M FFT length and work on a 42M exponent. I'd get a lot more credit (if I had an account) than someone using a 2240K FFT length but most of the work is redundant/wasted. Do we really want to reward wasted effort?
I thought it was just a reflection of the time taken for the test. Sure, you *could* run something using a ridiculously high FFT and get more credit, but it'll take you longer too.

I'm just guessing that the credit difference takes into account the difference in per-iteration times for the different FFT sizes so that it essentially makes it a "time taken" credit?

2017-10-25, 05:07   #8
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

24×383 Posts

Quote:
 Originally Posted by Madpoo I thought it was just a reflection of the time taken for the test. Sure, you *could* run something using a ridiculously high FFT and get more credit, but it'll take you longer too.
In the OPs case above, the two FFTs (2304k and 2240k) have similar run times, and do the same amount of useful work, but the OP sees different credit.

Last fiddled with by retina on 2017-10-25 at 05:10

2017-10-25, 11:13   #9
axn

Jun 2003

11×449 Posts

Quote:
 Originally Posted by retina the two FFTs (2304k and 2240k) have similar run times
And similar credits. 63 vs 61 isn't a significant difference.

2017-10-25, 13:08   #10
rudi_m

Jul 2005

2×7×13 Posts

Quote:
 Originally Posted by axn And similar credits. 63 vs 61 isn't a significant difference.
It's 3% less credits plus 3% longer run time. Maybe the most interesting part is that the larger FFT length can be the faster one at all. I've never seen that before.

Quote:
 Originally Posted by Prime95 That prime95 is switching back and forth means the auto-benchmark code thinks the throughtput of the two FFT sizes is nearly identical.
I did now a bit more analysis of all my log files and see that it's not really a big problem, because on most machines mprime finally uses the right FFT size continuously, once it has finished enough benchmarks. The most problematic machines were the ones which are often otherwise loaded by non-mprime jobs. I have only one out of 14 machines which is still using the wrong FFT length after having 10 auto-benchmarks finished.

To make this a bit better I've set now gwnum.txt to
BenchWorkers=1
BenchCores=3

.. as this is what I'm also using in practice in local.txt:
CoresPerTest=3

I would have expected that the default BenchCores should be the same like CoresPerTest.

Quote:
 Originally Posted by Prime95 You might be able to edit the gwnum.txt file so that the 2240K FFT is never selected.
Good Idea, actually I could merge all my gwnum.txt files from all similar machines. This would even save some benchmark time.

2017-10-25, 13:46   #11
science_man_88

"Forget I exist"
Jul 2009
Dumbassville

26·131 Posts

Quote:
 Originally Posted by rudi_m It's 3% less credits plus 3% longer run time.
so 94+% the credit per unit time.

 Similar Threads Thread Thread Starter Forum Replies Last Post swl551 Software 0 2012-12-04 17:49 mack Information & Answers 5 2009-12-17 10:41 hj47 PrimeNet 26 2009-01-23 22:14 uigrad PrimeNet 14 2008-12-31 02:37 precius1 Information & Answers 3 2008-11-03 22:23

All times are UTC. The time now is 23:15.

Thu Apr 22 23:15:35 UTC 2021 up 14 days, 17:56, 0 users, load averages: 2.63, 2.54, 2.46