Aefinity AI

L28 Negative Q8 · Speed numbers

A compiler setting silently deleted our vector instructions

QuestionHow can code run hundreds of times slower than its parts predict, with no error and correct output?

Run by us; no unaffiliated reproduction

01Why it matters

Code can be badly slow with no error and correct output.

02Method, step by step

  1. Count vector instructions in the preserved shipped binary with objdump.
  2. Rebuild with a hard-float target.
  3. Measure ticks per token and score a pre-registered prediction.

Method as recorded

Counted the vector instructions in the binary actually shipped (objdump census of a preserved copy), then rebuilt with a custom hard-float target and measured ticks/token on the Dell Inspiron 15 (i5-5200U, bare metal, no OS). A pre-registered root-cause prediction was scored. Run by us.

03Results, exact and sourced

  1. R1Hand-written AVX2 kernels compiled to zero vector instructions; the binary ran 217 to 258 times slower than the hard-float rebuild (soft-float 1.65-1.67e9 vs hard-float 6.48-7.59e6 ticks/token).

    Our hand-written AVX2 kernels compiled to zero vector instructions, and the resulting binary ran 217–258× slower than it should have.

    Verbatim source alice-aegis / 2026-08-05_uefi-soft-float-deletes-your-avx2.md

  2. R2Instruction census of the shipped (preserved, bit-identical) soft-float binary: no xmm, ymm or vfmadd instructions.

    census: xmm=0 ymm=0 vfmadd=0

    Verbatim source alice-aegis / 2026-08-05_uefi-soft-float-deletes-your-avx2.md

04What it does NOT show

A controlled benchmark; the 217 to 258 times is a ratio of ranges on one machine.

05Scope and caveats

  • One machine (Dell Inspiron 15, i5-5200U, bare metal, no OS); 217 to 258 times is the ratio of soft-float to hard-float ticks/token on that machine, derived from ranges (1.65e9/7.59e6 to 1.67e9/6.48e6), not a controlled benchmark.
  • A debugging post-mortem tied to Rust's stock x86_64-unknown-uefi target (+soft-float).
  • The first census (v1) was itself wrong because a concurrent rebuild overwrote the artifact; it was re-run on a preserved bit-identical copy and the log superseded. Conclusion unchanged.
  • A pre-registered root-cause prediction was also scored, in an analysis that covers the held-back operating-system comparison; we do not link that analysis while the comparison is held back.
  • Run by us; no unaffiliated reproduction.

06Outcome

Negative

The claim or approach failed, or we retracted it.

07What we learned

Trust the binary you ship, not the annotation you wrote. Nothing failed and nothing warned; only counting instructions in the artifact exposed it. A mechanical check (assert nonzero ymm/vfmadd count in CI) is the fix, not a benchmark.

08Check it yourself

Read the post (link above).