Skip to content

Conversation

AntoinePrv
Copy link
Contributor

@AntoinePrv AntoinePrv commented Sep 16, 2025

Rationale for this change

Refactor the unpack function code generator and dispatcher to accommodate more use cases:

  • uint16_t and uint64_t new sizes
  • A dispatch once function returning a function pointer to the correct bit width

What changes are included in this PR?

The diff are hard to look at but the important files to look at are:

  • The two python files for code generation accommodate new sizes (with the exception of uint16 on Avx512 for which the algorithms assumptions break);
  • The two code generators have a uniform structure for the "batch unpackers" they generate: each one of them is a specialization of a struct template unpack29_32 > Unpacker<uint32_t, 29>::unpack
    • Using specialization instead of hard coded number in function names makes it possible to use them in more generic code
    • Wrapping the functions in a struct makes it possible to carry information along the function (such as the number of values that said function unpacks) and to leave the door open for partial specialization for future improvements.
  • The public functions in bpacking_internal.h are also template specialization unpack32 -> unpack<uint32_t>
  • The large switch statements and for loops used to dispatch the bit width to its appropriate implementation are now all generic with a constexpr generated jump table. The logic is in bpacking_dispatch_internal.h

From a performance perspective:

  • there is no improvement to the individual "batch unpacker" generated
    • The SIMD code is actually doing worst that scalar on SSE4.2 OR uint16_t
  • there are new sizes that can bring improvements
    • unpack<uint64_t> has an SIMD implementation that should benefit DeltaBitPackDecoder
    • Novel unpack<uint16_t> should benefit the level decoders
    • The dispatch once mechanism should benefit all repeated calls to unpack functions (still need mixing with dynamic dispatch, but see get_unpack_fn for the building block).

Are these changes tested?

Very much.

Are there any user-facing changes?

Copy link

⚠️ GitHub issue #47572 has been automatically assigned in GitHub to PR creator.

@AntoinePrv
Copy link
Contributor Author

The results for this are not good

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant