mersenneforum.org  

Go Back   mersenneforum.org > New To GIMPS? Start Here! > Information & Answers

Reply
 
Thread Tools
Old 2011-07-13, 05:53   #1
davieddy
 
davieddy's Avatar
 
"Lucan"
Dec 2006
England

194A16 Posts
Default 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
davieddy is offline   Reply With Quote
Old 2011-07-13, 06:24   #2
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101×103 Posts

23×17×79 Posts
Default

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]
Uncwilly is online now   Reply With Quote
Old 2011-07-13, 06:41   #3
NBtarheel_33
 
NBtarheel_33's Avatar
 
"Nathan"
Jul 2008
Maryland, USA

21338 Posts
Default

Quote:
Originally Posted by davieddy View Post
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.
NBtarheel_33 is offline   Reply With Quote
Old 2011-07-13, 07:59   #4
davieddy
 
davieddy's Avatar
 
"Lucan"
Dec 2006
England

647410 Posts
Default

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
davieddy is offline   Reply With Quote
Old 2011-07-13, 12:10   #5
Mini-Geek
Account Deleted
 
Mini-Geek's Avatar
 
"Tim Sorbera"
Aug 2006
San Antonio, TX USA

2×3×23×31 Posts
Default

Quote:
Originally Posted by NBtarheel_33 View Post
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
Mini-Geek is offline   Reply With Quote
Old 2011-07-13, 12:37   #6
science_man_88
 
science_man_88's Avatar
 
"Forget I exist"
Jul 2009
Dumbassville

24·3·52·7 Posts
Default

Quote:
Originally Posted by Mini-Geek View Post
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.
science_man_88 is offline   Reply With Quote
Old 2011-07-16, 18:39   #7
LiquidNitrogen
 
LiquidNitrogen's Avatar
 
Jun 2011
Henlopen Acres, Delaware

8516 Posts
Default

Quote:
Originally Posted by NBtarheel_33 View Post
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
LiquidNitrogen is offline   Reply With Quote
Old 2011-07-16, 20:18   #8
c10ck3r
 
c10ck3r's Avatar
 
Aug 2010
Kansas

547 Posts
Default

Quote:
Originally Posted by science_man_88 View Post
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
c10ck3r is offline   Reply With Quote
Old 2011-07-16, 20:34   #9
cheesehead
 
cheesehead's Avatar
 
"Richard B. Woods"
Aug 2002
Wisconsin USA

22×3×641 Posts
Default

Quote:
Originally Posted by LiquidNitrogen View Post
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.
cheesehead is offline   Reply With Quote
Old 2011-07-16, 20:50   #10
LiquidNitrogen
 
LiquidNitrogen's Avatar
 
Jun 2011
Henlopen Acres, Delaware

7·19 Posts
Default

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
LiquidNitrogen is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Max FFT Size? aketilander Software 44 2018-12-19 17:58
100M exponent FFT size? NookieN Information & Answers 3 2017-09-04 22:11
Pi(x) value for x at 10^16 size edorajh Computer Science & Computational Number Theory 6 2017-03-08 20:28
Exponent Size Gap Mini-Geek PrimeNet 8 2007-03-25 07:29
FFT-Size 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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, 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.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔