Speeding up Grim - Adding SIMD support

[Axionize]

As our codebase grows with more checks, performance has and will become increasingly important.

This code here provides the basic structure necessary to add support for running operations with SIMD, and falling back on scalar operations when they are available at no runtime performance cost even in cases where SIMD is not available. Java 18 is the minimum requirement.

There are many parts of the code that can/may have to be change in order to take full advantage of SIMD. This PR Draft does not do that.

If there's interest, I'll consider also updating this draft to include Project Panama native code setup as well. We can include or download a small native library at runtime and our fall back order would look something like Native Code (probably SIMD) -> Java SIMD -> Scalar

[AoElite]

That's a good idea

[Axionize]

How do people feel about using my existing Vector implementation (yes I know its slow, it's more about the interfaces and how it works)? Is everyone fine with using the factory to create new instances and static imports?

I know I could probably speed it up just a little by eliminating the casting but that would require treating people on scalar as Second class citizens.

I figured it would be worth it since people still run Xeon V1/V2s for Minecraft servers and the oldest machines with support for AVX-256 for doubles are Haswell chips from 2013 (Intel Core i7-4770K & Intel Xeon E5-2697 v3)

Key differences below: (rest are mostly just replacing existing usage of Bukkit Vectors)

• https://github.com/GrimAnticheat/Grim/pull/1841/files#diff-9d977bf910697b7ece45500d0365d3c4cf6cb5e9b7f95475e210380a01e42862
• https://github.com/GrimAnticheat/Grim/pull/1841/files#diff-436d8c7f4c7c1feb15333603d86fb0a1ba234c861ffa288ff9be2f6b87789f68
• https://github.com/GrimAnticheat/Grim/pull/1841/files#diff-07dd0d4ffbf27d16919886febf695b5760f9f32d1efb52b04beef82c240ad1c8
• https://github.com/GrimAnticheat/Grim/pull/1841/files#diff-ae3519fabba86a583fae404089854aa9616175210701a851c3dcacc840134b7a

EDIT: This would likely supersede #1765

[Axionize]

It seems Project Panama has abandoned allowing you to ignore safety for performance by directly calling a method with its memory address in Java 21 which somewhat embarrassingly means that all of the implementations here (with the exception of SIMD cross product on Project Panama) will probably be slower than Scalar unless we batch them. The overhead is just too high when you're doing operations that are measured in nanoseconds.

I'll probably write a NalimVector3D implementation later just to prove we can beat the JVM if we try hard enough when I have time and post benchmarks later.

[Axionize]

Benchmark                                      Mode  Cnt   Score    Error  Units
NalimVector3DBenchmark.benchmarkCrossProduct   avgt    3   5.622 ±  0.409  ns/op
SIMDVector3DBenchmark.benchmarkCrossProduct    avgt    3  19.063 ± 57.292  ns/op
ScalarVector3DBenchmark.benchmarkCrossProduct  avgt    3   5.466 ±  1.033  ns/op

As you can see for very simple/trivial functions like these the overhead of using these techniques is often not worth it. Even using Nalim with SIMD the cost of calling the C function is too high. For vectors batching is needed for it to be worth it.

In any case. This is not important; the goal of this draft is too add the right tooling to the project to take advantage of SIMD, and low overhead native code calls. I'll continue to update this draft with example code and project setup to make it easy to understand how to take advantage of these features for real performance gains.

[SergioK29]

seems gimmicky idk, you can optimize grims performance considerably before resorting to simd operations, its not like we are doing image manipulation here that simd is great at.