Interlocked.Read from 32-bit apps are much slower on Intel Sapphire Rapids CPUs

[TrevorFellman-MSFT]

Description

Interlocked.Read from 32-bit apps are much slower (100x) on Intel Sapphire Rapids CPUs.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace UnmanagedMemoryStreamPerfTest
{
    class Program
    {
        static bool _Is32BitProcess = true;
        static Stream _Stream = null;
        static void Main(string[] args)
        {
            _Is32BitProcess = GetIs32BitProcess();
            _Stream = GetStream();

            Console.WriteLine("Is 32 bit process: " + _Is32BitProcess);
            Stopwatch sw = new Stopwatch();
            sw.Start();

            MainAsync();

            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);
            Console.ReadLine();

        }

        static async void MainAsync()
        {
            //100 threads to make it eaven more obvious
            List<Task> tasks = new List<Task>();
            for (int i = 0; i < 100; i++)
                tasks.Add(DoStuff(GetStream()));
            await Task.WhenAll(tasks);
        }


        static unsafe async Task DoStuff(Stream stream)
        {
            //contrived, but this is just so we can see it.
            //for every XAML file, WPF will read baml streams from the assembly.
            //for apps with dense UIs, that can thousands of streams to open a screen

             //the problem, 32-bit will be about 3-20 times slower.  200 times slower on high end 2023 AMD and Intel chips due to a throttling feature for the type of lock UnmangedMemoryStream takes.
            int count = 1000000;
            for (int i = 0; i < count; i++)
            {
                DoStuffStream(stream);
                //DoStuffInterlocked()
                //DoStuffInterlockedTreF()
            }

        }

        static unsafe long DoStuffStream(Stream stream)
        {
            return stream.Length;
        }

        static unsafe long DoStuffInterlocked()
        {
            long len = 0;
            Interlocked.Read(ref len);
            return len;
        }

        static unsafe long DoStuffInterlockedTreF()
        {
            // inspriation from Parallel.For() fix  //https://devdiv.visualstudio.com/DevDiv/_search?text=969699&type=workitem&pageSize=25&filters=Projects%7BDevDiv%7D
            //Read uses Add under the hood, so this should be ok

            //gotcha is that 32-bit apps could then only use 2GB streams, limited by 32-bit int
            //maybe another Flag _BigStream

            long len = 0;
            if (_Is32BitProcess  /*&& !_BigStream*/)
            {
                long* indexPtr = &len;
                {
                    Interlocked.Add(ref *(int*)indexPtr, 0);
                }
            }
            else
            {
                Interlocked.Read(ref len);
            }
            return len;
        }

        static unsafe Stream GetStream()
        {
            //https://learn.microsoft.com/en-us/dotnet/api/system.io.unmanagedmemorystream?view=net-7.0
            //this is over kill, but its copy/paste MS sample code...

            byte[] message = UnicodeEncoding.Unicode.GetBytes(GetMessage());

            // Allocate a block of unmanaged memory and return an IntPtr object.	
            IntPtr memIntPtr = Marshal.AllocHGlobal(message.Length);

            // Get a byte pointer from the IntPtr object.
            byte* memBytePtr = (byte*)memIntPtr.ToPointer();

            // Create an UnmanagedMemoryStream object using a pointer to unmanaged memory.
            UnmanagedMemoryStream writeStream = new UnmanagedMemoryStream(memBytePtr, message.Length, message.Length, FileAccess.Write);

            // Write the data.
            writeStream.Write(message, 0, message.Length);

            // Close the stream.
            writeStream.Close();
            writeStream.Dispose();

            // Create another UnmanagedMemoryStream object using a pointer to unmanaged memory.
            UnmanagedMemoryStream readStream = new UnmanagedMemoryStream(memBytePtr, message.Length, message.Length, FileAccess.Read);

            // Create a byte array to hold data from unmanaged memory.
            byte[] outMessage = new byte[message.Length];

            // Read from unmanaged memory to the byte array.
            readStream.Read(outMessage, 0, message.Length);

            // Close the stream.
            //readStream.Close();
            //readStream.Dispose();

            return readStream;
        }

        static string GetMessage()
        {
            return "Here is some data.";
        }


        static bool GetIs32BitProcess()
        {
            return IntPtr.Size == 4;
        }
    }
}

Configuration

.NET 4.8 and 6.0

Regression?

No, new CPU behavior.

Data

WPR of real world apps are available.

Analysis

This was found tuning WPF applications on VDI and seeing a noticeable performance drop opening new screens on these new processors.
Interlocked.Read is used by a lot of APIs and apps. If we can improve perf here, a lot of apps will magically run faster on modern hardware. Otherwise, this issue will have to be addressed on an individual basis.

Many large enterprise apps have 32-bit 3rd-party dependencies, so cannot be rebuilt as 64-bit processes to avoid this perf issue.

[TrevorFellman-MSFT]

Intel provided the following links.

https://lwn.net/Articles/790464
https://www.kernel.org/doc/html/v5.18/x86/buslock.html

Bit 29 in MSR 0x33 can be used to disable exception generation that is used by kernel/hypervisor to rate limit the bus locks
Your default value for MSR 0x33 may look like 0x20000000. You need to write 0 to bit 29 to disable this rate limit feature

Do we really need to take a lock to read a 64-bit int on 64-bit processors?

[ghost]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Interlocked.Read from 32-bit apps are much slower (100x) on Intel Sapphire Rapids CPUs.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace UnmanagedMemoryStreamPerfTest
{
class Program
{
static bool _Is32BitProcess = true;
static Stream _Stream = null;
static void Main(string[] args)
{
_Is32BitProcess = GetIs32BitProcess();
_Stream = GetStream();

        Console.WriteLine("Is 32 bit process: " + _Is32BitProcess);
        Stopwatch sw = new Stopwatch();
        sw.Start();

        MainAsync();

        sw.Stop();
        Console.WriteLine(sw.ElapsedMilliseconds);
        Console.ReadLine();

    }

    static async void MainAsync()
    {
        //100 threads to make it eaven more obvious
        List<Task> tasks = new List<Task>();
        for (int i = 0; i < 100; i++)
            tasks.Add(DoStuff(GetStream()));
        await Task.WhenAll(tasks);
    }


    static unsafe async Task DoStuff(Stream stream)
    {
        //contrived, but this is just so we can see it.
        //for every XAML file, WPF will read baml streams from the assembly.
        //for apps with dense UIs, that can thousands of streams to open a screen

         //the problem, 32-bit will be about 3-20 times slower.  200 times slower on high end 2023 AMD and Intel chips due to a throttling feature for the type of lock UnmangedMemoryStream takes.
        int count = 1000000;
        for (int i = 0; i < count; i++)
        {
            DoStuffStream(stream);
            //DoStuffInterlocked()
            //DoStuffInterlockedTreF()
        }

    }

    static unsafe long DoStuffStream(Stream stream)
    {
        return stream.Length;
    }

    static unsafe long DoStuffInterlocked()
    {
        long len = 0;
        Interlocked.Read(ref len);
        return len;
    }

    static unsafe long DoStuffInterlockedTreF()
    {
        // inspriation from Parallel.For() fix  //https://devdiv.visualstudio.com/DevDiv/_search?text=969699&type=workitem&pageSize=25&filters=Projects%7BDevDiv%7D
        //Read uses Add under the hood, so this should be ok

        //gotcha is that 32-bit apps could then only use 2GB streams, limited by 32-bit int
        //maybe another Flag _BigStream

        long len = 0;
        if (_Is32BitProcess  /*&& !_BigStream*/)
        {
            long* indexPtr = &len;
            {
                Interlocked.Add(ref *(int*)indexPtr, 0);
            }
        }
        else
        {
            Interlocked.Read(ref len);
        }
        return len;
    }

















    static unsafe Stream GetStream()
    {
        //https://learn.microsoft.com/en-us/dotnet/api/system.io.unmanagedmemorystream?view=net-7.0
        //this is over kill, but its copy/paste MS sample code...

        byte[] message = UnicodeEncoding.Unicode.GetBytes(GetMessage());

        // Allocate a block of unmanaged memory and return an IntPtr object.	
        IntPtr memIntPtr = Marshal.AllocHGlobal(message.Length);

        // Get a byte pointer from the IntPtr object.
        byte* memBytePtr = (byte*)memIntPtr.ToPointer();

        // Create an UnmanagedMemoryStream object using a pointer to unmanaged memory.
        UnmanagedMemoryStream writeStream = new UnmanagedMemoryStream(memBytePtr, message.Length, message.Length, FileAccess.Write);

        // Write the data.
        writeStream.Write(message, 0, message.Length);

        // Close the stream.
        writeStream.Close();
        writeStream.Dispose();

        // Create another UnmanagedMemoryStream object using a pointer to unmanaged memory.
        UnmanagedMemoryStream readStream = new UnmanagedMemoryStream(memBytePtr, message.Length, message.Length, FileAccess.Read);

        // Create a byte array to hold data from unmanaged memory.
        byte[] outMessage = new byte[message.Length];

        // Read from unmanaged memory to the byte array.
        readStream.Read(outMessage, 0, message.Length);

        // Close the stream.
        //readStream.Close();
        //readStream.Dispose();

        return readStream;
    }

    static string GetMessage()
    {
        return "Here is some data.";
    }


    static bool GetIs32BitProcess()
    {
        return IntPtr.Size == 4;
    }
}

}

Configuration

.NET 4.8 and 6.0

Regression?

No, new CPU behavior.

Data

WPR of real world apps are available.

Analysis

This was found tuning WPF applications on VDI and seeing a noticeable performance drop opening new screens on these new processors.
Interlocked.Read is used by a lot of APIs and apps. If we can improve perf here, a lot of apps will magically run faster on modern hardware. Otherwise, this issue will have to be addressed on an individual basis.

Many large enterprise apps have 32-bit 3rd-party dependencies, so cannot be rebuilt as 64-bit processes to avoid this perf issue.

Author:	TrevorFellman-MSFT
Assignees:	-
Labels:	area-System.Threading, tenet-performance, untriaged, needs-area-label
Milestone:	-

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Interlocked.Read from 32-bit apps are much slower (100x) on Intel Sapphire Rapids CPUs.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace UnmanagedMemoryStreamPerfTest
{
class Program
{
static bool _Is32BitProcess = true;
static Stream _Stream = null;
static void Main(string[] args)
{
_Is32BitProcess = GetIs32BitProcess();
_Stream = GetStream();

        Console.WriteLine("Is 32 bit process: " + _Is32BitProcess);
        Stopwatch sw = new Stopwatch();
        sw.Start();

        MainAsync();

        sw.Stop();
        Console.WriteLine(sw.ElapsedMilliseconds);
        Console.ReadLine();

    }

    static async void MainAsync()
    {
        //100 threads to make it eaven more obvious
        List<Task> tasks = new List<Task>();
        for (int i = 0; i < 100; i++)
            tasks.Add(DoStuff(GetStream()));
        await Task.WhenAll(tasks);
    }


    static unsafe async Task DoStuff(Stream stream)
    {
        //contrived, but this is just so we can see it.
        //for every XAML file, WPF will read baml streams from the assembly.
        //for apps with dense UIs, that can thousands of streams to open a screen

         //the problem, 32-bit will be about 3-20 times slower.  200 times slower on high end 2023 AMD and Intel chips due to a throttling feature for the type of lock UnmangedMemoryStream takes.
        int count = 1000000;
        for (int i = 0; i < count; i++)
        {
            DoStuffStream(stream);
            //DoStuffInterlocked()
            //DoStuffInterlockedTreF()
        }

    }

    static unsafe long DoStuffStream(Stream stream)
    {
        return stream.Length;
    }

    static unsafe long DoStuffInterlocked()
    {
        long len = 0;
        Interlocked.Read(ref len);
        return len;
    }

    static unsafe long DoStuffInterlockedTreF()
    {
        // inspriation from Parallel.For() fix  //https://devdiv.visualstudio.com/DevDiv/_search?text=969699&type=workitem&pageSize=25&filters=Projects%7BDevDiv%7D
        //Read uses Add under the hood, so this should be ok

        //gotcha is that 32-bit apps could then only use 2GB streams, limited by 32-bit int
        //maybe another Flag _BigStream

        long len = 0;
        if (_Is32BitProcess  /*&& !_BigStream*/)
        {
            long* indexPtr = &len;
            {
                Interlocked.Add(ref *(int*)indexPtr, 0);
            }
        }
        else
        {
            Interlocked.Read(ref len);
        }
        return len;
    }

















    static unsafe Stream GetStream()
    {
        //https://learn.microsoft.com/en-us/dotnet/api/system.io.unmanagedmemorystream?view=net-7.0
        //this is over kill, but its copy/paste MS sample code...

        byte[] message = UnicodeEncoding.Unicode.GetBytes(GetMessage());

        // Allocate a block of unmanaged memory and return an IntPtr object.	
        IntPtr memIntPtr = Marshal.AllocHGlobal(message.Length);

        // Get a byte pointer from the IntPtr object.
        byte* memBytePtr = (byte*)memIntPtr.ToPointer();

        // Create an UnmanagedMemoryStream object using a pointer to unmanaged memory.
        UnmanagedMemoryStream writeStream = new UnmanagedMemoryStream(memBytePtr, message.Length, message.Length, FileAccess.Write);

        // Write the data.
        writeStream.Write(message, 0, message.Length);

        // Close the stream.
        writeStream.Close();
        writeStream.Dispose();

        // Create another UnmanagedMemoryStream object using a pointer to unmanaged memory.
        UnmanagedMemoryStream readStream = new UnmanagedMemoryStream(memBytePtr, message.Length, message.Length, FileAccess.Read);

        // Create a byte array to hold data from unmanaged memory.
        byte[] outMessage = new byte[message.Length];

        // Read from unmanaged memory to the byte array.
        readStream.Read(outMessage, 0, message.Length);

        // Close the stream.
        //readStream.Close();
        //readStream.Dispose();

        return readStream;
    }

    static string GetMessage()
    {
        return "Here is some data.";
    }


    static bool GetIs32BitProcess()
    {
        return IntPtr.Size == 4;
    }
}

}

Configuration

.NET 4.8 and 6.0

Regression?

No, new CPU behavior.

Data

WPR of real world apps are available.

Analysis

This was found tuning WPF applications on VDI and seeing a noticeable performance drop opening new screens on these new processors.
Interlocked.Read is used by a lot of APIs and apps. If we can improve perf here, a lot of apps will magically run faster on modern hardware. Otherwise, this issue will have to be addressed on an individual basis.

Many large enterprise apps have 32-bit 3rd-party dependencies, so cannot be rebuilt as 64-bit processes to avoid this perf issue.

Author:	TrevorFellman-MSFT
Assignees:	-
Labels:	tenet-performance, area-CodeGen-coreclr, untriaged
Milestone:	-

[Clockwork-Muse]

Many large enterprise apps have 32-bit 3rd-party dependencies, so cannot be rebuilt as 64-bit processes to avoid this perf issue.

This might be true, but it always bugs me.
What I wish they would do is set up a private package repo....

[EgorBo]

@DeepakRajendrakumaran is that the issue we dicussed?

Long story short - the perf bottle-neck is in

runtime/src/libraries/System.Private.CoreLib/src/System/IO/UnmanagedMemoryStream.cs

Line 262 in 45ed0ab

return Interlocked.Read(ref _length);

the long field is not guaranteed to be aligned to 8-bytes on 32bit and that causes the perf regression. In theory, we could offer 8-byte alignment for such types (all types with long fields?) just like we do it for some cases with doubles (aligning to 8-bytes via fake objects) but that probably a bit of work, as, presumably, VM will have to align fields to 8-bytes then + potential heap size regression on 32bit.

Anyway we don't think it's a codegen issue in any way.

[DeepakRajendrakumaran]

@DeepakRajendrakumaran is that the issue we dicussed?

Long story short - the perf bottle-neck is in

runtime/src/libraries/System.Private.CoreLib/src/System/IO/UnmanagedMemoryStream.cs

Line 262 in 45ed0ab

return Interlocked.Read(ref _length);

the long field is not guaranteed to be aligned to 8-bytes on 32bit and that causes the perf regression. In theory, we could offer 8-byte alignment for such types (all types with long fields?) just like we do it for some cases with doubles (aligning to 8-bytes via fake objects) but that probably a bit of work, as, presumably, VM will have to align fields to 8-bytes then + potential heap size regression on 32bit.

Anyway we don't think it's a codegen issue in any way.

Yes. This is the same issue

@EgorBo : Is using a 4 byte data type instead of long an option for position and length?

[EgorBo]

@EgorBo : Is using a 4 byte data type instead of long an option for position and length?

Not for the UnmanagedMemoryStream I guess, it's a public API, changing types for it will be a breaking change. As a workaround, users can make their own UnmanagedMemoryStream2 with int length..

[TrevorFellman-MSFT]

is there a better implementation for Interlocked.Read that is better for modern hardware?
Why does UnmanagedMemoryStream need to use Interlocked.Read? Is it even necessary here?

MemoryStream doesn't

runtime/src/libraries/System.Private.CoreLib/src/System/IO/MemoryStream.cs

Line 292 in d65a39d

public override long Length

FileStream doesn't either

runtime/src/libraries/System.Private.CoreLib/src/System/IO/FileStream.cs

Line 451 in d65a39d

public override long Length

[EgorBo]

is there a better implementation for Interlocked.Read that is better for modern hardware?

I am not aware of simpler ways to perform a volatile/interlocked 8-byte load on x86 (32bit) other than https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange64

Why does UnmanagedMemoryStream need to use Interlocked.Read?

Presumably, to make it thread-safe so when some other thread is changing length, the value won't be torn if read by other thread - I don't know why it's done for UnmanagedMemoryStream and not for MemoryStream

PS: ah, MemoryStream's length is actually int so it doesn't need any Interlocked.

[Daniel-Svensson]

Just curious, wouldn't it work if the field was changed to a double making it aligned allowing a 8 byte load to vector register?

However it would lead to increased complexity and worse code on x64 (which might be somewhat negated by different code paths based on size of intptr) so it is not be a generic solution

[EgorBo]

Just curious, wouldn't it work if the field was changed to a double making it aligned allowing a 8 byte load to vector register?

double fields won't force GC to use 8-byte alignment, I think we use 8-byte alignment on 32 bit only in two cases:

1. arrays
2. boxed structs with doubles

Regarding SIMD, I don't think a simd load can guarantee us atomicity?

[DeepakRajendrakumaran]

There are other places we do something similar(End up doing a CompareExchange on long) -

For eg.

runtime/src/libraries/System.Private.Uri/src/System/Uri.cs

Line 211 in fa3babd

Interlocked.Or(ref Unsafe.As<Flags, ulong>(ref _flags), (ulong)flags);

->

runtime/src/libraries/System.Private.CoreLib/src/System/Threading/Interlocked.cs

Line 347 in fa3babd

long oldValue = CompareExchange(ref location1, newValue, current);

[EgorBo]

Interlocked.Or is expected to be accelerated on x64, but it's currently not implemented in JIT, it's a relatively new API (accelerated on ARM64 though).

[Clockwork-Muse]

PS: ah, MemoryStream's length is actually int so it doesn't need any Interlocked.

...on 32bit+ systems.
A good chunk of the embedded space is (and possibly always will be) less than that.

[gfoidl]

Regarding SIMD, I don't think a simd load can guarantee us atomicity?

When data is aligned then it's atomic. Otherwise no guarantee, and for cacheline split it's not atomic.

[EgorBo]

Regarding SIMD, I don't think a simd load can guarantee us atomicity?

When data is aligned then it's atomic. Otherwise no guarantee, and for cacheline split it's not atomic.

Only on AVX+ hardware, if aligned to 16b and special aligned loads/stores are used. It makes it useless for us for atomicity

[DeepakRajendrakumaran]

FYI - I locally switched the _position and _length in UnmanagedMemoryStream(We use the lock on these) to int and ran the app. The problem does go away

p.s. This was just an expt to verify and confirm that this is indeed the issue.

[ghost]

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

Issue Details

---

Description

Interlocked.Read from 32-bit apps are much slower (100x) on Intel Sapphire Rapids CPUs.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace UnmanagedMemoryStreamPerfTest
{
    class Program
    {
        static bool _Is32BitProcess = true;
        static Stream _Stream = null;
        static void Main(string[] args)
        {
            _Is32BitProcess = GetIs32BitProcess();
            _Stream = GetStream();

            Console.WriteLine("Is 32 bit process: " + _Is32BitProcess);
            Stopwatch sw = new Stopwatch();
            sw.Start();

            MainAsync();

            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);
            Console.ReadLine();

        }

        static async void MainAsync()
        {
            //100 threads to make it eaven more obvious
            List<Task> tasks = new List<Task>();
            for (int i = 0; i < 100; i++)
                tasks.Add(DoStuff(GetStream()));
            await Task.WhenAll(tasks);
        }


        static unsafe async Task DoStuff(Stream stream)
        {
            //contrived, but this is just so we can see it.
            //for every XAML file, WPF will read baml streams from the assembly.
            //for apps with dense UIs, that can thousands of streams to open a screen

             //the problem, 32-bit will be about 3-20 times slower.  200 times slower on high end 2023 AMD and Intel chips due to a throttling feature for the type of lock UnmangedMemoryStream takes.
            int count = 1000000;
            for (int i = 0; i < count; i++)
            {
                DoStuffStream(stream);
                //DoStuffInterlocked()
                //DoStuffInterlockedTreF()
            }

        }

        static unsafe long DoStuffStream(Stream stream)
        {
            return stream.Length;
        }

        static unsafe long DoStuffInterlocked()
        {
            long len = 0;
            Interlocked.Read(ref len);
            return len;
        }

        static unsafe long DoStuffInterlockedTreF()
        {
            // inspriation from Parallel.For() fix  //https://devdiv.visualstudio.com/DevDiv/_search?text=969699&type=workitem&pageSize=25&filters=Projects%7BDevDiv%7D
            //Read uses Add under the hood, so this should be ok

            //gotcha is that 32-bit apps could then only use 2GB streams, limited by 32-bit int
            //maybe another Flag _BigStream

            long len = 0;
            if (_Is32BitProcess  /*&& !_BigStream*/)
            {
                long* indexPtr = &len;
                {
                    Interlocked.Add(ref *(int*)indexPtr, 0);
                }
            }
            else
            {
                Interlocked.Read(ref len);
            }
            return len;
        }

        static unsafe Stream GetStream()
        {
            //https://learn.microsoft.com/en-us/dotnet/api/system.io.unmanagedmemorystream?view=net-7.0
            //this is over kill, but its copy/paste MS sample code...

            byte[] message = UnicodeEncoding.Unicode.GetBytes(GetMessage());

            // Allocate a block of unmanaged memory and return an IntPtr object.	
            IntPtr memIntPtr = Marshal.AllocHGlobal(message.Length);

            // Get a byte pointer from the IntPtr object.
            byte* memBytePtr = (byte*)memIntPtr.ToPointer();

            // Create an UnmanagedMemoryStream object using a pointer to unmanaged memory.
            UnmanagedMemoryStream writeStream = new UnmanagedMemoryStream(memBytePtr, message.Length, message.Length, FileAccess.Write);

            // Write the data.
            writeStream.Write(message, 0, message.Length);

            // Close the stream.
            writeStream.Close();
            writeStream.Dispose();

            // Create another UnmanagedMemoryStream object using a pointer to unmanaged memory.
            UnmanagedMemoryStream readStream = new UnmanagedMemoryStream(memBytePtr, message.Length, message.Length, FileAccess.Read);

            // Create a byte array to hold data from unmanaged memory.
            byte[] outMessage = new byte[message.Length];

            // Read from unmanaged memory to the byte array.
            readStream.Read(outMessage, 0, message.Length);

            // Close the stream.
            //readStream.Close();
            //readStream.Dispose();

            return readStream;
        }

        static string GetMessage()
        {
            return "Here is some data.";
        }


        static bool GetIs32BitProcess()
        {
            return IntPtr.Size == 4;
        }
    }
}

Configuration

.NET 4.8 and 6.0

Regression?

No, new CPU behavior.

Data

WPR of real world apps are available.

Analysis

This was found tuning WPF applications on VDI and seeing a noticeable performance drop opening new screens on these new processors.
Interlocked.Read is used by a lot of APIs and apps. If we can improve perf here, a lot of apps will magically run faster on modern hardware. Otherwise, this issue will have to be addressed on an individual basis.

Many large enterprise apps have 32-bit 3rd-party dependencies, so cannot be rebuilt as 64-bit processes to avoid this perf issue.

Author:	TrevorFellman-MSFT
Assignees:	-
Labels:	area-System.IO, tenet-performance, area-CodeGen-coreclr, untriaged, in-pr
Milestone:	-