 |
Today at 07:26:09 AM |
|
I've been reproducing the SOTA method constants on CPU before committing any GPU budget to #140. Posting the numbers here because I could not find them measured anywhere at this sample size.
Ported RC's Kang-1 to a Linux CLI, ~46k verified solves (R=40, dp=5, 512 kangs):
Classic 2.066 (published 2.10)
3-way 1.632 (published 1.60)
SOTAv1 1.173 (published 1.15)
SOTAv2 1.141 +/- 0.011 (published 1.15)
SOTA+ 0.997 (published 0.99)
The DP-overhead formula in RCKangaroo, K = 1.15 + (0.07 + 0.76/sqrt(x)) / (1 + 0.30x), matches simulation to under 1.4% across 10 values of x.
The loop statistics in the RCGpuCore.cu comments also check out:
measured L1S2 = 9.71e-4 vs 1/(2*JMP_CNT) = 9.766e-4 at JMP_CNT=512
measured L1S4 = 1.0e-6 vs L1S2/1024 = 9.5e-7
One result I did not expect, and I think it is worth stating clearly: K's real dependence is on kangaroo count, not on range.
K ~= 1.125 + 15.8/NK
Flat in range from 2^40 to 2^62 with DPs/kang pinned at ~100.
331k trials across 68 configurations.
NK=64 1.395
NK=512 1.154
NK=2048 1.137
NK>=8192 1.13 (saturated)
At any real fleet size that correction term is ~1e-6, so "same K for any higher range" holds exactly. It also means the apparent trend of K falling with range that shows up in practice is not about range at all - it is because bigger puzzles get attacked with bigger fleets. Pinning DPs/kang and holding NK fixed, the range slope is +0.0014/bit, i.e. slightly positive.
Two things I could not settle from the source alone:
1) SOTA+ under the turbo kernel.
The stated reason for leaving SOTA+ out is that it only pays off when group size is around 12-16 or less, and that if inversion cost goes to zero then SOTA+ is no better than SOTA. But the Triple Montgomery trick pushed inversion to ~3% and out of the main loop, which seems to invert that premise rather than confirm it. Counting the v4.0 core, a jump is about 5 MUL + 1 SQR and the cheap point adds 1 MUL + 1 SQR - roughly +33% cost for -13.9% ops. Has anyone actually measured SOTA+ against the v4.0 core, rather than carrying the group-size-24 conclusion over from v3.x?
2) Reusing tames across puzzles.
The suggestion was made to convert #135 DPs into tames and continue with #140. The tame band for #140 is [0, 2^134) and #135 tames live in [0, 2^129), so the nesting works. But in the code db.Header[0] != gRange rejects the load outright, so the range tag has to be rewritten by hand. Has anyone done this end to end? I would like to know whether anything else needs fixing up - in particular whether a tame set generated with stock RCKangaroo stays valid, given that SetRndSeed(0) ties the jump table to the range.
On that note: I am putting together a tame set for #140. If anyone has DPs left over from #135 that they are not going to use, I would be interested in talking.
|
