Skip to content

minor optimization for -mbmi2 compilation flag - #4746

Merged
Cyan4973 merged 2 commits into
devfrom
cctx-static-bmi2
Aug 27, 2026
Merged

Cyan4973 merged 2 commits into
devfrom
cctx-static-bmi2

Conversation

@Cyan4973

Copy link
Copy Markdown
Contributor

When -mbmi2 is specified, the code is compiled with bmi2 supposed present,
therefore there is no need to check for the presence of this feature flag in the cpuid,
saving one request at each CCtx creation.

This is correctly optimized on the decompression side,
but not on the compression side, which still issues a request.

On systems working on top of VMs, the cpuid request is intercepted,
and its resolution is much longer than usual on bare metal,
moving up from ~100ns to ~2us.
Consequently, in scenarios where small files are repetitively compressed using fast mode while not re-using a CCtx,
this request is paid at each compression, and is no longer negligible.

This is fixed in this PR.

@Cyan4973 Cyan4973 self-assigned this Aug 27, 2026
@meta-cla meta-cla Bot added the CLA Signed label Aug 27, 2026
The decompression side already compiles out its runtime BMI2 probe when
DYNAMIC_BMI2 is 0. The compression side did not: cctx->bmi2 was
unconditional, so both ZSTD_initCCtx() and ZSTD_initStaticCCtx() issued a
CPUID sequence per context even under -mbmi2, where the result is unused.

Mirror the decompression side: guard the field and both assignments, add
ZSTD_CCtx_get_bmi2(). Also route ZSTD_initStaticCCtx() through
ZSTD_cpuSupportsBmi2(), which checks BMI1 as well — required because
BMI2_TARGET_ATTRIBUTE enables "lzcnt,bmi,bmi2".

ZSTD_createCCtx + ZSTD_freeCCtx under -mbmi2: 2031 -> 100 ns; unchanged
without it. Fuzzer and zstreamtest pass under -O2, -mbmi2, and
-DDYNAMIC_BMI2=0.
Both bmi2 fields claimed "== 1 if the CPU supports BMI2 and 0 otherwise",
which is false for the value consumers actually see: when BMI2 is enabled
at compile time, DYNAMIC_BMI2 is 0 and the accessors return 0 even though
the CPU does support BMI2. The value selects between the default and the
BMI2_TARGET_ATTRIBUTE variant of a function; it is not a capability bit.

Benign today, since every consumer ignores it when DYNAMIC_BMI2 is 0, but
it invites future code to branch on it as a capability test and silently
take the wrong path on the fastest machines.

Comments only, no functional change.
@Cyan4973
Cyan4973 merged commit 10da6ba into dev Aug 27, 2026
109 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant