mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > PrimeNet

Reply
 
Thread Tools
Old 2017-10-24, 10:38   #1
rudi_m
 
rudi_m's Avatar
 
Jul 2005

B616 Posts
Default 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
rudi_m is offline   Reply With Quote
Old 2017-10-24, 12:09   #2
GP2
 
GP2's Avatar
 
Sep 2003

A1C16 Posts
Default

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

The program dynamically adjusts the FFT size if necessary, rather than using fixed boundaries.
GP2 is offline   Reply With Quote
Old 2017-10-24, 13:14   #3
axn
 
axn's Avatar
 
Jun 2003

114658 Posts
Default

Are these on the same machines? AVX vs AVX2 (FMA3) can sometimes have different FFTs.
axn is offline   Reply With Quote
Old 2017-10-24, 16:12   #4
rudi_m
 
rudi_m's Avatar
 
Jul 2005

2×7×13 Posts
Default

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
rudi_m is offline   Reply With Quote
Old 2017-10-24, 18:02   #5
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

163638 Posts
Default

Quote:
Originally Posted by rudi_m View Post
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
Prime95 is offline   Reply With Quote
Old 2017-10-25, 01:08   #6
retina
Undefined
 
retina's Avatar
 
"The unspeakable one"
Jun 2006
My evil lair

23·32·5·17 Posts
Default

Quote:
Originally Posted by Prime95 View Post
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
retina is offline   Reply With Quote
Old 2017-10-25, 03:42   #7
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

37·89 Posts
Default

Quote:
Originally Posted by retina View Post
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?
Madpoo is offline   Reply With Quote
Old 2017-10-25, 05:07   #8
retina
Undefined
 
retina's Avatar
 
"The unspeakable one"
Jun 2006
My evil lair

137508 Posts
Default

Quote:
Originally Posted by Madpoo View Post
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
retina is offline   Reply With Quote
Old 2017-10-25, 11:13   #9
axn
 
axn's Avatar
 
Jun 2003

133516 Posts
Default

Quote:
Originally Posted by retina View Post
the two FFTs (2304k and 2240k) have similar run times
And similar credits. 63 vs 61 isn't a significant difference.
axn is offline   Reply With Quote
Old 2017-10-25, 13:08   #10
rudi_m
 
rudi_m's Avatar
 
Jul 2005

2·7·13 Posts
Default

Quote:
Originally Posted by axn View Post
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 View Post
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:
WorkerThreads=1
CoresPerTest=3

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


Quote:
Originally Posted by Prime95 View Post
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.
rudi_m is offline   Reply With Quote
Old 2017-10-25, 13:46   #11
science_man_88
 
science_man_88's Avatar
 
"Forget I exist"
Jul 2009
Dumbassville

26·131 Posts
Default

Quote:
Originally Posted by rudi_m View Post
It's 3% less credits plus 3% longer run time.
so 94+% the credit per unit time.
science_man_88 is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
LL Credit Calculator swl551 Software 0 2012-12-04 17:49
What does the gHz credit actually mean? mack Information & Answers 5 2009-12-17 10:41
How much credit for LL? hj47 PrimeNet 26 2009-01-23 22:14
My v4 credit appears in: uigrad PrimeNet 14 2008-12-31 02:37
v4 Credit on v5 precius1 Information & Answers 3 2008-11-03 22:23

All times are UTC. The time now is 03:58.

Mon Apr 19 03:58:10 UTC 2021 up 10 days, 22:39, 0 users, load averages: 1.71, 1.54, 1.58

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.