Can confirm the poor performance on small matrices (less than 20x20). This is a problem particularly for robotics applications when your entities are positions, velocities, etc.
Huh, interesting - this is news to me, as I use Eigen all the time/see it used all over for robotics. Is there a good replacement for robotics-specific operations/small matrices generally (I see some people mentioning DirectXMath?)? Or is the tradeoff just between spending the time and effort to write SIMD intrinsics yourself vs. lower performance but greater convenience with Eigen?
One advantage of Eigen's approach that I haven't seen mentioned here is that its templated design makes it easy to substitute custom scalar types for operations, which helps enable straightforward automatic differentiation and other such tools (e.g. I'm currently using Eigen to make a tracing JIT for computations like FK, etc. over scenegraphs).
One small downside of Blaze vs. Eigen for robotics is that Blaze seems to lack the highly convenient geometry types and operations that Eigen ships with. This wouldn't be difficult to build on top of Blaze (and could lead to some interesting performance comparisons), but does present some additional work necessary to use Blaze in many robotics applications.
glm is also good for 3d math. It mimics the API of OpenGL shaders, so it's a good option if you already know how to write shaders (or are interested in learning).
> when your entities are positions, velocities, etc.
For use cases where FP32 precision is enough, I usually use DirectXMath library https://github.com/Microsoft/DirectXMath for that. That thing is cross-platform in practice. Even when building things for ARM Linux, it’s easy to copy-paste required pieces, NEON support is there.
When I need FP64 precision on PCs, I usually proceed without libraries, using AVX intrinsics.
https://stackoverflow.com/questions/58071344/is-eigen-slow-a...