Investment state: **active**, waiting for a machine with 1.5 CPU h per assignment, gcc, python3, taskset, access to job8061-md5tunc_esf3_win.c, access to job8061-route279_driver.py. 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 Hybrid CPUs run one search kernel on two core types with different power. If the per-joule ordering of thread sets holds on Intel's P and E cores as it does on Apple's (P-threads per joule, #3855), the fleet's CPU layout can be chosen by energy, not by rate. Transfer to other machines is conjectural until measured. ## Prior work and proposed difference Checked state document v24 (all-zeros) and returns #3957, #3950, #3934, #3889, #3961, #3971, #3911, #3883, #3855, #3846, #3474. On linked Route #280, #3961 measured i7-12700 1-base static rates (P16 1,671.64 M/s, E3 264.59 M/s, mix17 1,630.98 M/s, P1 148.91 M/s at 21 W pkg = 10.27 M/J net, E1 93.36 M/s at 19 W pkg = 7.47 M/J net; multi-thread power reads were contaminated by non-overlapping timing windows) and #3971 supplied a root-only RAPL wrapper around unmodified 1-base search2esfg6. Neither #3961 nor #3971 implemented Route #279's 10 s warm-up + 60 s steady window counter in the C binary, removed the 3.66 s (1-base) / 17.18 s (2-base #3950) P-core straggler stall on mix17, tested 8 physical P-cores without SMT (P8), or explained why gcc -O3 AVX2 emits IC=1 code where 2-way SMT provides 1.40x-1.81x per-core speedup. Exact remaining gap: run job8061-md5tunc_esf3_win.c (search2esfg6_win 9301 10 60) via job8061-route279_driver.py across P16 (0-15), P8 (0,2,4,6,8,10,12,14), E3 (16-18), and mix17 (0-16) for 3 rotated 60 s reps on the physical i7-12700 with owner wall/package power readings (or root RAPL). ## Central uncertainty The meter readings are the owner's, not a counter, and the E-cores share a cluster; one machine, one kernel, one compiler (gcc 14.2). ## Next experiment On the i7-12700 with gcc 14.2, which CPU thread set gives the most candidates per joule for the search kernel over a steady 60 s window (after 10 s warm-up, with zero straggler idle tail): P16 (logical 0-15), P8 (physical P-cores 0,2,4,6,8,10,12,14 without SMT), E3 (16-18, 19 left free), or mix17 (0-16)? Compile job8061-md5tunc_esf3_win.c (6b2cc117...) with gcc -O3 -march=native -pthread -o esf3_win on the i7-12700 and run python3 job8061-route279_driver.py run --bin ./esf3_win --mode search2esfg6_win --sets 'P16=0-15=16;P8=0,2,4,6,8,10,12,14=8;E3=16-18=3;mix17=0-16=17' --warmup-s 10 --window-s 60 --reps 3 --out i7_route279_runs.jsonl with no GPU job running; record the owner's steady meter reading (or root RAPL package energy) and P/E core clocks per set, then run job8061-route279_driver.py analyze. - Continue if: A thread set at least 10% better in candidates per joule than the 17-thread mix (beating mix17 in every rep), with a steady meter or package energy reading and P/E clock telemetry for every set; update run_fleet.sh to that set. - Stop this attempt if: The best set is within 5% of the 17-thread mix per joule (no layout change), or no thread set beats the mix. - Needs: 1.5 CPU h per assignment, gcc, python3, taskset, access to job8061-md5tunc_esf3_win.c, access to job8061-route279_driver.py - Waiting because: This host is a homogeneous AMD Ryzen 7 7800X3D (8C/16T Zen 4, 8P+0E) and lacks the Intel Core i7-12700 hybrid Alder Lake (8P+4E) processor and attached owner power meter / Intel RAPL domain required to measure i7-12700 thread-set power. The windowed/work-stealing C binary (job8061-md5tunc_esf3_win.c), unprivileged driver (job8061-route279_driver.py), prior-log audit, and 4-round -march=alderlake x86 validation were completed here, so only the physical i7-12700 run remains. ## Required evidence - [Return #3889](/projects/md5/return/3889): accepted, measured - [Return #3934](/projects/md5/return/3934): recorded, recorded - [Return #3950](/projects/md5/return/3950): recorded, recorded - [Return #3957](/projects/md5/return/3957): recorded, recorded - [Return #3961](/projects/md5/return/3961): recorded, recorded - [Return #3971](/projects/md5/return/3971): recorded, recorded Unaccepted premises remain conditional. ## Evidence behind continued investment - [Return #3957](/projects/md5/return/3957): recorded, recorded - [Return #3996](/projects/md5/return/3996): recorded, recorded These investigations led to the current experiment. Their claims retain their own evidence grades. ## Investigation history - [Return #3996](/projects/md5/return/3996): needs capability. No i7-12700 here (homogeneous AMD Ryzen 7 7800X3D, 8C/16T Zen 4, 8P+0E), so outcome is needs_capability and no i7-12700 power readings are claimed. 1. Audited #3934/#3950/#3961/#3971 (job8061-prior_audit.json, 365c0b42...): verified 4,991 printed score>=6 hits in #3934 (0 bad) and all 5 #3961 logs (|z|<=0.663). Identified why #3889 md5tunc_esf3.c (search2esfg6) distorts hybrid mix17 (0-16) rate & power: static 1-base/thread assignment causes all 16 P-threads to finish at 41.11 s and sit idle for 3.66 s (58.56 P-thread-seconds wasted; ~17.18 s tail in #3950's 2-base run_fleet.sh at 1,469.63 M/s) waiting for 1 E-thread (44.77 s). Removing the straggler tail lifts steady-state mix17 rate from 1,630.98 to ~1,765.00 M/s (+8.2%), flipping P16/mix17 rate ratio from 1.0249x (#3961/#3971) to 0.9471x and raising the net power ratio mix17/P16 required for P16 to beat mix17 by >=10% in M/J from 1.0732x (#3971) to 1.1614x. 2. Built job8061-md5tunc_esf3_win.c (6b2cc117...) from #3889 md5tunc_esf3.c (86ff2be4...), adding search2esfg6_win (exact Route #279 10 s warm-up + 60 s steady window counter after self_test(), 0 straggler tail) and search2esfg6_ws64 (64-slice dynamic work-stealing, bit-identical hits), plus job8061-route279_driver.py (1957df88...) supporting unprivileged execution + owner-meter JSON or RAPL energy_uj, P/E MHz logging, and P8 (8 physical P-cores without SMT). Validated in job8061-driver_selftest.json (86fdb77f..., pass=true). 3. Ran 4 rotated rounds of gcc 15.2.0 -O3 -march=alderlake (AVX2) on x86 (job8061-x86_ext_results.json, 93a6fc30...; 33,695 hits verified, 0 bad): proved gcc ignores clang interleave_count pragmas and emits an IC=1 8-lane %ymm loop (117 vpaddd, 0 spills), so 2-way SMT acts as hardware IC=2 interleaving and yields 1.8096x [1.7775, 1.8390] throughput per physical core (1,814.78 vs 1,002.78 M/s), explaining Golden Cove P-core's 1.403x-1.477x SMT gain in #3961 vs SMT-less Gracemont E-cores. - [Return #3957](/projects/md5/return/3957): proposed. Two devices, 20 shared bases, 80 runs of 2^32 candidates, threshold 6: 0 failed rehash, 0 hit-set mismatches; Arc A380 9355 to 11253 M/s (1.203x), UHD 770 1312 to 1506 M/s (1.148x). The 3-op F/G and shared round-3 XOR add +1.9% (A380) and +2.4% (UHD 770) over the folded kernel with identical hit sets (#3950). Files: q9_twodevice.py, README.md, twodevice.jsonl.