Unsafe trick to swap movsxd with mov in Unsafe.Add

[Sergio0694]

Hey, I've discovered this (arguably ugly) trick while working on the HighPerformance toolkit (specifically, here) to basically get rid of the movsxd (sign extension from int to native int) that occurs when using Unsafe.Add<T>(ref T, int). The thing is that this method would only ever be called with positive (and valid) values, so there's no point in paying the performance penalty here for the sign extension. We can just use a mov, which on 64 bit system automatically just sets the upper 32 bit of the target register to 0.

Basically, consider this (full sharplab.io sample here):

public static void SetAt(ref float r, int i, float x)
{
    Unsafe.Add(ref r, i) = x;
}

This produces the following (when inlined):

C.SetAt(Single ByRef, Int32, Single)
    movsxd rax, edx ; argh!
    vmovss [rcx+rax*4], xmm2
    ret

That's completely unnecessary. Turns out we can avoid that by doing:

Unsafe.Add(ref r, (IntPtr)(void*)(uint)i) = x;

Which gives us:

mov eax, edx ; yay!
vmovss [rcx+rax*4], xmm2

Now, this is a drop-in replacement, so the idea would be to simply replace all these occurrences in the codebase.
A few considerations to be made though:

• ✅ Faster
• ⛔ Messier
• ⛔ Potentially scarier for other devs reading the codebase

I made a quick search and we do have quite a few of these calls (also in loops):

The idea

I think we should consider doing a refactoring with these micro-optimizations in mind.
Specifically, we could:

• Use this trick for one-off accesses, or ones outside of a loop (also maybe (nuint) should work on C# 9 too?)
• Consider switching fast indexing loops with an IntPtr indexer, to remove the sign extension entirely. We can either do this already, just with some slightly uglier code (IntPtr + unsafe casts, etc.), or wait for C# 9 to get nint variables directly.

Just food for thought, thought I'd share! 😊

[saucecontrol]

or wait for C# 9 to get nint variables directly

That's the answer. Solves the problem without all that void* unpleasantness.

[Sergio0694]

But it's fun! 🤣

Jokes aside, yeah waiting for C# 9 is certainly a valid option.

[saucecontrol]

You don't even have to wait if you set <LangVersion>preview</LangVersion> and build with the .NET 5 Preview SDK. Not sure which IDEs support nint/nuint today other than VS Preview, but it won't be a long wait either way.

[antonfirsov]

I would definitely prefer to wait. Our attention and time is a very limited resource these days, better to focus it on topics where the biggest user value is, and try to not get distracted by every shiny little gem :)

[Sergio0694]

Yeah absolutely!
To be clear, this was not a suggestion to actually do this change now, it was just meant to say "hey here's a cool thing I discovered, we can keep this in mind if we want to do a refactoring in the future to possibly shave off some more performance for free" 😊