zlib-ng / zlib-ng / 29326637512 / 49

93%

develop: 93%

push

github

Read bits with zero refill latency

Look up the next length code before refilling the bit buffer, so the
refill's load latency overlaps with the table load instead of feeding
it. This is a small but confusing change discussed here:
https://dougallj.wordpress.com/2022/08/26/reading-bits-with-zero-refill-latency/

The loop-entry invariant becomes: hold contains at least the
MAX_LEN_ROOT_BITS (10) bits needed for the first-level length table
lookup. The refill before the loop establishes it, the literal-only
paths consume at most 35 of the 56+ bits from the in-loop refill, and
the distance path's conditional refill threshold is raised by
MAX_LEN_ROOT_BITS so that consuming the distance code and extra bits
(up to MAX_BITS + MAX_DIST_EXTRA_BITS) still leaves enough. The new
MAX_LEN_ROOT_BITS constant replaces the hardcoded 10 at the
state->lenbits assignments in inflate.c and infback.c so the invariant
cannot silently drift.

INFLATE_FAST_MIN_HAVE stays 15: there are still at most two 8-byte
refill reads per iteration, the first at the position validated by the
loop bound (advancing at most 7 bytes), and the pre-loop refill reads
at the entry position (avail_in >= 15) advancing exactly 7 bytes with
bits >= 56 left over, so the first iteration's in-loop refill advances
0 bytes before its read.

Inflate benchmarks on Apple Silicon (clang, Release):

  benchmark_zlib inflate_nocrc/1048576:   139 us -> 121 us  (-13.1%)
  benchmark_zlib small_output_buf/16384:   49 us ->  42 us  (-12.9%)
  zlib-ng sources, level 9:  919 MB/s -> 1042 MB/s  (+13.4%)
  dict/words, level 6:       804 MB/s ->  916 MB/s  (+14.0%)
  static library, level 6:   709 MB/s ->  794 MB/s  (+12.0%)

Assisted-By: Claude Fable 5

4620 of 4971 branches covered (92.94%)

Branch coverage included in aggregate %.

8587 of 9515 relevant lines covered (90.25%)

670910.81 hits per line