Add algorithm specification of XXH3 #750
No reviewers
Labels
No labels
announcement
bug
build
CI
dependencies
documentation
duplicate
enhancement
experience feedback
feature request
github_actions
help wanted
install
invalid
Long-term
optimization
portability
question
target-specific
test issue
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-Cyan4973/xxHash!750
Loading…
Reference in a new issue
No description provided.
Delete branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Update
xxhash_spec.mdto include XXH3 specification. Closes #589 and #675.Thanks @adrien1018 ! This is great work !
I think this documentation is in good shape, just give me a bit more time to read it in detail.
@ -52,2 +59,4 @@- `X xor Y`: denotes the bit-wise XOR of `X` and `Y` (same width).- `X | Y`: denotes the bit-wise OR of `X` and `Y` (same width).- `~X`: denotes the bit-wise negation of `X`.minor nit: use_ 64-bit modular (plural)
👍
It's interesting, the width of the modular arithmetic may be not obvious, making
*alone possibly insufficient to describe the operation.@ -327,0 +401,4 @@To make sure that all input bits have a chance to impact any bit in the output digest (avalanche effect), the final step of the XXH3 algorithm is usually one of the two fixed operations that mix the bits in a 64-bit value. These operation are denoted `avalanche()` and `avalanche_XXH64()` in the following XXH3 description.```ckudos for giving this constant a name
@ -327,0 +622,4 @@#### 129-240 bytes of inputThe input is split into 16-byte (XXH3-64) or 32-byte (XXH3-128) chunks. The first 128 bytes are first mixed chunk by chunk, followed by an intermediate avalanche operation. Then the remaining full chunks are processed, and finally the last 16/32 bytes are treated as a chunk to process.minor: this interface likely miss the
secretpointer parameter,the following code would only make sense if
secretwas a global variable only.@ -327,0 +730,4 @@acc[i] = acc[i] xor secretWords[i];acc[i] = acc[i] * PRIME32_1;}```👍
This is great work.
I only noticed a couple of nits, don't worry I'll fix them directly in my branch.
I'm even likely to update the source in a couple of ways to better follows the text of this specification.
Thanks @adrien1018 !
After reviewing the rest of the specification, I believe that the propose notification for 128-bit modular arithmetic does the job correctly.
@ -327,0 +622,4 @@#### 129-240 bytes of inputThe input is split into 16-byte (XXH3-64) or 32-byte (XXH3-128) chunks. The first 128 bytes are first mixed chunk by chunk, followed by an intermediate avalanche operation. Then the remaining full chunks are processed, and finally the last 16/32 bytes are treated as a chunk to process.I realize that not providing
secretas an input parameter is a good way to improve brevity, which is beneficial for readability.I think I'll keep it this way,
I just want to make it clear that
secretis not necessarily the standarddefaultSecret, it can also be any blob of bytes set by the user.There's already a paragraph about this point, which is probably clear enough.
Let's just ensure it.