Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
System.Numerics structs are incorrect sizes #6411
Many of the structures in the System.Numerics namespace are being padded out to an incorrectly-large size in memory. Although this was likely done as a kind of performance optimization, it has widespread side effects that break many of the main use cases for the types. This behavior is also different from .NET Core and .NET Framework.
The types affected:
Plane is probably larger because it contains a Vector3, but I've listed it anyways.
There are some test cases in corefx which ensure that these structures are the expected physical size in memory. For example
I remembered this Bugzilla bug where @kumpera indicated this is expected: https://bugzilla.xamarin.com/show_bug.cgi?id=56602
The size in memory of these structures is more important than individual SIMD optimizations, because there is a lot of code in the wild that works only under the assumption that these types are tightly-packed in memory. It is not a problem if the results of intermediate operations are expanded to a 16-byte form in order to better utilize SIMD operations -- this is what CoreCLR and .NET Framework do -- but the in-memory representation cannot change.
As a comparison, if this same behavior was observed in the analogous MonoGame structures, then a lot of things using them would break.