L19 Undated in the source Positive Q1 · Same bits on two computers
E29: does the compiler's optimiser change the bits?
QuestionDoes getting identical results mean giving up on fast, optimised code?
Run by us; no unaffiliated reproduction
01Why it matters
If identical results meant giving up optimised code, the approach would be too slow to use.
02Method, step by step
- Dump every intermediate of the normative decode from differently compiled builds.
- Compare them exactly with sha256 and a structural diff, and inspect the disassembly.
- Cover three binaries on two models, then ten opt-level and target-cpu cells.
Method as recorded
Every intermediate of the normative decode was dumped from differently compiled builds and compared exactly (sha256 plus a structural diff), with disassembly analysis. Core test: three x86_64 binaries (baseline; target-cpu=native with AVX2 on an i5-10210U; target-cpu=native SSE-only on a Celeron N4020) on SmolLM2-135M and Qwen2.5-0.5B. Extension: ten opt-level x target-cpu cells on SmolLM2-135M, x86_64. The same document later extends this to 20 cells across x86_64 and aarch64 in CI (E31). All with rustc 1.98.0. Run by us.
03Results, exact and sourced
-
R1On the x86_64 builds tested, the optimiser vectorised the code (hundreds of AVX2 instructions) and the dumped intermediates did not change.
turns out to be no: the optimizer may vectorize, and does, and the bits do not move.
Verbatim source cis2-spec / E29_OPTIMIZER_INVARIANCE.md -
R2Ten distinct x86_64 binaries (opt-level 0,1,2,3,s x generic/native) on SmolLM2-135M produced one identical 51,750,154-byte dump, with zero FMA instructions.
**Ten distinct binaries. One dump.**
Verbatim source cis2-spec / E29_OPTIMIZER_INVARIANCE.md
04What it does NOT show
A second compiler (one rustc version throughout), other flags, or why: the mechanism explanation was later corrected in E39.
05Scope and caveats
- Core test: two machines (a ChromeOS Crostini VM and a bare-metal Celeron box), same glibc, one rustc version (1.98.0, same LLVM). It is not a second-compiler test.
- The ten-cell opt-level sweep was SmolLM2-135M only, x86_64, run locally. At opt-level 0 the arithmetic kernels were not vectorised (the 147 ymm instructions there are in tokenizer/allocator code), so the informative cells are opt-level 1/2/3/s with native.
- Scope is limited: six prompts, longest context 64 generated tokens, ASCII only; flags outside opt-level, target-cpu, lto, codegen-units and profile-use are untested.
- The source later adds an aarch64 half (E31): 20 cells over x86_64 and aarch64 on GitHub-hosted runners, same dump. Same rustc. The earlier 'x86_64 only' caveat applies to the ten-cell sweep, not to the whole document.
- The document's mechanism explanation about subnormals/FTZ was later corrected in E39 (per E39, conclusions survive but the stated reason was wrong).
- Run by us; no unaffiliated reproduction. No timing claims.
06Outcome
The check worked as expected, within the stated scope.
07What we learned
Optimisation was not the enemy for this decode. The pinned order of operations is preserved in the emitted code, so builds with very different vector instruction counts produced identical bytes. This is measured on one compiler version and on the tested models and prompts.
08Check it yourself
- cis2-spec / E29_OPTIMIZER_INVARIANCE.mdhttps://github.com/Aefinity-AI/cis2-spec/blob/main/docs/E29_OPTIMIZER_INVARIANCE.md
- cis2-spec / E39_FTZ_IS_NOT_WHERE_WE_SAID.mdhttps://github.com/Aefinity-AI/cis2-spec/blob/main/docs/E39_FTZ_IS_NOT_WHERE_WE_SAID.md
Read the page and E39 (links above).