Add kernel interface, generic impl, and test suite (#848)#848
Open
terrelln wants to merge 4 commits into
Open
Conversation
|
@terrelln has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109878842. |
terrelln
added a commit
to terrelln/openzl
that referenced
this pull request
Jun 29, 2026
Summary: Introduces the architecture-specific kernel interface for the Huffman Pivoted codec along with a portable, correctness-oriented generic implementation and the kernel test suite. The `ZL_HuffmanPivotedEncode` and `ZL_HuffmanPivotedDecode` structs provide the interface to cleanly swap between implementations based on the CPU. The `select()` function will pick the best implementation based on the current CPU, when they are added, but for now just returns the generic implementation. These are the kernels defined in the [PivCo Huffman paper](https://arxiv.org/pdf/2606.05765). The only difference is the encode side is modified following the same strategy as the [upstream repo](https://github.com/MarcinZukowski/pivco-huffman) to operate on `uint8_t rank` values, rather than `uint16_t codeword` values. The reasoning for how that change work is explained in the next diff, but the benefit is working on `uint8_t` instead of `uint16_t`. Note that some buffers require `SLOP` bytes at the end, and `partitionFull` has an odd aliasing requirement. These are constraints that are imposed by the full implementation in the next diff. Differential Revision: D109878842
terrelln
force-pushed
the
export-D109878842
branch
from
a739046 to
624807c
Compare
terrelln
added a commit
to terrelln/openzl
that referenced
this pull request
Jun 29, 2026
Summary: Introduces the architecture-specific kernel interface for the Huffman Pivoted codec along with a portable, correctness-oriented generic implementation and the kernel test suite. The `ZL_HuffmanPivotedEncode` and `ZL_HuffmanPivotedDecode` structs provide the interface to cleanly swap between implementations based on the CPU. The `select()` function will pick the best implementation based on the current CPU, when they are added, but for now just returns the generic implementation. These are the kernels defined in the [PivCo Huffman paper](https://arxiv.org/pdf/2606.05765). The only difference is the encode side is modified following the same strategy as the [upstream repo](https://github.com/MarcinZukowski/pivco-huffman) to operate on `uint8_t rank` values, rather than `uint16_t codeword` values. The reasoning for how that change work is explained in the next diff, but the benefit is working on `uint8_t` instead of `uint16_t`. Note that some buffers require `SLOP` bytes at the end, and `partitionFull` has an odd aliasing requirement. These are constraints that are imposed by the full implementation in the next diff. Differential Revision: D109878842
terrelln
added a commit
to terrelln/openzl
that referenced
this pull request
Jun 29, 2026
Summary: Introduces the architecture-specific kernel interface for the Huffman Pivoted codec along with a portable, correctness-oriented generic implementation and the kernel test suite. The `ZL_HuffmanPivotedEncode` and `ZL_HuffmanPivotedDecode` structs provide the interface to cleanly swap between implementations based on the CPU. The `select()` function will pick the best implementation based on the current CPU, when they are added, but for now just returns the generic implementation. These are the kernels defined in the [PivCo Huffman paper](https://arxiv.org/pdf/2606.05765). The only difference is the encode side is modified following the same strategy as the [upstream repo](https://github.com/MarcinZukowski/pivco-huffman) to operate on `uint8_t rank` values, rather than `uint16_t codeword` values. The reasoning for how that change work is explained in the next diff, but the benefit is working on `uint8_t` instead of `uint16_t`. Note that some buffers require `SLOP` bytes at the end, and `partitionFull` has an odd aliasing requirement. These are constraints that are imposed by the full implementation in the next diff. Differential Revision: D109878842
terrelln
added a commit
to terrelln/openzl
that referenced
this pull request
Jun 29, 2026
Summary: Introduces the architecture-specific kernel interface for the Huffman Pivoted codec along with a portable, correctness-oriented generic implementation and the kernel test suite. The `ZL_HuffmanPivotedEncode` and `ZL_HuffmanPivotedDecode` structs provide the interface to cleanly swap between implementations based on the CPU. The `select()` function will pick the best implementation based on the current CPU, when they are added, but for now just returns the generic implementation. These are the kernels defined in the [PivCo Huffman paper](https://arxiv.org/pdf/2606.05765). The only difference is the encode side is modified following the same strategy as the [upstream repo](https://github.com/MarcinZukowski/pivco-huffman) to operate on `uint8_t rank` values, rather than `uint16_t codeword` values. The reasoning for how that change work is explained in the next diff, but the benefit is working on `uint8_t` instead of `uint16_t`. Note that some buffers require `SLOP` bytes at the end, and `partitionFull` has an odd aliasing requirement. These are constraints that are imposed by the full implementation in the next diff. Differential Revision: D109878842
terrelln
force-pushed
the
export-D109878842
branch
from
624807c to
61faf22
Compare
terrelln
added a commit
to terrelln/openzl
that referenced
this pull request
Jun 29, 2026
Summary: Introduces the architecture-specific kernel interface for the Huffman Pivoted codec along with a portable, correctness-oriented generic implementation and the kernel test suite. The `ZL_HuffmanPivotedEncode` and `ZL_HuffmanPivotedDecode` structs provide the interface to cleanly swap between implementations based on the CPU. The `select()` function will pick the best implementation based on the current CPU, when they are added, but for now just returns the generic implementation. These are the kernels defined in the [PivCo Huffman paper](https://arxiv.org/pdf/2606.05765). The only difference is the encode side is modified following the same strategy as the [upstream repo](https://github.com/MarcinZukowski/pivco-huffman) to operate on `uint8_t rank` values, rather than `uint16_t codeword` values. The reasoning for how that change work is explained in the next diff, but the benefit is working on `uint8_t` instead of `uint16_t`. Note that some buffers require `SLOP` bytes at the end, and `partitionFull` has an odd aliasing requirement. These are constraints that are imposed by the full implementation in the next diff. Differential Revision: D109878842
terrelln
added a commit
to terrelln/openzl
that referenced
this pull request
Jun 29, 2026
Summary: Introduces the architecture-specific kernel interface for the Huffman Pivoted codec along with a portable, correctness-oriented generic implementation and the kernel test suite. The `ZL_HuffmanPivotedEncode` and `ZL_HuffmanPivotedDecode` structs provide the interface to cleanly swap between implementations based on the CPU. The `select()` function will pick the best implementation based on the current CPU, when they are added, but for now just returns the generic implementation. These are the kernels defined in the [PivCo Huffman paper](https://arxiv.org/pdf/2606.05765). The only difference is the encode side is modified following the same strategy as the [upstream repo](https://github.com/MarcinZukowski/pivco-huffman) to operate on `uint8_t rank` values, rather than `uint16_t codeword` values. The reasoning for how that change work is explained in the next diff, but the benefit is working on `uint8_t` instead of `uint16_t`. Note that some buffers require `SLOP` bytes at the end, and `partitionFull` has an odd aliasing requirement. These are constraints that are imposed by the full implementation in the next diff. Differential Revision: D109878842
Summary: See https://www.internalfb.com/code/fbsource/[0b9e4a2588b4f716d3259505ea591a25cea158a1]/fbcode/folly/CpuId.h?lines=155-164 Reviewed By: daniellerozenblit Differential Revision: D109877948
Summary: As title Reviewed By: daniellerozenblit Differential Revision: D109877947
Summary: Adds byte-aligned bit reservation and pop primitives to the FF bitstream, needed by the upcoming PivCo-Huffman kernels: - `ZS_BitCStreamFF_reserveAlignedBits` / `ZS_BitCStreamFF_commitReservedBits` on the write side. - `ZS_BitDStreamFF_popAlignedBits` on the read side, plus a `begin` cursor in `ZS_BitDStreamFF` so the reader can compute byte offsets. - `ZS_BitDStreamFF_finish` now returns the number of bytes consumed. - Hardens `ZS_BitCStreamFF_init`/`_finish`/`_flush` against small buffers by avoiding pointer arithmetic that could underflow. Differential Revision: D109878843
Summary: Introduces the architecture-specific kernel interface for the PivCo-Huffman codec along with a portable, correctness-oriented generic implementation and the kernel test suite. The `ZL_PivCoHuffmanEncode` and `ZL_PivCoHuffmanDecode` structs provide the interface to cleanly swap between implementations based on the CPU. The `select()` function will pick the best implementation based on the current CPU, when they are added, but for now just returns the generic implementation. These are the kernels defined in the [PivCo Huffman paper](https://arxiv.org/pdf/2606.05765). The only difference is the encode side is modified following the same strategy as the [upstream repo](https://github.com/MarcinZukowski/pivco-huffman) to operate on `uint8_t rank` values, rather than `uint16_t codeword` values. The reasoning for how that change work is explained in the next diff, but the benefit is working on `uint8_t` instead of `uint16_t`. Note that some buffers require `SLOP` bytes at the end, and `partitionFull` has an odd aliasing requirement. These are constraints that are imposed by the full implementation in the next diff. Differential Revision: D109878842
terrelln
force-pushed
the
export-D109878842
branch
from
61faf22 to
4297c51
Compare
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
1 participant
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.
Summary:
Introduces the architecture-specific kernel interface for the PivCo-Huffman codec along with a portable, correctness-oriented generic implementation and the kernel test suite.
The
ZL_PivCoHuffmanEncodeandZL_PivCoHuffmanDecodestructs provide the interface to cleanly swap between implementations based on the CPU. Theselect()function will pick the best implementation based on the current CPU, when they are added, but for now just returns the generic implementation.These are the kernels defined in the PivCo Huffman paper. The only difference is the encode side is modified following the same strategy as the upstream repo to operate on
uint8_t rankvalues, rather thanuint16_t codewordvalues. The reasoning for how that change work is explained in the next diff, but the benefit is working onuint8_tinstead ofuint16_t.Note that some buffers require
SLOPbytes at the end, andpartitionFullhas an odd aliasing requirement. These are constraints that are imposed by the full implementation in the next diff.Differential Revision: D109878842