Repository navigation
Conversation
Collaborator
|
cc @rust-lang/wg-const-eval |
This comment has been minimized.
This comment has been minimized.
ywxt
marked this pull request as draft
October 31, 2026 08:39
ywxt
marked this pull request as ready for review
November 3, 2026 11:19
This branch has not been deployed
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 PR implements the SIMD UTF-8 validation lookup algorithm proposed by Keiser and Lemire.
There have been several previous attempts to improve UTF-8 validation, but they raised various concerns:
Test utf8 validaiton based on rust-isutf8 #68463: SIMD implementation using SSE3 intrinsics and targeting AVX2, while Rust's default x86 target feature level is SSE2. This PR instead targets AArch64, where NEON is enabled by default.
Faster UTF-8 string validation #111367:
It did not report the error position on validation failure. This PR falls back to the scalar path to preserve the existing error reporting behavior.
It included only a small set of benchmarks and did not cover enough real-world workloads. See the benchmark results below.
Rewrite libcore's UTF-8 validation for performance #107760 and Rewrite UTF-8 validation in shift-based DFA for 70%~135% performance increase on non-ASCII strings #136693:
They used a large lookup table of about 1 KiB, which is less suitable for embedded environments. This PR adds only three 16-byte lookup tables, for a total of 48 bytes.
They also lacked sufficient benchmark coverage.
The current implementation still has regressions for small inputs and early errors. I would appreciate suggestions on how to improve this.
r? @Amanieu
1. Overall
2. UTF-8 microbenchmarks
Aligned
Unaligned
3. Real-world web / book text
Aligned
Unaligned
4. CBOR
benchmarks: https://github.com/oxalica/shift-dfa-utf8/blob/d2b25627de764d1e857095bcf72136f921dd7d27/bench-de/benches/cbor.rs