20110713, 05:53  #1 
"Lucan"
Dec 2006
England
194A_{16} Posts 
GHz days v exponent size
Casual perusal of the "recent cleared" page throws up
lots of examples of an LLtest of a larger exponent receiving fewer GHz days than a smaller one. How come the "standard 1GHz core" of a CPU can manage to achieve this feat? Different software? David 
20110713, 06:24  #2 
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
2^{3}×17×79 Posts 
You have been around the forum long enough and have been already exposed to the answer. Please search for the answer.
^{[FONT="Arial Narrow"][COLOR="White"]"Bit level" anyone?[/COLOR][/FONT]} 
20110713, 06:41  #3  
"Nathan"
Jul 2008
Maryland, USA
2133_{8} Posts 
Quote:
There was also a weird bug (which I experienced) where Prime95 decided that exponents in the current test ranges (i.e. upper 40s/low 50s) needed a huge FFT (8192K IIRC). Because of this huge FFT size being used (erroneously) on one of my exponents, I received 130 GHzdays credit rather than the more typical 90100 GHzdays. Note that there is no benefit to exploiting the above bug, or to not updating to v26, as using an unnecessarily large FFT, while increasing GHzdays credit, also correspondingly increases the wallclock time required for an LL test. So the net GHzdays/day (=GHz?) would effectively be the same. 

20110713, 07:59  #4 
"Lucan"
Dec 2006
England
6474_{10} Posts 
THX.
I should have twigged that one for myself! BTW A kWh/h is obviously a kW, but to apply the same to GHzdays/day conceals the detailed definition of what George (after painstaking thought/testing) means by GHzday. You could compare it with realizing measurement of absolute temperature using a variety of the most accurate thermometers. (International Temperature Scale). David 
20110713, 12:10  #5 
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
2×3×23×31 Posts 
I think that is like saying miles/gallon, being (literally) distance/volume could be simplified like: L/L^{3}=L^{2}. But it ignores that you mean "energy released when burning one gallon of some certain fuel, at its current temperature and atmospheric pressure, in this particular vehicle", and could really be equated to energy, so it's distance/energy. Similarly, 1 GHzday is literally 1 billion cycles/second*day=86.4 trillion cycles, but is really (computation speed)*day, so dividing it by day results in "computation speed", which is exactly what Ghzdays per day is.
Last fiddled with by MiniGeek on 20110713 at 12:13 
20110713, 12:37  #6  
"Forget I exist"
Jul 2009
Dumbassville
2^{4}·3·5^{2}·7 Posts 
Quote:
I did the math off: Today's Numbers Teams 454 Users 66030 CPUs 466690 TFLOP/s 77.003 GHzDays 38501.482 and that means the average rate is: ( ~165 Mflops/s)/CPU Last fiddled with by science_man_88 on 20110713 at 13:03 Reason: got a wrong unit in my head. 

20110716, 18:39  #7  
Jun 2011
Henlopen Acres, Delaware
85_{16} Posts 
Quote:
I have some double check work assigned to one core, and somewhere along the way the software reported: "Roundoff errors > 0.4" ...but it kept plugging and chugging. About halfway through it decided to "resize the FFT" and start over. It churned a few percent into this resized FFT, and is reporting rounding errors again. The other 3 cores I have been assigned to LL of much larger exponents (a little over 1520 million higher) and these are running without any issues so far. Any ideas what might be responsible for the rounding errors on the smaller double check? Last fiddled with by LiquidNitrogen on 20110716 at 18:39 

20110716, 20:18  #8  
Aug 2010
Kansas
547 Posts 
Quote:
Today's Numbers Teams 454 Users 66224 CPUs 468289 TFLOP/s 8109876013496200593408.000 GHzDays 4054938006748100443504640.000 As much as I wish these were true ^^, I strongly doubt it. Last fiddled with by c10ck3r on 20110716 at 20:18 Reason: Lining up lines 

20110716, 20:34  #9  
"Richard B. Woods"
Aug 2002
Wisconsin USA
2^{2}×3×641 Posts 
Quote:
So that's why prime95 might decide halfway through a test to "resize the FFT" and start over. In each FFT range (the range of exponents for which it is used), the roundoff errors generally increase as one goes from the lowest exponents of the range to the highest exponents of the range. When the roundoff error exceeds certain values (such as 0.4), there is an increasing risk that the roundedoff result will actually be 1 less or 1 more than the correct integer (i.e., rounding took the result in the wrong direction from the correct integer). Example (numbers are for size illustration, _not_ the actual numbers): Suppose, hypothetically, that an FFT size: 2000K is used for exponents 26M28M, 2200K is used for exponents 28M31M, and 4000K is used for exponents 55M58M. Then the FFT result for exponent 26111111 (using 2000K FFT size) will usually (it's not absolutely guaranteed) have a smaller roundoff error than the FFT result for exponent 27777777 (using the same 2000K FFT size). The FFT result for exponent 28111111 (using 2200K FFT size) will usually have a smaller roundoff error than the FFT result for exponent 30777777 (using the same 2200K FFT size). Also, the FFT result for exponent 28111111 (using 2200K FFT size, and near the bottom of the range for that size) will usually have a smaller roundoff error than the FFT result for exponent 27777777 (near the top of the range for the smaller 2000K FFT size). The FFT result for exponent 55111111 (using 4000K FFT size, and near the bottom of the range for that size) will also usually have a smaller roundoff error than the FFT result for exponent 27777777 (near the top of the range for the smaller 2000K FFT size). So that's why you might have more rounding errors on the smallerexponent double check than on a largerexponent LL. As for "It churned a few percent into this resized FFT, and is reporting rounding errors again"  Note where I said, "In each FFT range ... the roundoff errors generally increase as one goes from the lowest exponents of the range to the highest exponents of the range." What you encountered may have been an exception to the "generally". Also, "reporting rounding errors" is harmless as long as the errors are not big enough to cause a decision to actually abort the test and go to an even larger FFT size. NOTE: this all assumes that the roundoff errors are due only to the approximations involved in converting from integer to floatingpoint and back to integer and in the FP calculations themselves. If, instead, some or all of the roundoff errors are due to mistakes your system is making during the FP calculations, this would inflate the size of roundoff errors regardless of where the exponent is within the range for which the particular FFT size is used. 

20110716, 20:50  #10 
Jun 2011
Henlopen Acres, Delaware
7·19 Posts 
That was the most articulate, wellwritten explanation I have experienced as a result of asking a question that I posted to this forum.
Thanks 10^6 + 1 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Max FFT Size?  aketilander  Software  44  20181219 17:58 
100M exponent FFT size?  NookieN  Information & Answers  3  20170904 22:11 
Pi(x) value for x at 10^16 size  edorajh  Computer Science & Computational Number Theory  6  20170308 20:28 
Exponent Size Gap  MiniGeek  PrimeNet  8  20070325 07:29 
FFTSize  andi314  Lounge  14  20070122 00:21 