GHz days v exponent size

[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

[Uncwilly]

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]}

[NBtarheel_33]

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.

[davieddy]

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

[Mini-Geek]

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/L³=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.

[science_man_88]

Originally Posted by Mini-Geek

I think that is like saying miles/gallon, being (literally) distance/volume could be simplified like: L/L³=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 :



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

[LiquidNitrogen]

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?

[c10ck3r]

Originally Posted by science_man_88

well dah even I can think of :



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.

[cheesehead]

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.

[LiquidNitrogen]

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