Add plain Vector128 support to IndexOfAnyAsciiSearcher #92680
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-buffers Issue DetailsContributes to dotnet/perf-autofiling-issues#21818 I believe this should be an okay implementation correctness-wise, but it's up to Mono implementations how efficiently they can handle the @fanyang-mono could you please check how this impacts Mono perf?
|
|
For initial validation, please run affected microbenchmarks from dotnet/perf-autofiling-issues#21818 using this script https://github.com/dotnet/performance/blob/main/scripts/benchmarks_local.py You should run them against both Mono JIT and Mono interpreter. It could be achieved by passing |
| @@ -42,7 +42,7 @@ internal override int IndexOfAny(ReadOnlySpan<char> span) | |||
|
|
|||
| // We check whether the first character is ASCII before calling into IndexOfAnyAsciiSearcher | |||
| // in order to minimize the overhead this fast-path has on non-ASCII texts. | |||
| if (IndexOfAnyAsciiSearcher.IsVectorizationSupported && span.Length >= Vector128<short>.Count && char.IsAscii(span[0])) | |||
There was a problem hiding this comment.
I think we need to keep IsSupported checks to ensure trimming works as expected on platforms without SIMD support.
There was a problem hiding this comment.
Is that needed even though all its ctor uses are guarded behind it?
There was a problem hiding this comment.
R2R has some special rules for various ISA checks and I'm pretty sure we expect them to be used even when all callers are expected to guard a given path.
CC. @davidwrighton
ghost
closed this
|
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
ghost
locked as resolved and limited conversation to collaborators
Contributes to dotnet/perf-autofiling-issues#21818
I believe this should be an okay implementation correctness-wise, but it's up to Mono implementations how efficiently they can handle the
Vector128paths (e.g. efficiently handingVector128.Shufflewith non-const indices).@fanyang-mono could you please check how this impacts Mono perf?
We shouldn't merge this without good validation as it will affect most uses of
SearchValues.