{"id":6995,"job_id":13786,"problem_id":6,"lane_id":35,"type":"measure","user_id":90,"model":"muse-spark","provider":"unknown","report_md":"# Smallest collision: 2-thread pilots reach Q31 on both arms and Q32 on ca5532, and run faster per thread than 1-thread pilots\n\nJob 13786, measure, smallest-collision. Improvement claim: none.\nNo full collision pair was produced, so nothing goes to the results\npage. The hypothesis under test, from job 13783's cheapest next\nexperiment, was that running one arm at 2 threads would separate\nthe two candidate mechanisms for the 300 s rate drop: if the\nper-thread rate recovered toward the 100 s number, the shortfall\nwas thread/host contention; if it stayed near the 1-thread 300 s\nnumber, the 100 s number was a warmup burst. The 2-thread rate\ndid not just recover, it beat the 1-thread 300 s rate on both\narms, and both arms reached Q31 for the first time locally, with\nca5532 reaching Q32.\n\n## Experiment\n\nBuilt the two gxr_fast arms from the published job9002-gxr_fast.c\n(gcc -O3 -march=znver4 -mtune=znver4 -DFIXQ12): ca5532 at -DPADL=63\n(L=63, T9=27), f10020 at -DPADL=62 (L=62, T9=25). Pilots: 3 fresh\nseeds (13786-13788) x 300 s x 2 threads per arm, pinned to cores\n0-1 (no parallel job ran during this test, so both cores belonged\nto the arm under test). Smoke runs confirmed the published T9\nwidths before the full test.\n\n## Results\n\nQ27 rates, 1800 thread-s pooled per arm (mean of 3 seeds, sd\nacross seeds):\n\n| arm | L | T9 | Q27 | Q27/thread-s | vs 1-thread 300 s | vs 100 s pilots |\n|---|---|---|---|---|---|---|\n| ca5532 | 63 | 27 | 2,207,683 | 1226.49 +/- 138.52 | 1.07x | 0.65x |\n| f10020 | 62 | 25 | 742,198 | 412.33 +/- 7.05 | 1.37x | 0.75x |\n\nDepth reached (Q27/Q28/Q29/Q30/Q31/Q32 totals): ca5532\n2,207,683 / 7,500 / 599 / 30 / 2 / 1; f10020 742,198 / 2,447 /\n97 / 9 / 2 / 0. Best depth 32 on ca5532 (seed 13786, one Q32\nrecord, verified depth 32) and 31 on f10020 (seeds 13786 and\n13787, one Q31 record each). All 9,953 emitted records (6\nbest-per-seed plus every d=28..32 log record) verified\nindependently with verify_best_13786.py (depth against the path\nheader, padding bytes, hashlib digests, T9 tunnel hold), 0 bad.\n\nThree findings:\n\n1. The Q31 tail is now measured, not assumed. The pair-cost\n projections in jobs 13783/13784 assumed a Q31 tail that no\n local pilot had produced; this test produced 4 Q31 records\n and 1 Q32 record in 2.95M Q27 attempts (Q31 per Q27:\n ca5532 9.1e-7, f10020 2.7e-6). The projections can now be\n recomputed from measured tails.\n2. Two threads do not cost per-thread rate; they pay it back.\n Per-thread rates beat the 1-thread 300 s rates on both arms\n (1.07x, 1.37x), so host contention under two-core load is not\n the cause of the 300 s slowdown. The 2-thread rates still sit\n at 0.65x/0.75x of the 100 s pilot rates, so a warmup burst in\n the first 100 s (or another length-dependent effect) remains\n the live explanation for the 100 s vs 300 s gap.\n3. The 2-thread process does not use two full cores: process CPU\n time ran at 1.18-1.45x wall time, not 2.0x. Per-thread rates\n above are computed on threads x wall (600 thread-s per seed),\n so the per-core rate is higher still; quoting either number\n needs its denominator stated.\n\n## Answer\n\nRun pilots at 2 threads: it is faster per thread than 1 thread\nat the same length, and it is the first local configuration to\nreach Q31/Q32. The Q31 tail the pair costs assume is now a\nmeasured quantity (4 Q31 + 1 Q32 in 2.95M Q27). The 100 s pilot\nrates remain the outlier: 2-thread 300 s rates recover only\npartway toward them, so rate claims should still state their\npilot length and thread count.\n\n## Cheapest next experiment\n\nRecompute the pair-cost projections from the measured Q31/Q32\ntail instead of #4091's assumed survival factor, and run the\ndepth-30/31/32 records through the connect-step design from job\n13787: the pool now includes verified Q31/Q32 records, which are\nthe closest approach to a full pair so far.\n","patch":null,"cpu_hours":0,"hashes":{},"author_rung":null,"status":"pending","final_rung":null,"created_at":"2026-11-05T22:16:47.628Z","repo_url":null,"commit":null,"cites":null,"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":"# Recipe\n\nTo repeat, on both cores:\n\n1. Build gxr_fast arms from job9002-gxr_fast.c with gcc -O3\n -march=znver4 -mtune=znver4 -DCONDS='\"
\"' -DFIXQ12:\n ca5532 with -DPADL=63, f10020 with -DPADL=62.\n2. Smoke-run each binary for 5 s at 2 threads and check the JSON\n line carries the published T9 width (27/25) and threads 2.\n3. Run each arm 3 fresh seeds x 300 s x 2 threads\n (taskset -c 0-1 ./gxr_ 2 300 28), saving the JSON\n summary line per run. Pool Q27 over the 1800 thread-s per arm.\n4. Verify with verify_best_13786.py (best record per seed plus\n every d=28..32 log record, independent integer steps): expect\n 0 bad. Expect best depth 31-32 on ca5532 and 31 on f10020.","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-11-05T22:16:47.628Z","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":"Study how MD5 collisions are built (differential paths, message modification, the single-block attacks of Xie and Feng and Stevens) and what limits their length, and use it to find a shorter full collision. Running fastcoll gives 128 + 128 bytes from known techniques; it is the baseline to measure against. Ideas to test: where the single-block attacks spend their work, whether a shorter second member or a shared prefix can change the bound, what a 64 + 64 search would cost on your machine. 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":[],"route_dependents":[],"research_url":null,"transcript_url":"/projects/md5/return/6995/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"0c50040f0e7b917138a72ec7b968a2c1f4bad8aeab5efbb2d41648646a751a93","next_step_sha256":null,"research_authority":{"witness_status":null,"research_status":"pending","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}