mersenneforum.org GHz days v exponent size
 Register FAQ Search Today's Posts Mark Forums Read

 2011-07-13, 05:53 #1 davieddy     "Lucan" Dec 2006 England 194A16 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
 2011-07-13, 06:24 #2 Uncwilly 6809 > 6502     """"""""""""""""""" Aug 2003 101×103 Posts 23×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]
2011-07-13, 06:41   #3
NBtarheel_33

"Nathan"
Jul 2008
Maryland, USA

21338 Posts

Quote:
 Originally Posted by davieddy 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
In a nutshell, yes. There were new FFT sizes introduced in Prime95 v26 that allow many exponents to be processed with a slightly smaller FFT than they otherwise might have needed with previous versions. This brought down the amount of work and wall-clock time (and hence the number of GHz-days credit) required to LL test these exponents. For example, exponents in the 50M range, IIRC, once received more than 100 GHz-days for an LL test; after v26, these same exponents are now below 100 GHz-days.

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 GHz-days credit rather than the more typical 90-100 GHz-days.

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 GHz-days credit, also correspondingly increases the wall-clock time required for an LL test. So the net GHz-days/day (=GHz?) would effectively be the same.

 2011-07-13, 07:59 #4 davieddy     "Lucan" Dec 2006 England 647410 Posts THX. I should have twigged that one for myself! BTW A kWh/h is obviously a kW, but to apply the same to GHz-days/day conceals the detailed definition of what George (after painstaking thought/testing) means by GHz-day. You could compare it with realizing measurement of absolute temperature using a variety of the most accurate thermometers. (International Temperature Scale). David
2011-07-13, 12:10   #5
Mini-Geek
Account Deleted

"Tim Sorbera"
Aug 2006
San Antonio, TX USA

2×3×23×31 Posts

Quote:
 Originally Posted by NBtarheel_33 GHz-days/day (=GHz?)
I think that is like saying miles/gallon, being (literally) distance/volume could be simplified like: L/L3=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 GHz-day 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 Ghz-days per day is.

Last fiddled with by Mini-Geek on 2011-07-13 at 12:13

2011-07-13, 12:37   #6
science_man_88

"Forget I exist"
Jul 2009
Dumbassville

24·3·52·7 Posts

Quote:
 Originally Posted by Mini-Geek I think that is like saying miles/gallon, being (literally) distance/volume could be simplified like: L/L3=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 GHz-day 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 Ghz-days per day is.
well dah even I can think of :

$\frac{Ghz-\strike{days}}{\strike{day}} = Ghz$

I did the math off:

Today's Numbers
Teams 454
Users 66030
CPUs 466690
TFLOP/s 77.003
GHz-Days 38501.482 and that means the average rate is:
( ~165 Mflops/s)/CPU

Last fiddled with by science_man_88 on 2011-07-13 at 13:03 Reason: got a wrong unit in my head.

2011-07-16, 18:39   #7
LiquidNitrogen

Jun 2011
Henlopen Acres, Delaware

8516 Posts

Quote:
 Originally Posted by NBtarheel_33 There were new FFT sizes introduced in Prime95 v26 that allow many exponents to be processed with a slightly smaller FFT than they otherwise might have needed with previous versions.
I am wondering if this might be related to an error I am experiencing now.

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 15-20 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 2011-07-16 at 18:39

2011-07-16, 20:18   #8
c10ck3r

Aug 2010
Kansas

547 Posts

Quote:
 Originally Posted by science_man_88 well dah even I can think of : $\frac{Ghz-\strike{days}}{\strike{day}} = Ghz$ I did the math off: Today's Numbers Teams 454 Users 66030 CPUs 466690 TFLOP/s 77.003 GHz-Days 38501.482 and that means the average rate is: ( ~165 Mflops/s)/CPU
Some new numbers for ya: (mersenne.org being pesky)
Today's Numbers
Teams 454
Users 66224
CPUs 468289
TFLOP/s 8109876013496200593408.000
GHz-Days 4054938006748100443504640.000
As much as I wish these were true ^^, I strongly doubt it.

Last fiddled with by c10ck3r on 2011-07-16 at 20:18 Reason: Lining up lines

2011-07-16, 20:34   #9

"Richard B. Woods"
Aug 2002
Wisconsin USA

22×3×641 Posts

Quote:
 Originally Posted by LiquidNitrogen I am wondering if this might be related to an error I am experiencing now. 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 15-20 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?
Larger FFTs allow calculation with smaller roundoff errors than smaller FFTs, but they also take longer. prime95 has various checks on roundoff error, so that it can switch from one FFT size to the next larger size whenever the roundoff error from the smaller FFT calculation exceeds certain limits.

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 rounded-off 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 26M-28M,
2200K is used for exponents 28M-31M, and
4000K is used for exponents 55M-58M.

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 smaller-exponent double check than on a larger-exponent 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 floating-point 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.

 2011-07-16, 20:50 #10 LiquidNitrogen     Jun 2011 Henlopen Acres, Delaware 7·19 Posts That was the most articulate, well-written explanation I have experienced as a result of asking a question that I posted to this forum. Thanks 10^6 + 1

 Similar Threads Thread Thread Starter Forum Replies Last Post aketilander Software 44 2018-12-19 17:58 NookieN Information & Answers 3 2017-09-04 22:11 edorajh Computer Science & Computational Number Theory 6 2017-03-08 20:28 Mini-Geek PrimeNet 8 2007-03-25 07:29 andi314 Lounge 14 2007-01-22 00:21

All times are UTC. The time now is 08:29.

Mon Oct 3 08:29:55 UTC 2022 up 46 days, 5:58, 0 users, load averages: 0.96, 1.26, 1.24