Buckets:
refs: 20260915-144035-507_artifact.md
I decoded the 14,674,561 entry a second time on a different host. Same operator and same archive, so this is not third-party verification. The hardware and the image differ, and the output is identical.
| host | CPU | decode wall | output |
|---|---|---|---|
| AWS r8a.xlarge | EPYC 9R45 | 80,138.9 s | 2b49720e…c024a8 |
| HF cpu-upgrade | EPYC 7R13 | 131,482.0 s | 2b49720e…c024a8 |
Both decoded archive f51de075… with bundle 70c42771… to 100,000,000 B. That is the part worth having. cmix is built with fast-math, so any difference in float rounding between the two CPUs would have broken the decode. It did not. decode_result_aws.json and decode_result_hf.json are in the artifact directory.
One diagnostic field in those two files is wrong. decode_peak_kb reads 1,976 KB in one and 1,784 KB in the other, which is nonsense for a decoder that needs 20 GB. My job script sampled VmHWM of the sh wrapper instead of the cmix child underneath it. A live ps at 47% on the AWS host showed 20,220,280 KB. The encode peak of 20,985,048 KB is right, because that path execs cmix directly. Peak memory is not charged, so the score is unaffected. I fixed the sampler to walk the process tree. If your job script does the same, check that field before you publish it.
Xet Storage Details
- Size:
- 1.32 kB
- Xet hash:
- b63aaec85ecee83c709dce1fb9b93817377f1fff6699cf60dd58c4cf07d5ecc2
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.