-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Add non-cryptographic hash algorithms #53623
Conversation
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
Tagging subscribers to this area: @tannergooding, @pgovind Issue Details
Fixes #24328.
|
src/libraries/System.IO.Hashing/src/System/IO/Hashing/NonCryptographicHashAlgorithm.cs
Show resolved
Hide resolved
byte idx = (byte)crc; | ||
idx ^= source[i]; | ||
crc = s_crcLookup[idx] ^ (crc >> 8); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we be able to use any of the hardware intrinsics to speed this up if we had a .NET 6+ build?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to this. If we make this an inbox binary (which I think our partners would really want us to do), it'd make sense to intrinsicify these code paths.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we make this an inbox binary (which I think our partners would really want us to do)
If I understand correctly, our thoughts for this library is "pure OOB".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would the lib need to be inbox to benefit from hardware intrinsics? Doesn't it just need to compile against net6.0 which and could be included in the package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It only needs to compile against at least 3.0 to get acceleration on x86/x64 and 5.0 for acceleration on ARM64.
In particular, it would be nice if we just put the CRC32C
algorithm under: #2036 (which is approved just NYI) and had this API forward to it.
You can then also accelerate plain CRC32
on Arm64, but that requires explicit intrinsics usage outside an xplat helper method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, but those are CRC32C, not CRC32. If there's a sensible way to get from CRC32C to CRC32, then sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For regular CRC32 (that is the variant where 0x04C11DB7
is the polynomial) its only available to accelerate on ARM64 (at least via a direct instruction, although technically also for Arm32, we just don't have intrinsic support here).
For CRC32-C (that is the variant where 0x1EDC6F41
is the polynomial) its available to x86/x64 and ARM64.
src/libraries/System.IO.Hashing/src/System/IO/Hashing/XxHash32.State.cs
Outdated
Show resolved
Hide resolved
/// </summary> | ||
/// <remarks> | ||
/// <para> | ||
/// This implementation emits the answer in the Little Endian byte order so that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary here, but I wonder if our code sample docs should show using BinaryPrimitives.ReadInt32LittleEndian
to get this data back out.
src/libraries/System.IO.Hashing/src/System/IO/Hashing/XxHash64.State.cs
Outdated
Show resolved
Hide resolved
namespace System.IO.Hashing | ||
{ | ||
/// <summary> | ||
/// Provides an implementation of the XxHash32 algorithm. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we provide a code sample showing using this and extracting a 32-bit hash, our code sample should demonstrate using BinaryPrimitives.ReadUInt32BigEndian
to convert the byte array back to an integer. In particular, devs may be drawn to Convert.ToInt32
, which will not provide the correct answer. This code sample doesn't need to be in the devdoc, but I do think it's a potential pit of failure if we don't show an example.
namespace System.IO.Hashing | ||
{ | ||
/// <summary> | ||
/// Provides an implementation of the XxHash64 algorithm. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we provide a code sample showing using this and extracting a 64-bit hash, our code sample should demonstrate using BinaryPrimitives.ReadUInt64BigEndian
to convert the byte array back to an integer. In particular, devs may be drawn to Convert.ToInt64
, which will not provide the correct answer. This code sample doesn't need to be in the devdoc, but I do think it's a potential pit of failure if we don't show an example.
src/libraries/System.IO.Hashing/src/System/IO/Hashing/XxHash64.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.IO.Hashing/src/System/IO/Hashing/XxHash64.State.cs
Outdated
Show resolved
Hide resolved
Code LGTM. Approved pending whatever fixups are necessary to make packaging work. :) |
<TargetFrameworks>net6.0;netstandard2.0;net461</TargetFrameworks> | ||
<IsPackable>true</IsPackable> | ||
<!-- TODO: Remove when the package ships with .NET 6. --> | ||
<DisablePackageBaselineValidation>true</DisablePackageBaselineValidation> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually the inverse. Sorry...
<DisablePackageBaselineValidation>true</DisablePackageBaselineValidation> | |
<EnablePackageBaselineValidation>false</EnablePackageBaselineValidation> |
Looks like you are missing the reference project, in case you want/need it. I don't it's strictly required. cc @ericstj |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the ref project question, LGTM. Thanks for addressing the packaging feedback.
I copied the structure from System.Formats.Asn1, where I understood it to be "we still generate the .cs file for API evolution/observation purposes, and we still build it to align the src and ref, but we don't need to ship it because we don't do versioned API"... or something like that. |
@bartonjs - was there a reason why this didn't include a https://github.com/dotnet/runtime/tree/main/src/libraries/System.IO.Hashing/ref Oh, I see the response above. I don't totally understand it, but I guess you addressed the question above. UPDATE: @ViktorHofer answered all my questions offline. |
Fixes #24328.