How is GHz days computed?

[daxmick]

This is probably a dumb/simple question but I just am looking for clarity.

Does a GHz day count "per thread" of a worker?

If I have, say, computer with 8 cores running at 2GHz and I assign 2 workers (with 4 threads each) would my GHz day be 16?

[Dubslow]

GHz-days are more of a currency-type of thing than a measurement of speed.

You get a flat amount of server credit, which is denominated in GHz-days, when you complete an assignment. Each assignment's "value", in that sense, in computed based on the underlying algorithm used, independent of whatever hardware was used to run it*.


(*This isn't strictly true: credit is based on the specific FFT used, and the same assignment might use different FFTs on different hardware architectures; but, for a given FFT, credit is always identical independent of the underlying clock speeds or whatever. There is no direct measurement of the hardware throughput. In this sense, the statement above is conceptually the right way to think about it at the level of the question asked.)

[daxmick]

Originally Posted by Dubslow

GHz-days are more of a currency-type of thing than a measurement of speed.

You get a flat amount of server credit, which is denominated in GHz-days, when you complete an assignment. Each assignment's "value", in that sense, in computed based on the underlying algorithm used, independent of whatever hardware was used to run it*.


(*This isn't strictly true: credit is based on the specific FFT used, and the same assignment might use different FFTs on different hardware architectures; but, for a given FFT, credit is always identical independent of the underlying clock speeds or whatever. There is no direct measurement of the hardware throughput. In this sense, the statement above is conceptually the right way to think about it at the level of the question asked.)

I get that it is a "currency" or rather used for your ranking. That said, I'd like to know how I can compute how I'm doing. I have several different machines (virtualized, paravirtualized, and bare metal) running prime95/mprime and I'd like to know how to compute how each is contributing to my rank. Is this possible?

From the way you describe it, it sounds like the GHz-days is either a fixed number for each FFT number and/or a randomly derived number to torture us with thinking we are doing better than we really are. :-)

[science_man_88]

the GHZ days thing is related to a specific chip type as a standard. it's been talked about other places. ( and yes VBcurtis this counts as a post).

[daxmick]

Originally Posted by science_man_88

the GHZ days thing is related to a specific chip type as a standard. it's been talked about other places. ( and yes VBcurtis this counts as a post).

So, going WAY BACK, this is akin to the Pentium90 equivalent that used to be used. Yes?

If so, then if I new what the "standard" chip type being used was, shouldn't I be able to compute my GHz-days for my machines?

[science_man_88]

Originally Posted by daxmick

So, going WAY BACK, this is akin to the Pentium90 equivalent that used to be used. Yes?

If so, then if I new what the "standard" chip type being used was, shouldn't I be able to compute my GHz-days for my machines?

http://mersenneforum.org/showthread....light=core%2A2 suggest it's Core2 being used now.

[daxmick]

Originally Posted by science_man_88

http://mersenneforum.org/showthread....light=core%2A2 suggest it's Core2 being used now.

Setting virtualized and paravirtualized CPUs to the side, for now, it appears that "very roughly" 1GHz is equivalent to 1 CPU core running at 1GHz for 1 day. I know that is very rough but I'm not looking for 5 9's of accuracy here.

If this "back of the envelope" comparison close, then I should be able to say that an 8 core 2.5GHz processor should yield me 20GHz-days (8*2.5) IF I was able to get 100% utilization out of it. So, assuming 20% waste then I'd be more likely to see 16GHz-days performance out of this CPU, yes?

Obviously I won't see that on a day by day basis in the rankings. I'll only see the accumulation of those GHz-days once my FFT/LL/etc test is done. Let's assume it took 50 hours to complete on my hypothetical 8 core 2.5GHz machine. Thus, 50hrs / 24hrs * 16GHz = 33.33GHz-days. (Wow. I made up those numbers on the fly and I ended up with 33 1/3 as the answer. Tesla would be proud.)


Are my ROUGH calculations close?

[science_man_88]

Originally Posted by daxmick

Setting virtualized and paravirtualized CPUs to the side, for now, it appears that "very roughly" 1GHz is equivalent to 1 CPU core running at 1GHz for 1 day. I know that is very rough but I'm not looking for 5 9's of accuracy here.

If this "back of the envelope" comparison close, then I should be able to say that an 8 core 2.5GHz processor should yield me 20GHz-days (8*2.5) IF I was able to get 100% utilization out of it. So, assuming 20% waste then I'd be more likely to see 16GHz-days performance out of this CPU, yes?

Obviously I won't see that on a day by day basis in the rankings. I'll only see the accumulation of those GHz-days once my FFT/LL/etc test is done. Let's assume it took 50 hours to complete on my hypothetical 8 core 2.5GHz machine. Thus, 50hrs / 24hrs * 16GHz = 33.33GHz-days. (Wow. I made up those numbers on the fly and I ended up with 33 1/3 as the answer. Tesla would be proud.)


Are my ROUGH calculations close?

we use a certain GHZ day measure only so it all depends on what a core2 would need.

[Uncwilly]

Originally Posted by daxmick

If this "back of the envelope" comparison close, then I should be able to say that an 8 core 2.5GHz processor should yield me 20GHz-days (8*2.5) IF I was able to get 100% utilization out of it.

Your CPU might have new functions that can make it more efficient than the old chip. AVX, MMX, and other such things have made various chips faster at doing LL's than the ones that don't have it, even at the same clock speed.

[daxmick]

Originally Posted by Uncwilly

Your CPU might have new functions that can make it more efficient than the old chip. AVX, MMX, and other such things have made various chips faster at doing LL's than the ones that don't have it, even at the same clock speed.

Alas, it appears there is no "back of the envelope" way for a layman, such as myself, to pre-calculate my GHz-days. Oh well. I'll just watch the https://www.mersenne.org/cpus/ page for my CPUs and see what they return.

Thank you to everyone for your patience in getting this concept through my thick skull.

[Dubslow]

Originally Posted by daxmick

I get that it is a "currency" or rather used for your ranking. That said, I'd like to know how I can compute how I'm doing. I have several different machines (virtualized, paravirtualized, and bare metal) running prime95/mprime and I'd like to know how to compute how each is contributing to my rank. Is this possible?

I emphasize "currency" as opposed to "measure of speed". It is *not* a measure of speed.

Your GIMPS account tracks the credit for each assignment. You can view your account at mersenne.org, in particular the individual results listing from all your computers, in addition to a detailed break down of all your credit received. Plenty of ways to view this information in easily accessible menus on the website.

Originally Posted by daxmick

From the way you describe it, it sounds like the GHz-days is either a fixed number for each FFT number and/or a randomly derived number to torture us with thinking we are doing better than we really are. :-)

Yes, it is fixed. It depends on 1) the exponent 2) the worktype and worktype parameters of the exponent. 2) can be broken down like so:

2a) for LL (and PRP) work, the parameter is the FFT size, and the particular implementation of that FFT, as well as a couple of other blackbox parameters from the underlying gwnum assembly library. Prime95 automatically picks the best FFT size based on roundoff checking for a given exponent, then selects the best implementation and blackbox parameters for that FFT size depending on what it detects the hardware as, by using extensive hand-created lookup tables in gwnum. (That is, for each new CPU architecture, George Woltmann manually creates a list of ~optimal parameters choices for all FFT sizes for that architecture, and all those lists are included in gwnum/Prime95.)

So for LL, the credit assigned is a fixed function of exponent, FFT size, FFT implementation, and blackbox parameters. If you directly reproduce those parameters on any other kind of computer, you will get exactly the same credit. (Of course choosing parameters that are optimal for one architecture, then using those params on a different architecture, may cause the assignment to be completed slower than is otherwise possible.)

For TF and P-1 etc, a similar process applies. Prime95 chooses the best possible settings for your hardware, but running those identical settings will always produce identical credit on any hardware, optimal or not.

Originally Posted by daxmick

So, going WAY BACK, this is akin to the Pentium90 equivalent that used to be used. Yes?

GIMPS used to use Pentium90 based credit, but the orders-of-magnitude advances in computing power since then necessitated a shift to the current unit of credit. It is theoretically the work done by one Intel Core2 processing core running at 1GHz for one day, though how well the computed credits awarded for completed assignments actually correlates to how long it would take a Core2 to complete those assignments is debatable, and frankly, not very important. It is an entirely arbitrary unit (though it is [or ought to be, assuming George's credit-computations are accurate] self-consistent).

Originally Posted by daxmick

If so, then if I new what the "standard" chip type being used was, shouldn't I be able to compute my GHz-days for my machines?

Again: based on the discussion above, GHz-days is *not* a measurement of speed. New architectures sometimes do some worktypes better or worse relative to a hypothetical Core2, so even varying the worktype might affect a given chip's credit-per-time "throughput". GPUs, in particular, or notorious for "breaking" the metric: GPUs doing TF receive credit an order of magnitude faster than the same GPUs doing LL, because TF is embarrassingly parallel where LL is not. So for instance, the TF leaderboards show a *lot* more GHz-days credit than the LL leaderboards.