GPU to 72 status...

[chalsall]

Originally Posted by James Heinrich

That would provide consistent data to map the 3D performance variance for the various GPUs. More data than I currently want to analyze, but could be interesting.

I would be very interested in having access to that kind of data -- to analyze in a 3 or 4 dimensional space.

As you know, I don't have privileged access to Primenet. But I understand that Primenet records (or, at least, is told) what client did what work.

If this knowledge could be exposed to those interested, it could be quite valuable.

[NickOfTime]

Originally Posted by kracker

60M on a HD 7770:

70-71: 153 GHz
71-72: 154 GHz
72-73: 154 GHz
73-74: 132 GHz

35M on same:

68-69: 188
69-70: 178
70-71: 160
71-72: 160

I'm curious if mfaktc is more "smooth".

Well, with mfakto, it switches from barrett15_73_gs to barrett15_82_gs where mfaktc is using barrett76_mul32

[kracker]

Originally Posted by NickOfTime

Well, with mfakto, it switches from barrett15_73_gs to barrett15_82_gs where mfaktc is using barrett76_mul32

If interested...

[NickOfTime]

Originally Posted by kracker

If interested...

Hmm, there is a BARRETT76_MUL32_GS. The only obvious difference is that it has stages 1 flag. Checked my ini and stages=1, maybe something about GCN is disabling it or some other bug....

Nope 76 is Mul32 where 82 is mul15 in find_fastest_kernel

/*  GPU_GCN  (7850@1050MHz, v=2) / (7770@1100MHz)*/       
BARRETT69_MUL15,  // "cl_barrett15_69" (393.88 M/s) / (259.96 M/s)       
BARRETT70_MUL15,  // "cl_barrett15_70" (393.47 M/s) / (259.69 M/s)       
BARRETT71_MUL15,  // "cl_barrett15_71" (365.89 M/s) / (241.50 M/s)       
BARRETT73_MUL15,  // "cl_barrett15_73" (322.45 M/s) / (212.96 M/s)       
BARRETT82_MUL15,  // "cl_barrett15_82" (285.47 M/s) / (188.74 M/s)       
BARRETT76_MUL32,  // "cl_barrett32_76" (282.95 M/s) / (186.72 M/s)       
BARRETT77_MUL32,  // "cl_barrett32_77" (274.09 M/s) / (180.93 M/s)

[VictordeHolland]

My HD7950 @900MHz is also more 'efficient' in the DC TF range.

mfakto v.014

35M
69-70 [cl_barrett15_71_gs_2] 420GHz-d
70-71 [cl_barrett15_73_gs_2] 380GHz-d

69M
71-72 [cl_barrett15_73_gs_2] 366GHz-d
72-73 [cl_barrett15_73_gs_2] 366GHz-d
73-74 [cl_barrett15_82_gs_2] 327GHz-d

[chalsall]

Originally Posted by VictordeHolland

My HD7950 @900MHz is also more 'efficient' in the DC TF range.

Then do everything you can in the DC range to 70.

Others will finish the exponents and release them for DCing.

[LaurV]

Originally Posted by James Heinrich

That seems unexpectedly lower than the 212GHd/d my chart predicts.

Not really, as we commented/discussed before, mfakto (AMD/OpenCL (?!?)) is known for getting lazy at higher bit levels. See my former posts about the subject. Now I can prove that it come from the (barrett? monty?) kernels which are better taking advantage of architecture, for lower bit levels.

For example my 7970 crunches 630G at ~40M to 69, but it gets as low as 400G at ~65M to 74. The best use (optimum point) for this card is either TF to ~70/71 bits, or DC of a ~37M exponent (where a power of 2 FFT is used optimally).

[Bdot]

There are 3 factors that influence mfakto (and mfaktc) performance:

• most important: the kernel being used (selected only by target bitlevel)
  Different algorithms / data chunk sizes have different effects ... For mfaktc you can see the effect when going beyond 76 bits, then it will also switch kernels.
• measurable: size of the exponent in bits
  For each bit, the exponentiation/modulo loop needs to be run once. The first ~6 bits are for free, and there is some one-time overhead, so the effect is not proportional, but that is why the same bit-level in the DC-range is faster than in the LL-range.
• negligible: the number of '1's vs. '0's in the exponent (in binary)
  For every '1' a small step needs to be done in addition. I think this is only measurable if you have no other 'noise' impacting the speed.

On AMD H/W, the 32-bit kernel have quite some penalty because 32-bit muls are executed by the DP unit, so they have the same SP/DP performance ratio (1:16 on low and mid-level H/W, 1:4 on high end). In addition, the carry flag is not usable in OpenCL and needs extra mimic to get it. Therefore, 15-bit kernels were my fastest implementation, utilizing fast 24-bit multiplications and having room for the carry flag.

[kracker]

Originally Posted by LaurV

Not really, as we commented/discussed before, mfakto (AMD/OpenCL (?!?)) is known for getting lazy at higher bit levels. See my former posts about the subject. Now I can prove that it come from the (barrett? monty?) kernels which are better taking advantage of architecture, for lower bit levels.

For example my 7970 crunches 630G at ~40M to 69, but it gets as low as 400G at ~65M to 74. The best use (optimum point) for this card is either TF to ~70/71 bits, or DC of a ~37M exponent (where a power of 2 FFT is used optimally).

I think anything below 73 bits is fine.

[chalsall]

Originally Posted by kracker

I think anything below 73 bits is fine.

OK. Can we think about and discuss this?

The whole point of GPU72 is to optimize the available GPU firepower.

I have been using James' analysis as to where the cross-over points should be (read: where TF'ing Makes More Sense than LL'ing or DC'ing).

I'm more than happy to add additional "WMS" options for different card types.

[manfred4]

If you are collecting these tests now, I can participate: Just checked the stats for my cards on mfactc 0.20:

GTX670@1176MHz:

Exp	toBit	Ghzd/d
66M	74	275.8
66M	73	275.9
66M	72	276.2
66M	71	276.2

35M	71	284.8
35M	70	284.7
35M	69	284.6

GTX460M@675MHz

66M	74	96.5
66M	73	96.4
66M	72	96.4
66M	71	96.4

35M	71	100.2
35M	70	100.2
35M	69	100.1

seems to be a lot smoother between the exponents and bitlevels.