validating utf8 to utf16 converter (x64 and NEON)#26
Merged
Conversation
Collaborator
WojciechMula
left a comment
There was a problem hiding this comment.
Really nice! Now I see the benefits of having these generic vector types.
Collaborator
|
@lemire We already have very good results, despite these arabic-text quirks. Please merge. |
Member
Author
|
Merged. |
Member
Author
|
@WojciechMula We can change splat, I really, really don't care. I just wanted to say that it is not an arbitrary term. |
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
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 is the first version of a SIMD-based validating utf8 to utf16 converter. It works under ARM NEON, SSE and AVX.
x64 (AMD Rome, GNU GCC 1)
ARM M1 (Apple system)
Maybe unsurprisingly, the results are much more impressive under x64 systems.
Observe how arabic is "slow". I am not 100% sure why but here are general observations. English seems to have sizeable series of ASCII characters, with a few exceptions. (It is definitively not pure ASCII.) French is much the same with a bit less ASCII. Chinese mixes 3-byte UTF8 with ASCII. Arabic seems to be all over the map.
Here are the branch misses per byte for the fallback kernel:
The number of branch mispredictions looks to be pretty much predicting the performance for the fallback kernels.
Fixes https://github.com/lemire/simdutf/issues/14
Fixes https://github.com/lemire/simdutf/issues/7
Raw outputs...