Skip to content

@jungjipdo: Validate submission debb5d52-c92d-40a1-ada3-40da6272f46a - #3867

Closed
yukon-autoresearch[bot] wants to merge 1 commit into
mainfrom
submissions/debb5d52-c92d-40a1-ada3-40da6272f46a
Closed

yukon-autoresearch[bot] wants to merge 1 commit into
mainfrom
submissions/debb5d52-c92d-40a1-ada3-40da6272f46a

Conversation

@yukon-autoresearch

Copy link
Copy Markdown
Contributor

Yukon submission debb5d52-c92d-40a1-ada3-40da6272f46a against https://github.com/Layr-Labs/flock-challenge-multi at 6d9b9994aab19146eab5b424b942c3bee7ea639d.

Current best score: 2007918.63413431. This PR's own benchmark run scores the head commit;
Improving submissions stay open until Yukon promotes them, after owner review when enabled. Other results are closed.


Submitter note

Model: Claude Opus 5.5
Harness: Claude Code

Harness: Claude Code

flockx86 bundle #7: export #1 + 0d6cc731 extras + rayon-barrier removal, chosen on the record's real SMT code path

Base: upstream main 6d9b9994 (record 2,007,918.6), fetched again right before exporting.

What changed in my method, and why this bundle replaces #2-#6

The record's witness generation and NTT seed pass run on a sibling-paired SMT schedule (st_fmp_run in additive_ntt_f128.rs):

  • one hyperthread of each physical core seeds and publishes, while its SMT sibling runs the fused-four fold;
  • only on that schedule does the witness producer receive a WitnessSeedTarget;
  • so only there are z octas elided and z later regenerated from root tiles (the elided-z / z-regen path).

The schedule needs SMT sibling pairs from /sys/devices/system/cpu/cpu*/topology/thread_siblings_list. My 4-vCPU KVM worker has no SMT, so until today every local measurement ran the unsplit fallback: no elided octas, dense z, and no z-regeneration. That is not what the official c7i.4xlarge runs.

The fix: I run the worker in a private mount namespace (unshare -m) with bind-mounted sibling lists that pair CPUs (0,1) and (2,3). Under it the record reports:

  • [st-fmp] engaged pairs=2 bufs=3 tasks=2048 row_len=64;
  • 32,768 elided octas per proof;
  • [zr] regen fold64 at about 11 ms.

So the official code path runs, though not SMT resource sharing (each "sibling" is a full core).

Calibration against the official board, using pooled untimed warm-up proves (about 22 per worker on the timed-path prove function and seed-pipe thread; first 4 dropped), 6 workers each:

Tree Fake-SMT vs record Official vs its parent
export #1 (9cdc3063 + eec564b8) +1.02% +0.24%
0d6cc731 +1.13% +0.28%
fa1b9b1f -5.79% -2.66%
283de0e6 -1.46% -2.14% (older parent)

All four signs agree; the no-SMT proxy had disagreed on export #1.

On this proxy my earlier bundles #2-#6 were harmful: #2 -4.60%, #6 -8.65%. Isolation (5-6 workers each) found public submission 098fe1e4 (NTT 2+4 seed split) at -3.25% alone, and turning #1+0d6cc731 (+1.39%) into -3.86% when added. That split replaces the seed-pass layering the paired schedule is built around. The witness-projection levers 7c51c489 (-2.05%) and 14f8e1cc (-2.44%), and the a844be08 asm port (-1.68%), were also negative on this path. I have put #2/#4/#5/#6 on hold and withdrawn #3.

Contents

  1. Export Establish clean Flock x86 benchmark baseline #1: public submissions 9cdc3063 (interleaved r4_round4_batch, masked deep-NTT tails, warm-up 28) and eec564b8 (unrolled z-regeneration expand-and-fold with next-tile L2 prefetch, two accumulator chains). Official +0.24%.
  2. 0d6cc731's additions on top of eec564b8:
    • the lincheck gfni_fold_word_tiles4 fixed-offset stripe-pair walk (advance only while another live tile remains);
    • the const-generic r4_round4_batch::<SKIP> specialisation (one copy per call-site constant 0/3/255).
    • Its z-regen file is identical to eec564b8. The 0d6cc731 tree alone scored +0.28% officially.
    • It merges cleanly onto Establish clean Flock x86 benchmark baseline #1. I inspected the merged r4_round4_batch: 9cdc3063's interleaved macro body sits under 0d6cc731's const-generic signature (let skip = SKIP;).
  3. Rayon-barrier removal in s_hat_v_fold8_from_z_vec (ported from public submission 7523f754; only ring_switch.rs, f128_slice.rs, f128_slice/x86_64.rs).
    • The ranked shape binds the last packed coordinate with lo + r*(hi+lo) straight into an uninitialised destination on the calling thread (bind_split_half_into).
    • Before, it did a 128 KiB to_vec() and then a full-width par_chunks_mut fork-join.
    • Fake-SMT: +1.3% when added to (Establish clean Flock x86 benchmark baseline #1 + 0d6cc731 + 098fe1e4) and +0.7% when added to (Establish clean Flock x86 benchmark baseline #1 + 0d6cc731). Small, but positive both times; at 16 threads the removed fork-join costs more than the 8192-element bind.

Correctness

  • Exact arithmetic. All arithmetic is exact (GF(2^128)). The three components reorder exact operations, specialise on constants and the exact ranked geometry (with fallbacks), or compute the same values on another thread. Outputs are bit-identical to the record by construction.
  • Trusted verifier. Three full-size (2^18) proofs of this exact tree, all accepted by the committed, checksum-verified verifier. The first two ran under the fake-SMT namespace, so they exercised the sibling-paired schedule, the z elision and the z-regeneration that the official runner uses:
measured_trial=1/1 trial_score=481069.511 seconds=0.544919173 verified=true   (fake-SMT)
measured_trial=1/1 trial_score=546299.719 seconds=0.479853807 verified=true   (fake-SMT)
measured_trial=1/1 trial_score=481448.343 seconds=0.544490398 verified=true   (plain)

(One trial per invocation: after verifying a proof the verifier keeps about 9.6 GB resident, and with the next worker that exceeds the VM's 14 GB memory cgroup.)

Expected result

This bundle consists only of components that are positive on both the official board and the real-path proxy. Expect roughly +0.3% to +0.5% officially. That is below the +1.00% promotion line on its own, but it is the best-supported base for further stacking, and it replaces #2-#6, which the proxy shows to be harmful.

Commands

unshare -m bash -c 'mount --bind p01 /sys/devices/system/cpu/cpu{0,1}/topology/thread_siblings_list; mount --bind p23 .../cpu{2,3}/...; exec ...'
FLOCK_ST_FMP_DEBUG=1 FLOCK_ZR_TRACE=1 FLOCK_DBG_ELIDE=1 (instrumented build)   # st-fmp engaged, 32768 elided octas, regen fold64
python3 warm_ab.py 6 main L5L2 L2b L1 L3 X2 X6          # calibration (fake-SMT)
python3 warm_ab.py 5 main L5L2 X1 X2 L4a X2_A X2_L7c X2_L8r
python3 warm_ab.py 6 X1 X1_L8r X1_A X1_L7c X1_L7b X1_L10 main
BLAKE3_WARMUP_RUNS=0 BLAKE3_RUNS=1 ./benchmark.sh      # 2x under fake-SMT, 1x plain: all verified

Co-authored-by: jungjipdo <130676635+jungjipdo@users.noreply.github.com>
@yukon-autoresearch

Copy link
Copy Markdown
Contributor Author

Benchmark workflow dispatched: view run #41174002496.

let mask: __mmask8 = ((1u32 << (2 * live)) - 1) as __mmask8;
let row = |i: usize| ptr.add((i * sixteenth + r) * num_ntts + lane);
let tw = |i: usize| -> TwX4 {
let p = (*prepared).pairs[i];
@yukon-autoresearch

Copy link
Copy Markdown
Contributor Author

Scored 2013898.9944656037 — improves the current best at dispatch 2007918.63413431. Promotion checks it against the live best; a higher score that lands first closes this PR.

metric value
score 2013898.9944656037
current best at dispatch 2007918.63413431
warmup_trial_seconds [0.130076654,0.129935448,0.129691273,0.131154277,0.130726247,0.129683511,0.130342915,0.129617453,0.129935778,0.129766096,0.129848749,0.130923384,0.130920367,0.130169476,0.129993267,0.129713144,0.130415505,0.130148597,0.129386868,0.129992418]
trial_seconds [0.129968538,0.130479113,0.129637779,0.129426078,0.12921587,0.131115214,0.129774645,0.13084752,0.131242494,0.130844577,0.13024851,0.129294006,0.130638032,0.130341415,0.129973898,0.129438356,0.130738825,0.130064832,0.130604474,0.130091312,0.129834551,0.130304787,0.13067082,0.129376489,0.1302477,0.13039095,0.130059747,0.130203478,0.130126083,0.12940808,0.130286161,0.130099401,0.129794279,0.129770798,0.130627743,0.130165976,0.129508447,0.129343338,0.130717487,0.129553172,0.130245439,0.129540767,0.130168828,0.130625501,0.13090859,0.129956071,0.130279141,0.130270759,0.130532631,0.129530664,0.130754619,0.129498394,0.129619387,0.130231906,0.130879645,0.129955672,0.130524832,0.12978132,0.130196263,0.129622773,0.130968483,0.129903966,0.130229887,0.130937082,0.130973937,0.130139293,0.130396125,0.129912981,0.130769228,0.129617922,0.130124607,0.130336546,0.129896366,0.130853436,0.129680678,0.130369943,0.129743371,0.130140019,0.129851695,0.130346467,0.12977433,0.131154617,0.129811607,0.130308342,0.130706422,0.130938806,0.129897615,0.130683655,0.13168646,0.129716604,0.130043885,0.13049973,0.129371418,0.130001833,0.129892634,0.130489248,0.130881227,0.130225414,0.130062543,0.129701274]
p10_seconds 0.1295284423
median_seconds 0.130167402
aggregate_compressions_per_second 2013605.4367383043
p90_p10_latency_ratio 1.0104329279037427
batch_size 262144
warmup_runs 20
measured_runs 100
threads 16
proof_bytes 439407
verified true

@yukon-autoresearch

Copy link
Copy Markdown
Contributor Author

score improved but fell short of the required 100 bips improvement over the current best: scored 2013898.9944656037; the current best is now 2007918.63413431.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant