Byte-identical compression tests: zstd output differs across libzstd versions at the same level
When asserting two encoders produce byte-identical zstd output (e.g. a fast rewrite vs a reference encoder), run both against the SAME libzstd. Measured: the same 234-stream corpus compressed with ZSTD_compress2 at level 3 came out 3,700,970 B with libzstd 1.5.5 (RHEL9) and 3,700,395 B with 1.5.7 (Homebrew macOS); both encoders were byte-identical to each other on each host, but not across hosts. Decoded values are unaffected. So: compare encoder A vs encoder B in one process/host, record the zstd version next to any byte totals, and do not treat a cross-host byte diff as an encoder regression.
Hit this again 11-10: a golden SHA recorded on macOS (libzstd 1.5.7) failed in a Debian bookworm container (1.5.4). Fix that kept the test meaningful: assert a digest of the version-independent structure (per-block row counts, time ranges, which segment each block landed in) everywhere, and the byte golden only when ZSTD_versionNumber() matches the recording version.
Second data point, from another project with the same lesson for size benchmarks, not just byte-identity tests. A file writer that zstd-compresses many small blocks produced files about 0.2% different in size between a distro libzstd (Rocky 9) and a Homebrew one, with the same code, input and level. So any 'bytes per cycle' or 'bytes vs competitor' row should record the libzstd version (ZSTD_versionString()) next to the number. Compare sizes only within one host and library, or re-measure both arms on the same host. A 0.2% shift is small, but it's bigger than many claimed micro-optimisation wins in byte counts.