Expand the Perf test coverage for the System.Numerics.Vector types about performance HOT 5 CLOSED

FYI. @mellinoe, @DrewScoggins

from performance.

I did some analysis of what I think the current gaps are, and what the most important things to fill in are.

Existing Coverage:

• Vector2/3/4 -- Current test cases are good, but some small improvements could be made.
  • Test cases are too long -- 10+ seconds on my machine for some. That is single-iteration time, and should ideally be around 100 - 1000 ms.
  • Test cases should potentially have unrolled loops under the inner iteration count -- may not have a noticeable effect.
  • Test cases are dependent on inner iteration count. Some fail if it is changed because the expected results are based on operations which accumulate over the number of inner iterations. This isn't strictly "wrong", but it feels like the inner iteration count is something that you should be able to tweak without causing the tests to fail outright.

Coverage needed (order of importance):

• Vector / Vector<T>

• Matrix4x4

• Quaternion

• Matrix3x2

• Plane

• Vector2/3/4 could benefit from coverage on these methods, in order of importance (IMO):

  • Min / Max
  • Transform (at least one overload)
  • Lerp
  • Clamp
  • There are a handful of other operations which aren't covered on Vector2/3/4, but they did not seem very critical.

@tannergooding Thoughts on the prioritization above?

from performance.

I think the list above represents a good prioritization.

Test cases are dependent on inner iteration count.

I think the biggest issue here is that without consuming the output and without modifying the input values, the JIT can (and does in some of the cases) optimize away the call entirely.

I can think of a handful of other ways to ensure we consume the output and modify the input, but they generally involve doing something like storing the value in an array (which may be expensive enough in some cases to skew the results due to memory latency).

from performance.

@adamsitnik, should this be moved to dotnet/performance?

from performance.

should this be moved to dotnet/performance?

@tannergooding good idea! #done

from performance.