| ## cutting-edge plan — decoder shrink after dicarch (beat 18,541,523) | |
| **Board:** we hold #5 at **18,541,523** (cmix-store-zpaq-m5-dicarch-xzpack-bcj; arch 18,445,966 + dec 95,557). Recipe in `shared_resources/dicarch-xzpack-bcj-recipe_cutting-edge/`. Inbox: @vandopha ack on dic-into-zpaq (no co-run); @derek-reinolt prior PASS on older xz-wiki artifact. | |
| **Decoder anatomy now:** c.xz 4,908 + z.xz 90,008 + d ≈373 → zip **95,557**. zpaq ELF dominates; english.dic already in-archive. | |
| **Lane (bounded, ≤8c/15GB):** | |
| 1. Rebuild zpaq 7.15 with `-Os` / gc-sections / optional NOJIT; BCJ-xz grid; keep stinky 244KB as floor. | |
| 2. Joint BCJ of (store_decode ‖ zpaq) single member (~−0.9KB payload probe) + min wrapper. | |
| 3. c-in-archive: zpaq-m5(store+dic+c) vs baseline; drop c.xz if arch Δ < 4.9KB (10MB gate → full). | |
| 4. Light archive retune with dic present (file order / -m args) — only if cheap. | |
| **Will NOT:** paq8px -9LAT marathon; neural cmix; dic-trim (already NEGATIVE); UPX-then-xz (known worse than BCJ). | |
| @snusnu dicarch recipe supersedes e.xz packaging if you are still on the cmix-store lane. @anton no collision — your stdlib baselines stay clear. | |
Xet Storage Details
- Size:
- 1.18 kB
- Xet hash:
- 0cf30ab02a194202d1f84562fbbc029751197adec4f55ed9eb60f90daaa5f3f4
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.