unity mathematics vs Mathf in nonbursted code.

Unity Engine
, , ,
1

So I have a lot of static math functions I ported to unity mathematics. Some of the functions are also used by monobehaviours is there a reason for me to maintain the old math code or should I remove it? As far as I can see mathematics is a better math library then Mathf.

I guess I could save on boxing and unboxing.

2

Not only should you probably remove it, but you should probably add some new [BurstCompile] attributes because this is a thing: GitHub - keijiro/BurstTestbed: Collection of Unity Burst samples

2 Likes
3

If you work with burst, you should be using float related DOTS Unity math.
However, unity classic mathf has certain methods optimised, to work better with vectors. That is, when you donā€™t need burst, and keep working with game object and classes.

4

Iā€™ve found unity.mathematics & NativeArray<> stuff in general to be significantly slower when called in regular boring managed code. Likely the compiler has problems inlining all the nested methods in unity.mathematics. Youā€™ll also be tempted to use various SIMD-based methods that than run on their slow software fallback because mono doesnā€™t optimize it. NativeArray overhead is probably because of checking safety on every index op, but I havenā€™t confirmed that.

Itā€™s a common mistake in ā€œburst vs managedā€ benchmarks, where they benchmark the burst job without burst as the ā€˜managedā€™ version. While a managed version using Mathf/Vector3 & regular arrays would outperform the mathematics/nativearray based version by a few factors.

So, Iā€™d say, keep your own math library alive for now. But for every new system or rework of existing systems, strongly consider if you can reasonably make a burst variant of it. Especially with the direct function call stuff linked above, you may be able to isolate the math heavy bits into a burst function.

P.S edit: I may be slightly out of date on the unity.mathematics being significantly slower in managed code, I just recalled there have been package updates that have tried to address it somewhat (like basically all of it is marked with AggressiveInlining now). But Iā€™ll leave my paragraphs as is for posterity)

5

Unity.Mathematicā€™s Pow() is actually System.Math.Pow() according to their git of the hub.

6

Same topic here: Naive question: Vector types everywhere?