Speed up the branchless UTF-8 decoder by removing !len #7
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
In your post, you say: "Adding that !len is actually somewhat costly, though I couldn’t figure out why." My suspicion was that it is because the "!" operator would essentially behave like a branch, returning 1 if the input is 0 and 0 otherwise. So, my idea was to copy the table of lengths you have and create another one for "error lengths" to get that same effect (0 when it's OK and 1 when there is an error, to ensure that it moves forward at least one byte, as mentioned). The throughput went up from 504 MB/s to 557 MB/s on my machine.
|
For what it's worth, I actually see the speed drop from |
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.
In your post, you say: "Adding that !len is actually somewhat costly,
though I couldn’t figure out why."
My suspicion was that it is because the "!" operator would essentially
behave like a branch, returning 1 if the input is 0 and 0 otherwise.
So, my idea was to copy the table of lengths you have and create another
one for "error lengths" to get that same effect (0 when it's OK and 1
when there is an error, to ensure that it moves forward at least one
byte, as mentioned).
The throughput went up from 504 MB/s to 557 MB/s on my machine.