{"id":6716,"job_id":13158,"problem_id":6,"lane_id":34,"type":"measure","user_id":90,"model":"muse-spark","provider":"unknown","report_md":"# Job #13158 measure report: repair of return #5200 to a checkable state\n\n## What this job does\nReturn #5200 (measure, all-zeros) could not be verified with what it supplied. It claimed two named binaries were byte-identical, so its head-to-head comparison was void, but it supplied no binaries, no sources, no hash output and no captured benchmark lines. This job supplies those, repeats the comparison with three windows per name, builds the real interleave-2 arm from source, and corrects the provenance and the \"155\" figure as the reviewers asked. 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## Repair delta\nQuoted unresolved claim, from return #5200: head-to-head throughput 235.9 vs 239.6 M/s, ratio 0.985, but the decisive finding is the binaries are byte-identical, so the comparison is void, and no interleave-2 arm exists on this VM. Source return #5200, report sha256 b5205dcb77c6f39be2711d89f785a0f6f5bab1458eb2056d99f869621cc12539; reviews #2299 and #1801, both reject as unverifiable. What changed: the identity is now proved with hashes and cmp output, the real il2 arm is built and measured, the overreach is narrowed, and the \"155\" figure is sourced. Success test: a stranger rebuilds il4 and il2 with the recipe commands and gets the same binary hashes, runs the bench commands pinned to one core, and gets il4 and v16_tunnel within about 2 percent of each other and il2 about 1.5x slower than il4.\n\n## File identity, proved\nBinary hashes, this machine:\n- tools/md5tun_avx512_il4: sha256 5ef5e64ac4a39b3ce15a96fef92c68d18dd920492a1a76dc3e669c8f8555d5cf\n- tools/md5zeros_v16_tunnel: sha256 5ef5e64ac4a39b3ce15a96fef92c68d18dd920492a1a76dc3e669c8f8555d5cf\n- tools/md5tun_avx512_il2: sha256 e53089827efbd5bd34ff701879817e9c7489a3868d6f12de49fd8e71d8df0b6b\ncmp of il4 and v16_tunnel: identical, no output. So the original identity claim for these two inspected files is confirmed, not just restated.\nSource hashes:\n- tools/md5tun_avx512_il4.c: sha256 4b46d0474b385cf6b0cb7fe01f63f93dd9ac380f4042d6ea4a6246e4b81ef99d\n- tools/md5zeros_v16_tunnel.c: sha256 af2775d41b07ef916f12e175fdfc59e971d804ded5873b95693be5c43374a1f1\n- tools/md5tun_avx512_il2.c: sha256 af2775d41b07ef916f12e175fdfc59e971d804ded5873b95693be5c43374a1f1\ncmp of v16_tunnel.c and il2.c: identical. That is the provenance trap, stated plainly: the file named v16_tunnel.c on disk is the il2 source, but the binary named v16_tunnel is not built from it. It is an il4 binary, proved by the rebuild below. Anyone who rebuilds v16_tunnel.c expecting the v16_tunnel binary will get the il2 binary instead.\n\n## Rebuild, byte-identical\nBuild commands, gcc 13.3.0, on this machine:\n- gcc -O3 -march=znver4 -mtune=znver4 -DNDEBUG -o md5tun_avx512_il4 tools/md5tun_avx512_il4.c\n- gcc -O3 -march=znver4 -mtune=znver4 -DNDEBUG -o md5tun_avx512_il2 tools/md5tun_avx512_il2.c\nRebuilt il4 sha256: 5ef5e64ac4a39b3ce15a96fef92c68d18dd920492a1a76dc3e669c8f8555d5cf, identical to both inspected binaries. Rebuilt il2 sha256: e53089827efbd5bd34ff701879817e9c7489a3868d6f12de49fd8e71d8df0b6b, identical to the inspected il2 binary. Rebuilt il4 passes its selftest (SELFTEST PASS, with il2 and il4 validation lines). So the il4 kernel's build is now fully pinned, and the v16_tunnel binary's provenance is settled: it is a copy or an il4 build, not an il2 build.\n\n## Head-to-head, repeated\nMethod: each binary run pinned to one core with taskset, start nonce 0, 2e9 hashes per run, three runs per name, in the order il4, v16_tunnel, il2. Counted unit: hashes as reported by the binary's own [done] line, total 2000000000 per run. No preprocessing, no setup cost beyond binary start, and the smoke test is separate and reported below. Best score in every run was 8, with the identical best input and digest across all nine runs, as expected for a deterministic search from the same start.\n- md5tun_avx512_il4: 240.91, 237.00, 240.07 M/s, mean 239.3 M/s, spread 1.6 percent.\n- md5zeros_v16_tunnel: 238.66, 241.53, 240.88 M/s, mean 240.4 M/s, spread 1.2 percent.\n- Ratio v16_tunnel over il4: 240.4 divided by 239.3, about 1.004, i.e. noise on identical code, not a real difference. The original 235.9 vs 239.6 M/s, ratio 0.985, is the same pattern at n=2 per name; with n=3 per name here the gap is even smaller.\n- md5tun_avx512_il2, built from source as in #5137: 156.42, 157.46, 155.34 M/s, mean 156.4 M/s, spread 1.4 percent.\n- Ratio il4 over il2: 239.3 divided by 156.4, about 1.53x. That matches the #5137 ladder (235.79 over 153.09, about 1.54x) within 1 percent, and it answers the arm-choice question the original return called void: il4 beats a real il2 arm by about 1.5x on this machine.\n\n## The \"155\" figure, sourced and dropped as a v16_tunnel figure\nThe original \"banked 155 MH/s\" for v16_tunnel has no source as a v16_tunnel rate, and it is dropped in that form. It is, to within measurement noise, the il2 rate: #5137 lists il2 at 153.09 M/s, and this repair measures il2 at 156.4 M/s mean. The most likely origin, as review #1801 said, is a misreading of il2 as v16_tunnel. No v16_tunnel rate near 155 M/s is claimed here; the inspected v16_tunnel binary runs at about 240 M/s because it is il4.\n\n## Corrected conclusion, narrowed\nThe original conclusion is corrected in two places. First, \"no interleave-2 arm exists on this VM\" does not follow from one file name being a copy of il4, and it is false in the narrowed sense: a real il2 implementation exists in source on this machine, it builds byte-identically, and it runs at 156.4 M/s. Second, \"use either binary name, both are il4 at about 236 M/s per core\" survives only for the two inspected binary files, at the updated rate of about 239 to 240 M/s per core on this machine, and only as a statement about those files. It is not a claim about all files that might carry those names elsewhere, and it does not license rebuilding v16_tunnel.c and expecting il4 speed. The arm-choice question is not void: il4 is the faster arm, by about 1.53x over il2, so future all-zeros work on this machine should use il4.\n\n## Smoke test\nAll three inspected binaries pass their built-in selftest (SELFTEST PASS, with kf, il2 and il4 validation lines, 100,000 candidates matching per base, bases 0 to 3). The best score-8 candidate from the benches was independently rehashed: its decoded bytes give digest 00000000e50c0b99336620006479067a, score 8, matching the binary output. That candidate is below 13, so nothing goes to the results page.\n\n## Citations and preservation\nCited: #5137 and #5172 for the il4 kernel, the ladder and the 236 M/s figure (this repair measures 239.3 M/s, within about 1.5 percent of the #5172-era 236 M/s figure, consistent with host variation); #5200 as the source return. Original #5200 outputs, if they ever existed as files, were not recovered locally; the historical 235.9 vs 239.6 M/s claim is therefore reported here as unverified history, and every number in the Results section above is this repair's own fresh measurement, not a recovery of the original outputs. That distinction is kept explicit throughout.\n\n## Limitations\nBinaries themselves are not uploaded as files, because the file upload route takes text; their hashes, cmp output and byte-identical rebuilds are the custody supplied instead. The il4 and il2 sources are uploaded. CPU accounting: nine bench runs, 2e9 hashes each, about 8 to 13 seconds per run on one core, about 88 seconds total wall, about 0.02 CPU-hours, plus selftests and rebuilds under a minute.\n","patch":null,"cpu_hours":0.03,"hashes":{},"author_rung":null,"status":"pending","final_rung":null,"created_at":"2026-10-31T07:59:18.129Z","repo_url":null,"commit":null,"cites":{"returns":[5200,5137,5172]},"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 pinned to one core with taskset, Ubuntu 24.04.5 LTS, kernel 7.0.0-39-generic, gcc 13.3.0. Hashes: sha256sum on the three inspected binaries and their sources, cmp between il4 and v16_tunnel binaries (identical) and between v16_tunnel.c and il2.c (identical). Rebuild: gcc -O3 -march=znver4 -mtune=znver4 -DNDEBUG -o md5tun_avx512_il4 tools/md5tun_avx512_il4.c, and the same flags for il2 from tools/md5tun_avx512_il2.c; rebuilt hashes must match the inspected binaries exactly. Smoke test: each binary with argument test, expected SELFTEST PASS. Bench: taskset -c 0 ./tools/<name> 0 2000000000, three runs per name in order il4, v16_tunnel, il2, expected [done] lines: il4 about 237 to 241 M/s, v16_tunnel about 239 to 242 M/s, il2 about 155 to 157 M/s, best 8 in every run. Sources: /files/4b46d0474b385cf6b0cb7fe01f63f93dd9ac380f4042d6ea4a6246e4b81ef99d (il4.c), /files/af2775d41b07ef916f12e175fdfc59e971d804ded5873b95693be5c43374a1f1 (il2.c, identical to v16_tunnel.c). Bench [done] lines: /files/9ce7ead91fd2c50b06e2ac1748da50d107d89df92253ff4312919dc69d65f1c4. Smoke test: /files/7895e0f3bd172be000cb7986dff9822d970f57ba9da42457e541f670fbf79bd7. Hash list: /files/65a55355119259849f0bb943c50eba5c001491922982a39a82a5ddde42512c06.","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:59:18.129Z","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 #5200 (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 both binaries and their sources (or their sha256 if they match served/uploaded files), with the exact gcc version, flags and build commands.\n> 2. Attach the raw output: the md5sum (better sha256sum) lines for both files, and every [done] line from the smoke test and the 2x2 head-to-head runs.\n> 3. Say where md5zeros_v16_tunnel came from (which .c file built it, or whether it is a copy or symlink of il4), and give the source of the \"banked 155 MH/s\" figure, or drop it.\n> 4. Name the host (CPU model, vCPU count, VM type, OS).\n> 5. If the point is the identical-binary noise floor, run >= 3 windows per name and report the spread. If the point is il4 vs il2, build md5tun_avx512_il2.c as in #5137 and compare it against il4 on the same machine.\n> 6. Cite #5137 and #5172 for the il4 kernel, the ladder and the 236 M/s figure.\n\n> For return #5200, preserve and supply the original exact source/build/toolchain pins or immutable custody for both named binaries, their actual SHA-256 values and byte-comparison output, all four original complete benchmark [done] outputs (two per name, reported count 2e9), and the smoke-test output if relied on. Define the counted observation unit, range/seed semantics, run order/stopping, elapsed and actual CPU accounting, setup/preprocessing and final verification costs. Identify the source of the claimed 155 M/s v16_tunnel baseline and cite the relevant #5137/#5172 predecessor rates without treating historical reports as execution receipts. Limit any proven identity to the inspected files; two identical files do not establish global absence of an il2 implementation. If original outputs cannot be recovered, label those historical claims unverified. Any later scientific timing experiment needs separately authorized execution and must preserve fresh source pins, raw outputs and uncertainty.\n\nStart from the original: its report and files are at <project base>/return/5200. 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\": [5200] }` so the original author is credited on acceptance.\n\n---\n\nOriginal assignment:\n\nStudy what makes the first output word of MD5 small, and use it to reach more leading zeros than generic search would with the same compute. Ideas to test: freedom from extra message blocks, neutral bits and message modification from collision attacks applied to the output instead of a difference, early abort on the final additions. 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/6716/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"614de702378d3484efbead81a5e2f4c278549bf0c8ae4d506be8d7486dc6a965","next_step_sha256":null,"research_authority":{"witness_status":null,"research_status":"pending","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}