Hacker News Reader

Comment by Const-me | Hacker News Reader

Using it for years, and mostly happy with that library. The performance is awesome for very long vectors / large matrices.

It’s less than ideal for small things when the size is known at compile-time. If one knows SIMD intrinsics, in some of these cases the Eigen’s implementation can be outperformed by a large factor like 2-4. Also it’s very hard to mess with RAM layout of some things (like sparse matrices), just too many layers of abstraction and too much template metaprogramming.

But still, out of the box the usability of Eigen is awesome. And until the code is written, debugged, integrated and benchmarked, it’s generally impossible to tell whether a particular algorithm gonna be a performance bottleneck. That’s why I’m mostly happy with the library.

View on HN

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.

https://stackoverflow.com/questions/58071344/is-eigen-slow-a...

No estoy de acuerdo con tus politicas

An other answer just debates wether that was a benchmarking issue

Multiple other users confirmed the results and that one answer's author never followed up.

> 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.

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).

Blaze [0] looks promising. There was a little discussion here [1] about it's comparison and performance, especially for small sizes.

[0] https://bitbucket.org/blaze-lib/blaze/src/master/

[1] https://bitbucket.org/blaze-lib/blaze/issues/266/blaze-vs-ei...

Thanks, this looks promising indeed! Especially because it similarly supports custom scalar types: https://bitbucket.org/blaze-lib/blaze/wiki/Vector%20and%20Ma...

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).

https://github.com/g-truc/glm

It may have improved recently -- I haven't measured -- but serial Eigen seems mostly a little less performant at plateau than optimized BLAS GEMM for reals, and about half as good for complex in results I've seen for v3.3. For multiplication/convolution of sufficiently small dimension matrices on x86 (aarch64 in development) you probably want libxsmm; it can be used header-only -- at least for C -- if that matters. I might guess Eigen does relatively better on L1 and L2 than BLAS libraries.

In my case Eigen is handling some 3000x3000 and bigger matrices. For these scenarios, it’s performance is about 98% of BLAS libraries, which is more than enough when combined with the ease and practicality of Eigen. It also handles RAM placement, so it doesn’t get affected by memory fragmentation.

Their current performance page is here [0].

[0]: https://eigen.tuxfamily.org/index.php?title=Performance_moni...

[0] still looks bad for complex (CGEMM, I assume). It doesn't have comparisons there, but Eigen's claim to be faster than any free BLAS is surely wrong. (I wouldn't doubt its similar if it has the right loop structure and prefetching, and a few percent is within the normal variance of HPC runs anyway, so not worth worry about.) Unfortunately it isn't convenient for me, not being clever enough for C++, but I've nothing against any good free linear algebra implementation for a platform I'm using.

What's "RAM placement" in this context?

I can't comment for performance of Eigen concerning complex calculations, since my work lives in the real domain.

On the other hand, Eigen didn't claim to be faster than any BLAS during my interaction with informational side of their website. Nowadays, I just get the latest version, update my code and directly reach for their reference guide.

However, being used by both CERN (in LHC ATLAS) and TensorFlow, I guess they're no slouch in terms of performance (it also genuinely amazed my heavy BLAS fan professor at my Jury when the performance numbers came up). Another plus is, Eigen's ability to be used in CUDA kernels (though I didn't try it yet).

On the other hand, they're insanely fast (almost BLAS fast in my experience) for what I'm doing, and it's really well optimized (shows when you use -O3, especially on the solvers side). Also, it has neat capabilities like dynamic matrices and instant submatrix access (you can get a submatrix of a matrix, or just patch in a submatrix in a single call).

About RAM placement: From my experience, code becomes overly dependent on non-fragmented memory when allocating big matrices and/or vectors naively (i.e. in a contiguous manner), and execution fails as the node you're running on (or your computer) gets busier with other code. Eigen counters this by intelligently dividing bigger matrices into smaller chunks, both optimizing the access time and reducing (or effectively eliminating from my experience) the risk of segmentation faults related to failed memory allocations due to not having not enough undivided space in the memory space.

> On the other hand, Eigen didn't claim to be faster than any BLAS during my interaction with informational side of their website.

It claims to be faster than any free BLAS in the FAQ (but talks about ATLAS and GotoBLAS there). Given how close GotoBLAS in the guise of OpenBLAS gets to peak performance for GEMM, that would be dubious without measuring 2/3 of OB DGEMM performance. I assume claims of speed are for when BLAS is actually providing it. (I'm too experienced to be susceptible to appeals to authority of HEP software!)

Thanks for explaining the memory thing. I'd hope HPC code wouldn't be subject to SEGVs due to memory allocation failing (for two reasons), but you typically want arrays on the stack and otherwise large pages to minimize TLB misses (per Goto).

I'm not intending to bash Eigen, happy if people can use performant free software.

That's interesting. I'd assume that a template library like Eigen would be most competitive for really small matrices and vectors of a known size -- it should have a fundamental advantage over something like MKL or BLIS, in that it can fully inline and unroll everything if it wants, right?

My guess it’s their deliberate design decision. It could be that most users of the library don’t care about small things.

About the template stuff, I think their main performance advantage over traditional BLAS is not even SIMD, it’s lazy evaluation. Expressions like x=a*b+c never compute the complete a*b matrix or vector. The a*b expression returns a small placeholder object on the stack, of a scary type with couple lines of template arguments in the type name. This way the complete expression runs without making temporary matrices, instead it streams data from all 3 arguments and only writes to memory once. And if the `x` is of the correct size already, it doesn’t call malloc/free.

Yeah, lazy evaluation/fusing operations is I think their best feature. Fixed interface BLAS has really good performance, but I mean, something as simple as DAXPBY is an extension. Selecting what functionality to super-optimize is hard for a fixed interface, and involves non-technical stuff like figuring out what subroutines people actually want.

I'm sure someone has already looked at this, but I wonder if Eigen can just somehow nab kernels directly from BLIS, haha.

This is called "expression templates" https://en.wikipedia.org/wiki/Expression_templates

Thank you for this. I wrote a small linear algebra library using intrinsics in C#, and my code was beating Eigen at the n<50 level, but I figured it was just some error of mine, so I never had the balls to make the claim publicly.

Any idea about perf diff between this and GLM? In Computer graphics my use case is with fixed 4x4 matrices and vec4s. Thanks!

I never really used GLM, but Eigen was substantially slower than DirectXMath https://github.com/microsoft/DirectXMath for these things. Despite the name, 99% of that library is OS agnostic, only a few small pieces (like perspective projection matrix formula) are specific to Direct3D. When enabled with corresponding macros, inline functions from that library normally compile into pretty efficient manually vectorized SSE, AVX or NEON code.

The only major issue, DirectXMath doesn’t support FP64 precision.

Last time I tried Eigen, it sucked for 4x4 matrices.

Could this be fixed with some template specialisation?

Eigen makes use of these already

Reply on news.ycombinator.com