30.8 & optimal P-1 for wavefront exponents

[techn1ciaN]

Originally Posted by techn1ciaN

...Prime95 optimizes to have A) Y > AX (where A is the tests_saved value passed)...

My night brain doesn't work so well. I meant to convey that increasing tests_saved decreases the number of P-1 factors found in a given amount of time (because each individual factor is presumed to be more valuable), but the condition I wrote out actually suggests the opposite. The correct condition should be Y > (X/A).

Edited: I see that this still isn't quite a correct representation. Perhaps one could say that Prime95 optimizes for Y "nearest to" (X/A) and then maximizes Y within that narrow band. A condition of Y > (X/A) suggests that tests_saved=1 and tests_saved=2 could produce the same bounds, which doesn't pass the sniff test.

[axn]

The correct condition is:
Minimize PRP Cost * tests_saved * (1-p) + P-1 Cost, where p is the probability of P-1 success

Or alternately, maximize PRP Cost * tests_saved * p - P-1 Cost,

[Zhangrc]

Originally Posted by techn1ciaN

* Some recent Nvidia models have such crippled FP64 throughput that this extra level actually can be optimal. I have such a one. However, I don't believe enough TFers own these to recommend the extra level universally.

Actually we can. and for some cards like 3090 and 3080, (PrimeNet TF level + 6) might be optimal too.
And GTX and RTX series are the most common GPU types here (in China; but I don't know what the market situations are like in your region. Also that explains why GIMPSChina team has a very large proportion for TF)

RTX3090 maximum throughput is about 6000GHZD/D, which means 45 exponents to TF from 2^76 to 2^77 per day.
In fact, only a dozen such cards would be more than enough for wavefront TF.

[kriesel]

Tests_saved = 2 used to be a good approximation to actual activity, when it was LL, LLDC, and occasional LLTC etc. which worked out to around 2.04 in practice.
With the changeover to PRP and then PRP/proof, there was a transition downward. Actual mean tests_saved was evaluated recently at 107M as ~1.0477. For some GPU apps, and for Mlucas, tests_saved is read in as an integer. For mprime/prime95, tests_saved is printed as 1.a but is processed internally with at least 1.ab precision (confirmed by empirical testing). The server currently issues assignments with tests_saved an integer 1 or 2, for lowest-common-denominator compatibility. However, there is nothing that requires us to leave it that way indefinitely.

The actual "in-the-wild" mean tests_saved is likely to continue to change with time. The asymptote would be all PRP/proof, no LL, no PRP without proof generation, no proof certification failures. While the wavefront optimal proof power was 8, and if all work was at the wavefront and done at optimal proof power, that would be tests_saved ~ 1+1/2⁸ ~ 1.0039; when the wavefront advanced to the point power 9 becomes optimal, ~ 1.00195, power 10 ~1.000975, etc. The transition from optimal proof power 9 to 10 is at 106.5M; from 10 to 11 at ~414.2M. (That assumes that available disk storage space is not a constraint limiting proof power, and that available application/hardware combinations are not either. Note Gpuowl is limited to proof power 10.)

Since the partial derivative for a merit function near an optimal of an independent variable is near zero, small differences in the independent variable make little difference. (There is less than 10 minutes difference per first-primality-test wavefront exponent in the fit in the attachment from tests_saved 0.9 to 1.2.) So there is little performance incentive to modify the PrimeNet server from integer to real tests_saved values. And the performance incentive likely will shrink over time.