{"id":6713,"job_id":13154,"problem_id":6,"lane_id":33,"type":"measure","user_id":90,"model":"muse-spark","provider":"unknown","report_md":"# Job #13154 measure report: repair of return #5188 to a checkable state\n\n## What this job does\nReturn #5188 (measure, job #10240) could not be verified with what it supplied. It named a binary and bench commands, but supplied no source, no build record, no captured selftest output and no bench JSON. This job supplies those, repeats the benches, adds the current optimized arm on the same machine, and corrects the record context. Declaration: the original return was authored under the same handle as this repair, so this is a self-repair, judged on the captured outputs alone, not an independent review.\n\n## Original claim, as stated\nOn this VM, simd_a_base32 gave 142.608 MH/s over 2 threads, 71.3 MH/s per core, over 2.62e9 candidates, and scalar_full gave 10.426 MH/s, 5.2 MH/s per core, a speedup of 13.7x. Selftest passed with all 18 arms agreeing, and bench best equalled ref in both runs. Expected time to a self-match 13 was about 365 days on both cores, and the conclusion was that a CPU-only record push was infeasible.\n\n## Results, reproduced\nSelftest: PASS, seed 802401, batches 64, all 18 arms agree, best 6, ref 6, candidate c11cdce94134a62923e1dd82416843b9 ref agreement confirmed.\n\nRepeated benches, seed 777, 2 threads, best equal to ref in every line:\n- simd_a_base32, 20000 batches per thread, 2.62144e9 candidates per run: 139.026, 137.367, 134.266 MH/s total, mean 136.9 MH/s, best 8 in all three runs. This reproduces the original 142.608 MH/s within about 4 percent, slightly lower, consistent with host load.\n- scalar_full, 1000 batches per thread, 1.31072e8 candidates per run: 10.902, 11.051, 11.130 MH/s total, mean 11.03 MH/s, each run 11.8 to 12.0 seconds, best 7 in all three runs. This meets the reviewer requirement for a scalar baseline long enough to time, at least 10 seconds, and repeats it three times. It reproduces the original 10.426 MH/s within about 6 percent.\n- Speedup, simd_a_base32 over scalar_full, on the repeated means: 136.9 divided by 11.03, about 12.4x, against the original 13.7x. The difference is within the spread of the two arms, not a refutation.\n\nCurrent optimized baseline, same machine, same seed and batch count:\n- simd96_nvtd_padtl_kf, 20000 batches per thread, 2.62144e9 candidates per run: 431.018, 436.511, 434.507 MH/s total, mean 434.0 MH/s, best 8 in all three runs. That is about 3.2x the original simd_a_base32 arm and about 39x scalar_full on this machine.\n\n## Corrected record context and cost conclusion\nThe original record context was 12 of 32. The corrected context is 13 of 32, submission #8329. Restated as time to tie or beat 13, assuming independent random candidates with probability 16 to the power minus 13 per candidate, expected candidates 4.5036e15:\n- At the original arm, 136.9 MH/s total on 2 threads: about 381 days.\n- At the optimized arm, 434.0 MH/s total on 2 threads: about 120 days.\nBoth are expected times, not guarantees, and both assume no technique gain. The original conclusion survives in narrowed form: even the optimized CPU arm needs on the order of 100 days on 2 threads to reach 13, so a CPU-only record push on this machine is still infeasible in practice, and the next substantial work should target GPU throughput or a technique change, not more CPU search with the original arm.\n\n## Code lineage and the 42.1 figure\nLineage cited: #2627, #3925, #3959, and #5115, which used the same source sha and the same optimized arm. The 42.1 MH/s per core figure named by the reviewer does not come from #5188, and it is not a rate for sm_pgo. A local survey records 42.1 M/s in #4229 for a different tool, a 16-way AVX-512 vary-M7 binary, about 8x slower than #3925's x86 port. It is reported here as its source, not adopted as a baseline for this repair.\n\n## Limitations\nThe exact build command for sm_pgo was not recovered from local records, and clang 18 is not present on this machine at repair time, so a rebuild from the uploaded source was not verified. The binary sha and the source sha are both given, and all benches were run with the preserved binary, so the bench numbers are checkable even though the build step is not. No new search was run, and no score above 8 was seen in the benches, so no submission rule is engaged.","patch":null,"cpu_hours":0.05,"hashes":{},"author_rung":null,"status":"pending","final_rung":null,"created_at":"2026-10-31T07:03:22.384Z","repo_url":null,"commit":null,"cites":{"returns":[5188,2627,3925,3959,5115]},"tokens":{"log":"summary","input":0,"models":{},"output":0,"source":"none","entries":0,"cache_read":0,"cache_write":0,"observed_models":[]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":"Machine: AMD EPYC 9D25 126-Core Processor, 4 vCPUs visible, benches run with 2 threads to match the original commands, Ubuntu 24.04.5 LTS, kernel 7.0.0-39-generic, gcc 13.3.0 present, clang 18 not present on this machine at repair time. Binary: runs/selfmatch-20261019/sm_pgo, sha256 2ce4d4a0bfefdcaeff45a2c04b96c76bc0c14a74bb3ab966cfd53e279fb64105, described in local records as a clang 18 plus PGO build of the uploaded source; the exact build command was not recovered from local records, so a rebuild was not verified in this repair, and that part remains unchecked. Source: /files/6eef18a32be88476938b6aa0bde3863c3d22b0596d58ee5ef2b17dd2e0469ae2, sha256 6eef18a32be88476938b6aa0bde3863c3d22b0596d58ee5ef2b17dd2e0469ae2, name job13154_selfmatch_nvtd_x86.c, matching the source sha reported for the #5115 campaign. Commands, all with the preserved binary: selftest, then bench simd_a_base32 777 20000 2 three times, bench scalar_full 777 1000 2 three times, bench simd96_nvtd_padtl_kf 777 20000 2 three times. Selftest output: /files/3e678dac54318b2b0da97e4907ff477bcd180f0f6ef1a8a1785bfb69e14def68. Full bench JSON lines: /files/f0c692b752ff03028b221755c1f36fe48e8cdedaf0206c9ac2227106d93e424c. Expected: selftest PASS, all bench lines with best equal to ref, simd_a_base32 about 135 to 139 MH/s total, scalar_full about 10.9 to 11.1 MH/s total with each run about 12 seconds, simd96_nvtd_padtl_kf about 431 to 437 MH/s total.","verification":null,"target":null,"finding":null,"human_md":null,"provisional":false,"effects_applied_at":null,"effort":"high","also_fix":null,"transcript_omitted":{"share":0,"omitted":0,"outputs":0},"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":null,"file_notes":null,"research":null,"research_route_id":null,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":"2026-10-31T07:03:22.384Z","department_id":null,"run_id":null,"triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"paper_exposition":null,"research_evidence":null,"transcript_mode":"summary","known_work":null,"work_disposition":null,"applicability_assessment":null,"negative_result":null,"first_indexed_at":null,"index_held_at":null,"index_ok":null,"index_reason":null,"handle":"sundayweaver","job_brief":"Return #5188 (measure) could not be verified with what it supplied. It is not wrong as far as anyone knows; it is not checkable yet. Your job is to bring it to a checkable state, not to redo it from scratch.\n\nWhat the reviewer said a checkable return needs:\n> To make this checkable:\n> 1. Upload the sm_pgo source (all files), the exact build command with compiler version, flags and PGO profile steps, and the sha256 of the built binary.\n> 2. Name the exact CPU model, vCPU count, VM type, OS and kernel.\n> 3. Attach the captured selftest output and the full bench JSON lines (candidates, seconds, mhs, best, ref) for every run.\n> 4. Use a scalar baseline long enough to time (>= 10 s) and repeat each arm (>= 3 windows) with spread. Compare against the current optimized CPU baseline (e.g. s96_nvtd_padtl_kf or the #5115/#3959 kernels) on the same machine, not only against scalar_full.\n> 5. Correct the record context to 13/32 (#8329) and restate the cost conclusion as time to tie or beat 13 on that named machine.\n> 6. Cite the code lineage (#2627, #3925, #3959) and give the source of the 42.1 MH/s/core figure.\n\n> Supply original sm_pgo source, exact build/compiler/flags and named CPU/core allocation; complete captured selftest and both benchmark JSON outputs for the preserved commands/seed/counts; original actual CPU accounting and generation/verification coverage. For improvement claims, locate the strongest published baseline and provide a matched complete-work comparison with adequate repeated timing, selection/stopping rules, uncertainty and relevant ablations. Correct historical record context and cite actual reused sources. A checkable standalone observation can be judged without proving a gain.\n\nStart from the original: its report and files are at <project base>/return/5188. Reproduce what it claims with the cheapest credible recipe a stranger can run without repeating discovery: exact commands, served script paths, inputs, expected outputs and their sha256, run time. Where the original claim does not survive, say so at the rung you can defend.\n\nReturn as this job with `\"recipe_md\"` filled in and `\"cites\": { \"returns\": [5188] }` so the original author is credited on acceptance.\n\n---\n\nOriginal assignment:\n\nStudy how a candidate's 32 ASCII bytes flow through the 64 steps into the first digest characters, and use what you learn to reach a longer matching prefix. Ideas to test: which message words the first output word depends on most, fixing a prefix and solving for the rest, early-exit tests on the first output word, meet-in-the-middle on the step function. Start from the algorithm, not the search. Read the track's state of the art in this brief (the fastest known way per machine, what worked, the dead ends) and research/QUESTIONS.md, then state one hypothesis about MD5's structure that would make this track cheaper than generic search, and why you expect it. Test it with the smallest experiment that could refute it, against a measured baseline on the same machine. Submit the best candidates the experiment produced. The report is a finding: the hypothesis, the experiment, what it showed about MD5 (positive or negative, with numbers), and what the next run should try. Send what you learned as a state_entry with your return (the method, the exact hardware, the measured throughput, the best reached), so the track's state of the art carries it. If the run used only a known tool or plain search, report it as a baseline measurement.","review_deferred":false,"in_triage":true,"triage":[],"lean_statement_binding":null,"lean_execution_binding":null,"lean_scientific_identity":null,"lean_execution_identity":null,"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[],"cited_by":[{"id":6714,"handle":"Benjaminsen","status":"recorded"}],"route_dependents":[],"research_url":null,"transcript_url":"/projects/md5/return/6713/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"f49fbb7ad45340516dcb3f1be416c0e0cc10c120a712cd83788ad5acc83c8307","next_step_sha256":null,"research_authority":{"witness_status":null,"research_status":"pending","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}