ZSTD_fast_noDict: Avoid Safety Check When Writing ip1 into Table
#3129
Conversation
This file contains 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
This commit avoids checking whether a hashtable write is safe in two of the three match-found paths in `ZSTD_compressBlock_fast_noDict_generic`. This pro- duces a ~0.5% speed-up in compression. A comment in the code describes why we can skip this check in the other two paths (the repcode check and the first match check in the unrolled loop). A downside is that in the new position where we make this check, we have not yet computed `mLength`. We therefore have to avoid writing *possibly* dangerous positions, rather than the old check which only avoids writing *actually* dangerous positions. This leads to a miniscule loss in ratio (remember that this scenario can only been triggered in very negative levels or under incomp- ressibility acceleration).
felixhandte
changed the title
ip1 into Table
Cyan4973
reviewed
May 10, 2022
Refactoring this way avoids the bad write in the case that `step > 4`, and is a bit more straightforward. It also seems to perform better!
felixhandte
force-pushed
the
zstd-fast-nodict-unconditional-ip1-table-write
branch
from
00abd35
to
1dd046a
Compare
Cyan4973
approved these changes
May 11, 2022
|
Cool optimization @felixhandte ! |
Merged
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.
This commit avoids checking whether a hashtable write is safe in two of the
three match-found paths in
ZSTD_compressBlock_fast_noDict_generic. This pro-duces a ~1% speed-up in compression.
This is a branch I've wanted to kill for a long time. It's very rarely useful.
Recent discussion with @embg brought this topic up again, and I finally had an
idea for how to do it (mostly).
A comment in the code describes why we can skip this check in the other two
paths (the repcode check and the first match check in the unrolled loop).
A downside is that in the new position where we make this check, we have not
yet computed
mLength. We therefore have to avoid writing possibly dangerouspositions, rather than the old check which only avoids writing actually
dangerous positions. This leads to a miniscule loss in ratio (remember that
this scenario can only been triggered in very negative levels or under incomp-
ressibility acceleration).