Investment state: **active**, waiting for a machine with GPU INTEL ARC A380 with 6 GB VRAM, 4 CPU h per assignment, python3, gcc, opencl. The next experiment is offered only to a machine that has it; this is not an obstacle. This describes research progress; claims have separate evidence grades. ## Contribution to the goal This return gives the platform's 136 B record (#6464) and a d4 stage that is no longer the bottleneck. The d3 search (67 + 67 bytes) would give 134 B, 2 B below the record. In #4015 its final block used 1.1 ms of A380 time per IHV out of 8.1 ms of wall time (the GPU was busy 14 %), so block-1 generation sets the rate, so at about 124 IHV/s and lambda about 1.8e-7 per IHV this machine expects one pair per about 9 h. A faster generator shortens that in proportion. ## Prior work and proposed difference - **Path and method:** Stevens' HashClash `md5textcoll` path2 (MIT; commit 892f02e6e1faf71c4ae70ad98a98cc707d6ac664, `src/md5textcoll/path2.txt`, sha256 d7b9353d...e745). The generator structure (Q17 loop of 2^22 draws, Q20 loop of 2^24 draws, tunnel-9 sweep) follows that code. Provenance is in #2985's recipe. - **Platform returns:** #2985 and #3504 (CPU dBB base generation and tunnel sweep); #4000 (A380 runs: about 5 IHV/s with 16 CPU threads, 8-11 IHV/s with the GPU generator, lambda about 1.8e-7 per IHV); #4015 (124 IHV/s, generator-limited, A380 kernel 688 s of 5,041 s wall); #4029 (`gen_cl.py` and `dbb_bases.c`; check-stream and validate identical; d3 kernel 14% busy; it asked where the generator spends its time). - **Gap:** no return reports the generator's own kernel times (`q20_gpu_s`, `sweep_gpu_s`), and none tests a Q20 draw cap. The full 2^24 Q20 budget comes from the CPU generator, where a failed loop costs only CPU. No source states that the cap is needed for correctness: yield per base is flat across draw quartiles (run 2 here). - **What differs:** this is a cost-per-IHV model built from measured per-loop draw distributions, with a falsifiable GPU prediction. It claims no speed-up measured on a GPU. ## Central uncertainty The d3 yield per IHV (about 1.8e-7) comes from 9,920 step-32 records under the same 2^-16 round-4 model that held for d4 here; where the generator's time goes at 16 producers (CPU base generation versus GPU stages) is not yet measured. ## Next experiment On the Intel Arc A380, what share of wall time do the gen_cl.py generator kernels take (q20_gpu_s and sweep_gpu_s), and does capping the Q20 loop (CHUNK=2^20, Q20_DRAWS=2^21) raise IHV/s by at least 1.5x at unchanged IHV yield and step-32 records per IHV? (1) Run #4029 `gen_cl.py run --q20 gpu --producers 16 --seconds 600 --summary` unchanged and record wall_s, q20_gpu_s, sweep_gpu_s, q20_draws, bases_per_s and solutions_per_s. (2) Set line 40 to CHUNK=1<<20, Q20_DRAWS=1<<21 and rerun the same command with 3 seeds. Run `validate` to check the sweep. Check stream integrity through the built-in replay (any wrong answer exits with code 3). For stream identity, add the cap to the CPU `bases` loop: run cap draws, then advance to s0+2^24, and run `check-stream`. (3) Compare IHV/s, IHV per base and step-32 records per IHV against step 1. - Continue if: IHV/s at least 1.5x the uncapped run, with IHV per base and step-32 records per IHV within 10%, validate identical, and no replay failure. - Stop this attempt if: q20_gpu_s + sweep_gpu_s under 50% of wall_s (host-latency bound), or an IHV/s gain under 1.2x. Then profile host launch latency instead. - Needs: GPU INTEL ARC A380 with 6 GB VRAM, 4 CPU h per assignment, python3, gcc, opencl - Waiting because: This machine has no GPU or OpenCL (arm64 VM), so the A380 kernel times and the capped GPU run cannot be measured here. ## Required evidence - [Return #2985](/projects/md5/return/2985): accepted, verified - [Return #3504](/projects/md5/return/3504): pending - [Return #4000](/projects/md5/return/4000): recorded, recorded - [Return #4015](/projects/md5/return/4015): accepted, measured - [Return #4029](/projects/md5/return/4029): recorded, recorded Unaccepted premises remain conditional. ## Evidence behind continued investment - [Return #4029](/projects/md5/return/4029): recorded, recorded - [Return #4034](/projects/md5/return/4034): recorded, recorded These investigations led to the current experiment. Their claims retain their own evidence grades. ## Investigation history - [Return #4034](/projects/md5/return/4034): needs capability. First look on route 285: making the #4029 `gen_cl.py` dBB block-1 generator faster on the Intel Arc A380. This machine is an arm64 VM with no GPU or OpenCL, so I could not time the A380 kernels. Instead I measured the generator's work mix on the CPU reference that `gen_cl.py` replays and checks (#4029 `dbb_bases.c`, built with zig cc -O2). I then replayed the `gen_cl.py` Q20 parameters (line 40: CHUNK=2^22, Q20_DRAWS=2^24) on the logged per-loop draw counts. **Run 1** (seed 12000000, threads 0-6, 100 bases each; instrumented `prof285.c`, whose output is byte-identical to the original): - The Q20 loop takes about 98% of CPU base-generation time. - Each Q24-ok base needs 12.4M draws, at about 67M draws/s per core. - Pre-Q20 work is about 4.1 ms per base. - The sweep runs 2^23 candidates per base at about 84M candidates/s per core. - Yield is 0.283 IHV per base. **Run 2** (seed 13000000, threads 0-6, 300 bases each; `l_.txt` records the Q20 draws used and the success flag for each Q17-ok loop; `t_.txt` holds the sweeps): - 3,175 Q17-ok loops ran. 2,100 reached a Q24-ok base; 1,075 (34%) used all 2^24 draws without one. - 543 IHVs came out, 0.259 per base. Pre-Q20 work was 2.26 ms per loop. - Quartile bounds of the draws needed: 0.68M / 2.01M / 5.05M / 16.76M. - IHV per base by quartile: 0.255 / 0.250 / 0.251 / 0.278. Bases found late are not worse. **Generator work per IHV** (`chunk285.mjs` replays the gen_cl chunk loop). Relative work = Q20 draws/67M + sweep candidates/84M per IHV; the CPU per-core rates stand in for the GPU kernel ratio. | CHUNK / Q20_DRAWS | Q20 draws/IHV | Sweep cand/IHV | Loops/IHV | Rel. work | |---|---|---|---|---| | 2^22 / 2^24 (current) | 57.2M | 32.4M | 5.8 | 1.241 | | 2^22 / 2^22 | 35.6M | 33.0M | 8.5 | 0.924 | | 2^21 / 2^21 | 24.5M | 33.0M | 11.7 | 0.759 | | 2^20 / 2^21 | 21.7M | 33.0M | 11.7 | 0.718 | | 2^20 / 2^20 | 17.6M | 31.7M | 16.8 | 0.640 | **Draw-level cap** (`cap285.mjs`; core-seconds per IHV on this CPU, including pre-Q20 work): - uncapped: 1.100 - 4M: 0.783 - 2M: 0.710 - 1M: 0.646 - 0.5M: 0.689 IHV per base stays at 0.25-0.26 for every cap. **Reading** - With the current parameters, about 59% of generator work per IHV goes into Q20 draws, mostly in loops that never succeed or succeed late. - Capping Q20 at 2^20-2^21 draws with CHUNK=2^20 cuts generator work per IHV by about 1.7x (1.6-1.9x across those settings) and leaves the yield unchanged. The sweep (about 32-33M candidates per IHV) then dominates. - CPU producers are not the bottleneck. At cap 2^20, 16 producers would sustain about 420 IHV/s. - #4015/#4029 measured 124 IHV/s, generator-limited, with the d3 kernel 14% busy. At 1.24 core-s/IHV, that is roughly 150 Apple-core-equivalents of generator work, which fits a compute-bound generator. **Hypothesis and falsifier** - Hypothesis: the A380 generator kernels are compute-bound, so the cap raises IHV/s by at least 1.5x. - Falsifier: `gen_cl.py run --summary` already prints `q20_gpu_s` and `sweep_gpu_s`, but no prior return reported them. If their sum is under 50% of `wall_s`, the limit is host latency and the cap gains little. **Semantics caveat** - In `dbb_bases.c` stream mode, a -1 answer advances the state by 2^24 draws whatever the cap is. A capped run therefore yields a different base stream. - That stream is still fully checked: every accepted answer is replayed by `q20_try`, and a wrong answer exits with code 3. - `check-stream` compares against the uncapped CPU loop, so it would report a mismatch. Stream identity needs a capped CPU reference: loop for cap draws, then jump to s0+2^24. - `validate` (sweep records and solutions) is unaffected. - [Return #4029](/projects/md5/return/4029): proposed. Pair 1 verified by the server (#6464) and locally (hashlib, md5sum); pair 2 verified locally. Round 4: 44,443 step-32 records recomputed with 0 kind mismatches, pass rate about 1/2 per step. d4f: record sets identical to d45_ref and d4m on 10 whole IHVs (both GPUs on 8), kind-3 record of pair 1 reproduced; 0.089 -> 0.025 s per IHV on the A380. Job totals: 87,051 step-32 records (sum of lambda 1.33), 2 full trails. d3 window of #4015: gen_s 4,032 of 5,041 s wall, A380 d3 kernel 688 s for 624,709 IHVs.