Uh oh!
There was an error while loading. Please reload this page.
Try Vector128 before Vector - #89797
Conversation
ghost
commented
Aug 1, 2023
Tagging subscribers to this area: @dotnet/area-system-text-encoding Issue Detailsnull
|
| { | ||
| return GetIndexOfFirstNonAsciiByte_Intrinsified(pBuffer, bufferLength); | ||
| } | ||
| else if (Vector128.IsHardwareAccelerated) |
There was a problem hiding this comment.
The above Sse2 or AdvSimd paths are the code paths that use Vector128 and are much more efficient than the associated Vector128 path.
I believe if it reaches this point, where we cannot use Vector512, Vector256, or Sse2/AdvSimd, then the Vector path itself will likely be as efficient and no need to call back into _Vector.
There was a problem hiding this comment.
We would prefer the Vector128 path for wasm
There was a problem hiding this comment.
Ok, understood. Thanks for the context.
tannergooding
left a comment
There was a problem hiding this comment.
LGTM. This just adds to the reasons why having a single shared implementation using the xplat APIs is goodness.
After #88532 The code prefers Vector512/Vector256/AdvSimd but then falls back to Vector rather than Vector128 which is implemented in the _Vector method
(I didn't actually check the Vector128 path closely)