Proposition to port math to native implementation

[OptimisticPeach]

I've used MonoGame for about a year, but then decided to switch languages, and ended up on Rust.
I have missed MonoGame, but I don't really want to leave Rust as it's an amazing programming language. So I came up with the idea to integrate rust with MonoGame, and thought that perhaps the math portion could be ported for ease of use instead of anything too complicated to put into an FFI. I wrote a test and, low and behold, I have great results:

Matrix.CreateLookAt()

	MonoGame Implementation	Rust native implementation
Time (Ticks)	17 551 010.16	314 615.39
Time (MS)	5273.5	94.5
Memory (MB) (VS Debugger)	71.1	76.2
Memory (MB) (Task Manager)	68.5	69.1
CPU% (Task Manager)	15 ~ 17.5	16 ~ 18.5

Here is my configuration for reference:

	Config
Target (Rust)	nightly-x86_64-pc-windows-msvc --release
Target (C#)	Any CPU (Release)
OS	Windows 10
MonoGame version	Latest Stable (3.7.1)
.Net version	.Net Framework 4.7.1
CPU	Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
Ticks Per Second	3328129

So I'm asking, if I were to rewrite alot of the math functions in MonoGame in Rust, would it ever be accepted? (Of course I'd make sure to keep the implementation outputting the same result)

The source for my tests

Edit:
I later realized, that while rust does compile to many platforms, it doesn't compile to all, so it may not have support for some of the less prominent targets that MonoGame targets.
Edit 2:
I was actually looking at DateTime for ticks per second, but I was actually using the StopWatch.Frequency ticks per second

[Jjagg]

@RUSshy could you give it a try with System.Numerics? That should boost the numbers some more.

[mrhelmut]

Real world benchmarks on complete games would be more relevant to assess this (my guess is that most games will have the GPU clogged way before the CPU becomes a limitation).

Please note that proposing native implementations for parts of MonoGame must cover all platforms, including consoles (or be optional).

[Jjagg]

For what it's worth, here's my timings for the toy program with .NET Core 2.0:

Implementation	Time
MonoGame	93361256.08
Rust	78294395.96
Numerics	44336846.19

[tomspilman]

while rust does compile to many platforms, it doesn't compile to all,

That is my first concern. Replacing our portable C# with something that isn't portable.

Second MonoGame is a C# library and ideally we should be dogfooding as much as possible. IMO we should use C# where ever we can.

For what it's worth, here's my timings for the toy program with .NET Core 2.0:

Wow... i'm surprised Numerics is that much faster.

[OptimisticPeach]

Then clearly porting the MonoGame math library is out of the question now, but now I have two questions:

• I'm open to port anything else in MonoGame that is too CPU intensive for C# to rust, as long as it isn't something that can't be done across an FFI boundary
• Just out of curiosity, what consoles/platforms does MonoGame run on? The ones I know are: Windows, Android, Mac, Linux, Xbox, Ouya (Deprecated?), Windows Phone, PlayStation, and TVos

[Apostolique]

There's also the Nintendo Switch.

[tomspilman]

@OptimisticPeach - We run on all the current gen consoles plus Vita and expect to be on all the upcoming 9th generation of consoles (PS5, etc). We have some talk of trying to get MG on Nintendo 3DS, but so far no work on that has started.

[OptimisticPeach]

Hmm, here's a table I just compiled for target that rust supports (or doesn't, or I'm not sure about)

Target	Target Triple(s)
Windows	- aarch64-pc-windows-msv - i686-pc-windows-msvc - x86_64-pc-windows-gnu - i586-pc-windows-msvc - thumbv7a-pc-windows-msvc - x86_64-pc-windows-msvc - i686-pc-windows-gnu
Apple Products	- i686-apple-darwin - x86_64-apple-darwin
Android	- aarch64-linux-android - arm-linux-androideabi - armv7-linux-androideabi - i686-linux-android - thumbv7neon-linux-androideabi - x86_64-linux-android
Linux	- aarch64-unknown-linux-gnu - aarch64-unknown-linux-musl - arm-unknown-linux-gnueabi - arm-unknown-linux-gnueabihf - arm-unknown-linux-musleabi - arm-unknown-linux-musleabihf - armv4t-unknown-linux-gnueabi - armv5te-unknown-linux-gnueabi ...
Xbox	According to this comment it's practically ready to go
Ouya	As far as I can tell, rust is not supported here :(
Windows Phone	I presume that this is the same story as Xbox
PS and Nintendo Switch	I don't know, NDAs don't let people talk about it very much 1 Nintendo Switch has something - aarch64-none-elf
TVOs and IWatch	An issue about it
Nintendo 3DS	There seems to be something, but it definitely needs work

And so, there doesn't seem to be full support for everything you're targeting, one of the big ones is PlayStation, and that seems to be an important target for MonoGame, so I think that porting anything in the main library over is out of question, unless we set up a hacky target check, but that doesn't seem to nice. Either way, I'd be happy work on anything that might need to be faster, and FFIing with a native language like rust.

Edit:
Although this may seem abit out of the picture, there is n64 support to some extent

[Jjagg]

I agree with @mrhelmut

Real world benchmarks on complete games would be more relevant to assess this (my guess is that most games will have the GPU clogged way before the CPU becomes a limitation).

I'm against burdening ourselves with native dependencies and offering up portability for speculative performance gains in very specific situations. IMO we can close this.

On a related note, I'm in favor of moving to System.Numerics from MG's vector/matrix classes in the future.

Still, thanks for looking into this @OptimisticPeach :)

[OptimisticPeach]

Well, that's alright, it was just an idea, anyway, I'm going to close this issue as @Jjagg mentioned, and I think I might try my hand at building something in MonoGame again. Perhaps in a few years I'll re-open this if the situation changes.