Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try Vector128 before Vector #89797

Merged
merged 1 commit into from
Aug 4, 2023
Merged

Try Vector128 before Vector #89797

merged 1 commit into from
Aug 4, 2023

Conversation

lewing
Copy link
Member

@lewing lewing commented Aug 1, 2023

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)

@ghost
Copy link

ghost commented Aug 1, 2023

Tagging subscribers to this area: @dotnet/area-system-text-encoding
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author: lewing
Assignees: lewing
Labels:

area-System.Text.Encoding

Milestone: -

@lewing lewing marked this pull request as ready for review August 1, 2023 17:24
@lewing lewing requested review from anthonycanino and kg August 1, 2023 17:27
@@ -109,6 +109,10 @@ internal static unsafe nuint GetIndexOfFirstNonAsciiByte(byte* pBuffer, nuint bu
{
return GetIndexOfFirstNonAsciiByte_Intrinsified(pBuffer, bufferLength);
}
else if (Vector128.IsHardwareAccelerated)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would prefer the Vector128 path for wasm

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, understood. Thanks for the context.

Copy link
Member

@tannergooding tannergooding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. This just adds to the reasons why having a single shared implementation using the xplat APIs is goodness.

@stephentoub stephentoub merged commit 3be370e into dotnet:main Aug 4, 2023
168 checks passed
@lewing lewing deleted the vector128 branch August 5, 2023 01:30
@ghost ghost locked as resolved and limited conversation to collaborators Sep 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants