Speedup expected_errors by using a lookup table #700
Merged
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
rhpvorderman
force-pushed
the
fasterexpectederrors
branch
from
f15bcc3
to
ebcb997
Compare
|
Very nice, much appreciated! (as always) |
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.
Also includes a check if every phred score is in fact a valid phred score. By assigning the phreds to a uint8_t array, the
quals[i] - basecalculation is unsigned, and thus the result will always be positive. If the invalid character is a phred lower than 33, say 10, then it will map to 245. As a result we can check all phreds with only one check: are they higher than 93?A lookup table is much faster than the expensive exponent calculations for floats. Especially since the lookup table will fit easily in L1-cache, the lookup time is at most ~3-4 clock cycles, which is hard to beat using arithmetic.