Monogame: 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

[RUSshy]

I was curious and i tried your code on .net core 3.0 preview 1 (i3 4150)

RunTime 1961730.42

That's almost 10x faster already, old .net framework is slow af

Edit: result with System.Numerics

RunTime 641126.5

[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.