Repository navigation
compat.zlib-ng 2.3.3: zlib's API with NEON and SSE2 paths chosen at compile time - #727
Merged
Merged
Conversation
…ompile time The ok image of mcppls-clangd reads its index shards through zlib; against macOS's own libz its warm start took 1.214-1.332 times the processor time with compat.zlib and 0.973-1.107 with no zlib (mcpp design 2026-11-08, W5). Co-authored-by: speak-agent <248744407+speak-agent@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
compat.zlib-ng 2.3.3
zlib-ng in its zlib-compatible form: zlib's API (
zlib.h,compress2,uncompress,inflate, gz files) and zlib's streams, with the inner loops of inflate, adler32 and the deflate match search written for the processor's vector unit.Why
mcppls-clangd's ok image reads its index shards through zlib. On darwin-arm64 the image's warm start against a native clangd linked to macOS's NEON libz measured, per pair, the following processor-time ratios (limit 1.15):
The two sets don't overlap, and the gap is far wider than the 0.03 spread. That makes the decompression the cause (mcpp-community/mcpp design 2026-11-08, W5).
Shape
WITH_RUNTIME_CPU_DETECTION=OFFbuild: each function binds at compile time to the best path the architecture's baseline guarantees. That is NEON on aarch64 (inflate_fast, adler32, chunkmemset, slide_hash, compare256, longest_match) and SSE2 on x86_64. An ok image needs this form because openkal names no processor feature. Paths beyond the baseline (Armv8 CRC32, SSSE3, AVX2, PCLMULQDQ) need a program-wide flag or run-time detection and are not built. The CRC32 instructions matter only to gzip streams; a zlib stream, which LLVM writes, is checked with adler32.#ifdef ARM_NEON,#ifdef X86_SSE2), and a generated configuration header sets the gate from the compiler's own architecture macro.arch/x86/slide_hash_sse2.chas no gate and is compiled through a generated forwarder.zlib.h,zconf.h,zlib_name_mangling.handgzread_mangle.hfrom the tarball's templates. zconf.h'sHAVE_UNISTD_Hline is written as#if !defined(_WIN32), so the library and every consumer computez_off_tfrom one text.mcpp-res/zlib-ng2.3.3 is published and byte-identical to GLOBAL (sha256f9c65aa9…07d1).Tests
tests/examples/zlib-ngchecks:gzgetc;z_off_t.The member is added to the openkal measurement list.
Local runs:
x86_64-linux-gnu(GCC 16): pass.x86_64-openkal: pass.aarch64-openkal: built;inflatecallsinflate_fast_neon.inflatecallsinflate_fast_sse2.