Buckets:

soixantesept's picture
|
download
raw
21.4 kB
# B6 — minimizing the shipped paq8px decoder bundle
**Scope.** Decoder-side only: no compression runs, no changes to the archive, nothing touched under
`V1-verify-queue/`, `publish67/` or the flagship run directory, no publication or HF API calls.
All work under `/root/hutter67/swarm67/B6-bundle/`.
## Headline
| | bytes | sha256 | notes |
|---|---:|---|---|
| P5/published paq8px blob-chain bundle | 766,308 | `debed42c9ec425e5461dd886148814e55c71c52ea43b2675d80b563030074dce` | b.xz 760,856 + v.xz 4,948 + d 236 + 268 framing |
| **B6 winner (`dyn_Os`)** | **204,244** | `7a3899220efe888bd0d0e3affed875094afaea382ef1eda67eb1268a15b0071a` | same launcher/inverse, new payload |
| saving | **562,064** | | one-line: **the winner ships 562,064 bytes smaller than the 766,308 B baseline.** |
## SHIP THIS
| | |
|---|---|
| artefact | `/root/hutter67/swarm67/B6-bundle/out/bundle_dyn_Os/decompressor.zip` |
| bytes / sha256 | **204,244** / `7a3899220efe888bd0d0e3affed875094afaea382ef1eda67eb1268a15b0071a` |
| contents | `b.xz` 198,792 (XZ of the 476,864 B `dyn_Os` ELF, sha256 `94cc29db…`) + `v.xz` 4,948 (unchanged P5 member) + `d` 409 raw / 236 deflated (unchanged P5 launcher) + 268 B ZIP framing |
| fallback if the verifier's `-9` decode hits anything unexpected | `/root/hutter67/swarm67/B6-bundle/out/bundle_dyn_O3/decompressor.zip` — 443,156 B, sha256 `411bd72a8deb791e…`, P1's exact `-O3 -flto` recipe with only `-static` removed, also small-chain proven (3/3) |
| evidence table for every variant | §4, with per-binary proofs in §6a/§6b and machine-readable form in `bundle67.json` |
**562,064 B** off the counted total, from a rebuild + repack of the payload only. On the assets basis
the entry is `A_blob + 204,244` (was `A_blob + 766,308`); with the flagship blob archive projecting to
~16.1 MB the entry lands at ≈16.29 MB, versus 17,969,555 B for the published v4 baseline. The launcher `d`
and the blob inverse `v.xz` are byte-identical to the published P5 package, so the decode chain a
verifier runs is unchanged; only the paq8px executable it unpacks is smaller.
## 1. The decoder chain that has to be shipped
Flagship production chain (`P1-paq8px-cal/fullrun_blob.sh`, `-9`):
```
archive.paq8px216 --paq8px -d--> blob (60,634,501 B) --blob inverse--> enwik8 (100,000,000 B)
```
P5 accounted that whole chain as a 766,308 B ZIP holding exactly three members
(`paq8px-blob/package.json`): `b.xz` 760,856 (XZ of the 1,895,080 B static paq8px binary),
`v.xz` 4,948 (the dedicated cmix-store blob inverse), `d` 409 raw / 236 deflated (Python launcher),
plus 268 B of ZIP framing. **B6 changes only `b.xz`.**
Byte-accounting validation: `work/make_bundle.py --verify-baseline` rebuilds the P5 ZIP from its
members and reproduces **766,308 B / sha256 `debed42c9ec425e5461dd886148814e55c71c52ea43b2675d80b563030074dce` byte-for-byte**. Stated plainly, because
it is the whole basis of the claim: **because the packer reproduces P5's ZIP byte-for-byte, the
−562,064 B is an apples-to-apples accounting change (same three members, same launcher, same inverse,
same 268 B of framing) and not a change of accounting basis.** The only member whose bytes differ is
the payload `b.xz`.
## 2. Lever 1 — rebuild the binary smaller (this is where the bytes were)
The shipped binary is a `-O3 -flto -march=native -static` build: 1,895,080 B raw. Static linking of
libc/libstdc++ plus `-O3` inlining is most of it. Rebuilding the **pinned source**
(`paq8px-29237fb44cb1995690e3eb72c6c3b1e4aede5791`, the same commit P1/P5 used) with size flags and
dynamic linking, **changing no source line**, gives:
| build | raw B | XZ payload B | bundle B |
|---|---:|---:|---:|
| P1 shipped (`-O3 -flto -march=native -static`), P5's own tuned XZ | 1,895,080 | 760,856 | 766,308 (the baseline) |
| `-O3 -flto=2` dynamic (identical codegen flags, only the link mode changes) | 1,012,192 | 437,704 | 443,156 |
| `-O2 -flto=2` dynamic | 647,648 | 264,480 | 269,932 |
| clang++-17 `-Oz` dynamic | 523,208 | 211,248 | 216,700 |
| **`-Os -flto=2` dynamic + gc-sections + strip** | **476,864** | **198,792** | **204,244** |
| `-Os -flto=2` dynamic + hard flags (`-fno-plt -fno-stack-protector …`) | 473,552 | 201,004 | 206,456 (smaller raw, *worse* packed) |
| `-Os` dynamic, no LTO | 509,632 | 204,672 | 210,124 |
| `-Os` static (self-contained fallback) | 1,277,800 | 480,876 | 486,328 |
Exact commands are in §5. `-flto=1` and `-flto=2` produced a byte-identical binary here
(sha256 `94cc29db…`), so that knob is a no-op. Every payload column below uses the same swept-optimal
XZ parameters as the winner, so variants are comparable at bundle level.
Cost of the size build: in the single-run measurements of §6a the `-Os` decode is **12.25 s** on the
32 KiB binary slice where the original binary takes **10.42 s** (≈ +18 %, within session noise on a
box that was simultaneously running a 4.5 GB encode; `dyn_O3` measured 9.38 s). This affects *decode
time only* — it is not a scoring term — but it is the honest trade: the smallest bundle decodes
somewhat slower than the `-O3` binary, and the fallback `dyn_O3` variant does not have that penalty.
**`-march=native` was deliberately NOT used** even though P1's build had it: it would bake AVX-512
instructions from this EPYC into the shipped decoder and could crash on a verifier's CPU. The
`-Os` build targets baseline x86-64. This is a portability gain, not just a size choice.
## 3. Lever 2 — pack the payload with the strongest *shippable* codec
All measured on the winner binary (`dyn_Os`, 476,864 B). "Shippable" means the decoder is either
already present on the host (Python's `lzma`) or small enough to pay for itself:
| codec | bytes | note |
|---|---:|---|
| xz + BCJ/x86, LZMA2 dict512K lc3 lp0 pb0 mf=bt2 nice96 (SHIPPED b.xz) | 198,792 | decoder is free on the host (launcher already uses Python lzma); winner |
| zpaq zc56 stream (libzpaq level 5, 64 MiB block) | 187,197 | smallest raw payload, but +16,476 B shipped libzpaq extractor = 203,673 B effective; loses |
| UPX 4.2.4 --best --lzma (upx -d restores byte-identical) | 202,768 | self-extracting; no host decoder, no xz payload; loses by 3,912 B |
| 7z PPMd mem=512m o=32 -mx=9 | 204,453 | needs a 7z binary on the host |
| brotli -q 11 -w 24 | 213,027 | needs brotli on the host |
| zstd --ultra -22 --long=27 | 222,742 | needs zstd on the host |
| bzip2 -9 | 248,621 | host-decodable via Python bz2, but far larger than xz |
XZ + x86/BCJ wins: it needs **zero extra shipped bytes** (the launcher already uses Python's `lzma`),
while zpaq's 11,595 B head start is eaten by the 16,476 B libzpaq extractor it would require
(187,197 + 16,476 = 203,673 > 198,792), and UPX's self-extracting stub lands at 202,768.
Swept per-parameter: `dict 1–64 MiB`, `lc 0–4`, `lp 0/1`, `pb 0–4`, `nice 128/192/273`,
`mf ∈ {bt2,bt3,bt4}`, BCJ `start` offsets 0…0x7fffffff — best is `dict=512 KiB, lc=3, lp=0, pb=0, mf=bt2, nice=96`,
whole-file BCJ. A `.text`/`.rodata` split with BCJ on code only saves a further 452 B but needs a
reassembly step in the launcher (≈ +60 B of launcher, +90 B of ZIP framing), so it was not shipped.
## 4. Every bundle variant built (size, sha256, decode round-trip)
Bundle = `b.xz` + `v.xz` + `d` + 268 B ZIP framing, all built with the same deterministic packer.
"binary" = the candidate executable decoded a real project archive byte-exactly (§6a);
"bundle" = the *packed bundle* ran the complete chain (`launcher → payload → paq8px -d → inverse`) with
the expected sha256 (§6b). Non-candidates were not decoded; `dyn_Os_flto1` is byte-identical to
`dyn_Os` (sha256 `94cc29db…`) so it inherits that proof by identity.
| label | raw binary B | payload (`b.xz`) B | bundle B | bundle sha256 | decode round-trip | what it is |
|---|---:|---:|---:|---|---|---|
| `dyn_Os` | 476,864 | 198,792 | **204,244** | `7a3899220efe888b…` | binary: PASS / bundle: PASS | same source, -Os -flto=2, dynamic, gc-sections, stripped |
| `dyn_Os_flto1` | 476,864 | 198,792 | **204,244** | `7a3899220efe888b…` | binary: PASS / bundle: not run | -Os -flto=1 dynamic |
| `dyn_Os_hard` | 473,552 | 201,004 | **206,456** | `0fe90be2b6518b8e…` | binary: PASS / bundle: not run | -Os -flto=2 dynamic + hard size flags (no-plt/stack-protector off) |
| `dyn_Os_noflto` | 509,632 | 204,672 | **210,124** | `0cd663827adf0895…` | binary: not run / bundle: not run | -Os dynamic, no LTO |
| `dyn_Oz_clang` | 523,208 | 211,248 | **216,700** | `47300c83eea0212b…` | binary: not run / bundle: not run | clang++-17 -Oz dynamic |
| `dyn_O2` | 647,648 | 264,480 | **269,932** | `37c10e004f267e3e…` | binary: not run / bundle: not run | -O2 -flto=2 dynamic |
| `dyn_O3` | 1,012,192 | 437,704 | **443,156** | `411bd72a8deb791e…` | binary: PASS / bundle: PASS | P1 flags verbatim (-O3 -flto) except dynamic link instead of -static |
| `static_Os` | 1,277,800 | 480,876 | **486,328** | `5f2c887528df97a9…` | binary: PASS / bundle: PASS | -Os static (self-contained: no host libstdc++/libc needed) |
| `orig_static_p1` | 1,895,080 | 761,640 | **767,092** | `df55287589ac25f0…` | binary: PASS / bundle: not run | P1's shipped static binary, unmodified (baseline payload) |
The last row re-packs the *baseline* binary with the winner's XZ parameters (761,640 B); P5's own
tuned parameters do 784 B better on that large binary (760,856 B → the 766,308 B published baseline),
which is why the baseline comparison uses 766,308 and not 767,092. On the ~477 KB winner the swept
parameters above are the better ones.
## 5. Winner and exact commands
Winner: **`dyn_Os`**, bundle **204,244 B**, sha256
`7a3899220efe888bd0d0e3affed875094afaea382ef1eda67eb1268a15b0071a`, payload `b.xz` 198,792 B sha256
`35d1f4ff1886a9d6a9714cede09cb7c0d74ce00ca3e3b652d48ab311fc9f6960`.
```sh
# zlib objects (9 C files)
gcc -c -DNDEBUG -I<src>/zlib -Os -fno-fast-math -ffp-contract=off -fexceptions -include unistd.h <zlib>.c -o <obj>.o
# paq8px link (single g++ invocation, sequential TUs)
g++ -DNDEBUG -I<src>/zlib -fno-rtti -std=gnu++17 -ffp-contract=off -fno-fast-math \
-Os -flto=2 -ffunction-sections -fdata-sections -Wl,--gc-sections \
-fno-unwind-tables -fno-asynchronous-unwind-tables -Wl,-s \
<zlib-objects> src/file/*.cpp src/filter/*.cpp src/model/*.cpp src/text/*.cpp src/lstm/*.cpp src/*.cpp \
-o paq8px
strip --strip-all paq8px
python3 work/make_bundle.py --binary out/build/dyn_Os --out out/bundle_dyn_Os --label dyn_Os
# == inside make_bundle.py:
# b.xz = lzma.compress(binary, FORMAT_XZ, CHECK_NONE,
# filters=[FILTER_X86, FILTER_LZMA2(dict_size=1<<19, lc=3, lp=0, pb=0,
# mode=MODE_NORMAL, mf=MF_BT2, nice_len=96, depth=0)])
# v.xz, d = byte-identical copies of the P5 paq8px-blob members
# zip = STORED b.xz, STORED v.xz, DEFLATED(9) d with mode 0755 and DOS-epoch timestamps
```
Rebuild the same bundle from scratch (all in `work/`):
```sh
./build_variant.sh dyn_Os dyn_Os # → out/build/dyn_Os (476,864 B)
python3 make_bundle.py --binary ../out/build/dyn_Os --out ../out/bundle_dyn_Os --label dyn_Os
bash e2e_bundle.sh dyn_Os ../out/bundle_dyn_Os # end-to-end proof, writes test/e2e_dyn_Os.json
```
## 6. Proof — what was actually decoded
### 6a. Binary-level proof (real project archives, `test/decode_proof.tsv`)
| binary | archive | out bytes | out sha256 | match expected | rss kB | wall |
|---|---|---:|---|---|---:|---|
| orig | slice32k.paq8px216 | 32768 | 252c561ddcdefb261e605f8e20f726e43de6a31b1b4cfb240563f5f7d4fd28e8 | YES | 561508 | 0:10.42 |
| dyn_O3 | slice32k.paq8px216 | 32768 | 252c561ddcdefb261e605f8e20f726e43de6a31b1b4cfb240563f5f7d4fd28e8 | YES | 564120 | 0:09.38 |
| dyn_Os | slice32k.paq8px216 | 32768 | 252c561ddcdefb261e605f8e20f726e43de6a31b1b4cfb240563f5f7d4fd28e8 | YES | 563812 | 0:12.25 |
| static_Os | slice32k.paq8px216 | 32768 | 252c561ddcdefb261e605f8e20f726e43de6a31b1b4cfb240563f5f7d4fd28e8 | YES | 562876 | 0:13.42 |
| dyn_Os_hard | slice32k.paq8px216 | 32768 | 252c561ddcdefb261e605f8e20f726e43de6a31b1b4cfb240563f5f7d4fd28e8 | YES | 563776 | 0:12.15 |
| orig | small.paq8px216 | 53 | c5cf4213e9e9568b3b7b8bb42e219d30cc66ed3adce28aa5292201d96f928430 | YES | 347900 | 0:00.25 |
| dyn_O3 | small.paq8px216 | 53 | c5cf4213e9e9568b3b7b8bb42e219d30cc66ed3adce28aa5292201d96f928430 | YES | 350696 | 0:00.22 |
| dyn_Os | small.paq8px216 | 53 | c5cf4213e9e9568b3b7b8bb42e219d30cc66ed3adce28aa5292201d96f928430 | YES | 350280 | 0:00.27 |
| static_Os | small.paq8px216 | 53 | c5cf4213e9e9568b3b7b8bb42e219d30cc66ed3adce28aa5292201d96f928430 | YES | 347376 | 0:00.29 |
| dyn_Os_hard | small.paq8px216 | 53 | c5cf4213e9e9568b3b7b8bb42e219d30cc66ed3adce28aa5292201d96f928430 | YES | 350380 | 0:00.33 |
`slice32k.paq8px216` is a **fresh `-1` archive of the first 32,768 bytes of the project's real
`store67/blob67.bin`**, encoded with the original binary (block type `default` = generic/binary path,
12,962 B archive). `small.paq8px216` is P1's calibration fixture (text path). Every candidate binary
reproduces the original binary's output exactly — including the two binaries that were *not* expected
to win (`dyn_Os_hard`, `static_Os`).
### 6b. Full-chain proof through the packed bundle (`test/e2e_dyn_Os.json`)
Fresh directory, `decompressor.zip` unpacked exactly as a verifier would, then the shipped launcher
was run on real archives:
| case | exit | out bytes | out sha256 | match | rss kB | wall | what |
|---|---:|---:|---|---:|---:|---:|---|
| chain_p5fixture | 0 | 17 | `4ab9cb28f180436abbd3a768…` | YES | 21732 | 0:00.12 | P5-certified 41 B paq8px -0L archive of blob35.bin -> full chain -> 17 B original |
| chain_blob35_m1 | 0 | 17 | `4ab9cb28f180436abbd3a768…` | YES | 532868 | 0:00.93 | fresh -1 archive of blob35.bin -> full chain -> 17 B original |
| paq8px_stage_slice32k | 0 | 32768 | `252c561ddcdefb261e605f8e…` | YES | 563896 | 0:12.46 | real 32 KiB slice of blob67.bin, -1 archive -> shipped paq8px stage only |
Case 1 is the P5-certified fixture (`blob-paq.paq`, a genuine `paq8px -0L` archive of the real
35-byte blob `blob35.bin` whose chain output P5 recorded as sha256 `4ab9cb28…`) — **the shipped
bundle produces that same 17-byte output**. Case 2 is a *fresh* `-1` archive of the same blob, so the
chain is also proven through the CM model path at level 1. Case 3 decodes the 32 KiB real-blob-slice
archive with the payload extracted from `b.xz` (extracted payload sha256
`94cc29dbfb2dd1e9ac2ae96fd6699789935cc16585b145ed02ca83361e9764ce` = the built `dyn_Os` binary, i.e. the XZ round-trip is
byte-exact), exercising the generic/binary model path.
### 6c. Inverse stage on a real 2 MiB blob, and independent `unzip` re-verification
The bundle's `v` member (extracted from `v.xz`, sha256 `60015c60…`) was run on P5's real
1,666,504 B blob fixture
(`R1-store-recovery/b2case/blob2m.bin`): exit 0, 2,097,152 B out, sha256
`9dd214e64458c0c36f75a6100aed1a90a7b76ff9dfbb85dc032dea17a1963f50` — identical to P5's certified
`unblob2m.out`, in 0.13 s at 6,780 kB RSS. So both stages of the shipped chain are exercised on real
project data: the payload stage in §6a/§6b, the inverse stage here.
The shipped `out/bundle_dyn_Os/decompressor.zip` (204,244 B, sha256
`7a3899220efe888bd0d0e3affed875094afaea382ef1eda67eb1268a15b0071a`) was unpacked with the system
`unzip` in a fresh directory (`unzip -t`: "No errors detected"), and the launcher was run on both
archives: two runs, exit 0 each, 17-byte outputs, both sha256
`4ab9cb28f180436abbd3a76866c13eb3dc0797888908947f298eec7fb546bcd6` (expected).
### 6d. Flagship `-9` acceptance test
**By director decision (after V1's timing correction) B6 did not run a full-archive decode.**
Decoding the 60,634,501 B blob at `-9` costs roughly as long as the encode (~7 h at ~4.3 GB RSS; P1's own receipt for the 1 MB blob arm at `-9` is 7:36 min / 4,042,460 kB, which scales linearly), so a B6 run would have duplicated the verifier's certification decode hour for hour. The waiter B6 had armed under `locked_run.sh 14400` (full67 + a poc slot, MemAvailable >= 2,500,000 kB, archive-quiescence check) was cancelled before it ever acquired `full67`; the lock was never taken by B6. **The definitive full-archive proof is therefore V1's single certification decode, running exactly the shipped 204,244 B artifact** (`7a389922…`, components in §5) against `runs/full_blob_m9/blob_full.paq8px216`, expecting blob 60,634,501 B / `9c869f14…` and then `enwik8` 100,000,000 B / `2b49720e…`. What this report contributes to that decode: the artifact receipt, the measured performance envelope (level-1 decode peak RSS 563,896 kB; the `-Os` payload runs ~10-20 % slower than the `-O3` binary in §6a's single-run timings, so size the certificate window at ~7-9 h and ~4.3 GB), and the fact that both stages were already exercised end-to-end on real project archives below.
### 6e. What is *not* yet proven
The `-9` level itself has not been exercised by B6 — every B6 measurement is at `-0L`/`-1` (≤ 564 MB RSS) because a `-9` decode needs ~4.3 GB and hours, outside the light lane and duplicative of V1's certification decode. The residual risk is therefore exactly this: codegen behaviour at `-9`'s larger model tables. It is bounded by construction — identical source commit, `-ffp-contract=off -fno-fast-math` preserved, no `-march=native`, and `Shared::mem = 65536 << level` means the level changes only table *sizes*, not which models run, so the level-1 proof exercises the same model code — but it is retired only by the verifier's single `-9` certification decode of this artifact, and by nothing B6 did. If that decode fails, the fallback is `dyn_O3` (443,156 B, §7, also proven on the small chain, packaged and waiting at `out/bundle_dyn_O3/decompressor.zip`), whose codegen is P1's exact `-O3 -flto` recipe with only `-static` removed.
```sh
cd <unpacked bundle> && ./d /path/blob_full.paq8px216 /path/restored_blob.bin # the inverse stage
# paq8px stage alone (no inverse), to compare against the blob hash directly:
python3 -c "import lzma,pathlib;p=pathlib.Path('.');(p/'b').write_bytes(lzma.open(p/'b.xz').read())"
./b -d /path/blob_full.paq8px216 /path/restored_blob.bin
sha256sum /path/restored_blob.bin # must equal 9c869f141bc91a9b164e2cd4faecfea5bb648bd996c8c0f5e865b4e4010be425
```
Residual risk is bounded by construction: same source commit, same `-ffp-contract=off -fno-fast-math`
semantics, no `-march=native`, and `Shared::mem = 65536 << level` means the level changes only model
*table sizes*, not which models run — the level-1 proof therefore exercises the same model code as
`-9`. The remaining uncertainty is codegen at larger tables, which the single `-9` decode settles.
## 7. Fallback ladder and lower-risk alternatives
If the verifier's `-9` decode of the winner hits anything unexpected, use the next rung — each rung is
packaged, hashed and small-chain proven, so no rework is needed:
1. **`dyn_O3`** — `out/bundle_dyn_O3/decompressor.zip`, **443,156 B**, sha256
`411bd72a8deb791e304f7d2ee56b86d35c6990166d90515b6d8f3de4be83b570` (proven 3/3 at bundle level).
2. **`static_Os`** — `out/bundle_static_Os/decompressor.zip`, 486,328 B (proven 3/3; no host DSOs).
3. **P5's original** — `P5-bundles/paq8px-blob/decompressor.zip`, 766,308 B, sha256
`debed42c…` (the published baseline, unchanged on disk).
Rungs 1–3 cost 238,912 / 282,084 / 562,064 B more than the winner respectively.
## 7b. Lower-risk alternatives (if a dynamic payload is unacceptable)
* **`dyn_O3`** (bundle 443,156 B): P1's exact `-O3 -flto=2` flags, only
`-static` removed. Same optimization level as the proven binary, so the codegen risk is the
smallest of any candidate; costs 238,912 B more.
* **`static_Os`** (bundle 486,328 B): fully static, needs no host
libstdc++/libc at all. Costs 282,084 B more
than the winner but is self-contained.
* The winner and `dyn_O3`/`static_Os` are dynamic/static respectively: `dyn_Os` requires
`ld-linux-x86-64.so.2`, `libc.so.6`, `libstdc++.so.6` (+ transitive `libm`/`libgcc_s`) on the
decode host, exactly like the published 16,306 B baseline ELF and like cmix/paq8l/paq9a in P5's
table. `static_Os` removes that requirement entirely.
## 8. Boundaries
* No source line was modified; no transform/model was removed; nothing about what the decoder outputs
changed. Only build flags, link mode, and payload packing.
* Not attempted (and reported as such): pruning encoder-only code or the LSTM (would change the
decoder's capability set and needs its own behavioural proof), and `-march=native` (portability).
* Measured-but-rejected levers, with numbers, are in §2/§3 so nothing is silently dropped.
* Light-lane discipline held: every build ≤ 285,260 kB peak RSS, every decode test ≤ 564,120 kB;
no heavy encode, no lock taken, no pattern-kill, nothing written outside `swarm67/B6-bundle/`.
* The full-archive `-9` decode was planned, armed under `locked_run.sh`, and then **cancelled before it
ever acquired `full67`** once V1's timing correction (~7 h, not ~23 min) showed it would duplicate
the verifier's certification decode. That decode, on exactly this 204,244 B artifact, is the
definitive full-archive proof; B6's evidence is the small-chain/real-archive work in §6.

Xet Storage Details

Size:
21.4 kB
·
Xet hash:
664257c07976355597b8404b7d99ffa3d578a0aeba7dac5d5f0f40d4ba618050

Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.