A interesting discussion about mono pef in our discord

So basicly what above means is that when dealing with floats (like vector3) in the domain code we actually are working with doubles.

 

Hasnt this always been the known case though?

Its one of the reasons DOTS is so great, because a float3 is actually a float3 and not some other data type masquerading as a float

If this is something worrying to you I really suggest looking into DOTS, I have been recently and it has come leaps and bounds in terms of usability.

Its still not production ready for a long time but I think its at a point where its worth starting to learn it so everyone is ready to jump ship when it matures and has decent tooling to make more game types viable

 

We will move some systems to it when it's production ready.

But it's plain bad that any operation on float first needs that double conversion.

 

Is it confirmed to be all floats though? I was under the impression it was only certain structs and certain functions in the API that do this, not all of them - but I am not honestly 100% on that and its been a very long time since I read up on this.

 

All operations on float, quaternion * vector3 resulted in over 300 operations and many convertions from and to double

 

Okay that does not sound right at all, it would be interesting to hear from someone on unity development/technical team regarding what/why this is? Im not really sure who would be best to tag in regarding that though

 

Might as well move straight to .NET 5

 

I consider this a humbling testament to the power of the modern processor (grin)

 

Wait there is more

 

lol, like I said it is amazing that this lack of performance doesn't cripple everything. I was staggered to find out that from my understanding unity didnt have any kind of SIMD acceleration under the hood before mathematics / burst came along. CPU's have come a long way since my ZX Spectrum

 

This is also pretty cool,. Net clr is a little bit faster than pure cpp

 

It goes to show that the vast majority of code that most people write doesn't actually need to be fast. And where code does need to be fast, it's often not bottlenecked by the things people expect. A 500% increase in float operation performance would most likely not get anywhere near a 500% increase in overall code performance in the vast majority of cases.

So, while looking at relative speed tests for operations like this is indeed informative and generally good to know, what actually matters on a day-to-day basis are quite different questions: "Is it fast enough?" and "Where are the slowest parts I can control?"

Knowing that using some other tool I don't have access to would make something 5 times faster doesn't help me answer either of those. If / when Unity addresses it everyone's life will be a bit easier when it comes to doing performance related stuff, but it's not worth my energy if I need something done today. I need to figure out what I can do with what I've got for it to make a difference.

Another thing to consider is that while the instructions are indeed slower, and that becomes a big deal when you're doing 100 million iterations to test the difference, it that may still not be the bottleneck in real-world code. Here's one example. That's no excuse for a compiler being arbitrarily inefficient, though. There are cases when we need to do lots of float operations in a row, and those cases should be supported properly.

 

IL2CPP kinda sidestepped the problem. Currently the only platform where Mono is used is PC, where CPUs usually have vastly better single core performance than phones and consoles.

Back when people often released Mono games on consoles it was probably one of the reasons behind the epidemic of terribly performing ports of Unity-made for PS4 games, like Firewatch, Broforce, and others.

 

Anders states exactly the same thing



But since all arithmetic functions in Unitys mono version are fubar I have a hard time seing it wont affect performance. After all most 3d games do a few arithmetic calculations every frame even in the domain code.