miniz Optimization: Checksums Win Before the Codec Does

The AMD measurements below were taken on:

The comparison Apple system was an Apple M4 Pro on macOS 15.5. Treat absolute throughput as machine-specific. The durable part is the pattern of which work can be widened and which work remains serial.

Random data, median throughput:

The valid 64 MiB checksum wins are:

This is the cleanest part of the optimization story. Checksums are simple streams over bytes. Their state is small, their memory access is regular, and their correctness can be checked against many buffer shapes.

The isolated microbenchmarks explain why some ideas helped and some did not:

The AVX2 match comparison win is real in isolation:

scalar compare: 2741.6 MB/s
AVX2 compare:  12356.8 MB/s

The match comparison hot path is exactly the kind of work SIMD likes: load two regular byte ranges, compare them, and stop at the first mismatch.

static size_t equal_prefix_avx2(
    const uint8_t* a,
    const uint8_t* b,
    size_t limit) {
  size_t i = 0;

  while (i + 32 <= limit) {
    const __m256i va = _mm256_loadu_si256(
        reinterpret_cast<const __m256i*>(a + i));
    const __m256i vb = _mm256_loadu_si256(
        reinterpret_cast<const __m256i*>(b + i));
    const __m256i eq = _mm256_cmpeq_epi8(va, vb);
    const uint32_t mask =
        static_cast<uint32_t>(_mm256_movemask_epi8(eq));

    if (mask != 0xffffffffu) {
      return i + static_cast<size_t>(__builtin_ctz(~mask));
    }

    i += 32;
  }

  while (i < limit && a[i] == b[i]) {
    ++i;
  }

  return i;
}

But the copy and prefetch results are the caution sign:

• libc memcpy beat the simple custom AVX2 copy by about 1.95x;
• prefetching the chain walk was slower than not prefetching;
• isolated wins only matter when the full codec exposes enough of that work.

The losing copy experiment was not mysterious. It was a simple fixed-width copy, and libc already had a better implementation on this machine.

static inline void copy64_avx2(uint8_t* dst, const uint8_t* src) {
  const __m256i a = _mm256_loadu_si256(
      reinterpret_cast<const __m256i*>(src));
  const __m256i b = _mm256_loadu_si256(
      reinterpret_cast<const __m256i*>(src + 32));

  _mm256_storeu_si256(reinterpret_cast<__m256i*>(dst), a);
  _mm256_storeu_si256(reinterpret_cast<__m256i*>(dst + 32), b);
}

The prefetch experiment had the same lesson. Adding a prefetch instruction is not the same thing as hiding latency:

for (size_t i = 0; i < chain_length; ++i) {
  const Link* next = cursor->next;

  if (next != nullptr) {
    __builtin_prefetch(next, 0, 1);
  }

  checksum += cursor->value;
  cursor = next;
}

That pattern only helps when the next address is known early enough and the prefetch distance matches the machine.

These optimizations only count when they preserve the byte stream.

The checksum tests cover empty, short, unaligned, random, repeated, and large buffers. Incremental checksum calls are compared with one-shot calls. Codec rows are accepted only when decompression reproduces the original bytes.

The checksum validation has a simple shape:

static bool same_crc32_behavior(const uint8_t* p, size_t n) {
  const uint32_t one_shot_ref = crc32_reference(0, p, n);
  const uint32_t one_shot_new = crc32_candidate(0, p, n);

  const size_t split = n / 2;
  uint32_t incremental = crc32_candidate(0, p, split);
  incremental = crc32_candidate(incremental, p + split, n - split);

  return one_shot_new == one_shot_ref &&
         incremental == one_shot_ref;
}

That is why the SSE4.2 CRC row is marked incorrect even though it is very fast. It answers a different checksum question.

The rule is:

measure speed only after proving the replacement is semantically identical