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

Replace memmove with Unsafe.CopyBlock in hydration code #98929

Merged
merged 1 commit into from
Feb 26, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -290,12 +290,7 @@ private static unsafe void RehydrateData(IntPtr dehydratedData, int length)
{
// At the time of writing this, 90% of DehydratedDataCommand.Copy cases
// would fall into the above specialized cases. 10% fall back to memmove.
memmove(pDest, pCurrent, (nuint)payload);

// Not a DllImport - we don't need a GC transition since this is early startup
[MethodImplAttribute(MethodImplOptions.InternalCall)]
[RuntimeImport("*", "memmove")]
static extern unsafe void* memmove(byte* dmem, byte* smem, nuint size);
Unsafe.CopyBlock(pDest, pCurrent, (uint)payload);
Copy link
Member

Choose a reason for hiding this comment

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

@EgorBo would this use the managed impl of the block copying after your #98623?

Wonder whether we should just replace the whole block from line 266 onwards with that.

When I originally wrote this code in #77884 (comment) I had concerns about this running extremely early at startup. If the managed impl works here, it would probably generate equivalent code with the added benefit of being even better for --instruction-set native.

Copy link
Member

@EgorBo EgorBo Feb 26, 2024

Choose a reason for hiding this comment

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

@EgorBo would this use the managed impl of the block copying after your #98623?

Correct, it will be a direct call to https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/SpanHelpers.ByteMemOps.cs#L253 (accelerated with avx512 if presented)

Copy link
Member

Choose a reason for hiding this comment

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

Oh, this is the thing called through RuntimeExports...

If we get a non-inlineable call then what this PR is doing is enough. We can't get rid of the small size special cases, the outer loop is very hot.

Copy link
Member

@EgorBo EgorBo Feb 26, 2024

Choose a reason for hiding this comment

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

If needed, we can consider exposing native memset/memmove/memset APIs in NativeMemory.cs API

}

pDest += payload;
Original file line number Diff line number Diff line change
@@ -119,5 +119,15 @@ public static T ReadUnaligned<T>(void* source)
{
throw new PlatformNotSupportedException();
}

/// <summary>
/// Copies bytes from the source address to the destination address.
/// </summary>
[Intrinsic]
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static void CopyBlock(void* destination, void* source, uint byteCount)
{
throw new PlatformNotSupportedException();
Copy link
Member

Choose a reason for hiding this comment

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

This will need to be implemented if we ever want hydration work with minimal runtime

}
}
}