Benchmarks for Blaze, A high-performance C++ math library (opens in new tab)

If you are interested in C++14 then you are "looking to the future" as it were, in which case I would suggest Eigen. Why? One word: tensors. Eigen has already a quite usable tensor implementation, whereas as far as I can descry Blaze has no plans in that direction. Tensors show up everywhere in scientific computing. They are incredibly useful. For this reason (along with several others, which I can elaborate on if you are interested) I feel like Eigen will become the Numpy of C++ numerical array software in the future.

Eigen is header only and heavily templated, which certainly keeps the source down.

However, SLOC is a poor metric for the quality of a codebase, especially scientific ones. I've certainly found many instances where longer line counts are more performant, for instance with hand-unrolling loops (very rare edge case, not suggesting doing this as a rule!).

Unless you intend to become involved in development of the library, I see no reason you would care about the lines of code. Even at that point, design philosophy, features, etc. are more likely to be major factors in your choice.

FYI: Computational Scientist here. I am neither affiliated with Blaze nor Eigen.

I agree with Arcanus; lines of code isn't a good measurement here. It's not uncommon for high performance math and science libraries to have specialized code to handle a lot of different cases the fastest way possible, or the most accurate way possible, etc. and some libraries are even able to switch between them heuristically based on the data they're being used on.

A common example is matrix multiply. For smaller matrices it's faster to use naive O(n^3) multiply because of the large constant factor with Strassen's algorithm. At some point n^3 will dominate the constant factor, and Strassen's becomes better. To get the best performance in all cases, both algorithms need to be implemented, which increases the code size.

Take a look at Armadillo as well. I did the same thing about a year ago, and looked at all of them. In the end, Armadillo made writing things very easy. Of course, I was really only focused on matrix multiplication, so you may have different requirements.

Or the analog of the link in the OP, https://bitbucket.org/blaze-lib/blaze/wiki/Benchmarks

HN mods: could someone change the discussion to point to this link? It has working pictures.

Thanks!

Off-topic: I like bitbucket better, so it is nice to see some projects going over there.

Thanks, I tried finding the link to the Bitbucket repository but I had a hard time finding the link via Google.

For what problems? General statements like this are hard to back up, especially in the wild world of numerical linear algebra.

From my experience, there are currently no good distributed-memory open source sparse-direct solvers.

No good distributed-memory ILU implementation, either. Scalability is almost non-existant beyond 100 cores.

An old thread on the Eigen list also mentioned that the Blaze folks were a little tricky with their benchmarks. Some of the reported performance numbers with Blaze were for calls out to Intel MKL routines. Eigen also supports MKL as a kernel backend, but the Blaze folks failed to enable this feature for the reported comparisons, if I recall.

Yep. A 32KB L1 cache can hold at most 4000 doubles. 4000/(2 input vectors + 1 result) =1333.

http://danluu.com/3c-conflict/

I'm guessing that's the point at which the working set exceeds the L1 cache size. You can see a few more subtle dips in the performance graph at later points; these correspond to working set spilling out of the L2 and L3 caches.

Turns out that it does implement its own, but it also has the possibility of wrapping existing libraries:

https://bitbucket.org/blaze-lib/blaze/src/e09d62ee714745b297...

Of course, if you're seriously going to use this library, you're going to use an established BLAS library like OpenBLAS or Intel MKL.