System.Numerics or Stride.Math

[Doprez]

I wanted to open a tracked discussion on using System.Numerics instead of Strides created types.

• I am curious if there were any reasons before as to not using numerics in the first place and if so what were they?
• what would need to change if we did a full conversion in our libraries
• what would/could break in user projects right now
• will there be a major performance impact and is there an easy way to quickly benchmark before doing this work?
• other

As far as I understand it the only breaking change would be that users would need to add an extra using statement to their existing projects for .NETs math libraries.

[Doprez]

Adding comments from Eideren that went over this already but they are getting lost in the discord.

So, we can either:
Deprecate our math type, replace their usage in source outside of Stride.Core.Mathematics with dotnet's System.Numerics' type. Add implicit conversion from our types to System.Numerics to reduce breaking changes. Create a new static type Stride.Mathematics for operations that are not covered by dotnet's numerics API.
Ref parameters, overriden virtual methods, compound assignment, etc. will still create some breaking changes
System.Numerics doesn't have equivalent to a lot of our types, like BoundingBox, ..Frustum, Ray, ... nor explicit types for other vector data types like half2-3, int2-3 ... This is going to be a bit confusing as now users would have to fetch vectors from dotnet's namespace and other datatypes from our math namespace.
We don't have full control over the type, meaning that implementing more operators and conversions is impossible for the former and fairly hard for the latter as long as dotnet doesn't support extensions for those function types.
Same as above but instead of relying on dotnet's we create a new one which wraps around dotnet's type internally.
Breaking changes isn't any better
No confusing namespace
We keep control over the whole type
More work on our part to create this one, cover the numerics api and keep up to date with changes dotnet might introduce
Keep our type, use dotnet's accelerated operations under the hood, break ref params anyway
Breaking changes are limited to ref params.
Larger breaking changes like below are harder to justify.
 
In #1 & #2 I think it would be a good idea to also adopt the way dotnet's System.Math is designed; Math.Round has overloads for int, float, double etc. under the same static type, instead of having Vector3.Round, Vector4.Round, etc. Also less confusing for operations that take different data types like RotationQuaternion(Quaternion rotation, out Matrix result) - should that be under Matrix or Quaternion ... and finally merging all of that with the not very well known MathUtil to help users discover helpers for angle conversions and such.

[Doprez]

Another comment from Ethereal to keep in mind

Regarding the math types, I think for Stride 4.2 we shouldn't do any major rewrite yet.
The .NET team has created many useful types and functions, but support for generic Vector2<T> where T can be float, double, Half, etc., is postponed to .NET 9 I believe. Those would be the more interesting targets to port the Stride math types to.
The Silk.NET team is also having a discussion right now about how to enhance their math library, with many interesting comments from Tanner Gooding. You can check [here](https://github.com/dotnet/Silk.NET/pull/1760#discussion_r1375156663).

referenced link.

[Doprez]

final thing I found that we should keep in mind is Silks ongoing work for 3.0. They are apparently dealing with this exact issue.
dotnet/Silk.NET#1727

[Kryptos-FR]

I am curious if there were any reasons before as to not using numerics in the first place and if so what were they?

Yes there was a big one. Those types just didn't exist when the engine was first being worked on. And after they were introduced they had at first slightly worse performance.

[ericwj]

With regard to what Eideren said, I think it would be beneficial in many places to replace some implementations in Stride.Math (method bodies) delegating as much as possible to usually well-optimized implementations in System.Numerics and review Stride.Math for opportunities to use intrinsics. For example converting RGBA to BGRA can be done in 2 instructions (BSWAP, ROL) or less (vectorized) and in some places what I remember it is done (or used to be done when I was working on a PR) in some 54.

One thing I recommend is marking the overloads with ref parameters obsolete. When I looked at it, it turns out they are often much slower and knowing how parameter passing works it is mostly pointless to pass a writable ref anyway. For parameters that fit a register or that might be broken into pieces and passed in more than one register, it might force them to stay on the stack.

By marking the obsoletions with some specific diagnostic ID, subsequently suppressing that warning in each project, people can go about their business without getting swamped with warnings while some issue tracks removing the suppression on a per-project basis, starting with the most specific projects and working backwards to the core Stride projects.